From owner-seamoby@diameter.org  Mon Jul  2 14:13:32 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21204
	for <seamoby-archive@odin.ietf.org>; Mon, 2 Jul 2001 14:13:29 -0400 (EDT)
Received: (qmail 5330 invoked by alias); 2 Jul 2001 17:58:57 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5323 invoked by uid 200); 2 Jul 2001 17:58:56 -0000
Received: (qmail 5309 invoked from network); 2 Jul 2001 17:58:41 -0000
Received: from motgate2.mot.com (136.182.1.10)
  by c900656-a.plstn1.sfba.home.com with SMTP; 2 Jul 2001 17:58:41 -0000
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA06305 for <seamoby@cdma-2000.org>; Mon, 2 Jul 2001 11:10:15 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA17892 for <seamoby@cdma-2000.org>; Mon, 2 Jul 2001 11:10:15 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19)
	id <NKTASGM7>; Mon, 2 Jul 2001 13:10:14 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E3F@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Cedric Westphal'" <cedric@iprg.nokia.com>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: RE: [seamoby] [Issue] Support for Multi-Phase CT
Date: Mon, 2 Jul 2001 13:10:13 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

Cedric,

If proactive MUST be multiphasic, then reactive MUST be
multiphasic too, don't you think?

You are in more trouble (higher probability of loosing
packets) when you are doing reactive than when you are
doing proactive, so it is even more important that
you send "urgent context" earlier than other context, when 
you are doing reactive.

Madjid

-----Original Message-----
From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
Sent: Friday, June 29, 2001 6:40 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Pat Calhoun; seamoby@cdma-2000.org
Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT




Nakhjiri Madjid-MNAKHJI1 wrote:

> Hi cedric,
>
> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> Sent: Tuesday, June 26, 2001 9:35 AM
> To: Pat Calhoun
> Cc: Gary Kenward; seamoby@cdma-2000.org
> Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT
>
> I agree with this (the support for multi-phase ct proposal)
> and would actually go one step further:
>
> requirement: a proactive transfer MUST be multiphasic (so that accounting
> transfer can be transfered after the handoff and config transfer before
the
> handoff)
> a reactive transfer SHOULD be monophasic.
>
> MN>> I don't agree, I think it is actually more important to have
> a multiphasic CT for reactive than it is for proactive.
> If you had to wait for packet delivery until the end of CT
> (which I am not proposing) then
> You would loose more packets in reactive. Hence you should break
> CT into pieces. After sending the more urgent context, you could
> resume packet delivery and at the same time, take your time with
> less urgent context.

[cedric] I agree with the fact that reactive CT could be pluriphasic,
that's why it is a SHOULD, not a MUST.
Or are you saying that _all_ CT should be in several phases? Are you
proposing that 'CT, even reactive, MUST be in several phase'? I hope
not.

> and the distinction between proactive and reactive becomes one of a number
> of phases.
>
> MN>> yet another proactive/ reactive definition, please give us a
> break :)

[cedric] not a definition, a distinction ;).
Take care,

Cedric.

>
>
> Madjid
>
> Cedric.
>
> Pat Calhoun wrote:
>
> > On Fri, Jun 22, 2001 at 03:23:43PM -0400, Gary Kenward wrote:
> > >   I with you up until that last two paragraphs of the proposed new
texts.
> > > The second to last paragraph is editorial, and presumes much about the
> > > context,
> > > the ctp design and the implementation.
> >
> > ok, I am certainly open to suggestions.
> >
> > >   As for the last paragraph, I do not see the need to add priority to
CTP.
> > > It is already required that the receiving AR process the context in
the
> > > order received, and this yields the same result (priority can always
be
> > > translated to a measurable performance criteria, such as "processed
sooner"
> > > or "given more resources"). I do not see the utility of a "priority"
bit.
> > > Perhaps you could
> > > elaborate?
> >
> > This isn't a question of a bit. It has to do with sending critical CT
> > information that is REQUIRED in order to deliver a single packet to the
> > mobile. This could include HC state, session keys, etc. This state info
> > is sent first when a handoff is occuring.
> >
> > Later (say, 1+ seconds later) additional state is sent. Although this
> > info is important, it may only be necessary when doing things such as
> > generating accounting messages, which are infrequent, and not required
> > during the handoff process.
> >
> > >   Otherwise I have no problem with the additional requirement
(although I
> > > wonder what an operator would say about "accounting" being "low
priority"
> > > ;^}).
> >
> > :)
> >
> > PatC
> >
> > >
> > > Gary
> > >
> > >
> > > > -----Original Message-----
> > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> > > > Sent: Thursday, June 21, 2001 6:37 PM
> > > > To: seamoby@cdma-2000.org
> > > > Subject: [seamoby] [Issue] Support for Multi-Phase CT
> > > >
> > > >
> > > > Issue 5: Support for multi-phase CT
> > > >
> > > >      Submitter name: Pat Calhoun
> > > >      Submitter email address: pcalhoun@eng.sun.com
> > > >      Date first submitted: June 21,2001
> > > >      Reference:
> > > >      Comment type: T
> > > >      Priority: 1
> > > >      Section: 4.9
> > > >
> > > >      Rationale/Explanation of issue:
> > > >      The current requirement in section 4.9 states that a CT can
only
> > > >      occur once all of the state has been gathered. The CT protocol
> > > >      must allow for state to be transferred in phases, where the
high
> > > >      priority state (e.g. Header Compression, session keys) is sent
> > > >      first, and low priority items are sent at a later time (e.g.
> > > >      accounting information).
> > > >
> > > >      This would reduce the size of the high priority CT packets,
> > > >      lower the computational cost of processing the packet,
> > > > and decrease
> > > >      the handoff latency.
> > > >
> > > >      Requested change:
> > > >      Change 4.9 to state something like:
> > > >
> > > >      "4.9 Context information MAY be transferred in phases,
> > > > allowing for
> > > >      higher priority state to be sent first, and lower priority
> > > >      state to be sent at a later time.
> > > >
> > > >      The total cost of processing a smaller packet with high
priority
> > > >      state is smaller, and would decrease any latency
> > > > introduced by CT. Each
> > > >      CT profile would need to specify whether it is to be considered
> > > >      as a high or low priority state."
> > > >
> > > >      Proposal:
> > > >      Adopt the text above in the -01 version of the
> > > > requirements spec.
> > > >


From owner-seamoby@diameter.org  Mon Jul  2 14:17:04 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23643
	for <seamoby-archive@odin.ietf.org>; Mon, 2 Jul 2001 14:17:02 -0400 (EDT)
Received: (qmail 5522 invoked by alias); 2 Jul 2001 18:00:58 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5515 invoked by uid 200); 2 Jul 2001 18:00:58 -0000
Received: (qmail 5509 invoked from network); 2 Jul 2001 18:00:57 -0000
Received: from motgate4.mot.com (144.189.100.102)
  by c900656-a.plstn1.sfba.home.com with SMTP; 2 Jul 2001 18:00:57 -0000
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id LAA07092 for <seamoby@diameter.org>; Mon, 2 Jul 2001 11:12:33 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA19062 for <seamoby@diameter.org>; Mon, 2 Jul 2001 11:05:32 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19)
	id <NKTASG39>; Mon, 2 Jul 2001 13:12:32 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E40@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing
Date: Mon, 2 Jul 2001 13:12:31 -0500 
Sensitivity: Company-Confidential
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

I suggest we leave this as an open issue, until we meet in IETF.

Madjid 

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Friday, June 29, 2001 10:28 AM
To: 'seamoby'
Subject: [seamoby] Issue #4: Clear, unambiguous definitions missing
Sensitivity: Confidential


In the interest of moving the requirements forward, I support the change in
the
definitions of "reactive" and "proactive' proposed by Pat:


Reactive CT: The context transfer process which takes place subsequent 
to arrival of a MN's packet at the target AR 

Proactive CT: The context transfer process in which the required contexts 
are in place at the target AR  prior to the arrival of MN's packet at target
AR. 


Since these are "definitions" and not requirements, I assume that there is
room
for change as we delve into the design process.

For what it's worth . . .

Gary


From owner-seamoby@diameter.org  Mon Jul  2 14:53:46 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18200
	for <seamoby-archive@odin.ietf.org>; Mon, 2 Jul 2001 14:53:38 -0400 (EDT)
Received: (qmail 6817 invoked by alias); 2 Jul 2001 18:40:55 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6810 invoked by uid 200); 2 Jul 2001 18:40:55 -0000
Received: (qmail 6802 invoked from network); 2 Jul 2001 18:40:51 -0000
Received: from ftpbox.mot.com (129.188.136.101)
  by c900656-a.plstn1.sfba.home.com with SMTP; 2 Jul 2001 18:40:51 -0000
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id LAA27201 for <seamoby@cdma-2000.org>; Mon, 2 Jul 2001 11:52:27 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA11306 for <seamoby@cdma-2000.org>; Mon, 2 Jul 2001 11:52:26 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <N53Y4WXZ>; Mon, 2 Jul 2001 13:52:26 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E42@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Rajeev Koodli'" <rajeev@iprg.nokia.com>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
        "'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>
Subject: RE: FW: [seamoby] CT trigger or CT completion? was:  proactive an
	d re active CT definitions
Date: Mon, 2 Jul 2001 13:52:25 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Rajeev,

I actually asked this question long time ago and the answer that
I got was that CT is supposed to be AR-AR and handle AR changes
not AP changes. If you have a different interpretation, then please
let me know.

Pat, if I misunderstood the scope of CT, please let me know,
I thought CT is scoped handle AR-AR only.

So If my observation is current, I don't see a relevance to CT
in your argument below.
Change of L2 link without change of AR is not what CT is dealing with.


Now opening up the issue a bit, I think what we were discussing was
whether link establishment is the same as having the new AR as default
router, and I am not sure whether that is the case.

I see the link establishment as more of a L2 event and default router
as a L3 event, so I think they are simultanous. 

BTW, I need to go look at the MIPv6 draft again to see how they
define change of default there :)

Madjid
 


-----Original Message-----
From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
Sent: Thursday, June 28, 2001 5:51 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Pat Calhoun'; 'Charles E. Perkins'; 'seamoby@cdma-2000.org'
Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
and re active CT definitions



Hello madjid,


Nakhjiri Madjid-MNAKHJI1 wrote:

> Hi Rajeev,
>
> -Rajeev: I have a question here. Is it possible that you can establish a new
> L2
> and still not change your AR ? If yes, if you don't change AR, is there is
> still any CT ? Is this too naive ?
> It seems to me that the AR is the key entity (for our defintion) since that
> holds the feature contexts.
>
> MN>>> But without broadening the scope of CT, lets assume that CT is AR1-AR2
>
> (change of AR is part of the scenario)
>
> *So the discussion is what is difference between new-L2 establishment and
> change
> of default router. I say difference is the timing.*
>
>

Rajeev: Actually, I am not sure if this is all..If you only change APs and are
still with the same AR, you don't change your default router. So, the point is
that changing L2 does not necessarily constitute changing AR, independent of
time.


> The case that comes to my mind, when you change L2 but newAR is still not
> your default router, is say:
> MN is at new L2, but did not have time to sent binding update to
> the oldAR before moving, so its using new L2 to start the L3 routing
> change procedure, it does not have newAR as default router but
> has L2 with newAR.
>

Rajeev: The new AR needs an entry in its neighbor cache before it could forward
packets, including Binding Updates.


> The other case is, if it has obtained its new IP address through
> stateless autoconfiguration, but the new address is rejected by
> newAR, although MN has L2 with newAR.
>

Rajeev: In this case, it (the MN) has not completed acquiring an IP address
yet.

In both the two cases you mentioned, you are assuming that new L2 implies new
AR. This need not be the case. So, the only definitive point of reference is if
the MN changes its default AR.


>
> So you can base your proactive CT on *predictions* based on L2 information
> Do the proactive CT and manage to get your context over to newAR
>
>

[snip].

>
> Rajeev: There is IP router discovery that indicates to a node when some AR
> has
> become the default AR.
>
> Any CT that happens prior to this phase is "Pre"-something. This includes
> using
> L2 triggers etc. When none of this is possible, the MN realizes that it has
> changed its AR through router advertisements and does CT, which is
> "Post"-something. Sure there is delay here. It is a matter of
> classification,
> not debating performance.
> Anyway, let's see if we can resolve the previous question.
>
> MN>> as I said earlier, the important point is to cover all the scenarios.
> whether proactive is pre-A or Pre-B is not important, but I think using
> default router which is probably one of the absolute last things that
> happens in handover might not be very suitable and is at least as ambiguous
> as other definitions, so we should not be creating new ambiguous definitions
> everyday.
>

Rajeev: could you say why it is ambiguous and why is it not very suitable ?

Regards,

-Rajeev


>
> Madjid


From owner-seamoby@diameter.org  Mon Jul  2 15:01:15 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24157
	for <seamoby-archive@odin.ietf.org>; Mon, 2 Jul 2001 15:01:14 -0400 (EDT)
Received: (qmail 7353 invoked by alias); 2 Jul 2001 18:49:15 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 7347 invoked by uid 200); 2 Jul 2001 18:49:15 -0000
Received: (qmail 7342 invoked from network); 2 Jul 2001 18:49:13 -0000
Received: from motgate2.mot.com (136.182.1.10)
  by c900656-a.plstn1.sfba.home.com with SMTP; 2 Jul 2001 18:49:13 -0000
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id MAA05938 for <seamoby@cdma-2000.org>; Mon, 2 Jul 2001 12:00:49 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA14377 for <seamoby@cdma-2000.org>; Mon, 2 Jul 2001 11:53:48 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <MZY3KLR4>; Mon, 2 Jul 2001 14:00:48 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E43@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Rajeev Koodli'" <rajeev@iprg.nokia.com>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: Kulwinder Atwal <kulwinder.atwal@zucotto.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: RE: [seamoby] Issue 2: Make IP messages uniform
Date: Mon, 2 Jul 2001 14:00:36 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk



-----Original Message-----
From: Rajeev Koodli [mailto:rajeev@iprg.nokia.com]
Sent: Thursday, June 28, 2001 5:59 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: Kulwinder Atwal; 'Pat Calhoun'; seamoby@cdma-2000.org
Subject: Re: [seamoby] Issue 2: Make IP messages uniform


Nakhjiri Madjid-MNAKHJI1 wrote:

> Exactly. As soon as the MN detects that it has undergone handover, it
sends
> a
> message which includes BU as an encapsulation. The new AR sends the CT
> message
> towards the old AR and the BU towards the mobility agent.
> We proposed this (the message is SHIN) in our -smoothv6-.txt draft (in
> Pittsburgh IETF).
>
> MN>> Rajeev, sorry I have not read the draft, so I am trying
> to see if I understand this.
> Could you define: "MN detects it has undergone handover",
> is it L2 signals from oldAR, PrRtAdv, L2 establishment at newAR?
>

Rajeev: This is through router advertisements on the new link. Recall that
we
are focussing on the scenario where a MN lost its existing link and regained
another without time for anything such as fast handovers. Through router
advertisement, the MN recognizes that it is on a new AR. It *could* detect
that it has changed L2, but may not be able to ascertain that it has changed
its AR. Using router advertisements is definitive.

MN>> Rajeev, well, it would be interesting to see a network that just
admits the mobile on the new link without doing an admission control
and allocating resources for the mobile!!
What I mean, the new link need to first make a bunch of decisions
based on capacity, link conditions and so on, to accept the mobile.
So you can bet that if you have policy.. based admissions, you have
 that L2 trigger prior to a default router selection, don't you?

So we can do better than sitting and waiting for default router 
selection to wait for CT.

Madjid



From owner-seamoby@diameter.org  Mon Jul  2 15:09:42 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29338
	for <seamoby-archive@odin.ietf.org>; Mon, 2 Jul 2001 15:09:42 -0400 (EDT)
Received: (qmail 7946 invoked by alias); 2 Jul 2001 18:57:51 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 7940 invoked by uid 200); 2 Jul 2001 18:57:50 -0000
Received: (qmail 7935 invoked from network); 2 Jul 2001 18:57:48 -0000
Received: from motgate3.mot.com (144.189.100.103)
  by c900656-a.plstn1.sfba.home.com with SMTP; 2 Jul 2001 18:57:48 -0000
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate3.mot.com (motgate3 2.1) with ESMTP id MAA13734 for <seamoby@cdma-2000.org>; Mon, 2 Jul 2001 12:02:24 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id MAA21323 for <seamoby@cdma-2000.org>; Mon, 2 Jul 2001 12:09:20 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19)
	id <NKTAS2QJ>; Mon, 2 Jul 2001 14:09:19 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E44@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Rajeev Koodli <rajeev@IPRG.nokia.com>
Cc: Gary Kenward <gkenward@nortelnetworks.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'Charles E. Perkins'" <charliep@IPRG.nokia.com>,
        "'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>
Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive and
	 re active CT definitions
Date: Mon, 2 Jul 2001 14:09:19 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk



-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: Friday, June 29, 2001 1:06 PM
To: Rajeev Koodli
Cc: Gary Kenward; Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri
Madjid-MNAKHJI1'; 'Charles E. Perkins'; 'seamoby@cdma-2000.org'
Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
and re active CT definitions


On Thu, Jun 28, 2001 at 02:07:28PM -0700, Rajeev Koodli wrote:
> It is puzzling to me that you would agree with the logic and yet do not
> understand what constitutes IP router discovery! It is a procedure that
> all IP nodes do as part of bootstrapping their interfaces, including
> when they change networks. Simply put, if you changed AR, you would be
> doing router discovery. Who is proposing to add more messages over the
> air interface?

I believe what folks are talking about is that CT can occur before neighbor
discovery is even performed. This is true in the fast MIPv4 draft, and in
the newly advertised BETH draft for MIPv6. We cannot rule these scenarios
out.

MN>> Thanks, that is exactly my point, we don't have to wait for neighbor
discovery mechanism (knowing the default router included) to initiate CT.

Madjid


From owner-seamoby@diameter.org  Mon Jul  2 15:39:55 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17822
	for <seamoby-archive@odin.ietf.org>; Mon, 2 Jul 2001 15:39:53 -0400 (EDT)
Received: (qmail 8863 invoked by alias); 2 Jul 2001 19:26:32 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 8857 invoked by uid 200); 2 Jul 2001 19:26:31 -0000
Received: (qmail 8849 invoked from network); 2 Jul 2001 19:26:29 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 2 Jul 2001 19:26:29 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <NXCGAYX8>; Mon, 2 Jul 2001 15:37:28 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E04844556D@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        "'Cedric Westphal'" <cedric@iprg.nokia.com>
Cc: Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: CT reliability model was RE: [seamoby] [Issue] Support for Multi-
	Phase CT
Date: Mon, 2 Jul 2001 15:37:25 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

In the pre- and post- conditions you are serializing something that
clearly does not have to be.  From very basic reliability theory,
it is clear to that combining the CT with another essential message,
the HR_request is the proper optimization.

proof:

For components in series, the joint reliability is given by:

Rs = R1 * R2 * ... * Rk.

For components in parallel:

Let Uk = 1 - Rk, then

Rp = 1 - (U1 * U2);

Suppose that CT is CTr reliable and Handover is HOr reliable.

Then pre- and post- methods are:

Rpre_post = CTr * HOr reliable

and in handover CT is 

Rin = 1 - (Uct * Uho) reliable

Assuming Uct > .5 and Uho >> .5 to have a useable system, thus

Rin >> Rpre_post

So a "IN" handover CT is far more reliable than either pro- or reactive-.

QED


> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Monday, July 02, 2001 2:10 PM
> To: 'Cedric Westphal'; Nakhjiri Madjid-MNAKHJI1
> Cc: Pat Calhoun; seamoby@cdma-2000.org
> Subject: RE: [seamoby] [Issue] Support for Multi-Phase CT
> 
> 
> Cedric,
> 
> If proactive MUST be multiphasic, then reactive MUST be
> multiphasic too, don't you think?
> 
> You are in more trouble (higher probability of loosing
> packets) when you are doing reactive than when you are
> doing proactive, so it is even more important that
> you send "urgent context" earlier than other context, when 
> you are doing reactive.
> 
> Madjid
> 
> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
> Sent: Friday, June 29, 2001 6:40 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Pat Calhoun; seamoby@cdma-2000.org
> Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT
> 
> 
> 
> 
> Nakhjiri Madjid-MNAKHJI1 wrote:
> 
> > Hi cedric,
> >
> > -----Original Message-----
> > From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> > Sent: Tuesday, June 26, 2001 9:35 AM
> > To: Pat Calhoun
> > Cc: Gary Kenward; seamoby@cdma-2000.org
> > Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT
> >
> > I agree with this (the support for multi-phase ct proposal)
> > and would actually go one step further:
> >
> > requirement: a proactive transfer MUST be multiphasic (so 
> that accounting
> > transfer can be transfered after the handoff and config 
> transfer before
> the
> > handoff)
> > a reactive transfer SHOULD be monophasic.
> >
> > MN>> I don't agree, I think it is actually more important to have
> > a multiphasic CT for reactive than it is for proactive.
> > If you had to wait for packet delivery until the end of CT
> > (which I am not proposing) then
> > You would loose more packets in reactive. Hence you should break
> > CT into pieces. After sending the more urgent context, you could
> > resume packet delivery and at the same time, take your time with
> > less urgent context.
> 
> [cedric] I agree with the fact that reactive CT could be pluriphasic,
> that's why it is a SHOULD, not a MUST.
> Or are you saying that _all_ CT should be in several phases? Are you
> proposing that 'CT, even reactive, MUST be in several phase'? I hope
> not.
> 
> > and the distinction between proactive and reactive becomes 
> one of a number
> > of phases.
> >
> > MN>> yet another proactive/ reactive definition, please give us a
> > break :)
> 
> [cedric] not a definition, a distinction ;).
> Take care,
> 
> Cedric.
> 
> >
> >
> > Madjid
> >
> > Cedric.
> >
> > Pat Calhoun wrote:
> >
> > > On Fri, Jun 22, 2001 at 03:23:43PM -0400, Gary Kenward wrote:
> > > >   I with you up until that last two paragraphs of the 
> proposed new
> texts.
> > > > The second to last paragraph is editorial, and presumes 
> much about the
> > > > context,
> > > > the ctp design and the implementation.
> > >
> > > ok, I am certainly open to suggestions.
> > >
> > > >   As for the last paragraph, I do not see the need to 
> add priority to
> CTP.
> > > > It is already required that the receiving AR process 
> the context in
> the
> > > > order received, and this yields the same result 
> (priority can always
> be
> > > > translated to a measurable performance criteria, such 
> as "processed
> sooner"
> > > > or "given more resources"). I do not see the utility of 
> a "priority"
> bit.
> > > > Perhaps you could
> > > > elaborate?
> > >
> > > This isn't a question of a bit. It has to do with sending 
> critical CT
> > > information that is REQUIRED in order to deliver a single 
> packet to the
> > > mobile. This could include HC state, session keys, etc. 
> This state info
> > > is sent first when a handoff is occuring.
> > >
> > > Later (say, 1+ seconds later) additional state is sent. 
> Although this
> > > info is important, it may only be necessary when doing 
> things such as
> > > generating accounting messages, which are infrequent, and 
> not required
> > > during the handoff process.
> > >
> > > >   Otherwise I have no problem with the additional requirement
> (although I
> > > > wonder what an operator would say about "accounting" being "low
> priority"
> > > > ;^}).
> > >
> > > :)
> > >
> > > PatC
> > >
> > > >
> > > > Gary
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> > > > > Sent: Thursday, June 21, 2001 6:37 PM
> > > > > To: seamoby@cdma-2000.org
> > > > > Subject: [seamoby] [Issue] Support for Multi-Phase CT
> > > > >
> > > > >
> > > > > Issue 5: Support for multi-phase CT
> > > > >
> > > > >      Submitter name: Pat Calhoun
> > > > >      Submitter email address: pcalhoun@eng.sun.com
> > > > >      Date first submitted: June 21,2001
> > > > >      Reference:
> > > > >      Comment type: T
> > > > >      Priority: 1
> > > > >      Section: 4.9
> > > > >
> > > > >      Rationale/Explanation of issue:
> > > > >      The current requirement in section 4.9 states 
> that a CT can
> only
> > > > >      occur once all of the state has been gathered. 
> The CT protocol
> > > > >      must allow for state to be transferred in 
> phases, where the
> high
> > > > >      priority state (e.g. Header Compression, session 
> keys) is sent
> > > > >      first, and low priority items are sent at a 
> later time (e.g.
> > > > >      accounting information).
> > > > >
> > > > >      This would reduce the size of the high priority 
> CT packets,
> > > > >      lower the computational cost of processing the packet,
> > > > > and decrease
> > > > >      the handoff latency.
> > > > >
> > > > >      Requested change:
> > > > >      Change 4.9 to state something like:
> > > > >
> > > > >      "4.9 Context information MAY be transferred in phases,
> > > > > allowing for
> > > > >      higher priority state to be sent first, and 
> lower priority
> > > > >      state to be sent at a later time.
> > > > >
> > > > >      The total cost of processing a smaller packet with high
> priority
> > > > >      state is smaller, and would decrease any latency
> > > > > introduced by CT. Each
> > > > >      CT profile would need to specify whether it is 
> to be considered
> > > > >      as a high or low priority state."
> > > > >
> > > > >      Proposal:
> > > > >      Adopt the text above in the -01 version of the
> > > > > requirements spec.
> > > > >
> 


From owner-seamoby@diameter.org  Tue Jul  3 03:24:01 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10242
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 03:23:56 -0400 (EDT)
Received: (qmail 13640 invoked by alias); 3 Jul 2001 07:10:17 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 13634 invoked by uid 200); 3 Jul 2001 07:10:16 -0000
Received: (qmail 13628 invoked from network); 3 Jul 2001 07:10:15 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 07:10:15 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA11474;
	Tue, 3 Jul 2001 00:21:21 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f637LK025305;
	Tue, 3 Jul 2001 00:21:20 -0700
X-mProtect:  Tue, 3 Jul 2001 00:21:20 -0700 Nokia Silicon Valley Messaging Protection
Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdiykTRI; Tue, 03 Jul 2001 00:21:18 PDT
Message-ID: <3B417265.A8C21A89@iprg.nokia.com>
Date: Tue, 03 Jul 2001 00:21:09 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
CC: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for 
 Multi-Phase CT
References: <0DF9FBC42474A24CA50F7A27FB08E04844556D@meshpdc.meshnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Phil,

you are right. Even though I'd say discussing the phases of a proactive or a
reactive CT is premature since there is no clear understanding of what is
proactive or reactive.
About your serialization point, most of the pre or post condition have to be
considered with respect to having the newAR being default router, or the MN
receiving packets from the newAR (cf. those pro/reactive threads), not the
pre or post handover  signaling. So I am not sure we are talking about
the same thing.

Cedric.


Phillip Neumiller wrote:

> In the pre- and post- conditions you are serializing something that
> clearly does not have to be.  From very basic reliability theory,
> it is clear to that combining the CT with another essential message,
> the HR_request is the proper optimization.
>
> proof:
>
> For components in series, the joint reliability is given by:
>
> Rs = R1 * R2 * ... * Rk.
>
> For components in parallel:
>
> Let Uk = 1 - Rk, then
>
> Rp = 1 - (U1 * U2);
>
> Suppose that CT is CTr reliable and Handover is HOr reliable.
>
> Then pre- and post- methods are:
>
> Rpre_post = CTr * HOr reliable
>
> and in handover CT is
>
> Rin = 1 - (Uct * Uho) reliable
>
> Assuming Uct > .5 and Uho >> .5 to have a useable system, thus
>
> Rin >> Rpre_post
>
> So a "IN" handover CT is far more reliable than either pro- or reactive-.
>
> QED
>
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> > Sent: Monday, July 02, 2001 2:10 PM
> > To: 'Cedric Westphal'; Nakhjiri Madjid-MNAKHJI1
> > Cc: Pat Calhoun; seamoby@cdma-2000.org
> > Subject: RE: [seamoby] [Issue] Support for Multi-Phase CT
> >
> >
> > Cedric,
> >
> > If proactive MUST be multiphasic, then reactive MUST be
> > multiphasic too, don't you think?
> >
> > You are in more trouble (higher probability of loosing
> > packets) when you are doing reactive than when you are
> > doing proactive, so it is even more important that
> > you send "urgent context" earlier than other context, when
> > you are doing reactive.
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
> > Sent: Friday, June 29, 2001 6:40 AM
> > To: Nakhjiri Madjid-MNAKHJI1
> > Cc: Pat Calhoun; seamoby@cdma-2000.org
> > Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT
> >
> >
> >
> >
> > Nakhjiri Madjid-MNAKHJI1 wrote:
> >
> > > Hi cedric,
> > >
> > > -----Original Message-----
> > > From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> > > Sent: Tuesday, June 26, 2001 9:35 AM
> > > To: Pat Calhoun
> > > Cc: Gary Kenward; seamoby@cdma-2000.org
> > > Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT
> > >
> > > I agree with this (the support for multi-phase ct proposal)
> > > and would actually go one step further:
> > >
> > > requirement: a proactive transfer MUST be multiphasic (so
> > that accounting
> > > transfer can be transfered after the handoff and config
> > transfer before
> > the
> > > handoff)
> > > a reactive transfer SHOULD be monophasic.
> > >
> > > MN>> I don't agree, I think it is actually more important to have
> > > a multiphasic CT for reactive than it is for proactive.
> > > If you had to wait for packet delivery until the end of CT
> > > (which I am not proposing) then
> > > You would loose more packets in reactive. Hence you should break
> > > CT into pieces. After sending the more urgent context, you could
> > > resume packet delivery and at the same time, take your time with
> > > less urgent context.
> >
> > [cedric] I agree with the fact that reactive CT could be pluriphasic,
> > that's why it is a SHOULD, not a MUST.
> > Or are you saying that _all_ CT should be in several phases? Are you
> > proposing that 'CT, even reactive, MUST be in several phase'? I hope
> > not.
> >
> > > and the distinction between proactive and reactive becomes
> > one of a number
> > > of phases.
> > >
> > > MN>> yet another proactive/ reactive definition, please give us a
> > > break :)
> >
> > [cedric] not a definition, a distinction ;).
> > Take care,
> >
> > Cedric.
> >
> > >
> > >
> > > Madjid
> > >
> > > Cedric.
> > >
> > > Pat Calhoun wrote:
> > >
> > > > On Fri, Jun 22, 2001 at 03:23:43PM -0400, Gary Kenward wrote:
> > > > >   I with you up until that last two paragraphs of the
> > proposed new
> > texts.
> > > > > The second to last paragraph is editorial, and presumes
> > much about the
> > > > > context,
> > > > > the ctp design and the implementation.
> > > >
> > > > ok, I am certainly open to suggestions.
> > > >
> > > > >   As for the last paragraph, I do not see the need to
> > add priority to
> > CTP.
> > > > > It is already required that the receiving AR process
> > the context in
> > the
> > > > > order received, and this yields the same result
> > (priority can always
> > be
> > > > > translated to a measurable performance criteria, such
> > as "processed
> > sooner"
> > > > > or "given more resources"). I do not see the utility of
> > a "priority"
> > bit.
> > > > > Perhaps you could
> > > > > elaborate?
> > > >
> > > > This isn't a question of a bit. It has to do with sending
> > critical CT
> > > > information that is REQUIRED in order to deliver a single
> > packet to the
> > > > mobile. This could include HC state, session keys, etc.
> > This state info
> > > > is sent first when a handoff is occuring.
> > > >
> > > > Later (say, 1+ seconds later) additional state is sent.
> > Although this
> > > > info is important, it may only be necessary when doing
> > things such as
> > > > generating accounting messages, which are infrequent, and
> > not required
> > > > during the handoff process.
> > > >
> > > > >   Otherwise I have no problem with the additional requirement
> > (although I
> > > > > wonder what an operator would say about "accounting" being "low
> > priority"
> > > > > ;^}).
> > > >
> > > > :)
> > > >
> > > > PatC
> > > >
> > > > >
> > > > > Gary
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> > > > > > Sent: Thursday, June 21, 2001 6:37 PM
> > > > > > To: seamoby@cdma-2000.org
> > > > > > Subject: [seamoby] [Issue] Support for Multi-Phase CT
> > > > > >
> > > > > >
> > > > > > Issue 5: Support for multi-phase CT
> > > > > >
> > > > > >      Submitter name: Pat Calhoun
> > > > > >      Submitter email address: pcalhoun@eng.sun.com
> > > > > >      Date first submitted: June 21,2001
> > > > > >      Reference:
> > > > > >      Comment type: T
> > > > > >      Priority: 1
> > > > > >      Section: 4.9
> > > > > >
> > > > > >      Rationale/Explanation of issue:
> > > > > >      The current requirement in section 4.9 states
> > that a CT can
> > only
> > > > > >      occur once all of the state has been gathered.
> > The CT protocol
> > > > > >      must allow for state to be transferred in
> > phases, where the
> > high
> > > > > >      priority state (e.g. Header Compression, session
> > keys) is sent
> > > > > >      first, and low priority items are sent at a
> > later time (e.g.
> > > > > >      accounting information).
> > > > > >
> > > > > >      This would reduce the size of the high priority
> > CT packets,
> > > > > >      lower the computational cost of processing the packet,
> > > > > > and decrease
> > > > > >      the handoff latency.
> > > > > >
> > > > > >      Requested change:
> > > > > >      Change 4.9 to state something like:
> > > > > >
> > > > > >      "4.9 Context information MAY be transferred in phases,
> > > > > > allowing for
> > > > > >      higher priority state to be sent first, and
> > lower priority
> > > > > >      state to be sent at a later time.
> > > > > >
> > > > > >      The total cost of processing a smaller packet with high
> > priority
> > > > > >      state is smaller, and would decrease any latency
> > > > > > introduced by CT. Each
> > > > > >      CT profile would need to specify whether it is
> > to be considered
> > > > > >      as a high or low priority state."
> > > > > >
> > > > > >      Proposal:
> > > > > >      Adopt the text above in the -01 version of the
> > > > > > requirements spec.
> > > > > >
> >



From owner-seamoby@diameter.org  Tue Jul  3 03:56:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01212
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 03:56:09 -0400 (EDT)
Received: (qmail 14157 invoked by alias); 3 Jul 2001 07:43:43 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 14151 invoked by uid 200); 3 Jul 2001 07:43:42 -0000
Received: (qmail 14146 invoked from network); 3 Jul 2001 07:43:41 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 07:43:41 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA12492;
	Tue, 3 Jul 2001 00:54:49 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f637smf07711;
	Tue, 3 Jul 2001 00:54:48 -0700
X-mProtect:  Tue, 3 Jul 2001 00:54:48 -0700 Nokia Silicon Valley Messaging Protection
Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdEcK67j; Tue, 03 Jul 2001 00:54:46 PDT
Message-ID: <3B417A3A.4A24ECFB@iprg.nokia.com>
Date: Tue, 03 Jul 2001 00:54:34 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
CC: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'seamoby'" <seamoby@diameter.org>, charliep@IPRG.nokia.com
Subject: Re: [seamoby] Issue #4: Clear, unambiguous definitions missing
References: <35DBB8B7AC89D4118E98009027B1009B017A9E40@IL27EXM10.cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sorry to breach the truce, but here are some comments:

Nakhjiri Madjid-MNAKHJI1 wrote:

> I suggest we leave this as an open issue, until we meet in IETF.
>
> Madjid
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Friday, June 29, 2001 10:28 AM
> To: 'seamoby'
> Subject: [seamoby] Issue #4: Clear, unambiguous definitions missing
> Sensitivity: Confidential
>
> In the interest of moving the requirements forward, I support the change in
> the
> definitions of "reactive" and "proactive' proposed by Pat:
>
> Reactive CT: The context transfer process which takes place subsequent
> to arrival of a MN's packet at the target AR
>
> Proactive CT: The context transfer process in which the required contexts
> are in place at the target AR  prior to the arrival of MN's packet at target
> AR.
>

reactive sounds good to me, but not proactive. There is a consensus for support
for several phases in CT. So it seems that the term 'required' needs to be
clarified.
In the CT phases discussion, the talk is about priority. Some contexts are more
important than other. Which is true, but mostly some contexts are more time
sensitive
than other. Some accounting contexts, which some operator would argue is _very_
important, can arrive later, after the arrival of MN's packet at new AR. This
requirement denies this possibility.

Solutions: 1) define a static context (configuration state) and a dynamic
context (accounting
state). Static context is what has to be transfered before the arrival of MN's
packet
at target AR. Replace 'required' in your definition by 'static', or 'config'.
Dynamic is what
can be transfered later to fill in the blanks. I have some text on this if you
want.

-or-

2) one of the issues with proactive/reactive is that it connotes a
serialization. pro/before, re/after.
There seems to be somewhat of a consensus as to before what and after what
(having the
newAR default router, or having the newAR receiving packets from the MN).
For instance in this proposal, the whole transfer has to be performed _before_
(prior in the
text) the arrival of MN's packet at newAR. Other proposals: pre-handoff,
post-handoff, same
thing. Charlie's proposal: reactive, predictive, also same thing.
On the other hand, CT can be initiated before/after, and completed before/after.
So, if you take
away the initiated after/completed before, you still need at least THREE terms.
There is also a consensus on reactive: initiated after/completed after. The
issue is with proactive,
which means before, and has to cover the CT completed *after* case, which is
somewhat
counter-intuitive.
So here is yet another proposal, which borrows the handoff terminology, and is
in everybody's
dictionnary:
hard CT = reactive CT
soft CT = a CT in which the transfer is initiated before the arrival of MN's
packet at the target
AR. (no mention of completion, covers the initiated before, completed before or
after case).
proactive CT= the definition up this mail (covers the initiated before/completed
before case).

Cheers,

Cedric.

>
> Since these are "definitions" and not requirements, I assume that there is
> room
> for change as we delve into the design process.
>
> For what it's worth . . .
>
> Gary



From owner-seamoby@diameter.org  Tue Jul  3 08:26:14 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21242
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 08:26:11 -0400 (EDT)
Received: (qmail 15095 invoked by alias); 3 Jul 2001 12:13:35 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15089 invoked by uid 200); 3 Jul 2001 12:13:34 -0000
Received: (qmail 15084 invoked from network); 3 Jul 2001 12:13:32 -0000
Received: from sj-msg-core-4.cisco.com (171.71.163.10)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 12:13:32 -0000
Received: from oranlt (oran-frame8.cisco.com [10.84.15.9])
	by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f63CO8r15921;
	Tue, 3 Jul 2001 05:24:08 -0700 (PDT)
From: "David R. Oran" <oran@cisco.com>
To: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>,
        "'Rajeev Koodli'" <rajeev@IPRG.nokia.com>
Cc: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'Charles E. Perkins'" <charliep@IPRG.nokia.com>,
        <seamoby@cdma-2000.org>
Subject: RE: FW: [seamoby] CT trigger or CT completion? was:  proactive and re active CT definitions
Date: Tue, 3 Jul 2001 08:29:24 -0400
Organization: Cisco Systems
Message-ID: <005601c103bb$cc0ee360$090f540a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B017A9E28@IL27EXM10.cig.mot.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2462.0000
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sorry for joining in late. Just a small comment. While I generally like
the idea of explaining the initiation and state management for context
transfer in terms of mobile link establishment, it is very important to
keep in mind that mobile link establishment may not be symmetric or
atomic with respect the the context transfer state machines. I think we
need to consider the definitions and overall model as if there were FOUR
links, not two:
 - old downlink
 - old uplink
 - new downlink
 - new uplink

It seems to me you usually can't start context transfer until the new
downlink is operational, at least at layer 2, (since the mobile doesn't
know really where it might move until then), and you need to complete
context transfer soon after the new uplink is operational, or you don't
get much benefit.

Perhaps if we talked in terms of these four links, plus the link
betweeen oldAR and newAR (which we can probably treat as symmetric
because it's on the non-mobile part of the net) we can more directly
discuss the timing and state machines for context transfer rather than
relying on somewhat slippery notions like "proactive" versus "reactive".

One exception to the above that may be worth at covering at least for
completeness, is true "predictive" context transfer, where the system
tries to predict where the mobile might show up before it even tries to
move. The model should not preclude that option, impractical as it may
be on some wireless systems.

Dave.

> -----Original Message-----
> From: owner-seamoby@diameter.org 
> [mailto:owner-seamoby@diameter.org] On Behalf Of Nakhjiri 
> Madjid-MNAKHJI1
> Sent: Thursday, June 28, 2001 11:58 AM
> To: 'Pat Calhoun'; Rajeev Koodli
> Cc: Kulwinder Atwal; Nakhjiri Madjid-MNAKHJI1; 'Charles E. 
> Perkins'; 'seamoby@cdma-2000.org'
> Subject: RE: FW: [seamoby] CT trigger or CT completion? was: 
> proactive and re active CT definitions
> 
> 
> I don't like this one, I seem to be chasing a moving target 
> (definition of 
> reactive, proactive). Last week we were talking about whether 
> to use link establishment or not, this week it is about 
> default router.
> 
> I started to like Charlie's definition based on link 
> establishment, (however, we accepted that by link we are 
> talking about L2) since L2 establishment is more crisp than 
> completed handover. and we explored different cases, so we 
> don't miss all the cases. The draft versus Charlie's 
> definition of reactive/ proactive 
> definitions in the two turned out to cover different
> set of scenarios without changing the outcome too much. 
> 
>  I don't see how this new definition that pop up everyday are 
> making the CT better.
> 
> I am the newAR, How long do I have to wait until I make sure 
> I am the default router, say in a FMIPv6 case: until I get
> the NA and make sure MN has a valid newCoA?
> What if the MN still has to use its oldCoA and a tunnel 
> between newAR and oldAR, how long do I have to wait to start CT, this 
> introduces unnecessary delay for CT.
> 
> Another confusing thing is folks on the list keep using their 
> own favorite words and definitions in the continuing 
> conversations without paying attention what the other ends 
> understanding of that word is,
> 
> Lets finish off the link establishment discussion and if it
> is not good enough, see what is better, the way it is going
> I am not sure we are making a lot of progress in wrapping things up.
> 
> Madjid
> 
> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Thursday, June 28, 2001 8:36 AM
> To: Rajeev Koodli
> Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri 
> Madjid-MNAKHJI1'; 'Charles E. Perkins'; 'seamoby@cdma-2000.org'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: 
> proactive and re active CT definitions
> 
> 
> > > How is this:
> > >
> > > Pre-Handoff Context Transfer: The Context Transfer is initiated 
> > > prior to
> the
> > > newAR becomes the MN's default router.
> > >
> > > Post-Handoff Context Transfer:  The Context Transfer is initiated 
> > > after
> the
> > > newAR becomes the MN's default router.
> > >
> > > -Kulwinder.
> > >
> > >
> > 
> > Rajeev: This would work for me.  May be we should ask PatC on how to
> proceed
> > next?
> 
> what do folks think about using this terminology? Is this 
> preferred over the existing terminology in the draft?
> 
> PatC
> 



From owner-seamoby@diameter.org  Tue Jul  3 08:37:32 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27530
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 08:37:31 -0400 (EDT)
Received: (qmail 15592 invoked by alias); 3 Jul 2001 12:25:46 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15586 invoked by uid 200); 3 Jul 2001 12:25:46 -0000
Received: (qmail 15578 invoked from network); 3 Jul 2001 12:25:45 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 12:25:45 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <NXCGAZ1X>; Tue, 3 Jul 2001 08:36:52 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445575@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'David R. Oran'" <oran@cisco.com>,
        "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>,
        "'Rajeev Koodli'" <rajeev@IPRG.nokia.com>
Cc: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'Charles E. Perkins'" <charliep@IPRG.nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: FW: [seamoby] CT trigger or CT completion? was:  proactive an
	d re active CT definitions
Date: Tue, 3 Jul 2001 08:36:42 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hello,

I agree with Dave, except OF COURSE I would like to generalize
this to the following:

> -----Original Message-----
> From: David R. Oran [mailto:oran@cisco.com]
> Sent: Tuesday, July 03, 2001 8:29 AM

  - old downlink SET
  - old uplink SET
  - new downlink SET
  - new uplink SET

Where the operations add/drop downlink Lk to downlink SET
and add/drop uplink Lj to uplink SET are assumed.  This would
cover radios that support multiple active link layers, like
those used in 3GPP, 3GPP2, 4G RF, and RF used in MANETS.

Please consider this.  Even if you don't use macroscopic 
diversity (i.e. have an SDU in your RAN for example) this
approach still adds flexibility to the design.

Thanks,

Phil Neumiller 
Mesh Networks, Inc.


From owner-seamoby@diameter.org  Tue Jul  3 09:51:05 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11768
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 09:50:48 -0400 (EDT)
Received: (qmail 16164 invoked by alias); 3 Jul 2001 13:31:57 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16158 invoked by uid 200); 3 Jul 2001 13:31:56 -0000
Received: (qmail 16153 invoked from network); 3 Jul 2001 13:31:55 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 13:31:55 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f63Dgg013530
	for <seamoby@cdma-2000.org>; Tue, 3 Jul 2001 09:42:43 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Tue, 3 Jul 2001 09:42:44 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <NZ9SAKCJ>; Tue, 3 Jul 2001 09:42:46 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DBA@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>
Cc: seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
         Phase CT
Date: Tue, 3 Jul 2001 09:42:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C103C6.0723F710"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C103C6.0723F710
Content-Type: text/plain;
	charset="iso-8859-1"

Phil:

  I confess I am confused as to why people keep suggesting that
"proactive" and "reactive" are serial to anything. It has been
stated, many times over, that, ideally, ct overlaps ho. Of course,
one can never prevent the situation where ct has to happen after
ho (although one could argue whether it was worth doing or not).

  I use the term "overlap" specifically, because there are no
absolute events that tie ct and ho together. In some networks,
one can arrange for L2 events to signal that an MN is "visible"
to a new set of base stations, and possibly to a new AR. In 
other networks, and possibly in inter-technology handovers, it
will be necessary to rely upon L3 messaging (from somewhere to
somewhere).

  Tying ct to ho messaging explicitly, would at this point 
limit the value of a proactive/predictive/anticipatory/prophylactic 
approach to context transfer. 

  I do believe there is value in "bundling" application messages
into one transport (i.e. putting some portion of ct with the ho
message), as long as we can do it without making ct MIP dependent.
All in all, this discussion is premature, as we are trying to
get through the requirements, and one of the requirements cannot
be that ct message y = ho message x. This is more then just idealism
on my part: while we may all have our respective ideas about what
the ct protocol looks like, none of us knows what the wg version of
the protocol will turn out to be once we put our collective knowledge
together.

  Finally, just to avoid confusion: you are correct, absolutely, 
serialization is a bad approach.

Gary

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Monday, July 02, 2001 3:37 PM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric Westphal'
> Cc: Pat Calhoun; seamoby@cdma-2000.org
> Subject: CT reliability model was RE: [seamoby] [Issue] Support for
> Multi- Phase CT
> 
> 
> In the pre- and post- conditions you are serializing something that
> clearly does not have to be.  From very basic reliability theory,
> it is clear to that combining the CT with another essential message,
> the HR_request is the proper optimization.
> 
> proof:
> 
> For components in series, the joint reliability is given by:
> 
> Rs = R1 * R2 * ... * Rk.
> 
> For components in parallel:
> 
> Let Uk = 1 - Rk, then
> 
> Rp = 1 - (U1 * U2);
> 
> Suppose that CT is CTr reliable and Handover is HOr reliable.
> 
> Then pre- and post- methods are:
> 
> Rpre_post = CTr * HOr reliable
> 
> and in handover CT is 
> 
> Rin = 1 - (Uct * Uho) reliable
> 
> Assuming Uct > .5 and Uho >> .5 to have a useable system, thus
> 
> Rin >> Rpre_post
> 
> So a "IN" handover CT is far more reliable than either pro- 
> or reactive-.
> 
> QED
> 
> 
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> > Sent: Monday, July 02, 2001 2:10 PM
> > To: 'Cedric Westphal'; Nakhjiri Madjid-MNAKHJI1
> > Cc: Pat Calhoun; seamoby@cdma-2000.org
> > Subject: RE: [seamoby] [Issue] Support for Multi-Phase CT
> > 
> > 
> > Cedric,
> > 
> > If proactive MUST be multiphasic, then reactive MUST be
> > multiphasic too, don't you think?
> > 
> > You are in more trouble (higher probability of loosing
> > packets) when you are doing reactive than when you are
> > doing proactive, so it is even more important that
> > you send "urgent context" earlier than other context, when 
> > you are doing reactive.
> > 
> > Madjid
> > 
> > -----Original Message-----
> > From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
> > Sent: Friday, June 29, 2001 6:40 AM
> > To: Nakhjiri Madjid-MNAKHJI1
> > Cc: Pat Calhoun; seamoby@cdma-2000.org
> > Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT
> > 
> > 
> > 
> > 
> > Nakhjiri Madjid-MNAKHJI1 wrote:
> > 
> > > Hi cedric,
> > >
> > > -----Original Message-----
> > > From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> > > Sent: Tuesday, June 26, 2001 9:35 AM
> > > To: Pat Calhoun
> > > Cc: Gary Kenward; seamoby@cdma-2000.org
> > > Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT
> > >
> > > I agree with this (the support for multi-phase ct proposal)
> > > and would actually go one step further:
> > >
> > > requirement: a proactive transfer MUST be multiphasic (so 
> > that accounting
> > > transfer can be transfered after the handoff and config 
> > transfer before
> > the
> > > handoff)
> > > a reactive transfer SHOULD be monophasic.
> > >
> > > MN>> I don't agree, I think it is actually more important to have
> > > a multiphasic CT for reactive than it is for proactive.
> > > If you had to wait for packet delivery until the end of CT
> > > (which I am not proposing) then
> > > You would loose more packets in reactive. Hence you should break
> > > CT into pieces. After sending the more urgent context, you could
> > > resume packet delivery and at the same time, take your time with
> > > less urgent context.
> > 
> > [cedric] I agree with the fact that reactive CT could be 
> pluriphasic,
> > that's why it is a SHOULD, not a MUST.
> > Or are you saying that _all_ CT should be in several phases? Are you
> > proposing that 'CT, even reactive, MUST be in several phase'? I hope
> > not.
> > 
> > > and the distinction between proactive and reactive becomes 
> > one of a number
> > > of phases.
> > >
> > > MN>> yet another proactive/ reactive definition, please give us a
> > > break :)
> > 
> > [cedric] not a definition, a distinction ;).
> > Take care,
> > 
> > Cedric.
> > 
> > >
> > >
> > > Madjid
> > >
> > > Cedric.
> > >
> > > Pat Calhoun wrote:
> > >
> > > > On Fri, Jun 22, 2001 at 03:23:43PM -0400, Gary Kenward wrote:
> > > > >   I with you up until that last two paragraphs of the 
> > proposed new
> > texts.
> > > > > The second to last paragraph is editorial, and presumes 
> > much about the
> > > > > context,
> > > > > the ctp design and the implementation.
> > > >
> > > > ok, I am certainly open to suggestions.
> > > >
> > > > >   As for the last paragraph, I do not see the need to 
> > add priority to
> > CTP.
> > > > > It is already required that the receiving AR process 
> > the context in
> > the
> > > > > order received, and this yields the same result 
> > (priority can always
> > be
> > > > > translated to a measurable performance criteria, such 
> > as "processed
> > sooner"
> > > > > or "given more resources"). I do not see the utility of 
> > a "priority"
> > bit.
> > > > > Perhaps you could
> > > > > elaborate?
> > > >
> > > > This isn't a question of a bit. It has to do with sending 
> > critical CT
> > > > information that is REQUIRED in order to deliver a single 
> > packet to the
> > > > mobile. This could include HC state, session keys, etc. 
> > This state info
> > > > is sent first when a handoff is occuring.
> > > >
> > > > Later (say, 1+ seconds later) additional state is sent. 
> > Although this
> > > > info is important, it may only be necessary when doing 
> > things such as
> > > > generating accounting messages, which are infrequent, and 
> > not required
> > > > during the handoff process.
> > > >
> > > > >   Otherwise I have no problem with the additional requirement
> > (although I
> > > > > wonder what an operator would say about "accounting" 
> being "low
> > priority"
> > > > > ;^}).
> > > >
> > > > :)
> > > >
> > > > PatC
> > > >
> > > > >
> > > > > Gary
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> > > > > > Sent: Thursday, June 21, 2001 6:37 PM
> > > > > > To: seamoby@cdma-2000.org
> > > > > > Subject: [seamoby] [Issue] Support for Multi-Phase CT
> > > > > >
> > > > > >
> > > > > > Issue 5: Support for multi-phase CT
> > > > > >
> > > > > >      Submitter name: Pat Calhoun
> > > > > >      Submitter email address: pcalhoun@eng.sun.com
> > > > > >      Date first submitted: June 21,2001
> > > > > >      Reference:
> > > > > >      Comment type: T
> > > > > >      Priority: 1
> > > > > >      Section: 4.9
> > > > > >
> > > > > >      Rationale/Explanation of issue:
> > > > > >      The current requirement in section 4.9 states 
> > that a CT can
> > only
> > > > > >      occur once all of the state has been gathered. 
> > The CT protocol
> > > > > >      must allow for state to be transferred in 
> > phases, where the
> > high
> > > > > >      priority state (e.g. Header Compression, session 
> > keys) is sent
> > > > > >      first, and low priority items are sent at a 
> > later time (e.g.
> > > > > >      accounting information).
> > > > > >
> > > > > >      This would reduce the size of the high priority 
> > CT packets,
> > > > > >      lower the computational cost of processing the packet,
> > > > > > and decrease
> > > > > >      the handoff latency.
> > > > > >
> > > > > >      Requested change:
> > > > > >      Change 4.9 to state something like:
> > > > > >
> > > > > >      "4.9 Context information MAY be transferred in phases,
> > > > > > allowing for
> > > > > >      higher priority state to be sent first, and 
> > lower priority
> > > > > >      state to be sent at a later time.
> > > > > >
> > > > > >      The total cost of processing a smaller packet with high
> > priority
> > > > > >      state is smaller, and would decrease any latency
> > > > > > introduced by CT. Each
> > > > > >      CT profile would need to specify whether it is 
> > to be considered
> > > > > >      as a high or low priority state."
> > > > > >
> > > > > >      Proposal:
> > > > > >      Adopt the text above in the -01 version of the
> > > > > > requirements spec.
> > > > > >
> > 
> 

------_=_NextPart_001_01C103C6.0723F710
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: CT reliability model was RE: [seamoby] [Issue] Support for Multi-  Phase CT</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Phil:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I confess I am confused as to why people keep suggesting that</FONT>
<BR><FONT SIZE=2>&quot;proactive&quot; and &quot;reactive&quot; are serial to anything. It has been</FONT>
<BR><FONT SIZE=2>stated, many times over, that, ideally, ct overlaps ho. Of course,</FONT>
<BR><FONT SIZE=2>one can never prevent the situation where ct has to happen after</FONT>
<BR><FONT SIZE=2>ho (although one could argue whether it was worth doing or not).</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I use the term &quot;overlap&quot; specifically, because there are no</FONT>
<BR><FONT SIZE=2>absolute events that tie ct and ho together. In some networks,</FONT>
<BR><FONT SIZE=2>one can arrange for L2 events to signal that an MN is &quot;visible&quot;</FONT>
<BR><FONT SIZE=2>to a new set of base stations, and possibly to a new AR. In </FONT>
<BR><FONT SIZE=2>other networks, and possibly in inter-technology handovers, it</FONT>
<BR><FONT SIZE=2>will be necessary to rely upon L3 messaging (from somewhere to</FONT>
<BR><FONT SIZE=2>somewhere).</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Tying ct to ho messaging explicitly, would at this point </FONT>
<BR><FONT SIZE=2>limit the value of a proactive/predictive/anticipatory/prophylactic </FONT>
<BR><FONT SIZE=2>approach to context transfer. </FONT>
</P>

<P><FONT SIZE=2>&nbsp; I do believe there is value in &quot;bundling&quot; application messages</FONT>
<BR><FONT SIZE=2>into one transport (i.e. putting some portion of ct with the ho</FONT>
<BR><FONT SIZE=2>message), as long as we can do it without making ct MIP dependent.</FONT>
<BR><FONT SIZE=2>All in all, this discussion is premature, as we are trying to</FONT>
<BR><FONT SIZE=2>get through the requirements, and one of the requirements cannot</FONT>
<BR><FONT SIZE=2>be that ct message y = ho message x. This is more then just idealism</FONT>
<BR><FONT SIZE=2>on my part: while we may all have our respective ideas about what</FONT>
<BR><FONT SIZE=2>the ct protocol looks like, none of us knows what the wg version of</FONT>
<BR><FONT SIZE=2>the protocol will turn out to be once we put our collective knowledge</FONT>
<BR><FONT SIZE=2>together.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Finally, just to avoid confusion: you are correct, absolutely, </FONT>
<BR><FONT SIZE=2>serialization is a bad approach.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phillip Neumiller [<A HREF="mailto:PNeumiller@MeshNetworks.com">mailto:PNeumiller@MeshNetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, July 02, 2001 3:37 PM</FONT>
<BR><FONT SIZE=2>&gt; To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric Westphal'</FONT>
<BR><FONT SIZE=2>&gt; Cc: Pat Calhoun; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: CT reliability model was RE: [seamoby] [Issue] Support for</FONT>
<BR><FONT SIZE=2>&gt; Multi- Phase CT</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; In the pre- and post- conditions you are serializing something that</FONT>
<BR><FONT SIZE=2>&gt; clearly does not have to be.&nbsp; From very basic reliability theory,</FONT>
<BR><FONT SIZE=2>&gt; it is clear to that combining the CT with another essential message,</FONT>
<BR><FONT SIZE=2>&gt; the HR_request is the proper optimization.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; proof:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; For components in series, the joint reliability is given by:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Rs = R1 * R2 * ... * Rk.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; For components in parallel:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Let Uk = 1 - Rk, then</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Rp = 1 - (U1 * U2);</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Suppose that CT is CTr reliable and Handover is HOr reliable.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Then pre- and post- methods are:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Rpre_post = CTr * HOr reliable</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; and in handover CT is </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Rin = 1 - (Uct * Uho) reliable</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Assuming Uct &gt; .5 and Uho &gt;&gt; .5 to have a useable system, thus</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Rin &gt;&gt; Rpre_post</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So a &quot;IN&quot; handover CT is far more reliable than either pro- </FONT>
<BR><FONT SIZE=2>&gt; or reactive-.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; QED</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Nakhjiri Madjid-MNAKHJI1 [<A HREF="mailto:Madjid.Nakhjiri@motorola.com">mailto:Madjid.Nakhjiri@motorola.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Monday, July 02, 2001 2:10 PM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: 'Cedric Westphal'; Nakhjiri Madjid-MNAKHJI1</FONT>
<BR><FONT SIZE=2>&gt; &gt; Cc: Pat Calhoun; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: RE: [seamoby] [Issue] Support for Multi-Phase CT</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Cedric,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; If proactive MUST be multiphasic, then reactive MUST be</FONT>
<BR><FONT SIZE=2>&gt; &gt; multiphasic too, don't you think?</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; You are in more trouble (higher probability of loosing</FONT>
<BR><FONT SIZE=2>&gt; &gt; packets) when you are doing reactive than when you are</FONT>
<BR><FONT SIZE=2>&gt; &gt; doing proactive, so it is even more important that</FONT>
<BR><FONT SIZE=2>&gt; &gt; you send &quot;urgent context&quot; earlier than other context, when </FONT>
<BR><FONT SIZE=2>&gt; &gt; you are doing reactive.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Madjid</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Cedric Westphal [<A HREF="mailto:cedric@iprg.nokia.com">mailto:cedric@iprg.nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Friday, June 29, 2001 6:40 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: Nakhjiri Madjid-MNAKHJI1</FONT>
<BR><FONT SIZE=2>&gt; &gt; Cc: Pat Calhoun; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Nakhjiri Madjid-MNAKHJI1 wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Hi cedric,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; From: Cedric Westphal [<A HREF="mailto:cedric@IPRG.nokia.com">mailto:cedric@IPRG.nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Sent: Tuesday, June 26, 2001 9:35 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; To: Pat Calhoun</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Cc: Gary Kenward; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Subject: Re: [seamoby] [Issue] Support for Multi-Phase CT</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; I agree with this (the support for multi-phase ct proposal)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; and would actually go one step further:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; requirement: a proactive transfer MUST be multiphasic (so </FONT>
<BR><FONT SIZE=2>&gt; &gt; that accounting</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; transfer can be transfered after the handoff and config </FONT>
<BR><FONT SIZE=2>&gt; &gt; transfer before</FONT>
<BR><FONT SIZE=2>&gt; &gt; the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; handoff)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; a reactive transfer SHOULD be monophasic.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; MN&gt;&gt; I don't agree, I think it is actually more important to have</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; a multiphasic CT for reactive than it is for proactive.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; If you had to wait for packet delivery until the end of CT</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; (which I am not proposing) then</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; You would loose more packets in reactive. Hence you should break</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; CT into pieces. After sending the more urgent context, you could</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; resume packet delivery and at the same time, take your time with</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; less urgent context.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; [cedric] I agree with the fact that reactive CT could be </FONT>
<BR><FONT SIZE=2>&gt; pluriphasic,</FONT>
<BR><FONT SIZE=2>&gt; &gt; that's why it is a SHOULD, not a MUST.</FONT>
<BR><FONT SIZE=2>&gt; &gt; Or are you saying that _all_ CT should be in several phases? Are you</FONT>
<BR><FONT SIZE=2>&gt; &gt; proposing that 'CT, even reactive, MUST be in several phase'? I hope</FONT>
<BR><FONT SIZE=2>&gt; &gt; not.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; and the distinction between proactive and reactive becomes </FONT>
<BR><FONT SIZE=2>&gt; &gt; one of a number</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; of phases.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; MN&gt;&gt; yet another proactive/ reactive definition, please give us a</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; break :)</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; [cedric] not a definition, a distinction ;).</FONT>
<BR><FONT SIZE=2>&gt; &gt; Take care,</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Cedric.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Madjid</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Cedric.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Pat Calhoun wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; On Fri, Jun 22, 2001 at 03:23:43PM -0400, Gary Kenward wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp; I with you up until that last two paragraphs of the </FONT>
<BR><FONT SIZE=2>&gt; &gt; proposed new</FONT>
<BR><FONT SIZE=2>&gt; &gt; texts.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; The second to last paragraph is editorial, and presumes </FONT>
<BR><FONT SIZE=2>&gt; &gt; much about the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; context,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; the ctp design and the implementation.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; ok, I am certainly open to suggestions.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp; As for the last paragraph, I do not see the need to </FONT>
<BR><FONT SIZE=2>&gt; &gt; add priority to</FONT>
<BR><FONT SIZE=2>&gt; &gt; CTP.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; It is already required that the receiving AR process </FONT>
<BR><FONT SIZE=2>&gt; &gt; the context in</FONT>
<BR><FONT SIZE=2>&gt; &gt; the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; order received, and this yields the same result </FONT>
<BR><FONT SIZE=2>&gt; &gt; (priority can always</FONT>
<BR><FONT SIZE=2>&gt; &gt; be</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; translated to a measurable performance criteria, such </FONT>
<BR><FONT SIZE=2>&gt; &gt; as &quot;processed</FONT>
<BR><FONT SIZE=2>&gt; &gt; sooner&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; or &quot;given more resources&quot;). I do not see the utility of </FONT>
<BR><FONT SIZE=2>&gt; &gt; a &quot;priority&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; bit.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; Perhaps you could</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; elaborate?</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; This isn't a question of a bit. It has to do with sending </FONT>
<BR><FONT SIZE=2>&gt; &gt; critical CT</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; information that is REQUIRED in order to deliver a single </FONT>
<BR><FONT SIZE=2>&gt; &gt; packet to the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; mobile. This could include HC state, session keys, etc. </FONT>
<BR><FONT SIZE=2>&gt; &gt; This state info</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; is sent first when a handoff is occuring.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Later (say, 1+ seconds later) additional state is sent. </FONT>
<BR><FONT SIZE=2>&gt; &gt; Although this</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; info is important, it may only be necessary when doing </FONT>
<BR><FONT SIZE=2>&gt; &gt; things such as</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; generating accounting messages, which are infrequent, and </FONT>
<BR><FONT SIZE=2>&gt; &gt; not required</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; during the handoff process.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp; Otherwise I have no problem with the additional requirement</FONT>
<BR><FONT SIZE=2>&gt; &gt; (although I</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; wonder what an operator would say about &quot;accounting&quot; </FONT>
<BR><FONT SIZE=2>&gt; being &quot;low</FONT>
<BR><FONT SIZE=2>&gt; &gt; priority&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; ;^}).</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; :)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; Gary</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; From: Pat Calhoun [<A HREF="mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; Sent: Thursday, June 21, 2001 6:37 PM</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; To: seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; Subject: [seamoby] [Issue] Support for Multi-Phase CT</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; Issue 5: Support for multi-phase CT</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Submitter name: Pat Calhoun</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Submitter email address: pcalhoun@eng.sun.com</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date first submitted: June 21,2001</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reference:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Comment type: T</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Priority: 1</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Section: 4.9</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Rationale/Explanation of issue:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The current requirement in section 4.9 states </FONT>
<BR><FONT SIZE=2>&gt; &gt; that a CT can</FONT>
<BR><FONT SIZE=2>&gt; &gt; only</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; occur once all of the state has been gathered. </FONT>
<BR><FONT SIZE=2>&gt; &gt; The CT protocol</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; must allow for state to be transferred in </FONT>
<BR><FONT SIZE=2>&gt; &gt; phases, where the</FONT>
<BR><FONT SIZE=2>&gt; &gt; high</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; priority state (e.g. Header Compression, session </FONT>
<BR><FONT SIZE=2>&gt; &gt; keys) is sent</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; first, and low priority items are sent at a </FONT>
<BR><FONT SIZE=2>&gt; &gt; later time (e.g.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; accounting information).</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This would reduce the size of the high priority </FONT>
<BR><FONT SIZE=2>&gt; &gt; CT packets,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; lower the computational cost of processing the packet,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; and decrease</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the handoff latency.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Requested change:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Change 4.9 to state something like:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &quot;4.9 Context information MAY be transferred in phases,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; allowing for</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; higher priority state to be sent first, and </FONT>
<BR><FONT SIZE=2>&gt; &gt; lower priority</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; state to be sent at a later time.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The total cost of processing a smaller packet with high</FONT>
<BR><FONT SIZE=2>&gt; &gt; priority</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; state is smaller, and would decrease any latency</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; introduced by CT. Each</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CT profile would need to specify whether it is </FONT>
<BR><FONT SIZE=2>&gt; &gt; to be considered</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; as a high or low priority state.&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Proposal:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Adopt the text above in the -01 version of the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; requirements spec.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C103C6.0723F710--


From owner-seamoby@diameter.org  Tue Jul  3 10:01:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18707
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 10:01:35 -0400 (EDT)
Received: (qmail 16625 invoked by alias); 3 Jul 2001 13:47:17 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16619 invoked by uid 200); 3 Jul 2001 13:47:17 -0000
Received: (qmail 16612 invoked from network); 3 Jul 2001 13:47:12 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 13:47:12 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <NXCGAZHR>; Tue, 3 Jul 2001 09:58:06 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445576@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
	 lti-  Phase CT
Date: Tue, 3 Jul 2001 09:57:59 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C103C8.2B0169E0"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C103C8.2B0169E0
Content-Type: text/plain;
	charset="iso-8859-1"

I guess I have come full circle on this one Gary.  I don't think its
a sin to build MIP friendly stuff into CT, in fact it is desirable at this
point, especially for FMIPv6++ which looks to be a great improvement.
Until there ARE other mobility protocols in the IETF or somebody 
can point me to some other one they are going to use, it seems
quite illogical to NOT support MIP whole heartedly.
 
I do agree that MIP has problems.  With some patience and diligence
these things will be worked out over time.  With this being said,
and the L2 trigger work going on in FMIP, it also seems logical
to have a L2 trigger that is used by both MIP for handover and
SeaMoby for CT.  The next step is combine the events to optimize
the design IMHO.  I guess I frankly don't see the value of:

A). Proactive CT
B). Reactive CT
C). Polyphasic CT
 
Could you shed some light on why these are perceived as important
in a few sentences?  I don't see the value add.  
 
Best regards,
 
Phil




------_=_NextPart_001_01C103C8.2B0169E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: CT reliability model was RE: [seamoby] [Issue] Support for Multi- Phase CT</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>I 
guess I have come full circle on this one Gary.&nbsp; I don't think 
its</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>a sin 
to build MIP friendly stuff into CT, in fact it is desirable at 
this</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>point, 
especially for FMIPv6++ which looks to be a great 
improvement.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>Until 
there ARE other mobility protocols in the IETF or somebody </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>can 
point me to some other one they are going to use, it seems</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>quite 
illogical to NOT support MIP whole heartedly.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=819074513-03072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>I do 
agree that MIP has problems.&nbsp; With some patience and 
diligence</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>these 
things will be worked out over time.&nbsp; With this being 
said,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>and 
the L2 trigger work going on in FMIP, it also seems logical</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>to 
have a L2 trigger that is used by both MIP for handover and</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=819074513-03072001>SeaMoby for CT.&nbsp; The next step is combine the 
events to optimize</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>the 
design IMHO.&nbsp; I guess I frankly don't see the value of:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=819074513-03072001><BR>A). Proactive CT</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>B). 
Reactive CT</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>C). 
Polyphasic CT</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=819074513-03072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>Could 
you shed some light on why these are perceived as important</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=819074513-03072001>in</SPAN></FONT><FONT color=#0000ff face=Arial 
size=2><SPAN class=819074513-03072001> a few sentences?&nbsp; I don't see the 
value add.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=819074513-03072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>Best 
regards,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=819074513-03072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=819074513-03072001>Phil</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2></DIV></FONT></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C103C8.2B0169E0--


From owner-seamoby@diameter.org  Tue Jul  3 10:08:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23250
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 10:08:22 -0400 (EDT)
Received: (qmail 16686 invoked by alias); 3 Jul 2001 13:48:41 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16680 invoked by uid 200); 3 Jul 2001 13:48:41 -0000
Received: (qmail 16671 invoked from network); 3 Jul 2001 13:48:37 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 13:48:37 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f63DxM016847
	for <seamoby@diameter.org>; Tue, 3 Jul 2001 09:59:22 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 3 Jul 2001 09:59:15 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <NZ9SAKYT>; Tue, 3 Jul 2001 09:59:18 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DBB@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Cedric Westphal'" <cedric@iprg.nokia.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing
Date: Tue, 3 Jul 2001 09:59:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C103C8.5500C1A0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C103C8.5500C1A0
Content-Type: text/plain;
	charset="iso-8859-1"

Cedric:

> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
> Sent: Tuesday, July 03, 2001 3:55 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; 
> charliep@iprg.nokia.com
> Subject: Re: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing
> 
> 
> Sorry to breach the truce, but here are some comments:
> 
> Nakhjiri Madjid-MNAKHJI1 wrote:
> 
> > I suggest we leave this as an open issue, until we meet in IETF.
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Friday, June 29, 2001 10:28 AM
> > To: 'seamoby'
> > Subject: [seamoby] Issue #4: Clear, unambiguous definitions missing
> > Sensitivity: Confidential
> >
> > In the interest of moving the requirements forward, I 
> support the change in
> > the
> > definitions of "reactive" and "proactive' proposed by Pat:
> >
> > Reactive CT: The context transfer process which takes place 
> subsequent
> > to arrival of a MN's packet at the target AR
> >
> > Proactive CT: The context transfer process in which the 
> required contexts
> > are in place at the target AR  prior to the arrival of MN's 
> packet at target
> > AR.
> >
> 
> reactive sounds good to me, but not proactive. There is a 

From your arguements below you seem to support being proactive,
it's all the connotations that have been spun around what proactive
does or not mean that you object to. It's impossible to counter the
tide of popular belief (just look what has happened with "seamless").
Please be assured, there has never been a formal definition of 
"proactive" that included, or implied serialization. Indeed, every 
attempt has been made to avoid this definition. Truthfully, I believe 
that whatever name we chose would end up painted with the same innuendo.

So at this time - if I am correct in my observation that we all do indeed
believe that serialization is a bad thing, but that being prepared for
the actual handover ahead of time is a good thing - we are really involved
in a nomenclature debate. From my point of view this is a waste of
our collective energy, but so be it. Let's pick a word.

"Dynamic" and "static" tends to capture somewhat the attributes of the
context at different phases, but the terms are too restrictive. An early
transfer of dynamic context should be allowed if it enhances handover.
"predictive" doesn't work for me either, as it implies that ct is involved
with some sort of inductive logic; while there may be an entity attempting
to "predict" which base/AP/AR the MN will appear on next, it is not part
of ct.

So that leaves? Well, how about prophylactic? Hmmm, unlikely to pass the
scrutiny of the IESG for all the snickers it would incite from the just-
out-of-high-school crowd.

We are deep into trying to define how the protocol should work, when we
are supposed to be finishing off the requirements document. Maybe the answer
is to avoid the use of catch phrases, and simply write requirements that
state what it is that we want to accomplish.

Cheers,
Gary

> consensus for support
> for several phases in CT. So it seems that the term 
> 'required' needs to be
> clarified.
> In the CT phases discussion, the talk is about priority. Some 
> contexts are more
> important than other. Which is true, but mostly some contexts 
> are more time
> sensitive
> than other. Some accounting contexts, which some operator 
> would argue is _very_
> important, can arrive later, after the arrival of MN's packet 
> at new AR. This
> requirement denies this possibility.
> 
> Solutions: 1) define a static context (configuration state) 
> and a dynamic
> context (accounting
> state). Static context is what has to be transfered before 
> the arrival of MN's
> packet
> at target AR. Replace 'required' in your definition by 
> 'static', or 'config'.
> Dynamic is what
> can be transfered later to fill in the blanks. I have some 
> text on this if you
> want.
> 
> -or-
> 
> 2) one of the issues with proactive/reactive is that it connotes a
> serialization. pro/before, re/after.
> There seems to be somewhat of a consensus as to before what 
> and after what
> (having the
> newAR default router, or having the newAR receiving packets 
> from the MN).
> For instance in this proposal, the whole transfer has to be 
> performed _before_
> (prior in the
> text) the arrival of MN's packet at newAR. Other proposals: 
> pre-handoff,
> post-handoff, same
> thing. Charlie's proposal: reactive, predictive, also same thing.
> On the other hand, CT can be initiated before/after, and 
> completed before/after.
> So, if you take
> away the initiated after/completed before, you still need at 
> least THREE terms.
> There is also a consensus on reactive: initiated 
> after/completed after. The
> issue is with proactive,
> which means before, and has to cover the CT completed *after* 
> case, which is
> somewhat
> counter-intuitive.
> So here is yet another proposal, which borrows the handoff 
> terminology, and is
> in everybody's
> dictionnary:
> hard CT = reactive CT
> soft CT = a CT in which the transfer is initiated before the 
> arrival of MN's
> packet at the target
> AR. (no mention of completion, covers the initiated before, 
> completed before or
> after case).
> proactive CT= the definition up this mail (covers the 
> initiated before/completed
> before case).
> 
> Cheers,
> 
> Cedric.
> 
> >
> > Since these are "definitions" and not requirements, I 
> assume that there is
> > room
> > for change as we delve into the design process.
> >
> > For what it's worth . . .
> >
> > Gary
> 
> 

------_=_NextPart_001_01C103C8.5500C1A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: [seamoby] Issue #4: Clear, unambiguous definitions missing</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Cedric:</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Cedric Westphal [<A HREF="mailto:cedric@iprg.nokia.com">mailto:cedric@iprg.nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Tuesday, July 03, 2001 3:55 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Nakhjiri Madjid-MNAKHJI1</FONT>
<BR><FONT SIZE=2>&gt; Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; </FONT>
<BR><FONT SIZE=2>&gt; charliep@iprg.nokia.com</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] Issue #4: Clear, unambiguous </FONT>
<BR><FONT SIZE=2>&gt; definitions missing</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sorry to breach the truce, but here are some comments:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Nakhjiri Madjid-MNAKHJI1 wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I suggest we leave this as an open issue, until we meet in IETF.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Madjid</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Gary Kenward [<A HREF="mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Friday, June 29, 2001 10:28 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: 'seamoby'</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: [seamoby] Issue #4: Clear, unambiguous definitions missing</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sensitivity: Confidential</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; In the interest of moving the requirements forward, I </FONT>
<BR><FONT SIZE=2>&gt; support the change in</FONT>
<BR><FONT SIZE=2>&gt; &gt; the</FONT>
<BR><FONT SIZE=2>&gt; &gt; definitions of &quot;reactive&quot; and &quot;proactive' proposed by Pat:</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Reactive CT: The context transfer process which takes place </FONT>
<BR><FONT SIZE=2>&gt; subsequent</FONT>
<BR><FONT SIZE=2>&gt; &gt; to arrival of a MN's packet at the target AR</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Proactive CT: The context transfer process in which the </FONT>
<BR><FONT SIZE=2>&gt; required contexts</FONT>
<BR><FONT SIZE=2>&gt; &gt; are in place at the target AR&nbsp; prior to the arrival of MN's </FONT>
<BR><FONT SIZE=2>&gt; packet at target</FONT>
<BR><FONT SIZE=2>&gt; &gt; AR.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; reactive sounds good to me, but not proactive. There is a </FONT>
</P>

<P><FONT SIZE=2>From your arguements below you seem to support being proactive,</FONT>
<BR><FONT SIZE=2>it's all the connotations that have been spun around what proactive</FONT>
<BR><FONT SIZE=2>does or not mean that you object to. It's impossible to counter the</FONT>
<BR><FONT SIZE=2>tide of popular belief (just look what has happened with &quot;seamless&quot;).</FONT>
<BR><FONT SIZE=2>Please be assured, there has never been a formal definition of </FONT>
<BR><FONT SIZE=2>&quot;proactive&quot; that included, or implied serialization. Indeed, every </FONT>
<BR><FONT SIZE=2>attempt has been made to avoid this definition. Truthfully, I believe </FONT>
<BR><FONT SIZE=2>that whatever name we chose would end up painted with the same innuendo.</FONT>
</P>

<P><FONT SIZE=2>So at this time - if I am correct in my observation that we all do indeed</FONT>
<BR><FONT SIZE=2>believe that serialization is a bad thing, but that being prepared for</FONT>
<BR><FONT SIZE=2>the actual handover ahead of time is a good thing - we are really involved</FONT>
<BR><FONT SIZE=2>in a nomenclature debate. From my point of view this is a waste of</FONT>
<BR><FONT SIZE=2>our collective energy, but so be it. Let's pick a word.</FONT>
</P>

<P><FONT SIZE=2>&quot;Dynamic&quot; and &quot;static&quot; tends to capture somewhat the attributes of the</FONT>
<BR><FONT SIZE=2>context at different phases, but the terms are too restrictive. An early</FONT>
<BR><FONT SIZE=2>transfer of dynamic context should be allowed if it enhances handover.</FONT>
<BR><FONT SIZE=2>&quot;predictive&quot; doesn't work for me either, as it implies that ct is involved</FONT>
<BR><FONT SIZE=2>with some sort of inductive logic; while there may be an entity attempting</FONT>
<BR><FONT SIZE=2>to &quot;predict&quot; which base/AP/AR the MN will appear on next, it is not part</FONT>
<BR><FONT SIZE=2>of ct.</FONT>
</P>

<P><FONT SIZE=2>So that leaves? Well, how about prophylactic? Hmmm, unlikely to pass the</FONT>
<BR><FONT SIZE=2>scrutiny of the IESG for all the snickers it would incite from the just-</FONT>
<BR><FONT SIZE=2>out-of-high-school crowd.</FONT>
</P>

<P><FONT SIZE=2>We are deep into trying to define how the protocol should work, when we</FONT>
<BR><FONT SIZE=2>are supposed to be finishing off the requirements document. Maybe the answer</FONT>
<BR><FONT SIZE=2>is to avoid the use of catch phrases, and simply write requirements that</FONT>
<BR><FONT SIZE=2>state what it is that we want to accomplish.</FONT>
</P>

<P><FONT SIZE=2>Cheers,</FONT>
<BR><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; consensus for support</FONT>
<BR><FONT SIZE=2>&gt; for several phases in CT. So it seems that the term </FONT>
<BR><FONT SIZE=2>&gt; 'required' needs to be</FONT>
<BR><FONT SIZE=2>&gt; clarified.</FONT>
<BR><FONT SIZE=2>&gt; In the CT phases discussion, the talk is about priority. Some </FONT>
<BR><FONT SIZE=2>&gt; contexts are more</FONT>
<BR><FONT SIZE=2>&gt; important than other. Which is true, but mostly some contexts </FONT>
<BR><FONT SIZE=2>&gt; are more time</FONT>
<BR><FONT SIZE=2>&gt; sensitive</FONT>
<BR><FONT SIZE=2>&gt; than other. Some accounting contexts, which some operator </FONT>
<BR><FONT SIZE=2>&gt; would argue is _very_</FONT>
<BR><FONT SIZE=2>&gt; important, can arrive later, after the arrival of MN's packet </FONT>
<BR><FONT SIZE=2>&gt; at new AR. This</FONT>
<BR><FONT SIZE=2>&gt; requirement denies this possibility.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Solutions: 1) define a static context (configuration state) </FONT>
<BR><FONT SIZE=2>&gt; and a dynamic</FONT>
<BR><FONT SIZE=2>&gt; context (accounting</FONT>
<BR><FONT SIZE=2>&gt; state). Static context is what has to be transfered before </FONT>
<BR><FONT SIZE=2>&gt; the arrival of MN's</FONT>
<BR><FONT SIZE=2>&gt; packet</FONT>
<BR><FONT SIZE=2>&gt; at target AR. Replace 'required' in your definition by </FONT>
<BR><FONT SIZE=2>&gt; 'static', or 'config'.</FONT>
<BR><FONT SIZE=2>&gt; Dynamic is what</FONT>
<BR><FONT SIZE=2>&gt; can be transfered later to fill in the blanks. I have some </FONT>
<BR><FONT SIZE=2>&gt; text on this if you</FONT>
<BR><FONT SIZE=2>&gt; want.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -or-</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 2) one of the issues with proactive/reactive is that it connotes a</FONT>
<BR><FONT SIZE=2>&gt; serialization. pro/before, re/after.</FONT>
<BR><FONT SIZE=2>&gt; There seems to be somewhat of a consensus as to before what </FONT>
<BR><FONT SIZE=2>&gt; and after what</FONT>
<BR><FONT SIZE=2>&gt; (having the</FONT>
<BR><FONT SIZE=2>&gt; newAR default router, or having the newAR receiving packets </FONT>
<BR><FONT SIZE=2>&gt; from the MN).</FONT>
<BR><FONT SIZE=2>&gt; For instance in this proposal, the whole transfer has to be </FONT>
<BR><FONT SIZE=2>&gt; performed _before_</FONT>
<BR><FONT SIZE=2>&gt; (prior in the</FONT>
<BR><FONT SIZE=2>&gt; text) the arrival of MN's packet at newAR. Other proposals: </FONT>
<BR><FONT SIZE=2>&gt; pre-handoff,</FONT>
<BR><FONT SIZE=2>&gt; post-handoff, same</FONT>
<BR><FONT SIZE=2>&gt; thing. Charlie's proposal: reactive, predictive, also same thing.</FONT>
<BR><FONT SIZE=2>&gt; On the other hand, CT can be initiated before/after, and </FONT>
<BR><FONT SIZE=2>&gt; completed before/after.</FONT>
<BR><FONT SIZE=2>&gt; So, if you take</FONT>
<BR><FONT SIZE=2>&gt; away the initiated after/completed before, you still need at </FONT>
<BR><FONT SIZE=2>&gt; least THREE terms.</FONT>
<BR><FONT SIZE=2>&gt; There is also a consensus on reactive: initiated </FONT>
<BR><FONT SIZE=2>&gt; after/completed after. The</FONT>
<BR><FONT SIZE=2>&gt; issue is with proactive,</FONT>
<BR><FONT SIZE=2>&gt; which means before, and has to cover the CT completed *after* </FONT>
<BR><FONT SIZE=2>&gt; case, which is</FONT>
<BR><FONT SIZE=2>&gt; somewhat</FONT>
<BR><FONT SIZE=2>&gt; counter-intuitive.</FONT>
<BR><FONT SIZE=2>&gt; So here is yet another proposal, which borrows the handoff </FONT>
<BR><FONT SIZE=2>&gt; terminology, and is</FONT>
<BR><FONT SIZE=2>&gt; in everybody's</FONT>
<BR><FONT SIZE=2>&gt; dictionnary:</FONT>
<BR><FONT SIZE=2>&gt; hard CT = reactive CT</FONT>
<BR><FONT SIZE=2>&gt; soft CT = a CT in which the transfer is initiated before the </FONT>
<BR><FONT SIZE=2>&gt; arrival of MN's</FONT>
<BR><FONT SIZE=2>&gt; packet at the target</FONT>
<BR><FONT SIZE=2>&gt; AR. (no mention of completion, covers the initiated before, </FONT>
<BR><FONT SIZE=2>&gt; completed before or</FONT>
<BR><FONT SIZE=2>&gt; after case).</FONT>
<BR><FONT SIZE=2>&gt; proactive CT= the definition up this mail (covers the </FONT>
<BR><FONT SIZE=2>&gt; initiated before/completed</FONT>
<BR><FONT SIZE=2>&gt; before case).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cheers,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cedric.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Since these are &quot;definitions&quot; and not requirements, I </FONT>
<BR><FONT SIZE=2>&gt; assume that there is</FONT>
<BR><FONT SIZE=2>&gt; &gt; room</FONT>
<BR><FONT SIZE=2>&gt; &gt; for change as we delve into the design process.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; For what it's worth . . .</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Gary</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C103C8.5500C1A0--


From owner-seamoby@diameter.org  Tue Jul  3 10:35:45 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10588
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 10:35:30 -0400 (EDT)
Received: (qmail 17657 invoked by alias); 3 Jul 2001 14:19:07 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 17651 invoked by uid 200); 3 Jul 2001 14:19:06 -0000
Received: (qmail 17646 invoked from network); 3 Jul 2001 14:19:05 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 14:19:05 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id HAA28983;
	Tue, 3 Jul 2001 07:30:14 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f63EUDJ16119;
	Tue, 3 Jul 2001 07:30:13 -0700
X-mProtect:  Tue, 3 Jul 2001 07:30:13 -0700 Nokia Silicon Valley Messaging Protection
Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdqYAYc7; Tue, 03 Jul 2001 07:30:09 PDT
Message-ID: <3B41D6E3.BC042D18@iprg.nokia.com>
Date: Tue, 03 Jul 2001 07:29:55 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gary Kenward <gkenward@nortelnetworks.com>
CC: "'seamoby'" <seamoby@diameter.org>
Subject: Re: [seamoby] Issue #4: Clear, unambiguous definitions missing
References: <9FBD322B7824D511B36900508BF93C9C9F5DBB@zcard031.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------0FB218E672391A4803F28DBB"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------0FB218E672391A4803F28DBB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gary:

Gary Kenward wrote:

>
>
> Cedric:
>
> > -----Original Message-----
> > From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
> > Sent: Tuesday, July 03, 2001 3:55 AM
> > To: Nakhjiri Madjid-MNAKHJI1
> > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby';
> > charliep@iprg.nokia.com
> > Subject: Re: [seamoby] Issue #4: Clear, unambiguous
> > definitions missing
> >
> >
> > Sorry to breach the truce, but here are some comments:
> >
> > Nakhjiri Madjid-MNAKHJI1 wrote:
> >
> > > I suggest we leave this as an open issue, until we meet in IETF.
> > >
> > > Madjid
> > >
> > > -----Original Message-----
> > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > Sent: Friday, June 29, 2001 10:28 AM
> > > To: 'seamoby'
> > > Subject: [seamoby] Issue #4: Clear, unambiguous definitions
> missing
> > > Sensitivity: Confidential
> > >
> > > In the interest of moving the requirements forward, I
> > support the change in
> > > the
> > > definitions of "reactive" and "proactive' proposed by Pat:
> > >
> > > Reactive CT: The context transfer process which takes place
> > subsequent
> > > to arrival of a MN's packet at the target AR
> > >
> > > Proactive CT: The context transfer process in which the
> > required contexts
> > > are in place at the target AR  prior to the arrival of MN's
> > packet at target
> > > AR.
> > >
> >
> > reactive sounds good to me, but not proactive. There is a
>
> From your arguements below you seem to support being proactive,
> it's all the connotations that have been spun around what proactive
> does or not mean that you object to. It's impossible to counter the
> tide of popular belief (just look what has happened with "seamless").
> Please be assured, there has never been a formal definition of
> "proactive" that included, or implied serialization. Indeed, every
> attempt has been made to avoid this definition. Truthfully, I believe
> that whatever name we chose would end up painted with the same
> innuendo.

pro-active means to act before. We should agree on that. Now, it seems
that the event answer to 'before what' is: 'arrival of MN's packet at
target AR'.
Fine with me. Thus if you define proactive CT this way, there is an
implicit
requirement that CT is completed before said event. Fine, we are in the
process of defining requirements, and I'd accept a 'proactive CT', as
you
define it.
Then again, why in the universe would you forbid that a CT initiated
before
the 'arrival  of ...' could only complete after. Maybe you don't, but
then don't use
a word that would actually mean this.

> So at this time - if I am correct in my observation that we all do
> indeed
> believe that serialization is a bad thing, but that being prepared for
>
> the actual handover ahead of time is a good thing - we are really
> involved
> in a nomenclature debate. From my point of view this is a waste of
> our collective energy, but so be it. Let's pick a word.
>
> "Dynamic" and "static" tends to capture somewhat the attributes of the
>
> context at different phases, but the terms are too restrictive. An
> early
> transfer of dynamic context should be allowed if it enhances handover.
>
> "predictive" doesn't work for me either, as it implies that ct is
> involved
> with some sort of inductive logic; while there may be an entity
> attempting
> to "predict" which base/AP/AR the MN will appear on next, it is not
> part
> of ct.
>
> So that leaves? Well, how about prophylactic? Hmmm, unlikely to pass
> the
> scrutiny of the IESG for all the snickers it would incite from the
> just-
> out-of-high-school crowd.

prophylactic? what I object to is any word that starts with pro- or
pre-,
latin root for before, to mean something that does indeed starts before,

but can end after. That's why I like 'soft'/'hard', but am open to
pretty much
anything.
Take care,

Cedric.

>
>
> We are deep into trying to define how the protocol should work, when
> we
> are supposed to be finishing off the requirements document. Maybe the
> answer
> is to avoid the use of catch phrases, and simply write requirements
> that
> state what it is that we want to accomplish.
>
> Cheers,
> Gary
>
> > consensus for support
> > for several phases in CT. So it seems that the term
> > 'required' needs to be
> > clarified.
> > In the CT phases discussion, the talk is about priority. Some
> > contexts are more
> > important than other. Which is true, but mostly some contexts
> > are more time
> > sensitive
> > than other. Some accounting contexts, which some operator
> > would argue is _very_
> > important, can arrive later, after the arrival of MN's packet
> > at new AR. This
> > requirement denies this possibility.
> >
> > Solutions: 1) define a static context (configuration state)
> > and a dynamic
> > context (accounting
> > state). Static context is what has to be transfered before
> > the arrival of MN's
> > packet
> > at target AR. Replace 'required' in your definition by
> > 'static', or 'config'.
> > Dynamic is what
> > can be transfered later to fill in the blanks. I have some
> > text on this if you
> > want.
> >
> > -or-
> >
> > 2) one of the issues with proactive/reactive is that it connotes a
> > serialization. pro/before, re/after.
> > There seems to be somewhat of a consensus as to before what
> > and after what
> > (having the
> > newAR default router, or having the newAR receiving packets
> > from the MN).
> > For instance in this proposal, the whole transfer has to be
> > performed _before_
> > (prior in the
> > text) the arrival of MN's packet at newAR. Other proposals:
> > pre-handoff,
> > post-handoff, same
> > thing. Charlie's proposal: reactive, predictive, also same thing.
> > On the other hand, CT can be initiated before/after, and
> > completed before/after.
> > So, if you take
> > away the initiated after/completed before, you still need at
> > least THREE terms.
> > There is also a consensus on reactive: initiated
> > after/completed after. The
> > issue is with proactive,
> > which means before, and has to cover the CT completed *after*
> > case, which is
> > somewhat
> > counter-intuitive.
> > So here is yet another proposal, which borrows the handoff
> > terminology, and is
> > in everybody's
> > dictionnary:
> > hard CT = reactive CT
> > soft CT = a CT in which the transfer is initiated before the
> > arrival of MN's
> > packet at the target
> > AR. (no mention of completion, covers the initiated before,
> > completed before or
> > after case).
> > proactive CT= the definition up this mail (covers the
> > initiated before/completed
> > before case).
> >
> > Cheers,
> >
> > Cedric.
> >
> > >
> > > Since these are "definitions" and not requirements, I
> > assume that there is
> > > room
> > > for change as we delve into the design process.
> > >
> > > For what it's worth . . .
> > >
> > > Gary
> >
> >

--------------0FB218E672391A4803F28DBB
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Gary:
<p>Gary Kenward wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>Cedric:</font>
<p><font size=-1>> -----Original Message-----</font>
<br><font size=-1>> From: Cedric Westphal [<a href="mailto:cedric@iprg.nokia.com">mailto:cedric@iprg.nokia.com</a>]</font>
<br><font size=-1>> Sent: Tuesday, July 03, 2001 3:55 AM</font>
<br><font size=-1>> To: Nakhjiri Madjid-MNAKHJI1</font>
<br><font size=-1>> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby';</font>
<br><font size=-1>> charliep@iprg.nokia.com</font>
<br><font size=-1>> Subject: Re: [seamoby] Issue #4: Clear, unambiguous</font>
<br><font size=-1>> definitions missing</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>> Sorry to breach the truce, but here are some comments:</font>
<br><font size=-1>></font>
<br><font size=-1>> Nakhjiri Madjid-MNAKHJI1 wrote:</font>
<br><font size=-1>></font>
<br><font size=-1>> > I suggest we leave this as an open issue, until we
meet in IETF.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Madjid</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > -----Original Message-----</font>
<br><font size=-1>> > From: Gary Kenward [<a href="mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</a>]</font>
<br><font size=-1>> > Sent: Friday, June 29, 2001 10:28 AM</font>
<br><font size=-1>> > To: 'seamoby'</font>
<br><font size=-1>> > Subject: [seamoby] Issue #4: Clear, unambiguous definitions
missing</font>
<br><font size=-1>> > Sensitivity: Confidential</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > In the interest of moving the requirements forward,
I</font>
<br><font size=-1>> support the change in</font>
<br><font size=-1>> > the</font>
<br><font size=-1>> > definitions of "reactive" and "proactive' proposed
by Pat:</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Reactive CT: The context transfer process which takes
place</font>
<br><font size=-1>> subsequent</font>
<br><font size=-1>> > to arrival of a MN's packet at the target AR</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Proactive CT: The context transfer process in which
the</font>
<br><font size=-1>> required contexts</font>
<br><font size=-1>> > are in place at the target AR&nbsp; prior to the
arrival of MN's</font>
<br><font size=-1>> packet at target</font>
<br><font size=-1>> > AR.</font>
<br><font size=-1>> ></font>
<br><font size=-1>></font>
<br><font size=-1>> reactive sounds good to me, but not proactive. There
is a</font>
<p><font size=-1>From your arguements below you seem to support being proactive,</font>
<br><font size=-1>it's all the connotations that have been spun around
what proactive</font>
<br><font size=-1>does or not mean that you object to. It's impossible
to counter the</font>
<br><font size=-1>tide of popular belief (just look what has happened with
"seamless").</font>
<br><font size=-1>Please be assured, there has never been a formal definition
of</font>
<br><font size=-1>"proactive" that included, or implied serialization.
Indeed, every</font>
<br><font size=-1>attempt has been made to avoid this definition. Truthfully,
I believe</font>
<br><font size=-1>that whatever name we chose would end up painted with
the same innuendo.</font></blockquote>
pro-active means to act before. We should agree on that. Now, it seems
<br>that the event answer to 'before what' is: 'arrival of MN's packet
at target AR'.
<br>Fine with me. Thus if you define proactive CT this way, there is an
implicit
<br>requirement that CT is completed before said event. Fine, we are in
the
<br>process of defining requirements, and I'd accept a 'proactive CT',
as you
<br>define it.
<br>Then again, why in the universe would you forbid that a CT initiated
before
<br>the 'arrival&nbsp; of ...' could only complete after. Maybe you don't,
but then don't use
<br>a word that would actually mean this.
<blockquote TYPE=CITE><font size=-1>So at this time - if I am correct in
my observation that we all do indeed</font>
<br><font size=-1>believe that serialization is a bad thing, but that being
prepared for</font>
<br><font size=-1>the actual handover ahead of time is a good thing - we
are really involved</font>
<br><font size=-1>in a nomenclature debate. From my point of view this
is a waste of</font>
<br><font size=-1>our collective energy, but so be it. Let's pick a word.</font>
<p><font size=-1>"Dynamic" and "static" tends to capture somewhat the attributes
of the</font>
<br><font size=-1>context at different phases, but the terms are too restrictive.
An early</font>
<br><font size=-1>transfer of dynamic context should be allowed if it enhances
handover.</font>
<br><font size=-1>"predictive" doesn't work for me either, as it implies
that ct is involved</font>
<br><font size=-1>with some sort of inductive logic; while there may be
an entity attempting</font>
<br><font size=-1>to "predict" which base/AP/AR the MN will appear on next,
it is not part</font>
<br><font size=-1>of ct.</font>
<p><font size=-1>So that leaves? Well, how about prophylactic? Hmmm, unlikely
to pass the</font>
<br><font size=-1>scrutiny of the IESG for all the snickers it would incite
from the just-</font>
<br><font size=-1>out-of-high-school crowd.</font></blockquote>
prophylactic? what I object to is any word that starts with pro- or pre-,
<br>latin root for before, to mean something that does indeed starts before,
<br>but can end after. That's why I like 'soft'/'hard', but am open to
pretty much
<br>anything.
<br>Take care,
<p>Cedric.
<blockquote TYPE=CITE><font size=-1></font>&nbsp;
<p><font size=-1>We are deep into trying to define how the protocol should
work, when we</font>
<br><font size=-1>are supposed to be finishing off the requirements document.
Maybe the answer</font>
<br><font size=-1>is to avoid the use of catch phrases, and simply write
requirements that</font>
<br><font size=-1>state what it is that we want to accomplish.</font>
<p><font size=-1>Cheers,</font>
<br><font size=-1>Gary</font>
<p><font size=-1>> consensus for support</font>
<br><font size=-1>> for several phases in CT. So it seems that the term</font>
<br><font size=-1>> 'required' needs to be</font>
<br><font size=-1>> clarified.</font>
<br><font size=-1>> In the CT phases discussion, the talk is about priority.
Some</font>
<br><font size=-1>> contexts are more</font>
<br><font size=-1>> important than other. Which is true, but mostly some
contexts</font>
<br><font size=-1>> are more time</font>
<br><font size=-1>> sensitive</font>
<br><font size=-1>> than other. Some accounting contexts, which some operator</font>
<br><font size=-1>> would argue is _very_</font>
<br><font size=-1>> important, can arrive later, after the arrival of MN's
packet</font>
<br><font size=-1>> at new AR. This</font>
<br><font size=-1>> requirement denies this possibility.</font>
<br><font size=-1>></font>
<br><font size=-1>> Solutions: 1) define a static context (configuration
state)</font>
<br><font size=-1>> and a dynamic</font>
<br><font size=-1>> context (accounting</font>
<br><font size=-1>> state). Static context is what has to be transfered
before</font>
<br><font size=-1>> the arrival of MN's</font>
<br><font size=-1>> packet</font>
<br><font size=-1>> at target AR. Replace 'required' in your definition
by</font>
<br><font size=-1>> 'static', or 'config'.</font>
<br><font size=-1>> Dynamic is what</font>
<br><font size=-1>> can be transfered later to fill in the blanks. I have
some</font>
<br><font size=-1>> text on this if you</font>
<br><font size=-1>> want.</font>
<br><font size=-1>></font>
<br><font size=-1>> -or-</font>
<br><font size=-1>></font>
<br><font size=-1>> 2) one of the issues with proactive/reactive is that
it connotes a</font>
<br><font size=-1>> serialization. pro/before, re/after.</font>
<br><font size=-1>> There seems to be somewhat of a consensus as to before
what</font>
<br><font size=-1>> and after what</font>
<br><font size=-1>> (having the</font>
<br><font size=-1>> newAR default router, or having the newAR receiving
packets</font>
<br><font size=-1>> from the MN).</font>
<br><font size=-1>> For instance in this proposal, the whole transfer has
to be</font>
<br><font size=-1>> performed _before_</font>
<br><font size=-1>> (prior in the</font>
<br><font size=-1>> text) the arrival of MN's packet at newAR. Other proposals:</font>
<br><font size=-1>> pre-handoff,</font>
<br><font size=-1>> post-handoff, same</font>
<br><font size=-1>> thing. Charlie's proposal: reactive, predictive, also
same thing.</font>
<br><font size=-1>> On the other hand, CT can be initiated before/after,
and</font>
<br><font size=-1>> completed before/after.</font>
<br><font size=-1>> So, if you take</font>
<br><font size=-1>> away the initiated after/completed before, you still
need at</font>
<br><font size=-1>> least THREE terms.</font>
<br><font size=-1>> There is also a consensus on reactive: initiated</font>
<br><font size=-1>> after/completed after. The</font>
<br><font size=-1>> issue is with proactive,</font>
<br><font size=-1>> which means before, and has to cover the CT completed
*after*</font>
<br><font size=-1>> case, which is</font>
<br><font size=-1>> somewhat</font>
<br><font size=-1>> counter-intuitive.</font>
<br><font size=-1>> So here is yet another proposal, which borrows the
handoff</font>
<br><font size=-1>> terminology, and is</font>
<br><font size=-1>> in everybody's</font>
<br><font size=-1>> dictionnary:</font>
<br><font size=-1>> hard CT = reactive CT</font>
<br><font size=-1>> soft CT = a CT in which the transfer is initiated before
the</font>
<br><font size=-1>> arrival of MN's</font>
<br><font size=-1>> packet at the target</font>
<br><font size=-1>> AR. (no mention of completion, covers the initiated
before,</font>
<br><font size=-1>> completed before or</font>
<br><font size=-1>> after case).</font>
<br><font size=-1>> proactive CT= the definition up this mail (covers the</font>
<br><font size=-1>> initiated before/completed</font>
<br><font size=-1>> before case).</font>
<br><font size=-1>></font>
<br><font size=-1>> Cheers,</font>
<br><font size=-1>></font>
<br><font size=-1>> Cedric.</font>
<br><font size=-1>></font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Since these are "definitions" and not requirements,
I</font>
<br><font size=-1>> assume that there is</font>
<br><font size=-1>> > room</font>
<br><font size=-1>> > for change as we delve into the design process.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > For what it's worth . . .</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Gary</font>
<br><font size=-1>></font>
<br><font size=-1>></font></blockquote>
</html>

--------------0FB218E672391A4803F28DBB--



From owner-seamoby@diameter.org  Tue Jul  3 11:46:32 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09778
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 11:46:20 -0400 (EDT)
Received: (qmail 18372 invoked by alias); 3 Jul 2001 15:29:11 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18366 invoked by uid 200); 3 Jul 2001 15:29:10 -0000
Received: (qmail 18361 invoked from network); 3 Jul 2001 15:29:08 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 15:29:08 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f63Fe2009460
	for <seamoby@cdma-2000.org>; Tue, 3 Jul 2001 11:40:02 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Tue, 3 Jul 2001 11:40:02 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <NZ9SA33G>; Tue, 3 Jul 2001 11:40:03 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DBC@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>
Cc: seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
         Phase CT
Date: Tue, 3 Jul 2001 11:40:02 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C103D6.6CB1F090"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C103D6.6CB1F090
Content-Type: text/plain;
	charset="iso-8859-1"

Phil:
 
  My first comment is that I seem to find myself frequently
being accused of trying to bias ct in one direction when in
fact I am trying hard to prevent bias. If I am trying to
pull the conversation away from a certain assumption it's
to take it towards the middle, not the other extreme.

-----Original Message-----
From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
Sent: Tuesday, July 03, 2001 9:58 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; Phillip Neumiller
Cc: seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
lti- Phase CT


I guess I have come full circle on this one Gary.  I don't think its
a sin to build MIP friendly stuff into CT, in fact it is desirable at this
point, especially for FMIPv6++ which looks to be a great improvement.
Until there ARE other mobility protocols in the IETF or somebody 
can point me to some other one they are going to use, it seems
quite illogical to NOT support MIP whole heartedly.
 
Absolutely, I agree. IETF protocols must support other
IETF protocols. But MIP is not a universal mobility solution,
and there are many indications that for certain mobile wireless
networks it will be, at the very least, a *long* time before
MIP is adopted. I don't want to get into the debate over
who is prepared to adopt what again, so I'm going to try
and take the easy way out and say that it's in our charter
(I believe) that CT will work with "other" mobility solutions. 
 
I do agree that MIP has problems.  With some patience and diligence
these things will be worked out over time.  With this being said, 
 
MIP's biggest problem, at the moment, is that it has
very little momentum in the mobile wireless world. As
far as I know, there is only one operational mobile
wireless network that uses it, Nextel (I'm sure that 
statement will open the flood gates of claims and
counter claims).
 
Frankly, MIP doesn't need Seamoby to solve this
problem. The best approach for MIP would be
to solve this within the MIP WG, using MIP
specific solutions.
 
I don't see the value in developing a "general"
CT solution that used MIP messaging. It seems
like a contradiction.
 
and the L2 trigger work going on in FMIP, it also seems logical
to have a L2 trigger that is used by both MIP for handover and
SeaMoby for CT.  The next step is combine the events to optimize
the design IMHO.  I guess I frankly don't see the value of:

A). Proactive CT
B). Reactive CT
C). Polyphasic CT
 
Could you shed some light on why these are perceived as important
in a few sentences?  I don't see the value add.   
 
This would all be so much easier if we could start
looking at solutions. Let's begin with "polyphasic" CT:
I agree with you about the value of this particular "catch
phrase", in that I've always considered ct to be a process, 
not an event. Processes occur over time, and if you want to
divide that time into "phases", fine - to me this is a design
issue.
 
Having said this, people felt that there was a need to require
aggregation, etc. This implied a "one shot" ct process, and
so others decided that it was necessary to counter balance
this with a "polyphasic" / "multiphasic" requirement. I have
no problem either way: I believe that the right way to do
ct will depend upon the network technology/configuration.
 
Now, as for "proactive": the whole idea, originally, was to
make sure that concept of "preparing" for a handover was
understood and agreed upon. Why? Well, it seems obvious
(to me anyways), that you can always react faster if you are
prepared for what's coming. It really is as simple as this.
In truth, this is not a new concept. As you know, the same
approach has been used for years in CDMA.
 
So, I assume you are not against being prepared, but are
perplexed over the brain twisting over nomenclature. So
am I.
 
Gary
 
Best regards,
 
Phil




------_=_NextPart_001_01C103D6.6CB1F090
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: CT reliability model was RE: [seamoby] [Issue] Support for Multi- Phase CT</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=530565313-03072001>Phil:</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=530565313-03072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>&nbsp; My first 
comment is that I seem to find myself frequently</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>being accused of 
trying to bias ct in one direction when in</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>fact I am trying 
hard to prevent bias. If I am trying to</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>pull the 
conversation away from a certain assumption it's</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>to take it 
towards the middle, not the other extreme.</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Phillip Neumiller 
  [mailto:PNeumiller@MeshNetworks.com]<BR><B>Sent:</B> Tuesday, July 03, 2001 
  9:58 AM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; Phillip 
  Neumiller<BR><B>Cc:</B> seamoby@cdma-2000.org<BR><B>Subject:</B> RE: CT 
  reliability model was RE: [seamoby] [Issue] Support for Mu lti- Phase 
  CT<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>I 
  guess I have come full circle on this one Gary.&nbsp; I don't think 
  its</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>a 
  sin to build MIP friendly stuff into CT, in fact it is desirable at 
  this</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001>point, especially for FMIPv6++ which looks to be a 
  great improvement.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001>Until there ARE other mobility protocols in the IETF 
  or somebody </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>can 
  point me to some other one they are going to use, it seems</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001>quite illogical to NOT support MIP whole 
  heartedly.</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001></SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>Absolutely, I agree.&nbsp;IETF protocols must support 
  other</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>IETF protocols. But MIP is not a 
  universal&nbsp;</SPAN></FONT></SPAN></FONT><FONT color=#0000ff face=Arial 
  size=2><SPAN class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" 
  size=3><SPAN class=530565313-03072001>mobility 
  solution,</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>and there are many indications that for&nbsp;certain 
  mobile wireless</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>networks it will&nbsp;be, at the very least, a *long* 
  time before</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>MIP is adopted. I don't want to get into the debate 
  over</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>who&nbsp;is prepared to adopt what&nbsp;again, so 
  I'm&nbsp;going to try</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>and take the&nbsp;easy way out and say that it's in 
  our charter</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>(I believe) that&nbsp;CT will work&nbsp;with "other" 
  mobility solutions.&nbsp;</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>I do 
  agree that MIP has problems.&nbsp; With some patience and 
  diligence</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001>these things will be worked out over time.&nbsp; With 
  this being said,<FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>&nbsp;</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>MIP's biggest problem, at the moment, is that it 
  has</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>very little momentum in the mobile wireless world. 
  As</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>far as I know, there is only one 
  operationa</SPAN></FONT></SPAN></FONT><FONT color=#0000ff face=Arial 
  size=2><SPAN class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" 
  size=3><SPAN class=530565313-03072001>l 
  mobile</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>wireless&nbsp;network</SPAN></FONT></SPAN></FONT><FONT 
  color=#0000ff face=Arial size=2><SPAN class=819074513-03072001><FONT 
  color=#000080 face="Comic Sans MS" size=3><SPAN class=530565313-03072001> that 
  uses it, Nextel (I'm sure that </SPAN></FONT></SPAN></FONT><FONT color=#0000ff 
  face=Arial size=2><SPAN class=819074513-03072001><FONT color=#000080 
  face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001></SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>statement will</SPAN></FONT></SPAN></FONT><FONT 
  color=#0000ff face=Arial size=2><SPAN class=819074513-03072001><FONT 
  color=#000080 face="Comic Sans MS" size=3><SPAN class=530565313-03072001> open 
  the flood gates of claims and</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>counter claims).</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>Frankly, MIP doesn't need Seamoby to solve 
  this</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>problem. The best 
  approach</SPAN></FONT></SPAN></FONT><FONT face="Comic Sans MS"><SPAN 
  class=530565313-03072001> for MIP would be</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>to solve this 
  within the MIP WG, using MIP</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>specific 
  solutions.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=530565313-03072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>I don't see the 
  value in developing a "general"</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>CT solution 
  that used MIP messaging. It seems</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>like a 
  contradiction.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=530565313-03072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>and 
  the L2 trigger work going on in FMIP, it also seems 
logical</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>to 
  have a L2 trigger that is used by both MIP for handover 
and</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001>SeaMoby for CT.&nbsp; The next step is combine the 
  events to optimize</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>the 
  design IMHO.&nbsp; I guess I frankly don't see the value 
  of:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><BR>A). Proactive CT</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>B). 
  Reactive CT</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>C). 
  Polyphasic CT</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001>Could you shed some light on why these are perceived 
  as important</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001>in</SPAN></FONT><FONT color=#0000ff face=Arial 
  size=2><SPAN class=819074513-03072001> a few sentences?&nbsp; I don't see the 
  value add.&nbsp;&nbsp;<FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>&nbsp;</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>This would all be so much easier if we could 
  start</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>looking at&nbsp;solutions. Let's begin with 
  "polyphasic" CT</SPAN></FONT></SPAN></FONT><FONT color=#0000ff face=Arial 
  size=2><SPAN class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" 
  size=3><SPAN class=530565313-03072001>:</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>I agree with you about the value of this 
  particular&nbsp;"catch</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>phrase",&nbsp;in that I've always 
  considered&nbsp;ct</SPAN></FONT></SPAN></FONT><FONT color=#0000ff face=Arial 
  size=2><SPAN class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" 
  size=3><SPAN class=530565313-03072001> to be a&nbsp;process, 
  </SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>not an event. Processes occur over time, and if you 
  want to</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>divide that time into "phases", fine - to me this is 
  a design</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>issue.</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>Having said this, people felt that there was a need 
  to require</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>aggregation, etc. This implied a "one shot" ct 
  process, and</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>so others decided that it was necessary to counter 
  balance</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>this with a "polyphasic" / "multiphasic" requirement. 
  I have</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>no problem either way: I believe that the right way 
  to do</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001>ct will depend upon the network 
  technology/configuration.</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=530565313-03072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>Now, as for 
  "proactive": the whole idea, originally, was to</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>make sure that 
  concept of "preparing" for a handover was</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>understood and 
  agreed upon. Why? Well, it seems obvious</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>(to me 
  anyways), that you can always react faster if you are</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>prepared for 
  what's coming. It really is as simple as this.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>In truth, this 
  is not a new concept. As you know, the same</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>approach has 
  been used for years in CDMA.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=530565313-03072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>So, I assume 
  you are not against being prepared, but are</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>perplexed over 
  the brain twisting over nomenclature. So</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=530565313-03072001>am 
  I.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=530565313-03072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=530565313-03072001>Gary</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=819074513-03072001>Best 
  regards,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=819074513-03072001>Phil</SPAN></FONT></DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2></DIV></FONT></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C103D6.6CB1F090--


From owner-seamoby@diameter.org  Tue Jul  3 11:59:15 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10296
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 11:58:42 -0400 (EDT)
Received: (qmail 18763 invoked by alias); 3 Jul 2001 15:39:10 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18757 invoked by uid 200); 3 Jul 2001 15:39:09 -0000
Received: (qmail 18746 invoked from network); 3 Jul 2001 15:39:04 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 15:39:04 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f63Fnm012773
	for <seamoby@diameter.org>; Tue, 3 Jul 2001 11:49:48 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Tue, 3 Jul 2001 11:49:48 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <NZ9SA3YG>; Tue, 3 Jul 2001 11:49:49 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DBD@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Cedric Westphal'" <cedric@IPRG.nokia.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing
Date: Tue, 3 Jul 2001 11:49:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C103D7.C961DB10"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C103D7.C961DB10
Content-Type: text/plain;
	charset="iso-8859-1"

*sigh*

From websters:

2 [pro-reactive] : acting in anticipation of future problems, needs, or
changes

It does not say "finish before", "complete before", or anything like it.

"Soft" and "hard" are cellular terms that have much too much baggage. To
begin with, they are strongly associated with L2 functionality (although, to
be precise, soft handover in CDMA is supported by extensive proactive L3
functions). 

Why do you have so much objection to trying to prepare for a handover? This
is what
ct is all about, preparing an AR to accept a handover so that the service is
not impaired by the handover. The fact that there will always be situations
that cannot be prepared for does not mean that preparation is not
worthwhile. 

This is nonsense - let's toss *all* the terms, and focus on the issue, which
is to develop a ct that enhances handover.

Gary

 
-----Original Message-----
From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
Sent: Tuesday, July 03, 2001 10:30 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]
Cc: 'seamoby'
Subject: Re: [seamoby] Issue #4: Clear, unambiguous definitions missing


Gary: 
Gary Kenward wrote: 
  
Cedric: 
> -----Original Message----- 
> From: Cedric Westphal [mailto:cedric@iprg.nokia.com] 
> Sent: Tuesday, July 03, 2001 3:55 AM 
> To: Nakhjiri Madjid-MNAKHJI1 
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; 
> charliep@iprg.nokia.com 
> Subject: Re: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing 
> 
> 
> Sorry to breach the truce, but here are some comments: 
> 
> Nakhjiri Madjid-MNAKHJI1 wrote: 
> 
> > I suggest we leave this as an open issue, until we meet in IETF. 
> > 
> > Madjid 
> > 
> > -----Original Message----- 
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com] 
> > Sent: Friday, June 29, 2001 10:28 AM 
> > To: 'seamoby' 
> > Subject: [seamoby] Issue #4: Clear, unambiguous definitions missing 
> > Sensitivity: Confidential 
> > 
> > In the interest of moving the requirements forward, I 
> support the change in 
> > the 
> > definitions of "reactive" and "proactive' proposed by Pat: 
> > 
> > Reactive CT: The context transfer process which takes place 
> subsequent 
> > to arrival of a MN's packet at the target AR 
> > 
> > Proactive CT: The context transfer process in which the 
> required contexts 
> > are in place at the target AR  prior to the arrival of MN's 
> packet at target 
> > AR. 
> > 
> 
> reactive sounds good to me, but not proactive. There is a 
From your arguements below you seem to support being proactive, 
it's all the connotations that have been spun around what proactive 
does or not mean that you object to. It's impossible to counter the 
tide of popular belief (just look what has happened with "seamless"). 
Please be assured, there has never been a formal definition of 
"proactive" that included, or implied serialization. Indeed, every 
attempt has been made to avoid this definition. Truthfully, I believe 
that whatever name we chose would end up painted with the same innuendo.
pro-active means to act before. We should agree on that. Now, it seems 
that the event answer to 'before what' is: 'arrival of MN's packet at target
AR'. 
Fine with me. Thus if you define proactive CT this way, there is an implicit

requirement that CT is completed before said event. Fine, we are in the 
process of defining requirements, and I'd accept a 'proactive CT', as you 
define it. 
Then again, why in the universe would you forbid that a CT initiated before 
the 'arrival  of ...' could only complete after. Maybe you don't, but then
don't use 
a word that would actually mean this. 
So at this time - if I am correct in my observation that we all do indeed 
believe that serialization is a bad thing, but that being prepared for 
the actual handover ahead of time is a good thing - we are really involved 
in a nomenclature debate. From my point of view this is a waste of 
our collective energy, but so be it. Let's pick a word. 
"Dynamic" and "static" tends to capture somewhat the attributes of the 
context at different phases, but the terms are too restrictive. An early 
transfer of dynamic context should be allowed if it enhances handover. 
"predictive" doesn't work for me either, as it implies that ct is involved 
with some sort of inductive logic; while there may be an entity attempting 
to "predict" which base/AP/AR the MN will appear on next, it is not part 
of ct. 
So that leaves? Well, how about prophylactic? Hmmm, unlikely to pass the 
scrutiny of the IESG for all the snickers it would incite from the just- 
out-of-high-school crowd.
prophylactic? what I object to is any word that starts with pro- or pre-, 
latin root for before, to mean something that does indeed starts before, 
but can end after. That's why I like 'soft'/'hard', but am open to pretty
much 
anything. 
Take care, 
Cedric. 
  
We are deep into trying to define how the protocol should work, when we 
are supposed to be finishing off the requirements document. Maybe the answer

is to avoid the use of catch phrases, and simply write requirements that 
state what it is that we want to accomplish. 
Cheers, 
Gary 
> consensus for support 
> for several phases in CT. So it seems that the term 
> 'required' needs to be 
> clarified. 
> In the CT phases discussion, the talk is about priority. Some 
> contexts are more 
> important than other. Which is true, but mostly some contexts 
> are more time 
> sensitive 
> than other. Some accounting contexts, which some operator 
> would argue is _very_ 
> important, can arrive later, after the arrival of MN's packet 
> at new AR. This 
> requirement denies this possibility. 
> 
> Solutions: 1) define a static context (configuration state) 
> and a dynamic 
> context (accounting 
> state). Static context is what has to be transfered before 
> the arrival of MN's 
> packet 
> at target AR. Replace 'required' in your definition by 
> 'static', or 'config'. 
> Dynamic is what 
> can be transfered later to fill in the blanks. I have some 
> text on this if you 
> want. 
> 
> -or- 
> 
> 2) one of the issues with proactive/reactive is that it connotes a 
> serialization. pro/before, re/after. 
> There seems to be somewhat of a consensus as to before what 
> and after what 
> (having the 
> newAR default router, or having the newAR receiving packets 
> from the MN). 
> For instance in this proposal, the whole transfer has to be 
> performed _before_ 
> (prior in the 
> text) the arrival of MN's packet at newAR. Other proposals: 
> pre-handoff, 
> post-handoff, same 
> thing. Charlie's proposal: reactive, predictive, also same thing. 
> On the other hand, CT can be initiated before/after, and 
> completed before/after. 
> So, if you take 
> away the initiated after/completed before, you still need at 
> least THREE terms. 
> There is also a consensus on reactive: initiated 
> after/completed after. The 
> issue is with proactive, 
> which means before, and has to cover the CT completed *after* 
> case, which is 
> somewhat 
> counter-intuitive. 
> So here is yet another proposal, which borrows the handoff 
> terminology, and is 
> in everybody's 
> dictionnary: 
> hard CT = reactive CT 
> soft CT = a CT in which the transfer is initiated before the 
> arrival of MN's 
> packet at the target 
> AR. (no mention of completion, covers the initiated before, 
> completed before or 
> after case). 
> proactive CT= the definition up this mail (covers the 
> initiated before/completed 
> before case). 
> 
> Cheers, 
> 
> Cedric. 
> 
> > 
> > Since these are "definitions" and not requirements, I 
> assume that there is 
> > room 
> > for change as we delve into the design process. 
> > 
> > For what it's worth . . . 
> > 
> > Gary 
> 
>

------_=_NextPart_001_01C103D7.C961DB10
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: [seamoby] Issue #4: Clear, unambiguous definitions =
missing</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>*sigh*</FONT>
</P>

<P><FONT SIZE=3D2>From websters:</FONT>
</P>

<P><FONT SIZE=3D2>2 [pro-reactive] : acting in anticipation of future =
problems, needs, or changes</FONT>
</P>

<P><FONT SIZE=3D2>It does not say &quot;finish before&quot;, =
&quot;complete before&quot;, or anything like it.</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Soft&quot; and &quot;hard&quot; are cellular =
terms that have much too much baggage. To begin with, they are strongly =
associated with L2 functionality (although, to be precise, soft =
handover in CDMA is supported by extensive proactive L3 functions). =
</FONT></P>

<P><FONT SIZE=3D2>Why do you have so much objection to trying to =
prepare for a handover? This is what</FONT>
<BR><FONT SIZE=3D2>ct is all about, preparing an AR to accept a =
handover so that the service is not impaired by the handover. The fact =
that there will always be situations that cannot be prepared for does =
not mean that preparation is not worthwhile. </FONT></P>

<P><FONT SIZE=3D2>This is nonsense - let's toss *all* the terms, and =
focus on the issue, which</FONT>
<BR><FONT SIZE=3D2>is to develop a ct that enhances handover.</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Cedric Westphal [<A =
HREF=3D"mailto:cedric@IPRG.nokia.com">mailto:cedric@IPRG.nokia.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, July 03, 2001 10:30 AM</FONT>
<BR><FONT SIZE=3D2>To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: 'seamoby'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [seamoby] Issue #4: Clear, unambiguous =
definitions missing</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Gary: </FONT>
<BR><FONT SIZE=3D2>Gary Kenward wrote: </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>Cedric: </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: Cedric Westphal [<A =
HREF=3D"mailto:cedric@iprg.nokia.com">mailto:cedric@iprg.nokia.com</A>] =
</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, July 03, 2001 3:55 AM </FONT>
<BR><FONT SIZE=3D2>&gt; To: Nakhjiri Madjid-MNAKHJI1 </FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; =
</FONT>
<BR><FONT SIZE=3D2>&gt; charliep@iprg.nokia.com </FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [seamoby] Issue #4: Clear, =
unambiguous </FONT>
<BR><FONT SIZE=3D2>&gt; definitions missing </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Sorry to breach the truce, but here are some =
comments: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Nakhjiri Madjid-MNAKHJI1 wrote: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I suggest we leave this as an open issue, =
until we meet in IETF. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Madjid </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Gary Kenward [<A =
HREF=3D"mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetwor=
ks.com</A>] </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Friday, June 29, 2001 10:28 AM =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: 'seamoby' </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: [seamoby] Issue #4: Clear, =
unambiguous definitions missing </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sensitivity: Confidential </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; In the interest of moving the requirements =
forward, I </FONT>
<BR><FONT SIZE=3D2>&gt; support the change in </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; definitions of &quot;reactive&quot; and =
&quot;proactive' proposed by Pat: </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Reactive CT: The context transfer process =
which takes place </FONT>
<BR><FONT SIZE=3D2>&gt; subsequent </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to arrival of a MN's packet at the target =
AR </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Proactive CT: The context transfer process =
in which the </FONT>
<BR><FONT SIZE=3D2>&gt; required contexts </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; are in place at the target AR&nbsp; prior =
to the arrival of MN's </FONT>
<BR><FONT SIZE=3D2>&gt; packet at target </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; AR. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; reactive sounds good to me, but not proactive. =
There is a </FONT>
<BR><FONT SIZE=3D2>From your arguements below you seem to support being =
proactive, </FONT>
<BR><FONT SIZE=3D2>it's all the connotations that have been spun around =
what proactive </FONT>
<BR><FONT SIZE=3D2>does or not mean that you object to. It's impossible =
to counter the </FONT>
<BR><FONT SIZE=3D2>tide of popular belief (just look what has happened =
with &quot;seamless&quot;). </FONT>
<BR><FONT SIZE=3D2>Please be assured, there has never been a formal =
definition of </FONT>
<BR><FONT SIZE=3D2>&quot;proactive&quot; that included, or implied =
serialization. Indeed, every </FONT>
<BR><FONT SIZE=3D2>attempt has been made to avoid this definition. =
Truthfully, I believe </FONT>
<BR><FONT SIZE=3D2>that whatever name we chose would end up painted =
with the same innuendo.</FONT>
<BR><FONT SIZE=3D2>pro-active means to act before. We should agree on =
that. Now, it seems </FONT>
<BR><FONT SIZE=3D2>that the event answer to 'before what' is: 'arrival =
of MN's packet at target AR'. </FONT>
<BR><FONT SIZE=3D2>Fine with me. Thus if you define proactive CT this =
way, there is an implicit </FONT>
<BR><FONT SIZE=3D2>requirement that CT is completed before said event. =
Fine, we are in the </FONT>
<BR><FONT SIZE=3D2>process of defining requirements, and I'd accept a =
'proactive CT', as you </FONT>
<BR><FONT SIZE=3D2>define it. </FONT>
<BR><FONT SIZE=3D2>Then again, why in the universe would you forbid =
that a CT initiated before </FONT>
<BR><FONT SIZE=3D2>the 'arrival&nbsp; of ...' could only complete =
after. Maybe you don't, but then don't use </FONT>
<BR><FONT SIZE=3D2>a word that would actually mean this. </FONT>
<BR><FONT SIZE=3D2>So at this time - if I am correct in my observation =
that we all do indeed </FONT>
<BR><FONT SIZE=3D2>believe that serialization is a bad thing, but that =
being prepared for </FONT>
<BR><FONT SIZE=3D2>the actual handover ahead of time is a good thing - =
we are really involved </FONT>
<BR><FONT SIZE=3D2>in a nomenclature debate. From my point of view this =
is a waste of </FONT>
<BR><FONT SIZE=3D2>our collective energy, but so be it. Let's pick a =
word. </FONT>
<BR><FONT SIZE=3D2>&quot;Dynamic&quot; and &quot;static&quot; tends to =
capture somewhat the attributes of the </FONT>
<BR><FONT SIZE=3D2>context at different phases, but the terms are too =
restrictive. An early </FONT>
<BR><FONT SIZE=3D2>transfer of dynamic context should be allowed if it =
enhances handover. </FONT>
<BR><FONT SIZE=3D2>&quot;predictive&quot; doesn't work for me either, =
as it implies that ct is involved </FONT>
<BR><FONT SIZE=3D2>with some sort of inductive logic; while there may =
be an entity attempting </FONT>
<BR><FONT SIZE=3D2>to &quot;predict&quot; which base/AP/AR the MN will =
appear on next, it is not part </FONT>
<BR><FONT SIZE=3D2>of ct. </FONT>
<BR><FONT SIZE=3D2>So that leaves? Well, how about prophylactic? Hmmm, =
unlikely to pass the </FONT>
<BR><FONT SIZE=3D2>scrutiny of the IESG for all the snickers it would =
incite from the just- </FONT>
<BR><FONT SIZE=3D2>out-of-high-school crowd.</FONT>
<BR><FONT SIZE=3D2>prophylactic? what I object to is any word that =
starts with pro- or pre-, </FONT>
<BR><FONT SIZE=3D2>latin root for before, to mean something that does =
indeed starts before, </FONT>
<BR><FONT SIZE=3D2>but can end after. That's why I like 'soft'/'hard', =
but am open to pretty much </FONT>
<BR><FONT SIZE=3D2>anything. </FONT>
<BR><FONT SIZE=3D2>Take care, </FONT>
<BR><FONT SIZE=3D2>Cedric. </FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
<BR><FONT SIZE=3D2>We are deep into trying to define how the protocol =
should work, when we </FONT>
<BR><FONT SIZE=3D2>are supposed to be finishing off the requirements =
document. Maybe the answer </FONT>
<BR><FONT SIZE=3D2>is to avoid the use of catch phrases, and simply =
write requirements that </FONT>
<BR><FONT SIZE=3D2>state what it is that we want to accomplish. </FONT>
<BR><FONT SIZE=3D2>Cheers, </FONT>
<BR><FONT SIZE=3D2>Gary </FONT>
<BR><FONT SIZE=3D2>&gt; consensus for support </FONT>
<BR><FONT SIZE=3D2>&gt; for several phases in CT. So it seems that the =
term </FONT>
<BR><FONT SIZE=3D2>&gt; 'required' needs to be </FONT>
<BR><FONT SIZE=3D2>&gt; clarified. </FONT>
<BR><FONT SIZE=3D2>&gt; In the CT phases discussion, the talk is about =
priority. Some </FONT>
<BR><FONT SIZE=3D2>&gt; contexts are more </FONT>
<BR><FONT SIZE=3D2>&gt; important than other. Which is true, but mostly =
some contexts </FONT>
<BR><FONT SIZE=3D2>&gt; are more time </FONT>
<BR><FONT SIZE=3D2>&gt; sensitive </FONT>
<BR><FONT SIZE=3D2>&gt; than other. Some accounting contexts, which =
some operator </FONT>
<BR><FONT SIZE=3D2>&gt; would argue is _very_ </FONT>
<BR><FONT SIZE=3D2>&gt; important, can arrive later, after the arrival =
of MN's packet </FONT>
<BR><FONT SIZE=3D2>&gt; at new AR. This </FONT>
<BR><FONT SIZE=3D2>&gt; requirement denies this possibility. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Solutions: 1) define a static context =
(configuration state) </FONT>
<BR><FONT SIZE=3D2>&gt; and a dynamic </FONT>
<BR><FONT SIZE=3D2>&gt; context (accounting </FONT>
<BR><FONT SIZE=3D2>&gt; state). Static context is what has to be =
transfered before </FONT>
<BR><FONT SIZE=3D2>&gt; the arrival of MN's </FONT>
<BR><FONT SIZE=3D2>&gt; packet </FONT>
<BR><FONT SIZE=3D2>&gt; at target AR. Replace 'required' in your =
definition by </FONT>
<BR><FONT SIZE=3D2>&gt; 'static', or 'config'. </FONT>
<BR><FONT SIZE=3D2>&gt; Dynamic is what </FONT>
<BR><FONT SIZE=3D2>&gt; can be transfered later to fill in the blanks. =
I have some </FONT>
<BR><FONT SIZE=3D2>&gt; text on this if you </FONT>
<BR><FONT SIZE=3D2>&gt; want. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -or- </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 2) one of the issues with proactive/reactive is =
that it connotes a </FONT>
<BR><FONT SIZE=3D2>&gt; serialization. pro/before, re/after. </FONT>
<BR><FONT SIZE=3D2>&gt; There seems to be somewhat of a consensus as to =
before what </FONT>
<BR><FONT SIZE=3D2>&gt; and after what </FONT>
<BR><FONT SIZE=3D2>&gt; (having the </FONT>
<BR><FONT SIZE=3D2>&gt; newAR default router, or having the newAR =
receiving packets </FONT>
<BR><FONT SIZE=3D2>&gt; from the MN). </FONT>
<BR><FONT SIZE=3D2>&gt; For instance in this proposal, the whole =
transfer has to be </FONT>
<BR><FONT SIZE=3D2>&gt; performed _before_ </FONT>
<BR><FONT SIZE=3D2>&gt; (prior in the </FONT>
<BR><FONT SIZE=3D2>&gt; text) the arrival of MN's packet at newAR. =
Other proposals: </FONT>
<BR><FONT SIZE=3D2>&gt; pre-handoff, </FONT>
<BR><FONT SIZE=3D2>&gt; post-handoff, same </FONT>
<BR><FONT SIZE=3D2>&gt; thing. Charlie's proposal: reactive, =
predictive, also same thing. </FONT>
<BR><FONT SIZE=3D2>&gt; On the other hand, CT can be initiated =
before/after, and </FONT>
<BR><FONT SIZE=3D2>&gt; completed before/after. </FONT>
<BR><FONT SIZE=3D2>&gt; So, if you take </FONT>
<BR><FONT SIZE=3D2>&gt; away the initiated after/completed before, you =
still need at </FONT>
<BR><FONT SIZE=3D2>&gt; least THREE terms. </FONT>
<BR><FONT SIZE=3D2>&gt; There is also a consensus on reactive: =
initiated </FONT>
<BR><FONT SIZE=3D2>&gt; after/completed after. The </FONT>
<BR><FONT SIZE=3D2>&gt; issue is with proactive, </FONT>
<BR><FONT SIZE=3D2>&gt; which means before, and has to cover the CT =
completed *after* </FONT>
<BR><FONT SIZE=3D2>&gt; case, which is </FONT>
<BR><FONT SIZE=3D2>&gt; somewhat </FONT>
<BR><FONT SIZE=3D2>&gt; counter-intuitive. </FONT>
<BR><FONT SIZE=3D2>&gt; So here is yet another proposal, which borrows =
the handoff </FONT>
<BR><FONT SIZE=3D2>&gt; terminology, and is </FONT>
<BR><FONT SIZE=3D2>&gt; in everybody's </FONT>
<BR><FONT SIZE=3D2>&gt; dictionnary: </FONT>
<BR><FONT SIZE=3D2>&gt; hard CT =3D reactive CT </FONT>
<BR><FONT SIZE=3D2>&gt; soft CT =3D a CT in which the transfer is =
initiated before the </FONT>
<BR><FONT SIZE=3D2>&gt; arrival of MN's </FONT>
<BR><FONT SIZE=3D2>&gt; packet at the target </FONT>
<BR><FONT SIZE=3D2>&gt; AR. (no mention of completion, covers the =
initiated before, </FONT>
<BR><FONT SIZE=3D2>&gt; completed before or </FONT>
<BR><FONT SIZE=3D2>&gt; after case). </FONT>
<BR><FONT SIZE=3D2>&gt; proactive CT=3D the definition up this mail =
(covers the </FONT>
<BR><FONT SIZE=3D2>&gt; initiated before/completed </FONT>
<BR><FONT SIZE=3D2>&gt; before case). </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Cheers, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Cedric. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Since these are &quot;definitions&quot; =
and not requirements, I </FONT>
<BR><FONT SIZE=3D2>&gt; assume that there is </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; room </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for change as we delve into the design =
process. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; For what it's worth . . . </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Gary </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C103D7.C961DB10--


From owner-seamoby@diameter.org  Tue Jul  3 12:06:03 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10626
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 12:06:01 -0400 (EDT)
Received: (qmail 18868 invoked by alias); 3 Jul 2001 15:41:27 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18862 invoked by uid 200); 3 Jul 2001 15:41:27 -0000
Received: (qmail 18854 invoked from network); 3 Jul 2001 15:41:22 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 15:41:22 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA03669;
	Tue, 3 Jul 2001 08:52:26 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f63FqPo07616;
	Tue, 3 Jul 2001 08:52:25 -0700
X-mProtect:  Tue, 3 Jul 2001 08:52:25 -0700 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdwdSEha; Tue, 03 Jul 2001 08:52:24 PDT
Message-ID: <3B41EA2B.3D9E377A@iprg.nokia.com>
Date: Tue, 03 Jul 2001 08:52:11 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gary Kenward <gkenward@nortelnetworks.com>
CC: "'seamoby'" <seamoby@diameter.org>
Subject: Re: [seamoby] Issue #4: Clear, unambiguous definitions missing
References: <9FBD322B7824D511B36900508BF93C9C9F5DBB@zcard031.ca.nortel.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Gary,

allow me to rephrase this in a more constructive manner.
In order to clarify the proactive/reactive issue, some definitions were
proposed.
The proposed definitions do meet their goals, and offer satisfying as
well as
intuitive definitions of proactive and reactive context transfer.
Yet, they do exclude a category of context transfers that should be part
of the
CT requirements, namely context transfer that are initiated before the
'arrival
of MN's packets to the mobile node' and completed after such an event.
Such CT would be neither reactive, nor proactive. It would occur for
instance
if some accounting QoS context is transfered after the hand off
is completed, whereas all the QoS configuration was transfered before.

The requirement draft gives the impression that two CT modes MUST be
supported,
one 4.5 proactive, one 4.4 reactive, and these only. The combination of
these two modes is described as
an unstable situation, or a fall back mechanism. This is what I disagree
with.
It could be per design that the CT is initiated before the 'arrival of
packets at target AR'
and completes afterward.

While I agree with these two requirements, I think a third type of CT at
least SHOULD be
supported.

I suggest:
-get rid of : 'It is useful to consider two modes of operation for
context transfer: proactive and reactive.

-add: 4.5 and 1/2, The context transfer framework SHOULD support a
'soft' context transfer.

-after the paragraph 'In many situations, there is no forewarning...'
add:

In some situation, a soft context transfer, namely a combination of
reactive and proactive may be used. Some part of the context
can be transfered before the arrival of MN's packets to the target AR
while the remaining context
is transfered afterwards. This situation may arise when some parts of
the context are more urgent than
other, and should be transfered before the arrival of MN's packet,
whereas there is no such
requirement on the remaing parts of the context transfer. [or add a
pointer to the
multi-phase support requirement].

-replace in the following paragraph: 'This also means that a' by 'A'.





From owner-seamoby@diameter.org  Tue Jul  3 13:23:27 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13055
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 13:23:24 -0400 (EDT)
Received: (qmail 19962 invoked by alias); 3 Jul 2001 17:06:56 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 19956 invoked by uid 200); 3 Jul 2001 17:06:56 -0000
Received: (qmail 19951 invoked from network); 3 Jul 2001 17:06:54 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 17:06:54 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f63HHm009151
	for <seamoby@diameter.org>; Tue, 3 Jul 2001 13:17:48 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Tue, 3 Jul 2001 13:17:55 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <NZ9SARD5>; Tue, 3 Jul 2001 13:17:55 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DBF@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Cedric Westphal'" <cedric@IPRG.nokia.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing
Date: Tue, 3 Jul 2001 13:17:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C103E4.177A6A90"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C103E4.177A6A90
Content-Type: text/plain;
	charset="iso-8859-1"

Cedric:

> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> Sent: Tuesday, July 03, 2001 11:52 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: Re: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing
> 
> 
> Gary,
> 
> allow me to rephrase this in a more constructive manner.
> In order to clarify the proactive/reactive issue, some 
> definitions were
> proposed.
> The proposed definitions do meet their goals, and offer satisfying as
> well as
> intuitive definitions of proactive and reactive context transfer.
> Yet, they do exclude a category of context transfers that 
> should be part
> of the
> CT requirements, namely context transfer that are initiated before the
> 'arrival
> of MN's packets to the mobile node' and completed after such an event.

This is not true. I simply do not understand where you see this "exclusion".
You are basing your assessment not on the current definition in the
requirements, but on the email exchanges that have been going on.
Personally, my preference
(as I have stated many times) is not to tie ct only to an initiating event
and
to define the completion in terms of a performance requirement.

The current definitions are not perfect. They have been word smythed many
times, and perhaps should be again. I say perhaps, because it is not clear
to me that there is any simple model for ct that will meet everyone's
expectations.
This is one of the reasons that the definitions are as vague as they are.

Below is the heart of the definitions as they currently exist in the draft.
Please explain to me, where in the first paragraph does it say that anything
about the "arrival of the packet at the AR". Proactive is initiated by some
"early warning" event, exactly what event, is tbd and very system dependent.

So much so, that some systems will not provide this early warning and 
the only mode for ct will be reactive. Reactive is initiated by 
a handover event. In some systems, the start of a handover will be available
at L3 for ct, in other systems, other events, such as "link establishment",
"route update", or "first packet arrival", may have to be used. 

   With proactive context transfer, the context is made available
   to an AR before it is needed. This means that the context is
   available at the AR before it is required to forward the first
   packet arrival in the MN's traffic. Proactive context transfer is
   coupled to mobile handover only by the requirement that the context 
   be in place before the handover of the MN's traffic is complete.
   
   With reactive context transfer, the context is made available to
   an AR when the need is imminent. The implication here is that the 
   initiation of a handover, or some event soon after initiation,
   triggers a reactive context transfer. Depending upon the network
   configuration, the MN's velocity and the behaviour of the mobility
   solution, a reactive context transfer may or may not complete quickly
   enough for the new forwarding AR to provide a consistent service to
   the first packets of the re-directed traffic. 

> Such CT would be neither reactive, nor proactive. It would occur for
> instance
> if some accounting QoS context is transferred after the hand off
> is completed, whereas all the QoS configuration was transferred before.

And if the QoS configuration includes metering information? What you
describe
about, is to me, a two phase proactive ct (actually probably m-phase,
depending
on how many separate ct transfers you do).
 
> 
> The requirement draft gives the impression that two CT modes MUST be
> supported,
> one 4.5 proactive, one 4.4 reactive, and these only. The 

Proactive and reactive cover the cases you cite, and are actually more
comprehensive in their coverage then your definitions for your cases omit a
number of scenarios. We could enumerate each scenario, but it *was* hoped
that
this would be part of the design process, not the requirements process.

The requirement, btw, is that the ct protocol support both modes, which
means that
the design must support both modes. The requirement explicitly states that
the use
of proactive is optional. The objective is to have one ct protocol design,
not a ct
protocol for each envisioned application.

   As the proactive mode of context transfer is an enhancement, there may be

   situations where the reactive mode is considered a sufficient solution. 
   While it is required that the context transfer protocol support proactive
   mode, its use is optional.

> combination of
> these two modes is described as
> an unstable situation, or a fall back mechanism. This is what 

??? Ok, let me try it this way: the network does its best to prepare
candidate
ARs for a possible handover of an MNs traffic. It does whatever it can do in
advance simply to keep the actually work load to be done during handover to
a 
minimum (this is proactive). However, in the mean time, the MN moves around
the corner of a building in the canyons of NYC, and *boom*, the MN is
illuminated
by a completely different cell, with no warning. Now, for arguments sake, 
imagine that the new cell is connected to a different AR. Guess what? All
the
preparation done by the network is for naught, and the network must "react"
to
the new situation. 

In short, no matter how you phrase it, the network must *always* be able to
"react"
to unexpected changes in the forwarding path. 

> I disagree
> with.
> It could be per design that the CT is initiated before the 'arrival of
> packets at target AR'
> and completes afterward.

Fine with me. Not an optimal design, but this is going to happen. Again,
the current definitions do cover this. Perhaps there is specific wording
in the current requirement which you would like changed?

> 
> While I agree with these two requirements, I think a third 
> type of CT at
> least SHOULD be
> supported.
> 
> I suggest:
> -get rid of : 'It is useful to consider two modes of operation for
> context transfer: proactive and reactive.
> 
> -add: 4.5 and 1/2, The context transfer framework SHOULD support a
> 'soft' context transfer.

Nope. I will not agree with using the word "soft", and I do recall
from previous discussions that there are others that agree.

> 
> -after the paragraph 'In many situations, there is no forewarning...'
> add:
> 
> In some situation, a soft context transfer, namely a combination of
> reactive and proactive may be used. Some part of the context

Note, in case it has slipped by, proactive and reactive are NOT two phases
of ct. They are non-exclusive *modes* of ct.

> can be transferred before the arrival of MN's packets to the target AR
> while the remaining context
> is transfered afterwards. This situation may arise when some parts of
> the context are more urgent than
> other, and should be transfered before the arrival of MN's packet,
> whereas there is no such
> requirement on the remaing parts of the context transfer. [or add a
> pointer to the
> multi-phase support requirement].

We clearly have a newly identified requirement for "non-critical" context 
transfer (e.g. some suggest accounting info). IMHO, this is already
covered, however, I see no problem in extending the current definitions 
to be more explicit. I do not see that it is justification for starting
up with new definitions.

Gary

> 
> -replace in the following paragraph: 'This also means that a' by 'A'.
> 
> 
> 
> 

------_=_NextPart_001_01C103E4.177A6A90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: [seamoby] Issue #4: Clear, unambiguous definitions =
missing</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Cedric:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Cedric Westphal [<A =
HREF=3D"mailto:cedric@IPRG.nokia.com">mailto:cedric@IPRG.nokia.com</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, July 03, 2001 11:52 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'seamoby'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [seamoby] Issue #4: Clear, =
unambiguous </FONT>
<BR><FONT SIZE=3D2>&gt; definitions missing</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Gary,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; allow me to rephrase this in a more =
constructive manner.</FONT>
<BR><FONT SIZE=3D2>&gt; In order to clarify the proactive/reactive =
issue, some </FONT>
<BR><FONT SIZE=3D2>&gt; definitions were</FONT>
<BR><FONT SIZE=3D2>&gt; proposed.</FONT>
<BR><FONT SIZE=3D2>&gt; The proposed definitions do meet their goals, =
and offer satisfying as</FONT>
<BR><FONT SIZE=3D2>&gt; well as</FONT>
<BR><FONT SIZE=3D2>&gt; intuitive definitions of proactive and reactive =
context transfer.</FONT>
<BR><FONT SIZE=3D2>&gt; Yet, they do exclude a category of context =
transfers that </FONT>
<BR><FONT SIZE=3D2>&gt; should be part</FONT>
<BR><FONT SIZE=3D2>&gt; of the</FONT>
<BR><FONT SIZE=3D2>&gt; CT requirements, namely context transfer that =
are initiated before the</FONT>
<BR><FONT SIZE=3D2>&gt; 'arrival</FONT>
<BR><FONT SIZE=3D2>&gt; of MN's packets to the mobile node' and =
completed after such an event.</FONT>
</P>

<P><FONT SIZE=3D2>This is not true. I simply do not understand where =
you see this &quot;exclusion&quot;.</FONT>
<BR><FONT SIZE=3D2>You are basing your assessment not on the current =
definition in the requirements, but on the email exchanges that have =
been going on. Personally, my preference</FONT></P>

<P><FONT SIZE=3D2>(as I have stated many times) is not to tie ct only =
to an initiating event and</FONT>
<BR><FONT SIZE=3D2>to define the completion in terms of a performance =
requirement.</FONT>
</P>

<P><FONT SIZE=3D2>The current definitions are not perfect. They have =
been word smythed many</FONT>
<BR><FONT SIZE=3D2>times, and perhaps should be again. I say perhaps, =
because it is not clear</FONT>
<BR><FONT SIZE=3D2>to me that there is any simple model for ct that =
will meet everyone's expectations.</FONT>
<BR><FONT SIZE=3D2>This is one of the reasons that the definitions are =
as vague as they are.</FONT>
</P>

<P><FONT SIZE=3D2>Below is the heart of the definitions as they =
currently exist in the draft.</FONT>
<BR><FONT SIZE=3D2>Please explain to me, where in the first paragraph =
does it say that anything</FONT>
<BR><FONT SIZE=3D2>about the &quot;arrival of the packet at the =
AR&quot;. Proactive is initiated by some</FONT>
<BR><FONT SIZE=3D2>&quot;early warning&quot; event, exactly what event, =
is tbd and very system dependent. </FONT>
<BR><FONT SIZE=3D2>So much so, that some systems will not provide this =
early warning and </FONT>
<BR><FONT SIZE=3D2>the only mode for ct will be reactive. Reactive is =
initiated by </FONT>
<BR><FONT SIZE=3D2>a handover event. In some systems, the start of a =
handover will be available</FONT>
<BR><FONT SIZE=3D2>at L3 for ct, in other systems, other events, such =
as &quot;link establishment&quot;,</FONT>
<BR><FONT SIZE=3D2>&quot;route update&quot;, or &quot;first packet =
arrival&quot;, may have to be used. </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; With proactive context transfer, the =
context is made available</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; to an AR before it is needed. This =
means that the context is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; available at the AR before it is =
required to forward the first</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; packet arrival in the MN's traffic. =
Proactive context transfer is</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; coupled to mobile handover only by the =
requirement that the context </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; be in place before the handover of the =
MN's traffic is complete.</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; With reactive context transfer, the =
context is made available to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; an AR when the need is imminent. The =
implication here is that the </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; initiation of a handover, or some event =
soon after initiation,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; triggers a reactive context transfer. =
Depending upon the network</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; configuration, the MN's velocity and =
the behaviour of the mobility</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; solution, a reactive context transfer =
may or may not complete quickly</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; enough for the new forwarding AR to =
provide a consistent service to</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; the first packets of the re-directed =
traffic. </FONT>
</P>

<P><FONT SIZE=3D2>&gt; Such CT would be neither reactive, nor =
proactive. It would occur for</FONT>
<BR><FONT SIZE=3D2>&gt; instance</FONT>
<BR><FONT SIZE=3D2>&gt; if some accounting QoS context is transferred =
after the hand off</FONT>
<BR><FONT SIZE=3D2>&gt; is completed, whereas all the QoS configuration =
was transferred before.</FONT>
</P>

<P><FONT SIZE=3D2>And if the QoS configuration includes metering =
information? What you describe</FONT>
<BR><FONT SIZE=3D2>about, is to me, a two phase proactive ct (actually =
probably m-phase, depending</FONT>
<BR><FONT SIZE=3D2>on how many separate ct transfers you do).</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The requirement draft gives the impression that =
two CT modes MUST be</FONT>
<BR><FONT SIZE=3D2>&gt; supported,</FONT>
<BR><FONT SIZE=3D2>&gt; one 4.5 proactive, one 4.4 reactive, and these =
only. The </FONT>
</P>

<P><FONT SIZE=3D2>Proactive and reactive cover the cases you cite, and =
are actually more comprehensive in their coverage then your definitions =
for your cases omit a</FONT></P>

<P><FONT SIZE=3D2>number of scenarios. We could enumerate each =
scenario, but it *was* hoped that</FONT>
<BR><FONT SIZE=3D2>this would be part of the design process, not the =
requirements process.</FONT>
</P>

<P><FONT SIZE=3D2>The requirement, btw, is that the ct protocol support =
both modes, which means that</FONT>
<BR><FONT SIZE=3D2>the design must support both modes. The requirement =
explicitly states that the use</FONT>
<BR><FONT SIZE=3D2>of proactive is optional. The objective is to have =
one ct protocol design, not a ct</FONT>
<BR><FONT SIZE=3D2>protocol for each envisioned application.</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp; As the proactive mode of context =
transfer is an enhancement, there may be </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; situations where the reactive mode is =
considered a sufficient solution. </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; While it is required that the context =
transfer protocol support proactive</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; mode, its use is optional.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; combination of</FONT>
<BR><FONT SIZE=3D2>&gt; these two modes is described as</FONT>
<BR><FONT SIZE=3D2>&gt; an unstable situation, or a fall back =
mechanism. This is what </FONT>
</P>

<P><FONT SIZE=3D2>??? Ok, let me try it this way: the network does its =
best to prepare candidate</FONT>
<BR><FONT SIZE=3D2>ARs for a possible handover of an MNs traffic. It =
does whatever it can do in</FONT>
<BR><FONT SIZE=3D2>advance simply to keep the actually work load to be =
done during handover to a </FONT>
<BR><FONT SIZE=3D2>minimum (this is proactive). However, in the mean =
time, the MN moves around</FONT>
<BR><FONT SIZE=3D2>the corner of a building in the canyons of NYC, and =
*boom*, the MN is illuminated</FONT>
<BR><FONT SIZE=3D2>by a completely different cell, with no warning. =
Now, for arguments sake, </FONT>
<BR><FONT SIZE=3D2>imagine that the new cell is connected to a =
different AR. Guess what? All the</FONT>
<BR><FONT SIZE=3D2>preparation done by the network is for naught, and =
the network must &quot;react&quot; to</FONT>
<BR><FONT SIZE=3D2>the new situation. </FONT>
</P>

<P><FONT SIZE=3D2>In short, no matter how you phrase it, the network =
must *always* be able to &quot;react&quot;</FONT>
<BR><FONT SIZE=3D2>to unexpected changes in the forwarding path. =
</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I disagree</FONT>
<BR><FONT SIZE=3D2>&gt; with.</FONT>
<BR><FONT SIZE=3D2>&gt; It could be per design that the CT is initiated =
before the 'arrival of</FONT>
<BR><FONT SIZE=3D2>&gt; packets at target AR'</FONT>
<BR><FONT SIZE=3D2>&gt; and completes afterward.</FONT>
</P>

<P><FONT SIZE=3D2>Fine with me. Not an optimal design, but this is =
going to happen. Again,</FONT>
<BR><FONT SIZE=3D2>the current definitions do cover this. Perhaps there =
is specific wording</FONT>
<BR><FONT SIZE=3D2>in the current requirement which you would like =
changed?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; While I agree with these two requirements, I =
think a third </FONT>
<BR><FONT SIZE=3D2>&gt; type of CT at</FONT>
<BR><FONT SIZE=3D2>&gt; least SHOULD be</FONT>
<BR><FONT SIZE=3D2>&gt; supported.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I suggest:</FONT>
<BR><FONT SIZE=3D2>&gt; -get rid of : 'It is useful to consider two =
modes of operation for</FONT>
<BR><FONT SIZE=3D2>&gt; context transfer: proactive and =
reactive.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -add: 4.5 and 1/2, The context transfer =
framework SHOULD support a</FONT>
<BR><FONT SIZE=3D2>&gt; 'soft' context transfer.</FONT>
</P>

<P><FONT SIZE=3D2>Nope. I will not agree with using the word =
&quot;soft&quot;, and I do recall</FONT>
<BR><FONT SIZE=3D2>from previous discussions that there are others that =
agree.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -after the paragraph 'In many situations, there =
is no forewarning...'</FONT>
<BR><FONT SIZE=3D2>&gt; add:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; In some situation, a soft context transfer, =
namely a combination of</FONT>
<BR><FONT SIZE=3D2>&gt; reactive and proactive may be used. Some part =
of the context</FONT>
</P>

<P><FONT SIZE=3D2>Note, in case it has slipped by, proactive and =
reactive are NOT two phases</FONT>
<BR><FONT SIZE=3D2>of ct. They are non-exclusive *modes* of ct.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; can be transferred before the arrival of MN's =
packets to the target AR</FONT>
<BR><FONT SIZE=3D2>&gt; while the remaining context</FONT>
<BR><FONT SIZE=3D2>&gt; is transfered afterwards. This situation may =
arise when some parts of</FONT>
<BR><FONT SIZE=3D2>&gt; the context are more urgent than</FONT>
<BR><FONT SIZE=3D2>&gt; other, and should be transfered before the =
arrival of MN's packet,</FONT>
<BR><FONT SIZE=3D2>&gt; whereas there is no such</FONT>
<BR><FONT SIZE=3D2>&gt; requirement on the remaing parts of the context =
transfer. [or add a</FONT>
<BR><FONT SIZE=3D2>&gt; pointer to the</FONT>
<BR><FONT SIZE=3D2>&gt; multi-phase support requirement].</FONT>
</P>

<P><FONT SIZE=3D2>We clearly have a newly identified requirement for =
&quot;non-critical&quot; context </FONT>
<BR><FONT SIZE=3D2>transfer (e.g. some suggest accounting info). IMHO, =
this is already</FONT>
<BR><FONT SIZE=3D2>covered, however, I see no problem in extending the =
current definitions </FONT>
<BR><FONT SIZE=3D2>to be more explicit. I do not see that it is =
justification for starting</FONT>
<BR><FONT SIZE=3D2>up with new definitions.</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -replace in the following paragraph: 'This also =
means that a' by 'A'.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C103E4.177A6A90--


From owner-seamoby@diameter.org  Tue Jul  3 17:27:59 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05999
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 17:27:57 -0400 (EDT)
Received: (qmail 20713 invoked by alias); 3 Jul 2001 21:09:46 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20707 invoked by uid 200); 3 Jul 2001 21:09:46 -0000
Received: (qmail 20697 invoked from network); 3 Jul 2001 21:09:44 -0000
Received: from motgate4.mot.com (144.189.100.102)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 21:09:44 -0000
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id OAA26219 for <seamoby@cdma-2000.org>; Tue, 3 Jul 2001 14:08:51 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id OAA28320 for <seamoby@cdma-2000.org>; Tue, 3 Jul 2001 14:01:49 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <N53YV54Q>; Tue, 3 Jul 2001 16:08:51 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E52@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'David R. Oran'" <oran@cisco.com>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>,
        "'Rajeev Koodli'" <rajeev@IPRG.nokia.com>
Cc: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'Charles E. Perkins'" <charliep@IPRG.nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: FW: [seamoby] CT trigger or CT completion? was:  proactive an
	d re active CT definitions
Date: Tue, 3 Jul 2001 16:08:49 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi David,

Just out of curiosity, why is new downlink is more important than 
new uplink?

Madjid

-----Original Message-----
From: David R. Oran [mailto:oran@cisco.com]
Sent: Tuesday, July 03, 2001 7:29 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; 'Rajeev Koodli'
Cc: 'Kulwinder Atwal'; 'Charles E. Perkins'; seamoby@cdma-2000.org
Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive
and re active CT definitions


Sorry for joining in late. Just a small comment. While I generally like
the idea of explaining the initiation and state management for context
transfer in terms of mobile link establishment, it is very important to
keep in mind that mobile link establishment may not be symmetric or
atomic with respect the the context transfer state machines. I think we
need to consider the definitions and overall model as if there were FOUR
links, not two:
 - old downlink
 - old uplink
 - new downlink
 - new uplink

It seems to me you usually can't start context transfer until the new
downlink is operational, at least at layer 2, (since the mobile doesn't
know really where it might move until then), and you need to complete
context transfer soon after the new uplink is operational, or you don't
get much benefit.

Perhaps if we talked in terms of these four links, plus the link
betweeen oldAR and newAR (which we can probably treat as symmetric
because it's on the non-mobile part of the net) we can more directly
discuss the timing and state machines for context transfer rather than
relying on somewhat slippery notions like "proactive" versus "reactive".

One exception to the above that may be worth at covering at least for
completeness, is true "predictive" context transfer, where the system
tries to predict where the mobile might show up before it even tries to
move. The model should not preclude that option, impractical as it may
be on some wireless systems.

Dave.

> -----Original Message-----
> From: owner-seamoby@diameter.org 
> [mailto:owner-seamoby@diameter.org] On Behalf Of Nakhjiri 
> Madjid-MNAKHJI1
> Sent: Thursday, June 28, 2001 11:58 AM
> To: 'Pat Calhoun'; Rajeev Koodli
> Cc: Kulwinder Atwal; Nakhjiri Madjid-MNAKHJI1; 'Charles E. 
> Perkins'; 'seamoby@cdma-2000.org'
> Subject: RE: FW: [seamoby] CT trigger or CT completion? was: 
> proactive and re active CT definitions
> 
> 
> I don't like this one, I seem to be chasing a moving target 
> (definition of 
> reactive, proactive). Last week we were talking about whether 
> to use link establishment or not, this week it is about 
> default router.
> 
> I started to like Charlie's definition based on link 
> establishment, (however, we accepted that by link we are 
> talking about L2) since L2 establishment is more crisp than 
> completed handover. and we explored different cases, so we 
> don't miss all the cases. The draft versus Charlie's 
> definition of reactive/ proactive 
> definitions in the two turned out to cover different
> set of scenarios without changing the outcome too much. 
> 
>  I don't see how this new definition that pop up everyday are 
> making the CT better.
> 
> I am the newAR, How long do I have to wait until I make sure 
> I am the default router, say in a FMIPv6 case: until I get
> the NA and make sure MN has a valid newCoA?
> What if the MN still has to use its oldCoA and a tunnel 
> between newAR and oldAR, how long do I have to wait to start CT, this 
> introduces unnecessary delay for CT.
> 
> Another confusing thing is folks on the list keep using their 
> own favorite words and definitions in the continuing 
> conversations without paying attention what the other ends 
> understanding of that word is,
> 
> Lets finish off the link establishment discussion and if it
> is not good enough, see what is better, the way it is going
> I am not sure we are making a lot of progress in wrapping things up.
> 
> Madjid
> 
> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Thursday, June 28, 2001 8:36 AM
> To: Rajeev Koodli
> Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri 
> Madjid-MNAKHJI1'; 'Charles E. Perkins'; 'seamoby@cdma-2000.org'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: 
> proactive and re active CT definitions
> 
> 
> > > How is this:
> > >
> > > Pre-Handoff Context Transfer: The Context Transfer is initiated 
> > > prior to
> the
> > > newAR becomes the MN's default router.
> > >
> > > Post-Handoff Context Transfer:  The Context Transfer is initiated 
> > > after
> the
> > > newAR becomes the MN's default router.
> > >
> > > -Kulwinder.
> > >
> > >
> > 
> > Rajeev: This would work for me.  May be we should ask PatC on how to
> proceed
> > next?
> 
> what do folks think about using this terminology? Is this 
> preferred over the existing terminology in the draft?
> 
> PatC
> 


From owner-seamoby@diameter.org  Tue Jul  3 17:57:14 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24283
	for <seamoby-archive@odin.ietf.org>; Tue, 3 Jul 2001 17:57:12 -0400 (EDT)
Received: (qmail 21212 invoked by alias); 3 Jul 2001 21:44:31 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 21206 invoked by uid 200); 3 Jul 2001 21:44:31 -0000
Received: (qmail 21201 invoked from network); 3 Jul 2001 21:44:29 -0000
Received: from motgate2.mot.com (136.182.1.10)
  by c900656-a.plstn1.sfba.home.com with SMTP; 3 Jul 2001 21:44:29 -0000
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA05577 for <seamoby@diameter.org>; Tue, 3 Jul 2001 14:56:09 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA06941 for <seamoby@diameter.org>; Tue, 3 Jul 2001 14:56:09 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <MZY3LMK6>; Tue, 3 Jul 2001 16:56:09 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E53@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Cedric Westphal'" <cedric@iprg.nokia.com>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'seamoby'" <seamoby@diameter.org>, charliep@iprg.nokia.com
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing
Date: Tue, 3 Jul 2001 16:55:45 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

Cedric,

I actually liked the cease fire, for the past three months we have 
opened the proactive/ reactive issue many times.
We talked about timing, reliability and other things,
 and time and after time we came back to the same discussion:

 CT's timing and its relation with handover

The issue has not been resolved, since different people have
different mental image about the sequence of events during
Handover and that impacts the way they want to see CT happen.

As I said many times it does not matter what scenario is called reactive or
whether reactive is post-A or post-B. 

The requirements need to consider the events, cover all the scenarios and
make CT as good of optimization as possible and remember that
this is supposed to be optimization over the no-CT case.

The nomenclature is less important at this point.

The last round of email discussion has concluded that we should
discuss this face to face to prevent going into cycles and having
people staring at their monitors for new proactive/ reactive that
might pop up on the list any minute.

So please lets not breach the truce, each one of us would have more
time to think about what we want out of CT in the meantime :)

Madjid


-----Original Message-----
From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
Sent: Tuesday, July 03, 2001 2:55 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Gary Kenward'; 'seamoby'; charliep@iprg.nokia.com
Subject: Re: [seamoby] Issue #4: Clear, unambiguous definitions missing


Sorry to breach the truce, but here are some comments:

Nakhjiri Madjid-MNAKHJI1 wrote:

> I suggest we leave this as an open issue, until we meet in IETF.
>
> Madjid
>
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Friday, June 29, 2001 10:28 AM
> To: 'seamoby'
> Subject: [seamoby] Issue #4: Clear, unambiguous definitions missing
> Sensitivity: Confidential
>
> In the interest of moving the requirements forward, I support the change
in
> the
> definitions of "reactive" and "proactive' proposed by Pat:
>
> Reactive CT: The context transfer process which takes place subsequent
> to arrival of a MN's packet at the target AR
>
> Proactive CT: The context transfer process in which the required contexts
> are in place at the target AR  prior to the arrival of MN's packet at
target
> AR.
>

reactive sounds good to me, but not proactive. There is a consensus for
support
for several phases in CT. So it seems that the term 'required' needs to be
clarified.
In the CT phases discussion, the talk is about priority. Some contexts are
more
important than other. Which is true, but mostly some contexts are more time
sensitive
than other. Some accounting contexts, which some operator would argue is
_very_
important, can arrive later, after the arrival of MN's packet at new AR.
This
requirement denies this possibility.

Solutions: 1) define a static context (configuration state) and a dynamic
context (accounting
state). Static context is what has to be transfered before the arrival of
MN's
packet
at target AR. Replace 'required' in your definition by 'static', or
'config'.
Dynamic is what
can be transfered later to fill in the blanks. I have some text on this if
you
want.

-or-

2) one of the issues with proactive/reactive is that it connotes a
serialization. pro/before, re/after.
There seems to be somewhat of a consensus as to before what and after what
(having the
newAR default router, or having the newAR receiving packets from the MN).
For instance in this proposal, the whole transfer has to be performed
_before_
(prior in the
text) the arrival of MN's packet at newAR. Other proposals: pre-handoff,
post-handoff, same
thing. Charlie's proposal: reactive, predictive, also same thing.
On the other hand, CT can be initiated before/after, and completed
before/after.
So, if you take
away the initiated after/completed before, you still need at least THREE
terms.
There is also a consensus on reactive: initiated after/completed after. The
issue is with proactive,
which means before, and has to cover the CT completed *after* case, which is
somewhat
counter-intuitive.
So here is yet another proposal, which borrows the handoff terminology, and
is
in everybody's
dictionnary:
hard CT = reactive CT
soft CT = a CT in which the transfer is initiated before the arrival of MN's
packet at the target
AR. (no mention of completion, covers the initiated before, completed before
or
after case).
proactive CT= the definition up this mail (covers the initiated
before/completed
before case).

Cheers,

Cedric.

>
> Since these are "definitions" and not requirements, I assume that there is
> room
> for change as we delve into the design process.
>
> For what it's worth . . .
>
> Gary


From owner-seamoby@diameter.org  Wed Jul  4 03:13:52 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01708
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 03:13:51 -0400 (EDT)
Received: (qmail 22549 invoked by alias); 4 Jul 2001 07:02:07 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 22543 invoked by uid 200); 4 Jul 2001 07:02:07 -0000
Received: (qmail 22538 invoked from network); 4 Jul 2001 07:02:05 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 07:02:05 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f647EAI03967
	for <seamoby@cdma-2000.org>; Wed, 4 Jul 2001 10:14:10 +0300 (EET DST)
Received: from esebh24nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T5489d3fa67ac158f2313e2@esvir03nok.nokia.com>;
 Wed, 4 Jul 2001 10:13:43 +0300
Received: by esebh24nok with Internet Mail Service (5.5.2652.78)
	id <MV1B3DTJ>; Wed, 4 Jul 2001 10:13:43 +0300
Message-ID: <01D91AFB08B6D211BFD00008C7EABAE10680B265@eseis04nok>
From: john.loughney@nokia.com
To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
Subject: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Date: Wed, 4 Jul 2001 10:13:40 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi James,

> In fact, I am preparing just such a draft as we speak. The 
> intent is to take the material from the BETH draft and from 
> the FMIPv4 draft and perhaps add something on the link with 
> Seamoby context transfer.

I think this would be extremely worthwhile.  It seems that 
SeaMoby is currently struggling over terminology about
triggers, etc. with respect to handovers.  I'd even suggest
that interested parties from both MIP & SeaMoby get together
in London to discuss how to move forward.  Perhaps it would 
be a good thing if MIP & SeaMoby could work together on this
issue - in order to assure that the resultant work suits both
groups.

best regards,
John


From owner-seamoby@diameter.org  Wed Jul  4 03:26:08 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01815
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 03:26:03 -0400 (EDT)
Received: (qmail 23031 invoked by alias); 4 Jul 2001 07:12:57 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 23025 invoked by uid 200); 4 Jul 2001 07:12:57 -0000
Received: (qmail 23020 invoked from network); 4 Jul 2001 07:12:55 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 07:12:55 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA25015;
	Wed, 4 Jul 2001 00:24:07 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f647O6522317;
	Wed, 4 Jul 2001 00:24:06 -0700
X-mProtect:  Wed, 4 Jul 2001 00:24:06 -0700 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdpYEaVJ; Wed, 04 Jul 2001 00:24:03 PDT
Message-ID: <3B42C491.E592BCAC@iprg.nokia.com>
Date: Wed, 04 Jul 2001 00:24:01 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gary Kenward <gkenward@nortelnetworks.com>
CC: "'seamoby'" <seamoby@diameter.org>
Subject: Need for support of neither pro nor reactive ct. was: Re: [seamoby] 
 Issue #4: Clear, unambiguous definitions missing
References: <9FBD322B7824D511B36900508BF93C9C9F5DBF@zcard031.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------0FBFD65FE83EDB7F68FD20C8"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------0FBFD65FE83EDB7F68FD20C8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gary:

I read your reply, and I have the feeling that you are trying to
convince me that
proactive and reactive cts are indeed required. I think you are missing
my point.
First, for the record: I an convinced both proactive and reactive ct are
required,
and the definition proposed in this issue #4 are satisfying in this
respect. They
are necessary. Agreed. They are not sufficient.
I am not going to comment point by point, I don't have time for this,
but sum up:
-in a previous mail, you said Rajeev's definitions (that you attributed
to Pat) were
good for you.
-they are good definition for proactive and reactive. They do not
consider a mixed situation,
initiated prior to arrival and completed after.
-the draft mentions the support of only proactive or reactive. The draft
as well prohibits
a mixed situation. A proactive ct that completes after whatever event is
a failed proactive ct.
It is a proactive that turns into a reactive (or should a fresh reactive
ct be initiated if the proactive
ct does not completes before the event, not so clear in the draft).
There was not much
point to comment before hand, since, as you say, the draft is ambiguous,
and could be read any way.
But since the clarification issue has been raised, we should address its
consequences.

Please consider the situation where MN at some point in the future  will
go from oldAR to
some identified newAR. I have this context that I want to transfer.
However, it is of no critical value
to the MN at newAR. I have the choice of: (a) proactive: I start
transfering now, and pray it
is established at newAR before (draft quote: 'it is required to forward
the first packet arrival
in the MN's traffic', new definition quote: 'the arrival of MN's packet
at target AR). (b) reactive:
I wait (new definition quote: 'subsequent to the arrival of MN's packet
at target AR) until
(draft mentions: 'initiation of a handover or soon after initiation').
Please explain to me why, since I have no critical deadline, I should
still make a choice between
(a) or (b), that is, to simplify (a) ensure that all my context is
transfered before handoff, or
(b) wait until I handoff to transfer. Where is (c): I take a leisurely
transfer around the handoff,
I start before, but take it easy, dude, whenever I get there is when I
get there.
You might see this as a terminology issue, (what do you call (c) since
it is not proactive nor reactive).
I think it is more a requirement issue. If the requirement draft
specifies (a) and (b), does not
mention any other possibility, explains that if (a) fails, then use (b)
as the only choice of combined/
mixed/soft ct, then it seems to imply that it excludes (c).
I agree with (a) MUST be supported, (b) MUST be supported, tell me why
(c) SHOULD NOT
be supported as a requirement?
Thanks,

Cedric.


>

--------------0FBFD65FE83EDB7F68FD20C8
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Gary:
<p>I read your reply, and I have the feeling that you are trying to convince
me that
<br>proactive and reactive cts are indeed required. I think you are missing
my point.
<br>First, for the record: I an convinced both proactive and reactive ct
are required,
<br>and the definition proposed in this issue #4 are satisfying in this
respect. They
<br>are necessary. Agreed. They are not sufficient.
<br>I am not going to comment point by point, I don't have time for this,
but sum up:
<br>-in a previous mail, you said Rajeev's definitions (that you attributed
to Pat) were
<br>good for you.
<br>-they are good definition for proactive and reactive. They do not consider
a mixed situation,
<br>initiated prior to arrival and completed after.
<br>-the draft mentions the support of only proactive or reactive. The
draft as well prohibits
<br>a mixed situation. A proactive ct that completes after whatever event
is a failed proactive ct.
<br>It is a proactive that turns into a reactive (or should a fresh reactive
ct be initiated if the proactive
<br>ct does not completes before the event, not so clear in the draft).
There was not much
<br>point to comment before hand, since, as you say, the draft is ambiguous,
and could be read any way.
<br>But since the clarification issue has been raised, we should address
its consequences.
<p>Please consider the situation where MN at some point in the future&nbsp;
will go from oldAR to
<br>some identified newAR. I have this context that I want to transfer.
However, it is of no critical value
<br>to the MN at newAR. I have the choice of: (a) proactive: I start transfering
now, and pray it
<br>is established at newAR before (draft quote: 'it is required to forward
the first packet arrival
<br>in the MN's traffic', new definition quote: 'the arrival of MN's packet
at target AR). (b) reactive:
<br>I wait (new definition quote: 'subsequent to the arrival of MN's packet
at target AR) until
<br>(draft mentions: 'initiation of a handover or soon after initiation').
<br>Please explain to me why, since I have no critical deadline, I should
still make a choice between
<br>(a) or (b), that is, to simplify (a) ensure that all my context is
transfered before handoff, or
<br>(b) wait until I handoff to transfer. Where is (c): I take a leisurely
transfer around the handoff,
<br>I start before, but take it easy, dude, whenever I get there is when
I get there.
<br>You might see this as a terminology issue, (what do you call (c) since
it is not proactive nor reactive).
<br>I think it is more a requirement issue. If the requirement draft specifies
(a) and (b), does not
<br>mention any other possibility, explains that if (a) fails, then use
(b) as the only choice of combined/
<br>mixed/soft ct, then it seems to imply that it excludes (c).
<br>I agree with (a) MUST be supported, (b) MUST be supported, tell me
why (c) SHOULD NOT
<br>be supported as a requirement?
<br>Thanks,
<p>Cedric.
<br>&nbsp;
<blockquote TYPE=CITE><font size=-1></font>&nbsp;</blockquote>
</html>

--------------0FBFD65FE83EDB7F68FD20C8--



From owner-seamoby@diameter.org  Wed Jul  4 03:28:27 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01841
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 03:28:22 -0400 (EDT)
Received: (qmail 22068 invoked by alias); 4 Jul 2001 06:47:47 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 22062 invoked by uid 200); 4 Jul 2001 06:47:47 -0000
Received: (qmail 22057 invoked from network); 4 Jul 2001 06:47:46 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 06:47:46 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id XAA23444;
	Tue, 3 Jul 2001 23:58:57 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f646wuN08971;
	Tue, 3 Jul 2001 23:58:56 -0700
X-mProtect:  Tue, 3 Jul 2001 23:58:56 -0700 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdbrcdNg; Tue, 03 Jul 2001 23:58:53 PDT
Message-ID: <3B42BEAC.872D0E1E@iprg.nokia.com>
Date: Tue, 03 Jul 2001 23:58:52 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gary Kenward <gkenward@nortelnetworks.com>
CC: "'seamoby'" <seamoby@diameter.org>
Subject: Re: [seamoby] Issue #4: Clear, unambiguous definitions missing
References: <9FBD322B7824D511B36900508BF93C9C9F5DBD@zcard031.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------66B506AE41594B212279AF52"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------66B506AE41594B212279AF52
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gary Kenward wrote:

>
>
> *sigh*
>
> From websters:
>
> 2 [pro-reactive] : acting in anticipation of future problems, needs,
> or changes
>
> It does not say "finish before", "complete before", or anything like
> it.

my own *sigh*. if 'anticipation' is not like it, then what does it mean?



> "Soft" and "hard" are cellular terms that have much too much baggage.
> To begin with, they are strongly associated with L2 functionality
> (although, to be precise, soft handover in CDMA is supported by
> extensive proactive L3 functions).

I don't care about terminology (even htough soft and hard have mostly a
handoff baggage, which
is not bad for ct). that's not the point.

> Why do you have so much objection to trying to prepare for a handover?
> This is what
> ct is all about, preparing an AR to accept a handover so that the
> service is not impaired by the handover. The fact that there will
> always be situations that cannot be prepared for does not mean that
> preparation is not worthwhile.
>

????? do I object to proactive ct? where? preparation is good. Early
bird gets the worm.
I worry you are missing my point though.
Which, even though I don't enjoy it, I will re-explain in the next
email.

Cedric.

>
> This is nonsense - let's toss *all* the terms, and focus on the issue,
> which
> is to develop a ct that enhances handover.

>
>
> Gary
>
>
> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> Sent: Tuesday, July 03, 2001 10:30 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'seamoby'
> Subject: Re: [seamoby] Issue #4: Clear, unambiguous definitions
> missing
>
> Gary:
> Gary Kenward wrote:
>
> Cedric:
> > -----Original Message-----
> > From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
> > Sent: Tuesday, July 03, 2001 3:55 AM
> > To: Nakhjiri Madjid-MNAKHJI1
> > Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby';
> > charliep@iprg.nokia.com
> > Subject: Re: [seamoby] Issue #4: Clear, unambiguous
> > definitions missing
> >
> >
> > Sorry to breach the truce, but here are some comments:
> >
> > Nakhjiri Madjid-MNAKHJI1 wrote:
> >
> > > I suggest we leave this as an open issue, until we meet in IETF.
> > >
> > > Madjid
> > >
> > > -----Original Message-----
> > > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > > Sent: Friday, June 29, 2001 10:28 AM
> > > To: 'seamoby'
> > > Subject: [seamoby] Issue #4: Clear, unambiguous definitions
> missing
> > > Sensitivity: Confidential
> > >
> > > In the interest of moving the requirements forward, I
> > support the change in
> > > the
> > > definitions of "reactive" and "proactive' proposed by Pat:
> > >
> > > Reactive CT: The context transfer process which takes place
> > subsequent
> > > to arrival of a MN's packet at the target AR
> > >
> > > Proactive CT: The context transfer process in which the
> > required contexts
> > > are in place at the target AR  prior to the arrival of MN's
> > packet at target
> > > AR.
> > >
> >
> > reactive sounds good to me, but not proactive. There is a
> From your arguements below you seem to support being proactive,
> it's all the connotations that have been spun around what proactive
> does or not mean that you object to. It's impossible to counter the
> tide of popular belief (just look what has happened with "seamless").
> Please be assured, there has never been a formal definition of
> "proactive" that included, or implied serialization. Indeed, every
> attempt has been made to avoid this definition. Truthfully, I believe
> that whatever name we chose would end up painted with the same
> innuendo.
> pro-active means to act before. We should agree on that. Now, it seems
>
> that the event answer to 'before what' is: 'arrival of MN's packet at
> target AR'.
> Fine with me. Thus if you define proactive CT this way, there is an
> implicit
> requirement that CT is completed before said event. Fine, we are in
> the
> process of defining requirements, and I'd accept a 'proactive CT', as
> you
> define it.
> Then again, why in the universe would you forbid that a CT initiated
> before
> the 'arrival  of ...' could only complete after. Maybe you don't, but
> then don't use
> a word that would actually mean this.
> So at this time - if I am correct in my observation that we all do
> indeed
> believe that serialization is a bad thing, but that being prepared for
>
> the actual handover ahead of time is a good thing - we are really
> involved
> in a nomenclature debate. From my point of view this is a waste of
> our collective energy, but so be it. Let's pick a word.
> "Dynamic" and "static" tends to capture somewhat the attributes of the
>
> context at different phases, but the terms are too restrictive. An
> early
> transfer of dynamic context should be allowed if it enhances handover.
>
> "predictive" doesn't work for me either, as it implies that ct is
> involved
> with some sort of inductive logic; while there may be an entity
> attempting
> to "predict" which base/AP/AR the MN will appear on next, it is not
> part
> of ct.
> So that leaves? Well, how about prophylactic? Hmmm, unlikely to pass
> the
> scrutiny of the IESG for all the snickers it would incite from the
> just-
> out-of-high-school crowd.
> prophylactic? what I object to is any word that starts with pro- or
> pre-,
> latin root for before, to mean something that does indeed starts
> before,
> but can end after. That's why I like 'soft'/'hard', but am open to
> pretty much
> anything.
> Take care,
> Cedric.
>
> We are deep into trying to define how the protocol should work, when
> we
> are supposed to be finishing off the requirements document. Maybe the
> answer
> is to avoid the use of catch phrases, and simply write requirements
> that
> state what it is that we want to accomplish.
> Cheers,
> Gary
> > consensus for support
> > for several phases in CT. So it seems that the term
> > 'required' needs to be
> > clarified.
> > In the CT phases discussion, the talk is about priority. Some
> > contexts are more
> > important than other. Which is true, but mostly some contexts
> > are more time
> > sensitive
> > than other. Some accounting contexts, which some operator
> > would argue is _very_
> > important, can arrive later, after the arrival of MN's packet
> > at new AR. This
> > requirement denies this possibility.
> >
> > Solutions: 1) define a static context (configuration state)
> > and a dynamic
> > context (accounting
> > state). Static context is what has to be transfered before
> > the arrival of MN's
> > packet
> > at target AR. Replace 'required' in your definition by
> > 'static', or 'config'.
> > Dynamic is what
> > can be transfered later to fill in the blanks. I have some
> > text on this if you
> > want.
> >
> > -or-
> >
> > 2) one of the issues with proactive/reactive is that it connotes a
> > serialization. pro/before, re/after.
> > There seems to be somewhat of a consensus as to before what
> > and after what
> > (having the
> > newAR default router, or having the newAR receiving packets
> > from the MN).
> > For instance in this proposal, the whole transfer has to be
> > performed _before_
> > (prior in the
> > text) the arrival of MN's packet at newAR. Other proposals:
> > pre-handoff,
> > post-handoff, same
> > thing. Charlie's proposal: reactive, predictive, also same thing.
> > On the other hand, CT can be initiated before/after, and
> > completed before/after.
> > So, if you take
> > away the initiated after/completed before, you still need at
> > least THREE terms.
> > There is also a consensus on reactive: initiated
> > after/completed after. The
> > issue is with proactive,
> > which means before, and has to cover the CT completed *after*
> > case, which is
> > somewhat
> > counter-intuitive.
> > So here is yet another proposal, which borrows the handoff
> > terminology, and is
> > in everybody's
> > dictionnary:
> > hard CT = reactive CT
> > soft CT = a CT in which the transfer is initiated before the
> > arrival of MN's
> > packet at the target
> > AR. (no mention of completion, covers the initiated before,
> > completed before or
> > after case).
> > proactive CT= the definition up this mail (covers the
> > initiated before/completed
> > before case).
> >
> > Cheers,
> >
> > Cedric.
> >
> > >
> > > Since these are "definitions" and not requirements, I
> > assume that there is
> > > room
> > > for change as we delve into the design process.
> > >
> > > For what it's worth . . .
> > >
> > > Gary
> >
> >

--------------66B506AE41594B212279AF52
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Gary Kenward wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>*sigh*</font>
<p><font size=-1>From websters:</font>
<p><font size=-1>2 [pro-reactive] : acting in anticipation of future problems,
needs, or changes</font>
<p><font size=-1>It does not say "finish before", "complete before", or
anything like it.</font></blockquote>
my own *sigh*. if 'anticipation' is not like it, then what does it mean?
<br>&nbsp;
<blockquote TYPE=CITE><font size=-1>"Soft" and "hard" are cellular terms
that have much too much baggage. To begin with, they are strongly associated
with L2 functionality (although, to be precise, soft handover in CDMA is
supported by extensive proactive L3 functions).</font></blockquote>
I don't care about terminology (even htough soft and hard have mostly a
handoff baggage, which
<br>is not bad for ct). that's not the point.
<blockquote TYPE=CITE><font size=-1>Why do you have so much objection to
trying to prepare for a handover? This is what</font>
<br><font size=-1>ct is all about, preparing an AR to accept a handover
so that the service is not impaired by the handover. The fact that there
will always be situations that cannot be prepared for does not mean that
preparation is not worthwhile.</font>
<br>&nbsp;</blockquote>
????? do I object to proactive ct? where? preparation is good. Early bird
gets the worm.
<br>I worry you are missing my point though.
<br>Which, even though I don't enjoy it, I will re-explain in the next
email.
<p>Cedric.
<blockquote TYPE=CITE>&nbsp;
<br><font size=-1>This is nonsense - let's toss *all* the terms, and focus
on the issue, which</font>
<br><font size=-1>is to develop a ct that enhances handover.</font></blockquote>

<blockquote TYPE=CITE><font size=-1></font>&nbsp;
<p><font size=-1>Gary</font>
<br>&nbsp;
<p><font size=-1>-----Original Message-----</font>
<br><font size=-1>From: Cedric Westphal [<a href="mailto:cedric@IPRG.nokia.com">mailto:cedric@IPRG.nokia.com</a>]</font>
<br><font size=-1>Sent: Tuesday, July 03, 2001 10:30 AM</font>
<br><font size=-1>To: Kenward, Gary [WDLN2:AN10:EXCH]</font>
<br><font size=-1>Cc: 'seamoby'</font>
<br><font size=-1>Subject: Re: [seamoby] Issue #4: Clear, unambiguous definitions
missing</font>
<p><font size=-1>Gary:</font>
<br><font size=-1>Gary Kenward wrote:</font>
<p><font size=-1>Cedric:</font>
<br><font size=-1>> -----Original Message-----</font>
<br><font size=-1>> From: Cedric Westphal [<a href="mailto:cedric@iprg.nokia.com">mailto:cedric@iprg.nokia.com</a>]</font>
<br><font size=-1>> Sent: Tuesday, July 03, 2001 3:55 AM</font>
<br><font size=-1>> To: Nakhjiri Madjid-MNAKHJI1</font>
<br><font size=-1>> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby';</font>
<br><font size=-1>> charliep@iprg.nokia.com</font>
<br><font size=-1>> Subject: Re: [seamoby] Issue #4: Clear, unambiguous</font>
<br><font size=-1>> definitions missing</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>> Sorry to breach the truce, but here are some comments:</font>
<br><font size=-1>></font>
<br><font size=-1>> Nakhjiri Madjid-MNAKHJI1 wrote:</font>
<br><font size=-1>></font>
<br><font size=-1>> > I suggest we leave this as an open issue, until we
meet in IETF.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Madjid</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > -----Original Message-----</font>
<br><font size=-1>> > From: Gary Kenward [<a href="mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</a>]</font>
<br><font size=-1>> > Sent: Friday, June 29, 2001 10:28 AM</font>
<br><font size=-1>> > To: 'seamoby'</font>
<br><font size=-1>> > Subject: [seamoby] Issue #4: Clear, unambiguous definitions
missing</font>
<br><font size=-1>> > Sensitivity: Confidential</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > In the interest of moving the requirements forward,
I</font>
<br><font size=-1>> support the change in</font>
<br><font size=-1>> > the</font>
<br><font size=-1>> > definitions of "reactive" and "proactive' proposed
by Pat:</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Reactive CT: The context transfer process which takes
place</font>
<br><font size=-1>> subsequent</font>
<br><font size=-1>> > to arrival of a MN's packet at the target AR</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Proactive CT: The context transfer process in which
the</font>
<br><font size=-1>> required contexts</font>
<br><font size=-1>> > are in place at the target AR&nbsp; prior to the
arrival of MN's</font>
<br><font size=-1>> packet at target</font>
<br><font size=-1>> > AR.</font>
<br><font size=-1>> ></font>
<br><font size=-1>></font>
<br><font size=-1>> reactive sounds good to me, but not proactive. There
is a</font>
<br><font size=-1>From your arguements below you seem to support being
proactive,</font>
<br><font size=-1>it's all the connotations that have been spun around
what proactive</font>
<br><font size=-1>does or not mean that you object to. It's impossible
to counter the</font>
<br><font size=-1>tide of popular belief (just look what has happened with
"seamless").</font>
<br><font size=-1>Please be assured, there has never been a formal definition
of</font>
<br><font size=-1>"proactive" that included, or implied serialization.
Indeed, every</font>
<br><font size=-1>attempt has been made to avoid this definition. Truthfully,
I believe</font>
<br><font size=-1>that whatever name we chose would end up painted with
the same innuendo.</font>
<br><font size=-1>pro-active means to act before. We should agree on that.
Now, it seems</font>
<br><font size=-1>that the event answer to 'before what' is: 'arrival of
MN's packet at target AR'.</font>
<br><font size=-1>Fine with me. Thus if you define proactive CT this way,
there is an implicit</font>
<br><font size=-1>requirement that CT is completed before said event. Fine,
we are in the</font>
<br><font size=-1>process of defining requirements, and I'd accept a 'proactive
CT', as you</font>
<br><font size=-1>define it.</font>
<br><font size=-1>Then again, why in the universe would you forbid that
a CT initiated before</font>
<br><font size=-1>the 'arrival&nbsp; of ...' could only complete after.
Maybe you don't, but then don't use</font>
<br><font size=-1>a word that would actually mean this.</font>
<br><font size=-1>So at this time - if I am correct in my observation that
we all do indeed</font>
<br><font size=-1>believe that serialization is a bad thing, but that being
prepared for</font>
<br><font size=-1>the actual handover ahead of time is a good thing - we
are really involved</font>
<br><font size=-1>in a nomenclature debate. From my point of view this
is a waste of</font>
<br><font size=-1>our collective energy, but so be it. Let's pick a word.</font>
<br><font size=-1>"Dynamic" and "static" tends to capture somewhat the
attributes of the</font>
<br><font size=-1>context at different phases, but the terms are too restrictive.
An early</font>
<br><font size=-1>transfer of dynamic context should be allowed if it enhances
handover.</font>
<br><font size=-1>"predictive" doesn't work for me either, as it implies
that ct is involved</font>
<br><font size=-1>with some sort of inductive logic; while there may be
an entity attempting</font>
<br><font size=-1>to "predict" which base/AP/AR the MN will appear on next,
it is not part</font>
<br><font size=-1>of ct.</font>
<br><font size=-1>So that leaves? Well, how about prophylactic? Hmmm, unlikely
to pass the</font>
<br><font size=-1>scrutiny of the IESG for all the snickers it would incite
from the just-</font>
<br><font size=-1>out-of-high-school crowd.</font>
<br><font size=-1>prophylactic? what I object to is any word that starts
with pro- or pre-,</font>
<br><font size=-1>latin root for before, to mean something that does indeed
starts before,</font>
<br><font size=-1>but can end after. That's why I like 'soft'/'hard', but
am open to pretty much</font>
<br><font size=-1>anything.</font>
<br><font size=-1>Take care,</font>
<br><font size=-1>Cedric.</font>
<p><font size=-1>We are deep into trying to define how the protocol should
work, when we</font>
<br><font size=-1>are supposed to be finishing off the requirements document.
Maybe the answer</font>
<br><font size=-1>is to avoid the use of catch phrases, and simply write
requirements that</font>
<br><font size=-1>state what it is that we want to accomplish.</font>
<br><font size=-1>Cheers,</font>
<br><font size=-1>Gary</font>
<br><font size=-1>> consensus for support</font>
<br><font size=-1>> for several phases in CT. So it seems that the term</font>
<br><font size=-1>> 'required' needs to be</font>
<br><font size=-1>> clarified.</font>
<br><font size=-1>> In the CT phases discussion, the talk is about priority.
Some</font>
<br><font size=-1>> contexts are more</font>
<br><font size=-1>> important than other. Which is true, but mostly some
contexts</font>
<br><font size=-1>> are more time</font>
<br><font size=-1>> sensitive</font>
<br><font size=-1>> than other. Some accounting contexts, which some operator</font>
<br><font size=-1>> would argue is _very_</font>
<br><font size=-1>> important, can arrive later, after the arrival of MN's
packet</font>
<br><font size=-1>> at new AR. This</font>
<br><font size=-1>> requirement denies this possibility.</font>
<br><font size=-1>></font>
<br><font size=-1>> Solutions: 1) define a static context (configuration
state)</font>
<br><font size=-1>> and a dynamic</font>
<br><font size=-1>> context (accounting</font>
<br><font size=-1>> state). Static context is what has to be transfered
before</font>
<br><font size=-1>> the arrival of MN's</font>
<br><font size=-1>> packet</font>
<br><font size=-1>> at target AR. Replace 'required' in your definition
by</font>
<br><font size=-1>> 'static', or 'config'.</font>
<br><font size=-1>> Dynamic is what</font>
<br><font size=-1>> can be transfered later to fill in the blanks. I have
some</font>
<br><font size=-1>> text on this if you</font>
<br><font size=-1>> want.</font>
<br><font size=-1>></font>
<br><font size=-1>> -or-</font>
<br><font size=-1>></font>
<br><font size=-1>> 2) one of the issues with proactive/reactive is that
it connotes a</font>
<br><font size=-1>> serialization. pro/before, re/after.</font>
<br><font size=-1>> There seems to be somewhat of a consensus as to before
what</font>
<br><font size=-1>> and after what</font>
<br><font size=-1>> (having the</font>
<br><font size=-1>> newAR default router, or having the newAR receiving
packets</font>
<br><font size=-1>> from the MN).</font>
<br><font size=-1>> For instance in this proposal, the whole transfer has
to be</font>
<br><font size=-1>> performed _before_</font>
<br><font size=-1>> (prior in the</font>
<br><font size=-1>> text) the arrival of MN's packet at newAR. Other proposals:</font>
<br><font size=-1>> pre-handoff,</font>
<br><font size=-1>> post-handoff, same</font>
<br><font size=-1>> thing. Charlie's proposal: reactive, predictive, also
same thing.</font>
<br><font size=-1>> On the other hand, CT can be initiated before/after,
and</font>
<br><font size=-1>> completed before/after.</font>
<br><font size=-1>> So, if you take</font>
<br><font size=-1>> away the initiated after/completed before, you still
need at</font>
<br><font size=-1>> least THREE terms.</font>
<br><font size=-1>> There is also a consensus on reactive: initiated</font>
<br><font size=-1>> after/completed after. The</font>
<br><font size=-1>> issue is with proactive,</font>
<br><font size=-1>> which means before, and has to cover the CT completed
*after*</font>
<br><font size=-1>> case, which is</font>
<br><font size=-1>> somewhat</font>
<br><font size=-1>> counter-intuitive.</font>
<br><font size=-1>> So here is yet another proposal, which borrows the
handoff</font>
<br><font size=-1>> terminology, and is</font>
<br><font size=-1>> in everybody's</font>
<br><font size=-1>> dictionnary:</font>
<br><font size=-1>> hard CT = reactive CT</font>
<br><font size=-1>> soft CT = a CT in which the transfer is initiated before
the</font>
<br><font size=-1>> arrival of MN's</font>
<br><font size=-1>> packet at the target</font>
<br><font size=-1>> AR. (no mention of completion, covers the initiated
before,</font>
<br><font size=-1>> completed before or</font>
<br><font size=-1>> after case).</font>
<br><font size=-1>> proactive CT= the definition up this mail (covers the</font>
<br><font size=-1>> initiated before/completed</font>
<br><font size=-1>> before case).</font>
<br><font size=-1>></font>
<br><font size=-1>> Cheers,</font>
<br><font size=-1>></font>
<br><font size=-1>> Cedric.</font>
<br><font size=-1>></font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Since these are "definitions" and not requirements,
I</font>
<br><font size=-1>> assume that there is</font>
<br><font size=-1>> > room</font>
<br><font size=-1>> > for change as we delve into the design process.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > For what it's worth . . .</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Gary</font>
<br><font size=-1>></font>
<br><font size=-1>></font></blockquote>
</html>

--------------66B506AE41594B212279AF52--



From owner-seamoby@diameter.org  Wed Jul  4 04:35:12 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA02752
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 04:35:07 -0400 (EDT)
Received: (qmail 23573 invoked by alias); 4 Jul 2001 08:22:18 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 23567 invoked by uid 200); 4 Jul 2001 08:22:17 -0000
Received: (qmail 23559 invoked from network); 4 Jul 2001 08:22:16 -0000
Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 08:22:16 -0000
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19)
	id <N72MTAFP>; Wed, 4 Jul 2001 04:33:22 -0400
Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F80B3@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'David R. Oran'" <oran@cisco.com>,
        "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>,
        "'Rajeev Koodli'" <rajeev@IPRG.nokia.com>
Cc: Kulwinder Atwal <kulwinder.atwal@zucotto.com>,
        "'Charles E. Perkins'" <charliep@IPRG.nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: FW: [seamoby] CT trigger or CT completion? was:  proactive an
	d re active CT definitions
Date: Wed, 4 Jul 2001 04:33:20 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk


The problem with having an uplink and a downlink is that it is L2 technology
specific.
Some wireless technologies have a single bi-directional
link.(802.11b,Bluetooth).

By assuming two links per MN requires adding unneccesary states to every
implementation.  It is better for a particular L2 to deal with the specifics
of its L2 at the L2 level, since we know that IP does not impose a
particular direction at the L3 level.  If IP had a direction bit in its
header, then I suppose we would have to consider it. 

- Kulwinder.

> -----Original Message-----
> From: David R. Oran [mailto:oran@cisco.com]
> Sent: Tuesday, July 03, 2001 8:29 AM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Pat Calhoun'; 'Rajeev Koodli'
> Cc: 'Kulwinder Atwal'; 'Charles E. Perkins'; seamoby@cdma-2000.org
> Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive
> and re active CT definitions
> 
> 
> Sorry for joining in late. Just a small comment. While I 
> generally like
> the idea of explaining the initiation and state management for context
> transfer in terms of mobile link establishment, it is very 
> important to
> keep in mind that mobile link establishment may not be symmetric or
> atomic with respect the the context transfer state machines. 
> I think we
> need to consider the definitions and overall model as if 
> there were FOUR
> links, not two:
>  - old downlink
>  - old uplink
>  - new downlink
>  - new uplink
> 
> It seems to me you usually can't start context transfer until the new
> downlink is operational, at least at layer 2, (since the 
> mobile doesn't
> know really where it might move until then), and you need to complete
> context transfer soon after the new uplink is operational, or 
> you don't
> get much benefit.
> 
> Perhaps if we talked in terms of these four links, plus the link
> betweeen oldAR and newAR (which we can probably treat as symmetric
> because it's on the non-mobile part of the net) we can more directly
> discuss the timing and state machines for context transfer rather than
> relying on somewhat slippery notions like "proactive" versus 
> "reactive".
> 
> One exception to the above that may be worth at covering at least for
> completeness, is true "predictive" context transfer, where the system
> tries to predict where the mobile might show up before it 
> even tries to
> move. The model should not preclude that option, impractical as it may
> be on some wireless systems.
> 
> Dave.
> 
> > -----Original Message-----
> > From: owner-seamoby@diameter.org 
> > [mailto:owner-seamoby@diameter.org] On Behalf Of Nakhjiri 
> > Madjid-MNAKHJI1
> > Sent: Thursday, June 28, 2001 11:58 AM
> > To: 'Pat Calhoun'; Rajeev Koodli
> > Cc: Kulwinder Atwal; Nakhjiri Madjid-MNAKHJI1; 'Charles E. 
> > Perkins'; 'seamoby@cdma-2000.org'
> > Subject: RE: FW: [seamoby] CT trigger or CT completion? was: 
> > proactive and re active CT definitions
> > 
> > 
> > I don't like this one, I seem to be chasing a moving target 
> > (definition of 
> > reactive, proactive). Last week we were talking about whether 
> > to use link establishment or not, this week it is about 
> > default router.
> > 
> > I started to like Charlie's definition based on link 
> > establishment, (however, we accepted that by link we are 
> > talking about L2) since L2 establishment is more crisp than 
> > completed handover. and we explored different cases, so we 
> > don't miss all the cases. The draft versus Charlie's 
> > definition of reactive/ proactive 
> > definitions in the two turned out to cover different
> > set of scenarios without changing the outcome too much. 
> > 
> >  I don't see how this new definition that pop up everyday are 
> > making the CT better.
> > 
> > I am the newAR, How long do I have to wait until I make sure 
> > I am the default router, say in a FMIPv6 case: until I get
> > the NA and make sure MN has a valid newCoA?
> > What if the MN still has to use its oldCoA and a tunnel 
> > between newAR and oldAR, how long do I have to wait to 
> start CT, this 
> > introduces unnecessary delay for CT.
> > 
> > Another confusing thing is folks on the list keep using their 
> > own favorite words and definitions in the continuing 
> > conversations without paying attention what the other ends 
> > understanding of that word is,
> > 
> > Lets finish off the link establishment discussion and if it
> > is not good enough, see what is better, the way it is going
> > I am not sure we are making a lot of progress in wrapping things up.
> > 
> > Madjid
> > 
> > -----Original Message-----
> > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> > Sent: Thursday, June 28, 2001 8:36 AM
> > To: Rajeev Koodli
> > Cc: Kulwinder Atwal; 'Pat Calhoun'; 'Nakhjiri 
> > Madjid-MNAKHJI1'; 'Charles E. Perkins'; 'seamoby@cdma-2000.org'
> > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: 
> > proactive and re active CT definitions
> > 
> > 
> > > > How is this:
> > > >
> > > > Pre-Handoff Context Transfer: The Context Transfer is initiated 
> > > > prior to
> > the
> > > > newAR becomes the MN's default router.
> > > >
> > > > Post-Handoff Context Transfer:  The Context Transfer is 
> initiated 
> > > > after
> > the
> > > > newAR becomes the MN's default router.
> > > >
> > > > -Kulwinder.
> > > >
> > > >
> > > 
> > > Rajeev: This would work for me.  May be we should ask 
> PatC on how to
> > proceed
> > > next?
> > 
> > what do folks think about using this terminology? Is this 
> > preferred over the existing terminology in the draft?
> > 
> > PatC
> > 
> 


From owner-seamoby@diameter.org  Wed Jul  4 06:20:05 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03726
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 06:20:03 -0400 (EDT)
Received: (qmail 24133 invoked by alias); 4 Jul 2001 09:44:35 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 24127 invoked by uid 200); 4 Jul 2001 09:44:35 -0000
Received: (qmail 24122 invoked from network); 4 Jul 2001 09:44:33 -0000
Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 09:44:33 -0000
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19)
	id <N72MTAGS>; Wed, 4 Jul 2001 05:55:45 -0400
Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F80B4@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        "'Cedric Westphal'" <cedric@iprg.nokia.com>
Cc: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'seamoby'" <seamoby@diameter.org>, charliep@iprg.nokia.com
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing
Date: Wed, 4 Jul 2001 05:55:44 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk


Consider a Network-Initiated Context Transfer (leaving out the Acks):

The Network Initiator could be any entity including: ParentAR, oldAR, newAR,
MN.

Step 1:

 MN	[oldAR]<---- CT Request MSG -----+
 |       |                             |
 |       |                             |
 |       |                             |
 |       |                            [ParentAR]<- Common RT Change/CT MSG
--[Network Initiator]
 |       |                             |
 |       |                             |
 V       |                             |
      [newAR]<--- New MN packets ------+

Step 2:

 |	[oldAR]--------------------------+
 |       |                             |
 |       |                             |
 |       |                             |
 |    Context                          [ParentAR]---------[Network
Initiator]
 |    Transfer                         |
 |       |                             |
 V       V                             |
 MN	[newAR]--------------------------+

You will notice that it is impossible for the Context Transfer to happen
BEFORE the Route Change, or the arrival of new MN packets.  

Putting the onus on CT to complete before handover is incorrect.  The
network must delay route change until the CT has a chance to get started to
increase the chance that the CT will complete and new packets arrive _near_
the same time.  The 'correct' delay is network specific.

If you assume FMIPv6, then you are creating an FMIPv6 specific solution.
The Care of Address could be held at the ParentAR.

Consider an MN-Initiated post-connection Context Transfer (leaving out the
Acks):

Step 1:

 	        [oldAR]<-------------------------+
 |               ^                             |
 |               ^                             |
 |               |                             |
 |            CT Req                           [ParentAR]--------------
 |               |                             |
 |               |                             |
 V               |                             |
MN RT/CT MSG->[newAR]---- Route Change Req --->+

Step 2:

 	[oldAR]--------------------------+
         |                             |
         |                             |
         |                             |
      Context                          [ParentAR]---------
      Transfer                         |
         |                             |
         V                             |
 MN	[newAR]<--- new MN pakcets ------+

In this case the network should introduce less delay to increase the chance
that new MN packets and context arrive _near_ the same time.

It is not up to the Context Transfer Protocol to ensure any 'timing
requirements' such as 'proactive' must complete or should complete before
handover.  This is a network responsibility.

How can CT possibly know what the network architecture is?

Again, I believe the linkage between Context transfer and Handover
completion needs to be removed.

- Kulwinder.

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Tuesday, July 03, 2001 5:56 PM
> To: 'Cedric Westphal'; Nakhjiri Madjid-MNAKHJI1
> Cc: 'Gary Kenward'; 'seamoby'; charliep@iprg.nokia.com
> Subject: RE: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing
> 
> 
> Cedric,
> 
> I actually liked the cease fire, for the past three months we have 
> opened the proactive/ reactive issue many times.
> We talked about timing, reliability and other things,
>  and time and after time we came back to the same discussion:
> 
>  CT's timing and its relation with handover
> 
> The issue has not been resolved, since different people have
> different mental image about the sequence of events during
> Handover and that impacts the way they want to see CT happen.
> 
> As I said many times it does not matter what scenario is 
> called reactive or
> whether reactive is post-A or post-B. 
> 
> The requirements need to consider the events, cover all the 
> scenarios and
> make CT as good of optimization as possible and remember that
> this is supposed to be optimization over the no-CT case.
> 
> The nomenclature is less important at this point.
> 
> The last round of email discussion has concluded that we should
> discuss this face to face to prevent going into cycles and having
> people staring at their monitors for new proactive/ reactive that
> might pop up on the list any minute.
> 
> So please lets not breach the truce, each one of us would have more
> time to think about what we want out of CT in the meantime :)
> 
> Madjid
> 
> 
> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
> Sent: Tuesday, July 03, 2001 2:55 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'Gary Kenward'; 'seamoby'; charliep@iprg.nokia.com
> Subject: Re: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing
> 
> 
> Sorry to breach the truce, but here are some comments:
> 
> Nakhjiri Madjid-MNAKHJI1 wrote:
> 
> > I suggest we leave this as an open issue, until we meet in IETF.
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> > Sent: Friday, June 29, 2001 10:28 AM
> > To: 'seamoby'
> > Subject: [seamoby] Issue #4: Clear, unambiguous definitions missing
> > Sensitivity: Confidential
> >
> > In the interest of moving the requirements forward, I 
> support the change
> in
> > the
> > definitions of "reactive" and "proactive' proposed by Pat:
> >
> > Reactive CT: The context transfer process which takes place 
> subsequent
> > to arrival of a MN's packet at the target AR
> >
> > Proactive CT: The context transfer process in which the 
> required contexts
> > are in place at the target AR  prior to the arrival of MN's 
> packet at
> target
> > AR.
> >
> 
> reactive sounds good to me, but not proactive. There is a 
> consensus for
> support
> for several phases in CT. So it seems that the term 
> 'required' needs to be
> clarified.
> In the CT phases discussion, the talk is about priority. Some 
> contexts are
> more
> important than other. Which is true, but mostly some contexts 
> are more time
> sensitive
> than other. Some accounting contexts, which some operator 
> would argue is
> _very_
> important, can arrive later, after the arrival of MN's packet 
> at new AR.
> This
> requirement denies this possibility.
> 
> Solutions: 1) define a static context (configuration state) 
> and a dynamic
> context (accounting
> state). Static context is what has to be transfered before 
> the arrival of
> MN's
> packet
> at target AR. Replace 'required' in your definition by 'static', or
> 'config'.
> Dynamic is what
> can be transfered later to fill in the blanks. I have some 
> text on this if
> you
> want.
> 
> -or-
> 
> 2) one of the issues with proactive/reactive is that it connotes a
> serialization. pro/before, re/after.
> There seems to be somewhat of a consensus as to before what 
> and after what
> (having the
> newAR default router, or having the newAR receiving packets 
> from the MN).
> For instance in this proposal, the whole transfer has to be performed
> _before_
> (prior in the
> text) the arrival of MN's packet at newAR. Other proposals: 
> pre-handoff,
> post-handoff, same
> thing. Charlie's proposal: reactive, predictive, also same thing.
> On the other hand, CT can be initiated before/after, and completed
> before/after.
> So, if you take
> away the initiated after/completed before, you still need at 
> least THREE
> terms.
> There is also a consensus on reactive: initiated 
> after/completed after. The
> issue is with proactive,
> which means before, and has to cover the CT completed *after* 
> case, which is
> somewhat
> counter-intuitive.
> So here is yet another proposal, which borrows the handoff 
> terminology, and
> is
> in everybody's
> dictionnary:
> hard CT = reactive CT
> soft CT = a CT in which the transfer is initiated before the 
> arrival of MN's
> packet at the target
> AR. (no mention of completion, covers the initiated before, 
> completed before
> or
> after case).
> proactive CT= the definition up this mail (covers the initiated
> before/completed
> before case).
> 
> Cheers,
> 
> Cedric.
> 
> >
> > Since these are "definitions" and not requirements, I 
> assume that there is
> > room
> > for change as we delve into the design process.
> >
> > For what it's worth . . .
> >
> > Gary
> 


From owner-seamoby@diameter.org  Wed Jul  4 09:31:14 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06284
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 09:31:06 -0400 (EDT)
Received: (qmail 25099 invoked by alias); 4 Jul 2001 13:16:18 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 25093 invoked by uid 200); 4 Jul 2001 13:16:18 -0000
Received: (qmail 25088 invoked from network); 4 Jul 2001 13:16:16 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 13:16:16 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f64DR1b09316
	for <seamoby@diameter.org>; Wed, 4 Jul 2001 09:27:01 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 4 Jul 2001 09:26:58 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2WGSD>; Wed, 4 Jul 2001 09:26:59 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DC2@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Cedric Westphal'" <cedric@iprg.nokia.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: [seamoby] RE: Need for support of neither pro nor reactive ct. was: Re: [se 
         amoby] Issue #4: Clear, unambiguous definitions missing
Date: Wed, 4 Jul 2001 09:26:59 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1048D.010F8A20"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1048D.010F8A20
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Cedric:
=20
  All of us our busy. It is regrettable that you wasted your time
explaining something which did not need explaining. You are missing
my point, which is, to be blunt, that proactive/reactive does cover
the case you are so concerned about, at least as far as I am concerned.
If you bother to check through the archives you will see that I have
stated this many times, in many ways.
=20
  'nuff said. I now agree with Pat. This will take at least a meeting =
at
IETF 51 to work out; at least. I may or may not be there. My only
caution is that exchanging one set of terms for another will likely
not resolve the real issue, just bury it until someone comes up with
more detail to argue. I have no great love for the terms "proactive"
and "reactive", but I am fully convinced that choosing new terminology
will set us back to January of this year, when Seamoby had the =
discussion
of "soft" versus "hard", "make-before-break" versus =
"break-before-make".
=20
  As I tried to indicate in my previous posting, if you believe your =
case
needs
emphasis, then let's work it into the wording of the current draft. =
Until
some
clearly superior terminology arises, let's work with what we have.
=20
Gary
Plus ca change, plus c'est le m=EAme chose.

-----Original Message-----
From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
Sent: Wednesday, July 04, 2001 3:24 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]
Cc: 'seamoby'
Subject: Need for support of neither pro nor reactive ct. was: Re: =
[seamoby]
Issue #4: Clear, unambiguous definitions missing


Gary:=20

I read your reply, and I have the feeling that you are trying to =
convince me
that=20
proactive and reactive cts are indeed required. I think you are missing =
my
point.=20
First, for the record: I an convinced both proactive and reactive ct =
are
required,=20
and the definition proposed in this issue #4 are satisfying in this =
respect.
They=20
are necessary. Agreed. They are not sufficient.=20
I am not going to comment point by point, I don't have time for this, =
but
sum up:=20
-in a previous mail, you said Rajeev's definitions (that you attributed =
to
Pat) were=20
good for you.=20
-they are good definition for proactive and reactive. They do not =
consider a
mixed situation,=20
initiated prior to arrival and completed after.=20
-the draft mentions the support of only proactive or reactive. The =
draft as
well prohibits=20
a mixed situation. A proactive ct that completes after whatever event =
is a
failed proactive ct.=20
It is a proactive that turns into a reactive (or should a fresh =
reactive ct
be initiated if the proactive=20
ct does not completes before the event, not so clear in the draft). =
There
was not much=20
point to comment before hand, since, as you say, the draft is =
ambiguous, and
could be read any way.=20
But since the clarification issue has been raised, we should address =
its
consequences.=20


Please consider the situation where MN at some point in the future  =
will go
from oldAR to=20
some identified newAR. I have this context that I want to transfer. =
However,
it is of no critical value=20
to the MN at newAR. I have the choice of: (a) proactive: I start =
transfering
now, and pray it=20
is established at newAR before (draft quote: 'it is required to forward =
the
first packet arrival=20
in the MN's traffic', new definition quote: 'the arrival of MN's packet =
at
target AR). (b) reactive:=20
I wait (new definition quote: 'subsequent to the arrival of MN's packet =
at
target AR) until=20
(draft mentions: 'initiation of a handover or soon after initiation').=20
Please explain to me why, since I have no critical deadline, I should =
still
make a choice between=20
(a) or (b), that is, to simplify (a) ensure that all my context is
transfered before handoff, or=20
(b) wait until I handoff to transfer. Where is (c): I take a leisurely
transfer around the handoff,=20
I start before, but take it easy, dude, whenever I get there is when I =
get
there.=20
You might see this as a terminology issue, (what do you call (c) since =
it is
not proactive nor reactive).=20
I think it is more a requirement issue. If the requirement draft =
specifies
(a) and (b), does not=20
mention any other possibility, explains that if (a) fails, then use (b) =
as
the only choice of combined/=20
mixed/soft ct, then it seems to imply that it excludes (c).=20
I agree with (a) MUST be supported, (b) MUST be supported, tell me why =
(c)
SHOULD NOT=20
be supported as a requirement?=20
Thanks,=20


Cedric.=20
 =20


=20


------_=_NextPart_001_01C1048D.010F8A20
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3D"Comic Sans MS"><SPAN=20
class=3D850370713-04072001>Cedric:</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN=20
class=3D850370713-04072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN =
class=3D850370713-04072001>&nbsp; All of us=20
our busy. It is regrettable that you wasted your =
time</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN =
class=3D850370713-04072001>explaining=20
something which did not need explaining. You are =
missing</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN class=3D850370713-04072001>my =
point, which=20
is, to be blunt, that proactive/reactive does cover</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN class=3D850370713-04072001>the =
case you are=20
so concerned about, at least as far as I am =
concerned.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN class=3D850370713-04072001>If =
you bother to=20
check through the archives you will see that I have</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN =
class=3D850370713-04072001>stated this many=20
times, in many ways.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN=20
class=3D850370713-04072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN =
class=3D850370713-04072001>&nbsp; 'nuff=20
said. I now agree with Pat. This will take at least a meeting=20
at</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN class=3D850370713-04072001>IETF =
51 to work=20
out; at least. I may or may not be there. My only</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN =
class=3D850370713-04072001>caution is that=20
exchanging one set of terms for another will likely</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN class=3D850370713-04072001>not =
resolve the=20
real issue, just bury it until someone comes up =
with</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN class=3D850370713-04072001>more =
detail to=20
argue. I have no great love for the terms =
"proactive"</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN class=3D850370713-04072001>and =
"reactive",=20
but I am fully convinced that choosing new =
terminology</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN class=3D850370713-04072001>will =
set us back=20
to January of this year, when Seamoby had the =
discussion</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN class=3D850370713-04072001>of =
"soft" versus=20
"hard", "make-before-break" versus =
"break-before-make".</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN=20
class=3D850370713-04072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN =
class=3D850370713-04072001>&nbsp; As I tried=20
to indicate in my previous posting, if you believe your case=20
needs</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN =
class=3D850370713-04072001>emphasis, then=20
let's work it into the wording of the current draft. Until=20
some</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN =
class=3D850370713-04072001>clearly superior=20
terminology arises, let's work with what we have.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN=20
class=3D850370713-04072001>Gary</SPAN></FONT></DIV>
<DIV><FONT face=3D"Comic Sans MS"><SPAN class=3D850370713-04072001>Plus =
ca change,=20
plus c'est le m=EAme chose.</SPAN></FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Cedric Westphal=20
  [mailto:cedric@iprg.nokia.com]<BR><B>Sent:</B> Wednesday, July 04, =
2001 3:24=20
  AM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]<BR><B>Cc:</B>=20
  'seamoby'<BR><B>Subject:</B> Need for support of neither pro nor =
reactive ct.=20
  was: Re: [seamoby] Issue #4: Clear, unambiguous definitions=20
  missing<BR><BR></DIV></FONT>Gary:=20
  <P>I read your reply, and I have the feeling that you are trying to =
convince=20
  me that <BR>proactive and reactive cts are indeed required. I think =
you are=20
  missing my point. <BR>First, for the record: I an convinced both =
proactive and=20
  reactive ct are required, <BR>and the definition proposed in this =
issue #4 are=20
  satisfying in this respect. They <BR>are necessary. Agreed. They are =
not=20
  sufficient. <BR>I am not going to comment point by point, I don't =
have time=20
  for this, but sum up: <BR>-in a previous mail, you said Rajeev's =
definitions=20
  (that you attributed to Pat) were <BR>good for you. <BR>-they are =
good=20
  definition for proactive and reactive. They do not consider a mixed =
situation,=20
  <BR>initiated prior to arrival and completed after. <BR>-the draft =
mentions=20
  the support of only proactive or reactive. The draft as well =
prohibits <BR>a=20
  mixed situation. A proactive ct that completes after whatever event =
is a=20
  failed proactive ct. <BR>It is a proactive that turns into a reactive =
(or=20
  should a fresh reactive ct be initiated if the proactive <BR>ct does =
not=20
  completes before the event, not so clear in the draft). There was not =
much=20
  <BR>point to comment before hand, since, as you say, the draft is =
ambiguous,=20
  and could be read any way. <BR>But since the clarification issue has =
been=20
  raised, we should address its consequences.=20
  <P>Please consider the situation where MN at some point in the =
future&nbsp;=20
  will go from oldAR to <BR>some identified newAR. I have this context =
that I=20
  want to transfer. However, it is of no critical value <BR>to the MN =
at newAR.=20
  I have the choice of: (a) proactive: I start transfering now, and =
pray it=20
  <BR>is established at newAR before (draft quote: 'it is required to =
forward=20
  the first packet arrival <BR>in the MN's traffic', new definition =
quote: 'the=20
  arrival of MN's packet at target AR). (b) reactive: <BR>I wait (new =
definition=20
  quote: 'subsequent to the arrival of MN's packet at target AR) until=20
  <BR>(draft mentions: 'initiation of a handover or soon after =
initiation').=20
  <BR>Please explain to me why, since I have no critical deadline, I =
should=20
  still make a choice between <BR>(a) or (b), that is, to simplify (a) =
ensure=20
  that all my context is transfered before handoff, or <BR>(b) wait =
until I=20
  handoff to transfer. Where is (c): I take a leisurely transfer around =
the=20
  handoff, <BR>I start before, but take it easy, dude, whenever I get =
there is=20
  when I get there. <BR>You might see this as a terminology issue, =
(what do you=20
  call (c) since it is not proactive nor reactive). <BR>I think it is =
more a=20
  requirement issue. If the requirement draft specifies (a) and (b), =
does not=20
  <BR>mention any other possibility, explains that if (a) fails, then =
use (b) as=20
  the only choice of combined/ <BR>mixed/soft ct, then it seems to =
imply that it=20
  excludes (c). <BR>I agree with (a) MUST be supported, (b) MUST be =
supported,=20
  tell me why (c) SHOULD NOT <BR>be supported as a requirement? =
<BR>Thanks,=20
  <P>Cedric. <BR>&nbsp;=20
  <BLOCKQUOTE TYPE=3D"CITE"><FONT=20
size=3D-1></FONT>&nbsp;</BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1048D.010F8A20--


From owner-seamoby@diameter.org  Wed Jul  4 09:37:17 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06363
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 09:37:14 -0400 (EDT)
Received: (qmail 25571 invoked by alias); 4 Jul 2001 13:24:20 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 25565 invoked by uid 200); 4 Jul 2001 13:24:20 -0000
Received: (qmail 25560 invoked from network); 4 Jul 2001 13:24:18 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 13:24:18 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f64DZDb10891
	for <seamoby@cdma-2000.org>; Wed, 4 Jul 2001 09:35:13 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 4 Jul 2001 09:35:11 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2WG5Z>; Wed, 4 Jul 2001 09:35:12 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DC3@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Date: Wed, 4 Jul 2001 09:35:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1048E.26F7B680"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1048E.26F7B680
Content-Type: text/plain;
	charset="iso-8859-1"

  Just a note to cover what I believe is a possible misinterpretation
that can be made from John's and Madjid's recent emails.

  The issue with triggers has nothing to do with "terminology" (yet). 
The issue with triggers has to do with the fact that there are a 
plethora of possible triggers that can be used. If we identify one
trigger in the requirements, then we need to identify either all, or a 
comprehensive set of examples. This is not "specmanship" - given 
that these triggers control ct, this is one of the most important 
issues to be resolved.

  I'm still not convinced that it is worthwhile trying to solve it 
in a requirements document.

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Wednesday, July 04, 2001 3:14 AM
> To: mobile-ip@sunroof.eng.sun.com; seamoby@cdma-2000.org
> Subject: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> 
> 
> Hi James,
> 
> > In fact, I am preparing just such a draft as we speak. The 
> > intent is to take the material from the BETH draft and from 
> > the FMIPv4 draft and perhaps add something on the link with 
> > Seamoby context transfer.
> 
> I think this would be extremely worthwhile.  It seems that 
> SeaMoby is currently struggling over terminology about
> triggers, etc. with respect to handovers.  I'd even suggest
> that interested parties from both MIP & SeaMoby get together
> in London to discuss how to move forward.  Perhaps it would 
> be a good thing if MIP & SeaMoby could work together on this
> issue - in order to assure that the resultant work suits both
> groups.
> 
> best regards,
> John
> 

------_=_NextPart_001_01C1048E.26F7B680
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>&nbsp; Just a note to cover what I believe is a possible misinterpretation</FONT>
<BR><FONT SIZE=2>that can be made from John's and Madjid's recent emails.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; The issue with triggers has nothing to do with &quot;terminology&quot; (yet). </FONT>
<BR><FONT SIZE=2>The issue with triggers has to do with the fact that there are a </FONT>
<BR><FONT SIZE=2>plethora of possible triggers that can be used. If we identify one</FONT>
<BR><FONT SIZE=2>trigger in the requirements, then we need to identify either all, or a </FONT>
<BR><FONT SIZE=2>comprehensive set of examples. This is not &quot;specmanship&quot; - given </FONT>
<BR><FONT SIZE=2>that these triggers control ct, this is one of the most important </FONT>
<BR><FONT SIZE=2>issues to be resolved.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I'm still not convinced that it is worthwhile trying to solve it </FONT>
<BR><FONT SIZE=2>in a requirements document.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: john.loughney@nokia.com [<A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, July 04, 2001 3:14 AM</FONT>
<BR><FONT SIZE=2>&gt; To: mobile-ip@sunroof.eng.sun.com; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi James,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; In fact, I am preparing just such a draft as we speak. The </FONT>
<BR><FONT SIZE=2>&gt; &gt; intent is to take the material from the BETH draft and from </FONT>
<BR><FONT SIZE=2>&gt; &gt; the FMIPv4 draft and perhaps add something on the link with </FONT>
<BR><FONT SIZE=2>&gt; &gt; Seamoby context transfer.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think this would be extremely worthwhile.&nbsp; It seems that </FONT>
<BR><FONT SIZE=2>&gt; SeaMoby is currently struggling over terminology about</FONT>
<BR><FONT SIZE=2>&gt; triggers, etc. with respect to handovers.&nbsp; I'd even suggest</FONT>
<BR><FONT SIZE=2>&gt; that interested parties from both MIP &amp; SeaMoby get together</FONT>
<BR><FONT SIZE=2>&gt; in London to discuss how to move forward.&nbsp; Perhaps it would </FONT>
<BR><FONT SIZE=2>&gt; be a good thing if MIP &amp; SeaMoby could work together on this</FONT>
<BR><FONT SIZE=2>&gt; issue - in order to assure that the resultant work suits both</FONT>
<BR><FONT SIZE=2>&gt; groups.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; best regards,</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1048E.26F7B680--


From owner-seamoby@diameter.org  Wed Jul  4 09:42:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06450
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 09:41:59 -0400 (EDT)
Received: (qmail 26028 invoked by alias); 4 Jul 2001 13:28:03 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26022 invoked by uid 200); 4 Jul 2001 13:28:03 -0000
Received: (qmail 26013 invoked from network); 4 Jul 2001 13:28:01 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 13:28:01 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f64Dcob11537
	for <seamoby@diameter.org>; Wed, 4 Jul 2001 09:38:50 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 4 Jul 2001 09:38:46 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2WG90>; Wed, 4 Jul 2001 09:38:48 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DC4@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing
Date: Wed, 4 Jul 2001 09:38:49 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1048E.A7EFEAF0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1048E.A7EFEAF0
Content-Type: text/plain;
	charset="iso-8859-1"

Kulwinder:

> -----Original Message-----
> From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
> Sent: Wednesday, July 04, 2001 5:56 AM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric Westphal'
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; 
> charliep@iprg.nokia.com
> Subject: RE: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing
> 
> 
> 
> Consider a Network-Initiated Context Transfer (leaving out the Acks):
> 
> The Network Initiator could be any entity including: 
> ParentAR, oldAR, newAR,
> MN.
> 
> Step 1:
> 
>  MN	[oldAR]<---- CT Request MSG -----+
>  |       |                             |
>  |       |                             |
>  |       |                             |
>  |       |                            [ParentAR]<- Common RT 
> Change/CT MSG
> --[Network Initiator]
>  |       |                             |
>  |       |                             |
>  V       |                             |
>       [newAR]<--- New MN packets ------+
> 
> Step 2:
> 
>  |	[oldAR]--------------------------+
>  |       |                             |
>  |       |                             |
>  |       |                             |
>  |    Context                          [ParentAR]---------[Network
> Initiator]
>  |    Transfer                         |
>  |       |                             |
>  V       V                             |
>  MN	[newAR]--------------------------+
> 
> You will notice that it is impossible for the Context 
> Transfer to happen
> BEFORE the Route Change, or the arrival of new MN packets.  

Why? It is not only possible, but the equivalent of ct is performed today
in 2G cellular networks. There seems to be some presumptions built into
your model which I prefer not to guess at, perhaps you could explain 
why this is impossibility exists? 

*snip*

Gary

------_=_NextPart_001_01C1048E.A7EFEAF0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [seamoby] Issue #4: Clear, unambiguous definitions =
missing</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Kulwinder:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Kulwinder Atwal [<A =
HREF=3D"mailto:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucot=
to.com</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, July 04, 2001 5:56 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric =
Westphal'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; =
</FONT>
<BR><FONT SIZE=3D2>&gt; charliep@iprg.nokia.com</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: [seamoby] Issue #4: Clear, =
unambiguous </FONT>
<BR><FONT SIZE=3D2>&gt; definitions missing</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Consider a Network-Initiated Context Transfer =
(leaving out the Acks):</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; The Network Initiator could be any entity =
including: </FONT>
<BR><FONT SIZE=3D2>&gt; ParentAR, oldAR, newAR,</FONT>
<BR><FONT SIZE=3D2>&gt; MN.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Step 1:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; MN&nbsp;&nbsp; [oldAR]&lt;---- CT Request =
MSG -----+</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp; [ParentAR]&lt;- Common RT </FONT>
<BR><FONT SIZE=3D2>&gt; Change/CT MSG</FONT>
<BR><FONT SIZE=3D2>&gt; --[Network Initiator]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[newAR]&lt;--- New MN packets ------+</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Step 2:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp; =
[oldAR]--------------------------+</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp; =
Context&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; [ParentAR]---------[Network</FONT>
<BR><FONT SIZE=3D2>&gt; Initiator]</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp; =
Transfer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp; |</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; MN&nbsp;&nbsp; =
[newAR]--------------------------+</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You will notice that it is impossible for the =
Context </FONT>
<BR><FONT SIZE=3D2>&gt; Transfer to happen</FONT>
<BR><FONT SIZE=3D2>&gt; BEFORE the Route Change, or the arrival of new =
MN packets.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>Why? It is not only possible, but the equivalent of =
ct is performed today</FONT>
<BR><FONT SIZE=3D2>in 2G cellular networks. There seems to be some =
presumptions built into</FONT>
<BR><FONT SIZE=3D2>your model which I prefer not to guess at, perhaps =
you could explain </FONT>
<BR><FONT SIZE=3D2>why this is impossibility exists? </FONT>
</P>

<P><FONT SIZE=3D2>*snip*</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1048E.A7EFEAF0--


From owner-seamoby@diameter.org  Wed Jul  4 09:51:59 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06664
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 09:51:57 -0400 (EDT)
Received: (qmail 26522 invoked by alias); 4 Jul 2001 13:40:10 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26516 invoked by uid 200); 4 Jul 2001 13:40:10 -0000
Received: (qmail 26511 invoked from network); 4 Jul 2001 13:40:08 -0000
Received: from smtp1.cluster.oleane.net (195.25.12.16)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 13:40:08 -0000
Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp1.cluster.oleane.net with SMTP id f64Dpmg89223 for <seamoby@cdma-2000.org>; Wed, 4 Jul 2001 15:51:49 +0200 (CEST)
Message-ID: <008501c10490$58e21da0$0601a8c0@oleane.com>
From: "Peter Lewis" <peter.lewis@upperside.fr>
To: <seamoby@cdma-2000.org>
Subject: [seamoby] Mobile AD HOC Networks conference
Date: Wed, 4 Jul 2001 15:50:54 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0082_01C104A1.1BFD10A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0082_01C104A1.1BFD10A0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

=20
Mobile AD HOC Networks conference, Paris, December 4-7, 2001.
A call for proposals is on-line at:
http://www.upperside.fr/adhoc/adhocintro.htm



------=_NextPart_000_0082_01C104A1.1BFD10A0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial><FONT face=3DArial>&nbsp;
<DIV><FONT size=3D2>Mobile <STRONG>AD HOC Networks </STRONG>conference, =
Paris,=20
December 4-7, 2001.</FONT></DIV>
<DIV><FONT size=3D2>A call for proposals is on-line at:</FONT></DIV>
<DIV><FONT size=3D2><A=20
href=3D"http://www.upperside.fr/adhoc/adhocintro.htm">http://www.uppersid=
e.fr/adhoc/adhocintro.htm</A></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></FONT></FONT></DIV></BODY></HTML>

------=_NextPart_000_0082_01C104A1.1BFD10A0--



From owner-seamoby@diameter.org  Wed Jul  4 10:58:43 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07777
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 10:58:42 -0400 (EDT)
Received: (qmail 27031 invoked by alias); 4 Jul 2001 14:24:41 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27025 invoked by uid 200); 4 Jul 2001 14:24:41 -0000
Received: (qmail 27020 invoked from network); 4 Jul 2001 14:24:40 -0000
Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 14:24:40 -0000
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19)
	id <N72MTA3R>; Wed, 4 Jul 2001 10:35:52 -0400
Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F80B9@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        Kulwinder Atwal <kulwinder.atwal@zucotto.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing
Date: Wed, 4 Jul 2001 10:35:50 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C10496.9F736570"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10496.9F736570
Content-Type: text/plain;
	charset="iso-8859-1"

Does not the CT arrive after the first packet, if the CT cannot start until
the CT req has arrived from the ParentAR?
 
- Kulwinder.

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, July 04, 2001 9:39 AM
To: 'Kulwinder Atwal'
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing



Kulwinder: 

> -----Original Message----- 
> From: Kulwinder Atwal [ mailto:kulwinder.atwal@zucotto.com
<mailto:kulwinder.atwal@zucotto.com> ] 
> Sent: Wednesday, July 04, 2001 5:56 AM 
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric Westphal' 
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; 
> charliep@iprg.nokia.com 
> Subject: RE: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing 
> 
> 
> 
> Consider a Network-Initiated Context Transfer (leaving out the Acks): 
> 
> The Network Initiator could be any entity including: 
> ParentAR, oldAR, newAR, 
> MN. 
> 
> Step 1: 
> 
>  MN   [oldAR]<---- CT Request MSG -----+ 
>  |       |                             | 
>  |       |                             | 
>  |       |                             | 
>  |       |                            [ParentAR]<- Common RT 
> Change/CT MSG 
> --[Network Initiator] 
>  |       |                             | 
>  |       |                             | 
>  V       |                             | 
>       [newAR]<--- New MN packets ------+ 
> 
> Step 2: 
> 
>  |    [oldAR]--------------------------+ 
>  |       |                             | 
>  |       |                             | 
>  |       |                             | 
>  |    Context                          [ParentAR]---------[Network 
> Initiator] 
>  |    Transfer                         | 
>  |       |                             | 
>  V       V                             | 
>  MN   [newAR]--------------------------+ 
> 
> You will notice that it is impossible for the Context 
> Transfer to happen 
> BEFORE the Route Change, or the arrival of new MN packets.  

Why? It is not only possible, but the equivalent of ct is performed today 
in 2G cellular networks. There seems to be some presumptions built into 
your model which I prefer not to guess at, perhaps you could explain 
why this is impossibility exists? 

*snip* 

Gary 


------_=_NextPart_001_01C10496.9F736570
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>RE: [seamoby] Issue #4: Clear, unambiguous definitions =
missing</TITLE>

<META content=3D"MSHTML 5.50.4616.200" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D299333114-04072001><FONT face=3DArial =
color=3D#0000ff size=3D2>Does=20
not the CT arrive after the first packet, if the CT cannot start until =
the CT=20
req has arrived from the ParentAR?</FONT></SPAN></DIV>
<DIV><SPAN class=3D299333114-04072001><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D299333114-04072001><FONT face=3DArial =
color=3D#0000ff size=3D2>-=20
Kulwinder.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Gary Kenward=20
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, July =
04, 2001=20
  9:39 AM<BR><B>To:</B> 'Kulwinder Atwal'<BR><B>Cc:</B>=20
  'seamoby'<BR><B>Subject:</B> RE: [seamoby] Issue #4: Clear, =
unambiguous=20
  definitions missing<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Kulwinder:</FONT> </P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Kulwinder Atwal [<A=20
  =
href=3D"mailto:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucot=
to.com</A>]</FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Wednesday, July 04, 2001 5:56 AM</FONT> =
<BR><FONT=20
  size=3D2>&gt; To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric =
Westphal'</FONT> <BR><FONT=20
  size=3D2>&gt; Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; =
</FONT><BR><FONT=20
  size=3D2>&gt; charliep@iprg.nokia.com</FONT> <BR><FONT size=3D2>&gt; =
Subject: RE:=20
  [seamoby] Issue #4: Clear, unambiguous </FONT><BR><FONT size=3D2>&gt; =

  definitions missing</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
Consider a=20
  Network-Initiated Context Transfer (leaving out the Acks):</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; The Network Initiator =
could be any=20
  entity including: </FONT><BR><FONT size=3D2>&gt; ParentAR, oldAR, =
newAR,</FONT>=20
  <BR><FONT size=3D2>&gt; MN.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; Step 1:</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =

  size=3D2>&gt;&nbsp; MN&nbsp;&nbsp; [oldAR]&lt;---- CT Request MSG =
-----+</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;=20
  [ParentAR]&lt;- Common RT </FONT><BR><FONT size=3D2>&gt; Change/CT =
MSG</FONT>=20
  <BR><FONT size=3D2>&gt; --[Network Initiator]</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [newAR]&lt;--- New MN packets ------+</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Step 2:</FONT> <BR><FONT size=3D2>&gt; =

  </FONT><BR><FONT size=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;=20
  [oldAR]--------------------------+</FONT> <BR><FONT =
size=3D2>&gt;&nbsp;=20
  |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;=20
  =
Context&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;=20
  [ParentAR]---------[Network</FONT> <BR><FONT size=3D2>&gt; =
Initiator]</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;=20
  =
Transfer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;=20
  |</FONT> <BR><FONT size=3D2>&gt;&nbsp; MN&nbsp;&nbsp;=20
  [newAR]--------------------------+</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; You will notice that it is impossible =
for the=20
  Context </FONT><BR><FONT size=3D2>&gt; Transfer to happen</FONT> =
<BR><FONT=20
  size=3D2>&gt; BEFORE the Route Change, or the arrival of new MN =
packets.&nbsp;=20
  </FONT></P>
  <P><FONT size=3D2>Why? It is not only possible, but the equivalent of =
ct is=20
  performed today</FONT> <BR><FONT size=3D2>in 2G cellular networks. =
There seems=20
  to be some presumptions built into</FONT> <BR><FONT size=3D2>your =
model which I=20
  prefer not to guess at, perhaps you could explain </FONT><BR><FONT =
size=3D2>why=20
  this is impossibility exists? </FONT></P>
  <P><FONT size=3D2>*snip*</FONT> </P>
  <P><FONT size=3D2>Gary</FONT> </P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C10496.9F736570--


From owner-seamoby@diameter.org  Wed Jul  4 11:24:59 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08241
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 11:24:43 -0400 (EDT)
Received: (qmail 27546 invoked by alias); 4 Jul 2001 15:09:57 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27540 invoked by uid 200); 4 Jul 2001 15:09:56 -0000
Received: (qmail 27535 invoked from network); 4 Jul 2001 15:09:55 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 15:09:55 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA10013;
	Wed, 4 Jul 2001 08:21:08 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f64FL7a01862;
	Wed, 4 Jul 2001 08:21:07 -0700
X-mProtect:  Wed, 4 Jul 2001 08:21:07 -0700 Nokia Silicon Valley Messaging Protection
Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdd2DN6S; Wed, 04 Jul 2001 08:21:04 PDT
Message-ID: <3B433458.8BFE4345@iprg.nokia.com>
Date: Wed, 04 Jul 2001 08:20:56 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gary Kenward <gkenward@nortelnetworks.com>
CC: "'seamoby'" <seamoby@diameter.org>
Subject: Re: [seamoby] RE: Need for support of neither pro nor reactive ct. was: 
 Re: [se amoby] Issue #4: Clear, unambiguous definitions missing
References: <9FBD322B7824D511B36900508BF93C9C9F5DC2@zcard031.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------6378423E23DFCB90E3108FF7"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------6378423E23DFCB90E3108FF7
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Gary,

here again you tell me I want to scrap the proactive/reactive terms. How

many times do I have to tell you I like the definitions, I love
proactive CT,
I love reactive CT, I want to marry them in Utah and have a nice menage
a trois (plus c'est LA meme chose, by the way).
What's missing it the little kiddie of proactive and reactive, but you
are
right, there is no point continuing this discussion this way. Meeting in
London
ain't gonna happen, but I'll take up your offer and try to work it in
the wording.
Cheers,

Cedric.

Gary Kenward wrote:

>  Cedric:  All of us our busy. It is regrettable that you wasted your
> timeexplaining something which did not need explaining. You are
> missingmy point, which is, to be blunt, that proactive/reactive does
> coverthe case you are so concerned about, at least as far as I am
> concerned.If you bother to check through the archives you will see
> that I havestated this many times, in many ways.  'nuff said. I now
> agree with Pat. This will take at least a meeting atIETF 51 to work
> out; at least. I may or may not be there. My onlycaution is that
> exchanging one set of terms for another will likelynot resolve the
> real issue, just bury it until someone comes up withmore detail to
> argue. I have no great love for the terms "proactive"and "reactive",
> but I am fully convinced that choosing new terminologywill set us back
> to January of this year, when Seamoby had the discussionof "soft"
> versus "hard", "make-before-break" versus "break-before-make".  As I
> tried to indicate in my previous posting, if you believe your case
> needsemphasis, then let's work it into the wording of the current
> draft. Until someclearly superior terminology arises, let's work with
> what we have. GaryPlus ca change, plus c'est le même chose.
>
>      -----Original Message-----
>      From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
>      Sent: Wednesday, July 04, 2001 3:24 AM
>      To: Kenward, Gary [WDLN2:AN10:EXCH]
>      Cc: 'seamoby'
>      Subject: Need for support of neither pro nor reactive ct.
>      was: Re: [seamoby] Issue #4: Clear, unambiguous definitions
>      missing
>
>      Gary:
>
>      I read your reply, and I have the feeling that you are
>      trying to convince me that
>      proactive and reactive cts are indeed required. I think you
>      are missing my point.
>      First, for the record: I an convinced both proactive and
>      reactive ct are required,
>      and the definition proposed in this issue #4 are satisfying
>      in this respect. They
>      are necessary. Agreed. They are not sufficient.
>      I am not going to comment point by point, I don't have time
>      for this, but sum up:
>      -in a previous mail, you said Rajeev's definitions (that you
>      attributed to Pat) were
>      good for you.
>      -they are good definition for proactive and reactive. They
>      do not consider a mixed situation,
>      initiated prior to arrival and completed after.
>      -the draft mentions the support of only proactive or
>      reactive. The draft as well prohibits
>      a mixed situation. A proactive ct that completes after
>      whatever event is a failed proactive ct.
>      It is a proactive that turns into a reactive (or should a
>      fresh reactive ct be initiated if the proactive
>      ct does not completes before the event, not so clear in the
>      draft). There was not much
>      point to comment before hand, since, as you say, the draft
>      is ambiguous, and could be read any way.
>      But since the clarification issue has been raised, we should
>      address its consequences.
>
>      Please consider the situation where MN at some point in the
>      future  will go from oldAR to
>      some identified newAR. I have this context that I want to
>      transfer. However, it is of no critical value
>      to the MN at newAR. I have the choice of: (a) proactive: I
>      start transfering now, and pray it
>      is established at newAR before (draft quote: 'it is required
>      to forward the first packet arrival
>      in the MN's traffic', new definition quote: 'the arrival of
>      MN's packet at target AR). (b) reactive:
>      I wait (new definition quote: 'subsequent to the arrival of
>      MN's packet at target AR) until
>      (draft mentions: 'initiation of a handover or soon after
>      initiation').
>      Please explain to me why, since I have no critical deadline,
>      I should still make a choice between
>      (a) or (b), that is, to simplify (a) ensure that all my
>      context is transfered before handoff, or
>      (b) wait until I handoff to transfer. Where is (c): I take a
>      leisurely transfer around the handoff,
>      I start before, but take it easy, dude, whenever I get there
>      is when I get there.
>      You might see this as a terminology issue, (what do you call
>      (c) since it is not proactive nor reactive).
>      I think it is more a requirement issue. If the requirement
>      draft specifies (a) and (b), does not
>      mention any other possibility, explains that if (a) fails,
>      then use (b) as the only choice of combined/
>      mixed/soft ct, then it seems to imply that it excludes (c).
>      I agree with (a) MUST be supported, (b) MUST be supported,
>      tell me why (c) SHOULD NOT
>      be supported as a requirement?
>      Thanks,
>
>      Cedric.
>
>
>     >
>

--------------6378423E23DFCB90E3108FF7
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Gary,
<p>here again you tell me I want to scrap the proactive/reactive terms.
How
<br>many times do I have to tell you I like the definitions, I love proactive
CT,
<br>I love reactive CT, I want to marry them in Utah and have a nice menage
<br>a trois (plus c'est LA meme chose, by the way).
<br>What's missing it the little kiddie of proactive and reactive, but
you are
<br>right, there is no point continuing this discussion this way. Meeting
in London
<br>ain't gonna happen, but I'll take up your offer and try to work it
in
<br>the wording.
<br>Cheers,
<p>Cedric.
<p>Gary Kenward wrote:
<blockquote TYPE=CITE>&nbsp;<span 
class=850370713-04072001><font face="Comic Sans MS">Cedric:</font></span><span 
class=850370713-04072001></span><span class=850370713-04072001><font face="Comic Sans MS">&nbsp;
All of us our busy. It is regrettable that you wasted your time</font></span><span class=850370713-04072001><font face="Comic Sans MS">explaining
something which did not need explaining. You are missing</font></span><span class=850370713-04072001><font face="Comic Sans MS">my
point, which is, to be blunt, that proactive/reactive does cover</font></span><span class=850370713-04072001><font face="Comic Sans MS">the
case you are so concerned about, at least as far as I am concerned.</font></span><span class=850370713-04072001><font face="Comic Sans MS">If
you bother to check through the archives you will see that I have</font></span><span class=850370713-04072001><font face="Comic Sans MS">stated
this many times, in many ways.</font></span><span 
class=850370713-04072001></span><span class=850370713-04072001><font face="Comic Sans MS">&nbsp;
'nuff said. I now agree with Pat. This will take at least a meeting at</font></span><span class=850370713-04072001><font face="Comic Sans MS">IETF
51 to work out; at least. I may or may not be there. My only</font></span><span class=850370713-04072001><font face="Comic Sans MS">caution
is that exchanging one set of terms for another will likely</font></span><span class=850370713-04072001><font face="Comic Sans MS">not
resolve the real issue, just bury it until someone comes up with</font></span><span class=850370713-04072001><font face="Comic Sans MS">more
detail to argue. I have no great love for the terms "proactive"</font></span><span class=850370713-04072001><font face="Comic Sans MS">and
"reactive", but I am fully convinced that choosing new terminology</font></span><span class=850370713-04072001><font face="Comic Sans MS">will
set us back to January of this year, when Seamoby had the discussion</font></span><span class=850370713-04072001><font face="Comic Sans MS">of
"soft" versus "hard", "make-before-break" versus "break-before-make".</font></span><span 
class=850370713-04072001></span><span class=850370713-04072001><font face="Comic Sans MS">&nbsp;
As I tried to indicate in my previous posting, if you believe your case
needs</font></span><span class=850370713-04072001><font face="Comic Sans MS">emphasis,
then let's work it into the wording of the current draft. Until some</font></span><span class=850370713-04072001><font face="Comic Sans MS">clearly
superior terminology arises, let's work with what we have.</font></span>&nbsp;<span 
class=850370713-04072001><font face="Comic Sans MS">Gary</font></span><span class=850370713-04072001><font face="Comic Sans MS">Plus
ca change, plus c'est le m&ecirc;me chose.</font></span>
<blockquote 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Cedric Westphal [<A HREF="mailto:cedric@iprg.nokia.com">mailto:cedric@iprg.nokia.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, July 04,
2001 3:24 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Kenward, Gary [WDLN2:AN10:EXCH]</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> 'seamoby'</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> Need for support
of neither pro nor reactive ct. was: Re: [seamoby] Issue #4: Clear, unambiguous
definitions missing</font></font>
<br>&nbsp;</div>
Gary:
<p>I read your reply, and I have the feeling that you are trying to convince
me that
<br>proactive and reactive cts are indeed required. I think you are missing
my point.
<br>First, for the record: I an convinced both proactive and reactive ct
are required,
<br>and the definition proposed in this issue #4 are satisfying in this
respect. They
<br>are necessary. Agreed. They are not sufficient.
<br>I am not going to comment point by point, I don't have time for this,
but sum up:
<br>-in a previous mail, you said Rajeev's definitions (that you attributed
to Pat) were
<br>good for you.
<br>-they are good definition for proactive and reactive. They do not consider
a mixed situation,
<br>initiated prior to arrival and completed after.
<br>-the draft mentions the support of only proactive or reactive. The
draft as well prohibits
<br>a mixed situation. A proactive ct that completes after whatever event
is a failed proactive ct.
<br>It is a proactive that turns into a reactive (or should a fresh reactive
ct be initiated if the proactive
<br>ct does not completes before the event, not so clear in the draft).
There was not much
<br>point to comment before hand, since, as you say, the draft is ambiguous,
and could be read any way.
<br>But since the clarification issue has been raised, we should address
its consequences.
<p>Please consider the situation where MN at some point in the future&nbsp;
will go from oldAR to
<br>some identified newAR. I have this context that I want to transfer.
However, it is of no critical value
<br>to the MN at newAR. I have the choice of: (a) proactive: I start transfering
now, and pray it
<br>is established at newAR before (draft quote: 'it is required to forward
the first packet arrival
<br>in the MN's traffic', new definition quote: 'the arrival of MN's packet
at target AR). (b) reactive:
<br>I wait (new definition quote: 'subsequent to the arrival of MN's packet
at target AR) until
<br>(draft mentions: 'initiation of a handover or soon after initiation').
<br>Please explain to me why, since I have no critical deadline, I should
still make a choice between
<br>(a) or (b), that is, to simplify (a) ensure that all my context is
transfered before handoff, or
<br>(b) wait until I handoff to transfer. Where is (c): I take a leisurely
transfer around the handoff,
<br>I start before, but take it easy, dude, whenever I get there is when
I get there.
<br>You might see this as a terminology issue, (what do you call (c) since
it is not proactive nor reactive).
<br>I think it is more a requirement issue. If the requirement draft specifies
(a) and (b), does not
<br>mention any other possibility, explains that if (a) fails, then use
(b) as the only choice of combined/
<br>mixed/soft ct, then it seems to imply that it excludes (c).
<br>I agree with (a) MUST be supported, (b) MUST be supported, tell me
why (c) SHOULD NOT
<br>be supported as a requirement?
<br>Thanks,
<p>Cedric.
<br>&nbsp;
<blockquote TYPE="CITE">&nbsp;</blockquote>
</blockquote>
</blockquote>
</html>

--------------6378423E23DFCB90E3108FF7--



From owner-seamoby@diameter.org  Wed Jul  4 11:52:49 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08512
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 11:52:48 -0400 (EDT)
Received: (qmail 28014 invoked by alias); 4 Jul 2001 15:17:36 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28008 invoked by uid 200); 4 Jul 2001 15:17:36 -0000
Received: (qmail 27998 invoked from network); 4 Jul 2001 15:17:32 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 15:17:32 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f64FSIb03781
	for <seamoby@diameter.org>; Wed, 4 Jul 2001 11:28:18 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 4 Jul 2001 11:28:16 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2WKQQ>; Wed, 4 Jul 2001 11:28:16 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DCA@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing
Date: Wed, 4 Jul 2001 11:28:12 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1049D.F01D8E90"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1049D.F01D8E90
Content-Type: text/plain;
	charset="iso-8859-1"

Well, no, CT does not arrive after the first packet. Not if your aiming
for seamlessness and you attempt to be proactive.
 
This concept of a "ParentAR" is new to me, as far as I know, it is not 
required for ct. Regardless, ct can start as soon as the network determines
that there is a potential for handover to the receiving AR (aka "newAR",
although
I dislike this term as it implies a singular AR is involved in receiving
context, and 
that this "newAR" will be the handover target, which it may or may not be),
and
generates an L3 event to inform the ct peer to exchange context (somehow -
tbd
if and when we get around to designing a protocol).
 
The assumptions behind your scenario are valid for certain networking
solutions.
But, they are not generally applicable. Some networks know a lot about what
is
happening to the MN at the PHY/MAC level.
 
Regards,
Gary

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Wednesday, July 04, 2001 10:36 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; Kulwinder Atwal
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing


Does not the CT arrive after the first packet, if the CT cannot start until
the CT req has arrived from the ParentAR?
 
- Kulwinder.

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, July 04, 2001 9:39 AM
To: 'Kulwinder Atwal'
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing



Kulwinder: 

> -----Original Message----- 
> From: Kulwinder Atwal [ mailto:kulwinder.atwal@zucotto.com
<mailto:kulwinder.atwal@zucotto.com> ] 
> Sent: Wednesday, July 04, 2001 5:56 AM 
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric Westphal' 
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; 
> charliep@iprg.nokia.com 
> Subject: RE: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing 
> 
> 
> 
> Consider a Network-Initiated Context Transfer (leaving out the Acks): 
> 
> The Network Initiator could be any entity including: 
> ParentAR, oldAR, newAR, 
> MN. 
> 
> Step 1: 
> 
>  MN   [oldAR]<---- CT Request MSG -----+ 
>  |       |                             | 
>  |       |                             | 
>  |       |                             | 
>  |       |                            [ParentAR]<- Common RT 
> Change/CT MSG 
> --[Network Initiator] 
>  |       |                             | 
>  |       |                             | 
>  V       |                             | 
>       [newAR]<--- New MN packets ------+ 
> 
> Step 2: 
> 
>  |    [oldAR]--------------------------+ 
>  |       |                             | 
>  |       |                             | 
>  |       |                             | 
>  |    Context                          [ParentAR]---------[Network 
> Initiator] 
>  |    Transfer                         | 
>  |       |                             | 
>  V       V                             | 
>  MN   [newAR]--------------------------+ 
> 
> You will notice that it is impossible for the Context 
> Transfer to happen 
> BEFORE the Route Change, or the arrival of new MN packets.  

Why? It is not only possible, but the equivalent of ct is performed today 
in 2G cellular networks. There seems to be some presumptions built into 
your model which I prefer not to guess at, perhaps you could explain 
why this is impossibility exists? 

*snip* 

Gary 


------_=_NextPart_001_01C1049D.F01D8E90
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [seamoby] Issue #4: Clear, unambiguous definitions missing</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>Well, no, CT does 
not arrive after the first packet. Not if your aiming</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>for seamlessness 
and you attempt to be proactive.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>This concept of a 
"ParentAR" is new to me, as far as I know, it is not </SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>required for ct. 
Regardless, ct can start as soon as the network determines</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>that there is a 
potential for handover to the receiving AR (aka "newAR", 
although</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>I dislike this 
term as it implies a singular AR is involved in receiving context, and 
</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>that this "newAR" 
will be the handover target, which it may or may not be), 
and</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>generates an L3 
event to inform the ct peer to exchange context (somehow - 
tbd</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>if and when we 
get around to designing a protocol).</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=920001415-04072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>The assumptions 
behind your scenario are valid for certain networking 
solutions.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>But, they are not 
generally applicable. Some networks know a lot about what is</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>happening to the 
MN at&nbsp;the PHY/MAC level.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=920001415-04072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=920001415-04072001>Regards,</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=920001415-04072001>Gary</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Kulwinder Atwal 
  [mailto:kulwinder.atwal@zucotto.com]<BR><B>Sent:</B> Wednesday, July 04, 2001 
  10:36 AM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; Kulwinder 
  Atwal<BR><B>Cc:</B> 'seamoby'<BR><B>Subject:</B> RE: [seamoby] Issue #4: 
  Clear, unambiguous definitions missing<BR><BR></DIV></FONT>
  <DIV><SPAN class=299333114-04072001><FONT color=#0000ff face=Arial size=2>Does 
  not the CT arrive after the first packet, if the CT cannot start until the CT 
  req has arrived from the ParentAR?</FONT></SPAN></DIV>
  <DIV><SPAN class=299333114-04072001><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=299333114-04072001><FONT color=#0000ff face=Arial size=2>- 
  Kulwinder.</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
    [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, July 04, 
    2001 9:39 AM<BR><B>To:</B> 'Kulwinder Atwal'<BR><B>Cc:</B> 
    'seamoby'<BR><B>Subject:</B> RE: [seamoby] Issue #4: Clear, unambiguous 
    definitions missing<BR><BR></FONT></DIV>
    <P><FONT size=2>Kulwinder:</FONT> </P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: Kulwinder Atwal [<A 
    href="mailto:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucotto.com</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: Wednesday, July 04, 2001 5:56 AM</FONT> 
    <BR><FONT size=2>&gt; To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric 
    Westphal'</FONT> <BR><FONT size=2>&gt; Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 
    'seamoby'; </FONT><BR><FONT size=2>&gt; charliep@iprg.nokia.com</FONT> 
    <BR><FONT size=2>&gt; Subject: RE: [seamoby] Issue #4: Clear, unambiguous 
    </FONT><BR><FONT size=2>&gt; definitions missing</FONT> <BR><FONT 
    size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; Consider a Network-Initiated Context Transfer 
    (leaving out the Acks):</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; The Network Initiator could be any entity including: 
    </FONT><BR><FONT size=2>&gt; ParentAR, oldAR, newAR,</FONT> <BR><FONT 
    size=2>&gt; MN.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    Step 1:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; 
    MN&nbsp;&nbsp; [oldAR]&lt;---- CT Request MSG -----+</FONT> <BR><FONT 
    size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    [ParentAR]&lt;- Common RT </FONT><BR><FONT size=2>&gt; Change/CT MSG</FONT> 
    <BR><FONT size=2>&gt; --[Network Initiator]</FONT> <BR><FONT 
    size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp; V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    [newAR]&lt;--- New MN packets ------+</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; Step 2:</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp; 
    [oldAR]--------------------------+</FONT> <BR><FONT size=2>&gt;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp; 
    Context&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    [ParentAR]---------[Network</FONT> <BR><FONT size=2>&gt; Initiator]</FONT> 
    <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp; 
    Transfer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp; V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    |</FONT> <BR><FONT size=2>&gt;&nbsp; MN&nbsp;&nbsp; 
    [newAR]--------------------------+</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; You will notice that it is impossible for the 
    Context </FONT><BR><FONT size=2>&gt; Transfer to happen</FONT> <BR><FONT 
    size=2>&gt; BEFORE the Route Change, or the arrival of new MN packets.&nbsp; 
    </FONT></P>
    <P><FONT size=2>Why? It is not only possible, but the equivalent of ct is 
    performed today</FONT> <BR><FONT size=2>in 2G cellular networks. There seems 
    to be some presumptions built into</FONT> <BR><FONT size=2>your model which 
    I prefer not to guess at, perhaps you could explain </FONT><BR><FONT 
    size=2>why this is impossibility exists? </FONT></P>
    <P><FONT size=2>*snip*</FONT> </P>
    <P><FONT size=2>Gary</FONT> </P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1049D.F01D8E90--


From owner-seamoby@diameter.org  Wed Jul  4 12:28:30 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08954
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 12:28:27 -0400 (EDT)
Received: (qmail 28514 invoked by alias); 4 Jul 2001 15:50:00 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28508 invoked by uid 200); 4 Jul 2001 15:50:00 -0000
Received: (qmail 28501 invoked from network); 4 Jul 2001 15:49:58 -0000
Received: from 165.113.18.216.gt-est.net (HELO NEPTUNE.zucotto.com) (216.18.113.165)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 15:49:58 -0000
Received: by NEPTUNE.zucotto.com with Internet Mail Service (5.5.2653.19)
	id <N72MTASM>; Wed, 4 Jul 2001 12:01:11 -0400
Message-ID: <6833D86F1B05CA4FBAB3C73DD98BD8B95F80BA@NEPTUNE.zucotto.com>
From: Kulwinder Atwal <kulwinder.atwal@zucotto.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing
Date: Wed, 4 Jul 2001 12:01:10 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C104A2.8ABA1AF0"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C104A2.8ABA1AF0
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, July 04, 2001 11:28 AM
To: 'Kulwinder Atwal'
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing


Well, no, CT does not arrive after the first packet. Not if your aiming
for seamlessness and you attempt to be proactive.
 
This concept of a "ParentAR" is new to me, as far as I know, it is not 
required for ct. Regardless, ct can start as soon as the network determines 
 
[KA] My point is that it is the network that determines when to start CT.
It is a network's responsibility to determine when to start CT.  And, it is
the network's responsibility to ensure that Handover and CT complete near
the same time.  It is NOT the CT protocol's responsibility to ensure this,
therefore instisting that CT must complete before Handover is not a valid
requirement.  We could just as easily for a particular network say that we
want Handover to complete before CT, and put the requirement into the
Handover Protocol.  The End-User would be just as satisfied.  The ordering
is inconsequential.
 
[KA]  It is network specific whether to start CT first, or Handover first.
It absolutely does not matter which finishes first.  Just as you can provide
examples of when Handover happens first,  I can provide examples where the
reverse is true.
 
[KA]  Rather than have people say, " Oh, but we really need CT to happen
before handover.  So much so, that we must have it as a MUST requirement",
I would like these same people to show what terrible thing would happen if
the order were reversed by a few milliseconds.
 
[KA] We are all interested in having CT happen quickly, so I really don't
see the reason for this unnecessary sequential linkage in a requirements
document.
 
that there is a potential for handover to the receiving AR (aka "newAR",
although
I dislike this term as it implies a singular AR is involved in receiving
context, and 
that this "newAR" will be the handover target, which it may or may not be),
and
generates an L3 event to inform the ct peer to exchange context (somehow -
tbd
if and when we get around to designing a protocol).
 
The assumptions behind your scenario are valid for certain networking
solutions.
But, they are not generally applicable. Some networks know a lot about what
is
happening to the MN at the PHY/MAC level.
 
Regards,
Gary

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Wednesday, July 04, 2001 10:36 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]; Kulwinder Atwal
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing


Does not the CT arrive after the first packet, if the CT cannot start until
the CT req has arrived from the ParentAR?
 
- Kulwinder.

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, July 04, 2001 9:39 AM
To: 'Kulwinder Atwal'
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing



Kulwinder: 

> -----Original Message----- 
> From: Kulwinder Atwal [ mailto:kulwinder.atwal@zucotto.com
<mailto:kulwinder.atwal@zucotto.com> ] 
> Sent: Wednesday, July 04, 2001 5:56 AM 
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric Westphal' 
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'; 
> charliep@iprg.nokia.com 
> Subject: RE: [seamoby] Issue #4: Clear, unambiguous 
> definitions missing 
> 
> 
> 
> Consider a Network-Initiated Context Transfer (leaving out the Acks): 
> 
> The Network Initiator could be any entity including: 
> ParentAR, oldAR, newAR, 
> MN. 
> 
> Step 1: 
> 
>  MN   [oldAR]<---- CT Request MSG -----+ 
>  |       |                             | 
>  |       |                             | 
>  |       |                             | 
>  |       |                            [ParentAR]<- Common RT 
> Change/CT MSG 
> --[Network Initiator] 
>  |       |                             | 
>  |       |                             | 
>  V       |                             | 
>       [newAR]<--- New MN packets ------+ 
> 
> Step 2: 
> 
>  |    [oldAR]--------------------------+ 
>  |       |                             | 
>  |       |                             | 
>  |       |                             | 
>  |    Context                          [ParentAR]---------[Network 
> Initiator] 
>  |    Transfer                         | 
>  |       |                             | 
>  V       V                             | 
>  MN   [newAR]--------------------------+ 
> 
> You will notice that it is impossible for the Context 
> Transfer to happen 
> BEFORE the Route Change, or the arrival of new MN packets.  

Why? It is not only possible, but the equivalent of ct is performed today 
in 2G cellular networks. There seems to be some presumptions built into 
your model which I prefer not to guess at, perhaps you could explain 
why this is impossibility exists? 

*snip* 

Gary 


------_=_NextPart_001_01C104A2.8ABA1AF0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [seamoby] Issue #4: Clear, unambiguous definitions missing</TITLE>

<META content="MSHTML 5.50.4616.200" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=340313215-04072001><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, July 04, 2001 
  11:28 AM<BR><B>To:</B> 'Kulwinder Atwal'<BR><B>Cc:</B> 
  'seamoby'<BR><B>Subject:</B> RE: [seamoby] Issue #4: Clear, unambiguous 
  definitions missing<BR><BR></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>Well, no, CT 
  does not arrive after the first packet. Not if your aiming</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>for 
  seamlessness and you attempt to be proactive.</SPAN></FONT></DIV>
  <DIV><FONT face=Arial color=#0000ff size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>This concept of 
  a "ParentAR" is new to me, as far as I know, it is not </SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>required for 
  ct. Regardless, ct can start as soon as the network determines<SPAN 
  class=340313215-04072001><FONT face=Arial color=#0000ff 
  size=2>&nbsp;</FONT></SPAN></SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
  class=340313215-04072001></SPAN></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
  class=340313215-04072001>[KA] My point is that it is the network that 
  determines when to start CT.&nbsp; It is a network's responsibility to 
  determine when to start CT.&nbsp; And, it is the network's responsibility to 
  ensure that Handover and CT complete near the same time.&nbsp; It is NOT the 
  CT protocol's responsibility to ensure this, therefore instisting that CT must 
  complete before Handover is not a valid requirement.&nbsp; We could just as 
  easily for a particular network say that we want Handover to complete before 
  CT, and put the requirement into the Handover Protocol.&nbsp; The End-User 
  would be just as satisfied.&nbsp; The ordering is 
  inconsequential.</SPAN></SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
  class=340313215-04072001></SPAN></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
  class=340313215-04072001>[KA]&nbsp; It is network specific whether to start CT 
  first, or Handover first.&nbsp; It absolutely does not matter which finishes 
  first.&nbsp; Just as you can provide examples of when Handover happens 
  first,&nbsp; I can provide examples where the reverse is 
  true.</SPAN></SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
  class=340313215-04072001></SPAN></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
  class=340313215-04072001>[KA]&nbsp; Rather than have people say, " Oh, but we 
  really need CT to happen before handover.&nbsp; So much so, that we must have 
  it as a MUST requirement",&nbsp; I would like these same people to show what 
  terrible thing would happen if the order were reversed by a few 
  milliseconds.</SPAN></SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
  class=340313215-04072001></SPAN></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
  class=340313215-04072001>[KA] We are all interested in having CT happen 
  quickly, so I really don't see the reason for this unnecessary sequential 
  linkage in a requirements document.</SPAN></SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
  class=340313215-04072001></SPAN></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>that there is a 
  potential for handover to the receiving AR (aka "newAR", 
  although</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>I dislike this 
  term as it implies a singular AR is involved in receiving context, and 
  </SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>that this 
  "newAR" will be the handover target, which it may or may not be), 
  and</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>generates an L3 
  event to inform the ct peer to exchange context (somehow - 
  tbd</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>if and when we 
  get around to designing a protocol).</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=920001415-04072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>The assumptions 
  behind your scenario are valid for certain networking 
  solutions.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>But, they are 
  not generally applicable. Some networks know a lot about what 
  is</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>happening to 
  the MN at&nbsp;the PHY/MAC level.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=920001415-04072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=920001415-04072001>Regards,</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=920001415-04072001>Gary</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000080 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Kulwinder Atwal 
    [mailto:kulwinder.atwal@zucotto.com]<BR><B>Sent:</B> Wednesday, July 04, 
    2001 10:36 AM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; Kulwinder 
    Atwal<BR><B>Cc:</B> 'seamoby'<BR><B>Subject:</B> RE: [seamoby] Issue #4: 
    Clear, unambiguous definitions missing<BR><BR></DIV></FONT>
    <DIV><SPAN class=299333114-04072001><FONT face=Arial color=#0000ff 
    size=2>Does not the CT arrive after the first packet, if the CT cannot start 
    until the CT req has arrived from the ParentAR?</FONT></SPAN></DIV>
    <DIV><SPAN class=299333114-04072001><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=299333114-04072001><FONT face=Arial color=#0000ff size=2>- 
    Kulwinder.</FONT></SPAN></DIV>
    <BLOCKQUOTE dir=ltr 
    style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
      [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, July 04, 
      2001 9:39 AM<BR><B>To:</B> 'Kulwinder Atwal'<BR><B>Cc:</B> 
      'seamoby'<BR><B>Subject:</B> RE: [seamoby] Issue #4: Clear, unambiguous 
      definitions missing<BR><BR></FONT></DIV>
      <P><FONT size=2>Kulwinder:</FONT> </P>
      <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
      size=2>&gt; From: Kulwinder Atwal [<A 
      href="mailto:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucotto.com</A>]</FONT> 
      <BR><FONT size=2>&gt; Sent: Wednesday, July 04, 2001 5:56 AM</FONT> 
      <BR><FONT size=2>&gt; To: 'Nakhjiri Madjid-MNAKHJI1'; 'Cedric 
      Westphal'</FONT> <BR><FONT size=2>&gt; Cc: Kenward, Gary 
      [WDLN2:AN10:EXCH]; 'seamoby'; </FONT><BR><FONT size=2>&gt; 
      charliep@iprg.nokia.com</FONT> <BR><FONT size=2>&gt; Subject: RE: 
      [seamoby] Issue #4: Clear, unambiguous </FONT><BR><FONT size=2>&gt; 
      definitions missing</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
      size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
      Consider a Network-Initiated Context Transfer (leaving out the 
      Acks):</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; The 
      Network Initiator could be any entity including: </FONT><BR><FONT 
      size=2>&gt; ParentAR, oldAR, newAR,</FONT> <BR><FONT size=2>&gt; 
      MN.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Step 
      1:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt;&nbsp; 
      MN&nbsp;&nbsp; [oldAR]&lt;---- CT Request MSG -----+</FONT> <BR><FONT 
      size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      [ParentAR]&lt;- Common RT </FONT><BR><FONT size=2>&gt; Change/CT 
      MSG</FONT> <BR><FONT size=2>&gt; --[Network Initiator]</FONT> <BR><FONT 
      size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp; V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      [newAR]&lt;--- New MN packets ------+</FONT> <BR><FONT size=2>&gt; 
      </FONT><BR><FONT size=2>&gt; Step 2:</FONT> <BR><FONT size=2>&gt; 
      </FONT><BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp; 
      [oldAR]--------------------------+</FONT> <BR><FONT size=2>&gt;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp; 
      Context&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      [ParentAR]---------[Network</FONT> <BR><FONT size=2>&gt; Initiator]</FONT> 
      <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp; 
      Transfer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp; V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      |</FONT> <BR><FONT size=2>&gt;&nbsp; MN&nbsp;&nbsp; 
      [newAR]--------------------------+</FONT> <BR><FONT size=2>&gt; 
      </FONT><BR><FONT size=2>&gt; You will notice that it is impossible for the 
      Context </FONT><BR><FONT size=2>&gt; Transfer to happen</FONT> <BR><FONT 
      size=2>&gt; BEFORE the Route Change, or the arrival of new MN 
      packets.&nbsp; </FONT></P>
      <P><FONT size=2>Why? It is not only possible, but the equivalent of ct is 
      performed today</FONT> <BR><FONT size=2>in 2G cellular networks. There 
      seems to be some presumptions built into</FONT> <BR><FONT size=2>your 
      model which I prefer not to guess at, perhaps you could explain 
      </FONT><BR><FONT size=2>why this is impossibility exists? </FONT></P>
      <P><FONT size=2>*snip*</FONT> </P>
      <P><FONT size=2>Gary</FONT> 
</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C104A2.8ABA1AF0--


From owner-seamoby@diameter.org  Wed Jul  4 13:59:43 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09901
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 13:59:11 -0400 (EDT)
Received: (qmail 29102 invoked by alias); 4 Jul 2001 17:42:39 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 29096 invoked by uid 200); 4 Jul 2001 17:42:39 -0000
Received: (qmail 29091 invoked from network); 4 Jul 2001 17:42:36 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 17:42:36 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f64HrWb22899
	for <seamoby@diameter.org>; Wed, 4 Jul 2001 13:53:32 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 4 Jul 2001 13:53:33 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2W3JK>; Wed, 4 Jul 2001 13:53:34 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DCC@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing
Date: Wed, 4 Jul 2001 13:53:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C104B2.3D4E3570"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C104B2.3D4E3570
Content-Type: text/plain;
	charset="iso-8859-1"

Kulwinder:
 
  Sorry if I missed your point in the previous posting, some comments below.

-----Original Message-----
From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
Sent: Wednesday, July 04, 2001 12:01 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing


 

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, July 04, 2001 11:28 AM
To: 'Kulwinder Atwal'
Cc: 'seamoby'
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing


Well, no, CT does not arrive after the first packet. Not if your aiming
for seamlessness and you attempt to be proactive.
 
This concept of a "ParentAR" is new to me, as far as I know, it is not 
required for ct. Regardless, ct can start as soon as the network determines 
 
[KA] My point is that it is the network that determines when to start CT.
It is a network's responsibility to determine when to start CT.  And, it is
the network's responsibility to ensure that Handover and CT complete near
the same time.  It is NOT the CT protocol's responsibility to ensure this,
therefore instisting that CT must complete before Handover is not a valid
requirement.  We could just as easily for a particular network say that we
want Handover to complete before CT, and put the requirement into the
Handover Protocol.  The End-User would be just as satisfied.  The ordering
is inconsequential. 
 
> I didn't see this point in your previous posting.
> We do agree.
 
> My only caveat is that I am concerned that if we do not tie ct completion
somehow to handover 
> completion, there will be proposals ctp that have no time limit. We all
believe ct should finish quickly, 
> and the essential forwarding context should be installed at the newAR
before handover completion in 
> order to achieve the best possible handover performance. I think we all
agree that we have to be
> very careful about the exceptions to this "ideal" situation. Do we not?
 
It seems that the greatest difficulty we are experiencing is in capturing
the exceptions without losing the preferred "ideal".
 
[KA]  It is network specific whether to start CT first, or Handover first.
It absolutely does not matter which finishes first.  Just as you can provide
examples of when Handover happens first,  I can provide examples where the
reverse is true. 
 
> It does matter which completes first. If handover "completes" first (e.g.
packets are sitting in a queue > at the newAR) but the encryption context
has not arrived, then the newAR cannot forward those > packets. They will
incur an additional delay. 
 
> Does it matter if the packets are delayed by 0.0001 seconds waiting for
context? Clearly not, but
> somehow we must capture the fact that a 100 ms delay does matter.
 
[KA]  Rather than have people say, " Oh, but we really need CT to happen
before handover.  So much so, that we must have it as a MUST requirement",
I would like these same people to show what terrible thing would happen if
the order were reversed by a few milliseconds. 
 
> A few milliseconds, no. A 100 ms yes. As an example, a 100 ms additional
delay incurred by 
> G.729 voice frames in a conversational voice session, and you might as
well drop the frames. 
> Dropping 4-5 sequential voice frames is *very* noticeable to a user, and
is clearly not "seamless".
 
[KA] We are all interested in having CT happen quickly, so I really don't
see the reason for this unnecessary sequential linkage in a requirements
document. 
 
> Well, I do not either. I am trying to come up with some definition that
preserves the flexibility
> of the current definition, but answers some peoples concerns. I would, at
this point, like
> to toss "proactive" and "reactive" and replace it with a description of
the desirable 
> timing characteristics of the ct process - something similar to the
concepts you and
> I are talking about here. I would submit an issue, if there was any hint
of support for
> this change.
 
Cheers,
Gary


------_=_NextPart_001_01C104B2.3D4E3570
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [seamoby] Issue #4: Clear, unambiguous definitions missing</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=900023017-04072001>Kulwinder:</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=900023017-04072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=900023017-04072001>&nbsp; Sorry if I 
missed your point in the previous posting, some comments 
below.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Kulwinder Atwal 
  [mailto:kulwinder.atwal@zucotto.com]<BR><B>Sent:</B> Wednesday, July 04, 2001 
  12:01 PM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]<BR><B>Cc:</B> 
  'seamoby'<BR><B>Subject:</B> RE: [seamoby] Issue #4: Clear, unambiguous 
  definitions missing<BR><BR></DIV></FONT>
  <DIV><SPAN class=340313215-04072001><FONT color=#0000ff face=Arial 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <BLOCKQUOTE dir=ltr 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
    [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, July 04, 
    2001 11:28 AM<BR><B>To:</B> 'Kulwinder Atwal'<BR><B>Cc:</B> 
    'seamoby'<BR><B>Subject:</B> RE: [seamoby] Issue #4: Clear, unambiguous 
    definitions missing<BR><BR></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>Well, no, CT 
    does not arrive after the first packet. Not if your 
    aiming</SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>for 
    seamlessness and you attempt to be proactive.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>This concept 
    of a "ParentAR" is new to me, as far as I know, it is not 
    </SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001>required for 
    ct. Regardless, ct can start as soon as the network determines<SPAN 
    class=340313215-04072001><FONT color=#0000ff face=Arial 
    size=2>&nbsp;</FONT></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001>[KA] My point is that it is the network that 
    determines when to start CT.&nbsp; It is a network's responsibility to 
    determine when to start CT.&nbsp; And, it is the network's responsibility to 
    ensure that Handover and CT complete near the same time.&nbsp; It is NOT the 
    CT protocol's responsibility to ensure this, therefore instisting that CT 
    must complete before Handover is not a valid requirement.&nbsp; We could 
    just as easily for a particular network say that we want Handover to 
    complete before CT, and put the requirement into the Handover 
    Protocol.&nbsp; The End-User would be just as satisfied.&nbsp; The ordering 
    is inconsequential.<SPAN 
    class=900023017-04072001>&nbsp;</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001></SPAN></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>I didn't see 
    this point in your previous posting.</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>We do 
    agree.</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&nbsp;</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>My only 
    caveat is that I am concerned that if we do not tie ct completion 
    somehow</SPAN></SPAN></SPAN></FONT><FONT face="Comic Sans MS"><SPAN 
    class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
    class=900023017-04072001>&nbsp;to handover 
</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>completion, 
    there will be proposals ctp that have no time limit. We 
    all</SPAN></SPAN></SPAN></FONT><FONT face="Comic Sans MS"><SPAN 
    class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
    class=900023017-04072001> believe ct should finish quickly, 
    </SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>and the 
    essential forwarding context should be installed at the newAR before 
    handover completion in </SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>order to 
    achieve the best possible handover performance. I think we all agree that we 
    have to be</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>very careful 
    about the exceptions to this "ideal" situation. Do we 
    not?</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001></SPAN></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001>It seems that the 
    greatest difficulty we are experiencing is in capturing the exceptions 
    without losing the preferred "ideal".</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001>[KA]&nbsp; It is network specific whether to start 
    CT first, or Handover first.&nbsp; It absolutely does not&nbsp;matter which 
    finishes first.&nbsp; Just as you can provide examples of when Handover 
    happens first,&nbsp;</SPAN></SPAN></FONT><FONT face="Comic Sans MS"><SPAN 
    class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
    class=900023017-04072001>&nbsp;</SPAN>I can<SPAN 
    class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
    class=900023017-04072001>&nbsp;</SPAN></SPAN></SPAN>provide examples where 
    the reverse is true.<SPAN 
    class=900023017-04072001>&nbsp;</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001></SPAN></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>It does 
    matter which completes first.&nbsp;If handover "completes" first 
    (e.g.&nbsp;packets are sitting in&nbsp;a queue <FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>at the newAR) 
    but the encryption context has not arrived, then the newAR cannot forward 
    those <FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>packets. They 
    will incur an additional delay. </SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001></SPAN></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>Does it 
    matter if the packets are delayed by 0.0001 seconds waiting for context? 
    Clearly not, but</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>somehow we 
    must capture the fact that a 100 ms delay does 
    matter.</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001>[KA]&nbsp; Rather than have people say, " Oh, but 
    we really need CT to happen before handover.&nbsp; So much so, that we must 
    have it as a MUST requirement",&nbsp; I would like these same people to show 
    what terrible thing would happen if the order were reversed by a few 
    milliseconds.<SPAN 
    class=900023017-04072001>&nbsp;</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001></SPAN></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>A few 
    milliseconds, no. A&nbsp;100 ms yes. As an example, a 100 ms additional 
    delay incurred by </SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>G.729 voice 
    frames in a conversational voice session, and you might as well drop the 
    frames. </SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>Dropping 4-5 
    sequential voice frames is *very* noticeable to a user, and is clearly not 
    "seamless".</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001>[KA] We are all interested in having CT happen 
    quickly, so I really don't see the reason for this unnecessary sequential 
    linkage in a requirements document.<SPAN 
    class=900023017-04072001>&nbsp;</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001></SPAN></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>Well, I do 
    not either. I&nbsp;am trying to come up with some definition 
    that&nbsp;preserves the flexibility</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>of the 
    current definition, but answers some peoples concerns. I would, at this 
    point, like</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>to toss 
    "proactive" and "reactive" and&nbsp;replace it with a description 
    of&nbsp;t</SPAN></SPAN></SPAN></FONT><FONT face="Comic Sans MS"><SPAN 
    class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
    class=900023017-04072001>he 
desirable&nbsp;</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN 
    class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN></FONT>timing 
    characteristics of the ct process&nbsp;- something similar to the concepts 
    you and</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001>&gt;&nbsp;I are 
    talking about here.&nbsp;I would submit an issue, if there was any hint of 
    support for</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001><SPAN class=900023017-04072001>&gt; this 
    change.</SPAN></SPAN></SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN class=920001415-04072001><SPAN 
    class=340313215-04072001></SPAN></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN 
    class=900023017-04072001>Cheers,</SPAN></FONT></DIV>
    <DIV><FONT face="Comic Sans MS"><SPAN 
    class=900023017-04072001>Gary</SPAN></FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C104B2.3D4E3570--


From owner-seamoby@diameter.org  Wed Jul  4 14:17:26 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10137
	for <seamoby-archive@odin.ietf.org>; Wed, 4 Jul 2001 14:17:15 -0400 (EDT)
Received: (qmail 29581 invoked by alias); 4 Jul 2001 18:00:38 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 29575 invoked by uid 200); 4 Jul 2001 18:00:37 -0000
Received: (qmail 29570 invoked from network); 4 Jul 2001 18:00:36 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 4 Jul 2001 18:00:36 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f64IBXb26209
	for <seamoby@diameter.org>; Wed, 4 Jul 2001 14:11:33 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 4 Jul 2001 14:11:33 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2W36A>; Wed, 4 Jul 2001 14:11:34 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DCE@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Cedric Westphal'" <cedric@iprg.nokia.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] RE: Need for support of neither pro nor reactive ct . 
         was: Re: [se amoby] Issue #4: Clear, unambiguous definitions missing
Date: Wed, 4 Jul 2001 14:11:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C104B4.C1B4CAC0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C104B4.C1B4CAC0
Content-Type: text/plain;
	charset="iso-8859-1"

Cedric:
 
   I suspect that we are actually close to agreement, just 10 degrees out of
phase.

-----Original Message-----
From: Cedric Westphal [mailto:cedric@iprg.nokia.com]
Sent: Wednesday, July 04, 2001 11:21 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]
Cc: 'seamoby'
Subject: Re: [seamoby] RE: Need for support of neither pro nor reactive ct.
was: Re: [se amoby] Issue #4: Clear, unambiguous definitions missing


Gary, 

here again you tell me I want to scrap the proactive/reactive terms. How   
many times do I have to tell you I like the definitions, I love proactive
CT,   
I love reactive CT, I want to marry them in Utah and have a nice menage 
a trois (plus c'est LA meme chose, by the way).  

Sounds very kinky. I actually didn't say anything such thing in my last
posting, or at least, 
I didn't intend to. I was trying to convince you that there wasn't a need
for another mode
(perhaps I misunderstand what you meant by proposing "soft" ct).

Thanks for reminding me. My French is atrocious. My country may be
bi-lingual, 
but I'm definitely semi-lingual.

 
What's missing it the little kiddie of proactive and reactive, but you are 
right, there is no point continuing this discussion this way. Meeting in
London  

Again, you interpret proactive and reactive  with a specific connotation.
I don't. So be it, but do we really need to define a new "soft" mode for ct?
Since I see this little kiddie accounted for in the current modes, and you
don't, something needs clarification. 

 Aside from not liking the term "soft", the reason I'm leery of new modes is
because it adds one more variable in an already contentious scenario. At
this
point, I would prefer to scrap these modes and instead describe the
preferred/
required characteristics of the ct process - e.g. it SHOULD start as early,
if possible,
so that the essential context is available at the newAR when the first
packet arrives,
*but* that some context may still be transferred after the forwarding
begins, *and* 
in some networks there may be no warning and ct can only be performed after
handover
begins/finishes.

Something like that, with a hell of a lot of word smithing.

ain't gonna happen, but I'll take up your offer and try to work it in  

Actually, between these email exchanges the earth shifted on it's axis,
and it turns out I will be there. I'm looking forward to it, as I'm sure
that
90% of the discussions over this issue are an artefact of using email rather
then face to face discussions. I'll bring my flame retardant long johns just
in
case.

 
the wording.  

Words are great.

 
Cheers, 

Cedric.   


Tally ho! Now, getting back to this thing in LA with "pro" and "rea" . . .  
Gary 


Gary Kenward wrote: 


 Cedric:  All of us our busy. It is regrettable that you wasted your
timeexplaining something which did not need explaining. You are missingmy
point, which is, to be blunt, that proactive/reactive does coverthe case you
are so concerned about, at least as far as I am concerned.If you bother to
check through the archives you will see that I havestated this many times,
in many ways.  'nuff said. I now agree with Pat. This will take at least a
meeting atIETF 51 to work out; at least. I may or may not be there. My
onlycaution is that exchanging one set of terms for another will likelynot
resolve the real issue, just bury it until someone comes up withmore detail
to argue. I have no great love for the terms "proactive"and "reactive", but
I am fully convinced that choosing new terminologywill set us back to
January of this year, when Seamoby had the discussionof "soft" versus
"hard", "make-before-break" versus "break-before-make".  As I tried to
indicate in my previous posting, if you believe your case needsemphasis,
then let's work it into the wording of the current draft. Until someclearly
superior terminology arises, let's work with what we have. GaryPlus ca
change, plus c'est le même chose. 

-----Original Message----- 
From: Cedric Westphal [ mailto:cedric@iprg.nokia.com
<mailto:cedric@iprg.nokia.com> ] 
Sent: Wednesday, July 04, 2001 3:24 AM 
To: Kenward, Gary [WDLN2:AN10:EXCH] 
Cc: 'seamoby' 
Subject: Need for support of neither pro nor reactive ct. was: Re: [seamoby]
Issue #4: Clear, unambiguous definitions missing 
 
Gary: 

I read your reply, and I have the feeling that you are trying to convince me
that 
proactive and reactive cts are indeed required. I think you are missing my
point. 
First, for the record: I an convinced both proactive and reactive ct are
required, 
and the definition proposed in this issue #4 are satisfying in this respect.
They 
are necessary. Agreed. They are not sufficient. 
I am not going to comment point by point, I don't have time for this, but
sum up: 
-in a previous mail, you said Rajeev's definitions (that you attributed to
Pat) were 
good for you. 
-they are good definition for proactive and reactive. They do not consider a
mixed situation, 
initiated prior to arrival and completed after. 
-the draft mentions the support of only proactive or reactive. The draft as
well prohibits 
a mixed situation. A proactive ct that completes after whatever event is a
failed proactive ct. 
It is a proactive that turns into a reactive (or should a fresh reactive ct
be initiated if the proactive 
ct does not completes before the event, not so clear in the draft). There
was not much 
point to comment before hand, since, as you say, the draft is ambiguous, and
could be read any way. 
But since the clarification issue has been raised, we should address its
consequences. 


Please consider the situation where MN at some point in the future  will go
from oldAR to 
some identified newAR. I have this context that I want to transfer. However,
it is of no critical value 
to the MN at newAR. I have the choice of: (a) proactive: I start transfering
now, and pray it 
is established at newAR before (draft quote: 'it is required to forward the
first packet arrival 
in the MN's traffic', new definition quote: 'the arrival of MN's packet at
target AR). (b) reactive: 
I wait (new definition quote: 'subsequent to the arrival of MN's packet at
target AR) until 
(draft mentions: 'initiation of a handover or soon after initiation'). 
Please explain to me why, since I have no critical deadline, I should still
make a choice between 
(a) or (b), that is, to simplify (a) ensure that all my context is
transfered before handoff, or 
(b) wait until I handoff to transfer. Where is (c): I take a leisurely
transfer around the handoff, 
I start before, but take it easy, dude, whenever I get there is when I get
there. 
You might see this as a terminology issue, (what do you call (c) since it is
not proactive nor reactive). 
I think it is more a requirement issue. If the requirement draft specifies
(a) and (b), does not 
mention any other possibility, explains that if (a) fails, then use (b) as
the only choice of combined/ 
mixed/soft ct, then it seems to imply that it excludes (c). 
I agree with (a) MUST be supported, (b) MUST be supported, tell me why (c)
SHOULD NOT 
be supported as a requirement? 
Thanks, 


Cedric. 
  


 


------_=_NextPart_001_01C104B4.C1B4CAC0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=680094717-04072001>Cedric:</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=680094717-04072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=680094717-04072001>&nbsp;&nbsp; I 
suspect that we are actually close to agreement, just 10 degrees out of 
phase.</SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Cedric Westphal 
  [mailto:cedric@iprg.nokia.com]<BR><B>Sent:</B> Wednesday, July 04, 2001 11:21 
  AM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]<BR><B>Cc:</B> 
  'seamoby'<BR><B>Subject:</B> Re: [seamoby] RE: Need for support of neither pro 
  nor reactive ct. was: Re: [se amoby] Issue #4: Clear, unambiguous definitions 
  missing<BR><BR></DIV></FONT>Gary, 
  <P>here again you tell me I want to scrap the proactive/reactive terms. 
  How&nbsp;<SPAN class=680094717-04072001><FONT 
  face="Comic Sans MS">&nbsp;</FONT></SPAN><SPAN 
  class=680094717-04072001>&nbsp;</SPAN><BR>many times do I have to tell you I 
  like the definitions, I love proactive CT,&nbsp;<SPAN 
  class=680094717-04072001><FONT face="Comic Sans MS">&nbsp;</FONT></SPAN><SPAN 
  class=680094717-04072001>&nbsp;</SPAN><BR>I love reactive CT, I want to marry 
  them in Utah and have a nice menage <BR>a trois (plus c'est LA meme chose, by 
  the way).&nbsp;<SPAN class=680094717-04072001><FONT 
  face="Comic Sans MS">&nbsp;</FONT></SPAN></P>
  <P><FONT face="Comic Sans MS"><SPAN class=680094717-04072001>Sounds very 
  kinky. I actually didn't say anything such thing in my&nbsp;last posting, or 
  at least, </SPAN></FONT><FONT face="Comic Sans MS"><SPAN 
  class=680094717-04072001><BR>I didn't intend to. I was trying to convince you 
  that there wasn't a need for another mode<BR>(perhaps I misunderstand what you 
  meant by proposing "soft" ct).</SPAN></FONT></P>
  <P><FONT face="Comic Sans MS"><SPAN class=680094717-04072001>Thanks for 
  reminding me. My French is atrocious. My country may be 
  bi-lingual,</SPAN></FONT><SPAN class=680094717-04072001><FONT 
  face="Comic Sans MS"> <BR>but I'm 
  definitely&nbsp;semi-lingual.</FONT></SPAN></P>
  <P><SPAN class=680094717-04072001>&nbsp;</SPAN><BR>What's missing it the 
  little kiddie of proactive and reactive, but you are <BR>right, there is no 
  point continuing this discussion this way. Meeting in London&nbsp;<FONT 
  face="Comic Sans MS"><SPAN class=680094717-04072001>&nbsp;</SPAN><SPAN 
  class=680094717-04072001></FONT><BR></SPAN><SPAN 
  class=680094717-04072001><BR><FONT face="Comic Sans MS">Again, you interpret 
  proactive and reactive&nbsp;</FONT>&nbsp;<FONT face="Comic Sans MS">with a 
  specific connotation.<BR>I don't. So be it, but do we really need to define a 
  new "soft" mode for ct?<BR>Since I see this little kiddie&nbsp;accounted for 
  in the current modes, and you<BR>don't, something needs clarification. 
  </FONT></SPAN></P>
  <P><SPAN class=680094717-04072001></SPAN><FONT face="Comic Sans MS"><SPAN 
  class=680094717-04072001>&nbsp;Aside from not liking the term "soft",&nbsp;the 
  reason I'm leery of new modes</SPAN><SPAN 
  class=680094717-04072001></FONT><FONT face="Comic Sans MS"> is<BR>because it 
  adds one more variable in an already contentious scenario. At this<BR>point, I 
  would prefer to scrap these modes and&nbsp;instead describe 
  the&nbsp;preferred/</FONT></SPAN><SPAN class=680094717-04072001><BR><FONT 
  face="Comic Sans MS">required characteristics of the ct process - e.g. 
  it&nbsp;SHOULD start as early</FONT></SPAN><FONT face="Comic Sans MS"><SPAN 
  class=680094717-04072001>, if possible,<BR>so that the essential context is 
  available at the&nbsp;newAR when the first packet arrives,</SPAN></FONT><SPAN 
  class=680094717-04072001><BR><FONT face="Comic Sans MS">*but* that some 
  context may still be transferred after the forwarding 
  begins,&nbsp;*and*</FONT>&nbsp;<BR></SPAN><SPAN class=680094717-04072001><FONT 
  face="Comic Sans MS">in some networks there may be no warning and ct can only 
  be performed after handover<BR>begins/finishes.</FONT></SPAN></P>
  <P><SPAN class=680094717-04072001><FONT face="Comic Sans MS">Something like 
  that, with a hell of a lot of word smithing.</FONT><BR></SPAN><BR>ain't gonna 
  happen, but I'll take up your offer and try to work it in&nbsp;<SPAN 
  class=680094717-04072001><FONT face="Comic Sans MS">&nbsp;</FONT></SPAN></P>
  <P><FONT face="Comic Sans MS"><SPAN 
  class=680094717-04072001>Actually,&nbsp;between&nbsp;these&nbsp;email 
  exchanges the earth shifted on it's ax</SPAN><SPAN 
  class=680094717-04072001>is,</SPAN><SPAN 
  class=680094717-04072001></FONT><BR><FONT face="Comic Sans MS">and it turns 
  out I will be there. I'm looking forward to it, as I'm sure 
  that</FONT></SPAN><SPAN class=680094717-04072001><BR><FONT 
  face="Comic Sans MS">90% of the discussions over this issue are an artefact 
  of&nbsp;using email&nbsp;rather</FONT></SPAN><SPAN 
  class=680094717-04072001><BR><FONT face="Comic Sans MS">then face to face 
  discussions. I'll bring my flame retardant&nbsp;long johns just 
  in</FONT></SPAN><SPAN class=680094717-04072001><BR><FONT 
  face="Comic Sans MS">case.</FONT></SPAN></P>
  <P><SPAN class=680094717-04072001>&nbsp;</SPAN><BR>the wording.&nbsp;<SPAN 
  class=680094717-04072001><FONT face="Comic Sans MS">&nbsp;</FONT></SPAN></P>
  <P><SPAN class=680094717-04072001><FONT face="Comic Sans MS">Words are 
  great.</FONT></SPAN></P>
  <P><SPAN class=680094717-04072001>&nbsp;</SPAN><BR>Cheers, </P>
  <P>Cedric.&nbsp;<FONT face="Comic Sans MS"><SPAN 
  class=680094717-04072001>&nbsp;</SPAN></FONT>
  <P><FONT face="Comic Sans MS"><SPAN class=680094717-04072001>Tally ho! Now, 
  getting back to this thing in LA with "pro" and "rea" . . 
  .&nbsp;&nbsp;<BR>Gary</SPAN></FONT>
  <P>Gary Kenward wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp;<SPAN class=850370713-04072001><FONT 
    face="Comic Sans MS">Cedric:</FONT></SPAN><SPAN 
    class=850370713-04072001></SPAN><SPAN class=850370713-04072001><FONT 
    face="Comic Sans MS">&nbsp; All of us our busy. It is regrettable that you 
    wasted your time</FONT></SPAN><SPAN class=850370713-04072001><FONT 
    face="Comic Sans MS">explaining something which did not need explaining. You 
    are missing</FONT></SPAN><SPAN class=850370713-04072001><FONT 
    face="Comic Sans MS">my point, which is, to be blunt, that 
    proactive/reactive does cover</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">the case you are so 
    concerned about, at least as far as I am concerned.</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">If you bother to check 
    through the archives you will see that I have</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">stated this many times, 
    in many ways.</FONT></SPAN><SPAN class=850370713-04072001></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">&nbsp; 'nuff said. I now 
    agree with Pat. This will take at least a meeting at</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">IETF 51 to work out; at 
    least. I may or may not be there. My only</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">caution is that 
    exchanging one set of terms for another will likely</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">not resolve the real 
    issue, just bury it until someone comes up with</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">more detail to argue. I 
    have no great love for the terms "proactive"</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">and "reactive", but I am 
    fully convinced that choosing new terminology</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">will set us back to 
    January of this year, when Seamoby had the discussion</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">of "soft" versus "hard", 
    "make-before-break" versus "break-before-make".</FONT></SPAN><SPAN 
    class=850370713-04072001></SPAN><SPAN class=850370713-04072001><FONT 
    face="Comic Sans MS">&nbsp; As I tried to indicate in my previous posting, 
    if you believe your case needs</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">emphasis, then let's 
    work it into the wording of the current draft. Until some</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">clearly superior 
    terminology arises, let's work with what we have.</FONT></SPAN>&nbsp;<SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">Gary</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">Plus ca change, plus 
    c'est le même chose.</FONT></SPAN> 
    <BLOCKQUOTE 
    style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
      <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
      size=-1>-----Original Message-----</FONT></FONT> <BR><FONT 
      face=Tahoma><FONT size=-1><B>From:</B> Cedric Westphal [<A 
      href="mailto:cedric@iprg.nokia.com">mailto:cedric@iprg.nokia.com</A>]</FONT></FONT> 
      <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Wednesday, July 04, 2001 
      3:24 AM</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> 
      Kenward, Gary [WDLN2:AN10:EXCH]</FONT></FONT> <BR><FONT face=Tahoma><FONT 
      size=-1><B>Cc:</B> 'seamoby'</FONT></FONT> <BR><FONT face=Tahoma><FONT 
      size=-1><B>Subject:</B> Need for support of neither pro nor reactive ct. 
      was: Re: [seamoby] Issue #4: Clear, unambiguous definitions 
      missing</FONT></FONT> <BR>&nbsp;</DIV>Gary: 
      <P>I read your reply, and I have the feeling that you are trying to 
      convince me that <BR>proactive and reactive cts are indeed required. I 
      think you are missing my point. <BR>First, for the record: I an convinced 
      both proactive and reactive ct are required, <BR>and the definition 
      proposed in this issue #4 are satisfying in this respect. They <BR>are 
      necessary. Agreed. They are not sufficient. <BR>I am not going to comment 
      point by point, I don't have time for this, but sum up: <BR>-in a previous 
      mail, you said Rajeev's definitions (that you attributed to Pat) were 
      <BR>good for you. <BR>-they are good definition for proactive and 
      reactive. They do not consider a mixed situation, <BR>initiated prior to 
      arrival and completed after. <BR>-the draft mentions the support of only 
      proactive or reactive. The draft as well prohibits <BR>a mixed situation. 
      A proactive ct that completes after whatever event is a failed proactive 
      ct. <BR>It is a proactive that turns into a reactive (or should a fresh 
      reactive ct be initiated if the proactive <BR>ct does not completes before 
      the event, not so clear in the draft). There was not much <BR>point to 
      comment before hand, since, as you say, the draft is ambiguous, and could 
      be read any way. <BR>But since the clarification issue has been raised, we 
      should address its consequences. 
      <P>Please consider the situation where MN at some point in the 
      future&nbsp; will go from oldAR to <BR>some identified newAR. I have this 
      context that I want to transfer. However, it is of no critical value 
      <BR>to the MN at newAR. I have the choice of: (a) proactive: I start 
      transfering now, and pray it <BR>is established at newAR before (draft 
      quote: 'it is required to forward the first packet arrival <BR>in the MN's 
      traffic', new definition quote: 'the arrival of MN's packet at target AR). 
      (b) reactive: <BR>I wait (new definition quote: 'subsequent to the arrival 
      of MN's packet at target AR) until <BR>(draft mentions: 'initiation of a 
      handover or soon after initiation'). <BR>Please explain to me why, since I 
      have no critical deadline, I should still make a choice between <BR>(a) or 
      (b), that is, to simplify (a) ensure that all my context is transfered 
      before handoff, or <BR>(b) wait until I handoff to transfer. Where is (c): 
      I take a leisurely transfer around the handoff, <BR>I start before, but 
      take it easy, dude, whenever I get there is when I get there. <BR>You 
      might see this as a terminology issue, (what do you call (c) since it is 
      not proactive nor reactive). <BR>I think it is more a requirement issue. 
      If the requirement draft specifies (a) and (b), does not <BR>mention any 
      other possibility, explains that if (a) fails, then use (b) as the only 
      choice of combined/ <BR>mixed/soft ct, then it seems to imply that it 
      excludes (c). <BR>I agree with (a) MUST be supported, (b) MUST be 
      supported, tell me why (c) SHOULD NOT <BR>be supported as a requirement? 
      <BR>Thanks, 
      <P>Cedric. <BR>&nbsp; 
      <BLOCKQUOTE 
TYPE="CITE">&nbsp;</BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C104B4.C1B4CAC0--


From owner-seamoby@diameter.org  Thu Jul  5 03:30:07 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04514
	for <seamoby-archive@odin.ietf.org>; Thu, 5 Jul 2001 03:29:44 -0400 (EDT)
Received: (qmail 30830 invoked by alias); 5 Jul 2001 07:12:18 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30824 invoked by uid 200); 5 Jul 2001 07:12:18 -0000
Received: (qmail 30819 invoked from network); 5 Jul 2001 07:12:16 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jul 2001 07:12:16 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA05805;
	Thu, 5 Jul 2001 00:23:30 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f657NUp03494;
	Thu, 5 Jul 2001 00:23:30 -0700
X-mProtect:  Thu, 5 Jul 2001 00:23:30 -0700 Nokia Silicon Valley Messaging Protection
Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdzRqyCw; Thu, 05 Jul 2001 00:23:26 PDT
Message-ID: <3B4415E6.AF334D48@iprg.nokia.com>
Date: Thu, 05 Jul 2001 00:23:18 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gary Kenward <gkenward@nortelnetworks.com>
CC: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'seamoby'" <seamoby@diameter.org>
Subject: [seamoby] Timing characteristics Re: [seamoby] Issue #4: Clear, 
 unambiguous definitions missing
References: <9FBD322B7824D511B36900508BF93C9C9F5DCC@zcard031.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------C25EB0CB61C2F2804AF083F6"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------C25EB0CB61C2F2804AF083F6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gary,

with respect to your last comment, please do submit an issue about the
timing characteristics
of the ctp.
The sticky point of the other thread (neither pro nor reac thread) is
exactly this, so you can count
it as support for change. Let me explain: proactive/reactive as defined
in Issue#4 (whether
or not this will be integrated in the draft aside, many people, myself
included, liked these
crisp and clear definitions) do imply a time frame. Stuff happens
_before_ or _after_ some event,
so it situates them on the time axis compared to the event. The draft as
well, even though it
is more vaguely, situates the pro/reac ct on this axis.
This is useful in many/most situations, and IMO MUST be supported. Let's
say that proactive
and reactive belong to a class of ct that we could definitely use, the
timing aware ct (TACT).
Before anybody jumps on me, this is aware, not constrained.
The kiddies I mentioned earlier do not have a strict timing constraint,
more of a best effort
constraint. Call it in-tact, as a symmetric to tact, in being either a
negation (after pro and
re, latin prefixes are edgy nowadays) or indifferent/neutral wrt timing
(asynchronous transfer
mode was already taken :-).  Would you allow me to provide some text in
this direction?
If I may go further, the ct itself could be neither tactful nor intact
as a whole, each phase could
have a different characteristic. I'd elaborate on this but I'd like to
see first how the multiphase
support requirement is going to end up wordsmithed.
Cheers,

Cedric.



Gary Kenward wrote:

>  Kulwinder:  Sorry if I missed your point in the previous posting,
> some comments below.
>
>      -----Original Message-----
>      From: Kulwinder Atwal [mailto:kulwinder.atwal@zucotto.com]
>      Sent: Wednesday, July 04, 2001 12:01 PM
>      To: Kenward, Gary [WDLN2:AN10:EXCH]
>      Cc: 'seamoby'
>      Subject: RE: [seamoby] Issue #4: Clear, unambiguous
>      definitions missing
>
>
>           -----Original Message-----
>           From: Gary Kenward
>           [mailto:gkenward@nortelnetworks.com]
>           Sent: Wednesday, July 04, 2001 11:28 AM
>           To: 'Kulwinder Atwal'
>           Cc: 'seamoby'
>           Subject: RE: [seamoby] Issue #4: Clear,
>           unambiguous definitions missing
>
>           Well, no, CT does not arrive after the first
>           packet. Not if your aimingfor seamlessness and you
>           attempt to be proactive. This concept of a
>           "ParentAR" is new to me, as far as I know, it is
>           not required for ct. Regardless, ct can start as
>           soon as the network determines[KA] My point is
>           that it is the network that determines when to
>           start CT.  It is a network's responsibility to
>           determine when to start CT.  And, it is the
>           network's responsibility to ensure that Handover
>           and CT complete near the same time.  It is NOT the
>           CT protocol's responsibility to ensure this,
>           therefore instisting that CT must complete before
>           Handover is not a valid requirement.  We could
>           just as easily for a particular network say that
>           we want Handover to complete before CT, and put
>           the requirement into the Handover Protocol.  The
>           End-User would be just as satisfied.  The ordering
>           is inconsequential.> I didn't see this point in
>           your previous posting.> We do agree.> My only
>           caveat is that I am concerned that if we do not
>           tie ct completion somehow to
>           handover > completion, there will be proposals ctp
>           that have no time limit. We all believe ct should
>           finish quickly, > and the essential forwarding
>           context should be installed at the newAR before
>           handover completion in > order to achieve the best
>           possible handover performance. I think we all
>           agree that we have to be> very careful about the
>           exceptions to this "ideal" situation. Do we not?It
>           seems that the greatest difficulty we are
>           experiencing is in capturing the exceptions
>           without losing the preferred "ideal".[KA]  It is
>           network specific whether to start CT first, or
>           Handover first.  It absolutely does not matter
>           which finishes first.  Just as you can provide
>           examples of when Handover happens first, I
>           canprovide examples where the reverse is true.> It
>           does matter which completes first. If handover
>           "completes" first (e.g. packets are sitting in a
>           queue > at the newAR) but the encryption context
>           has not arrived, then the newAR cannot forward
>           those > packets. They will incur an additional
>           delay. > Does it matter if the packets are delayed
>           by 0.0001 seconds waiting for context? Clearly
>           not, but> somehow we must capture the fact that a
>           100 ms delay does matter.[KA]  Rather than have
>           people say, " Oh, but we really need CT to happen
>           before handover.  So much so, that we must have it
>           as a MUST requirement",  I would like these same
>           people to show what terrible thing would happen if
>           the order were reversed by a few milliseconds.> A
>           few milliseconds, no. A 100 ms yes. As an example,
>           a 100 ms additional delay incurred by > G.729
>           voice frames in a conversational voice session,
>           and you might as well drop the frames. > Dropping
>           4-5 sequential voice frames is *very* noticeable
>           to a user, and is clearly not "seamless".[KA] We
>           are all interested in having CT happen quickly, so
>           I really don't see the reason for this unnecessary
>           sequential linkage in a requirements
>           document.> Well, I do not either. I am trying to
>           come up with some definition that preserves the
>           flexibility> of the current definition, but
>           answers some peoples concerns. I would, at this
>           point, like> to toss "proactive" and "reactive"
>           and replace it with a description of the
>           desirable > timing characteristics of the ct
>           process - something similar to the concepts you
>           and> I are talking about here. I would submit an
>           issue, if there was any hint of support for> this
>           change.Cheers,Gary
>

--------------C25EB0CB61C2F2804AF083F6
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Gary,
<p>with respect to your last comment, please do submit an issue about the
timing characteristics
<br>of the ctp.
<br>The sticky point of the other thread (neither pro nor reac thread)
is exactly this, so you can count
<br>it as support for change. Let me explain: proactive/reactive as defined
in Issue#4 (whether
<br>or not this will be integrated in the draft aside, many people, myself
included, liked these
<br>crisp and clear definitions) do imply a time frame. Stuff happens _before_
or _after_ some event,
<br>so it situates them on the time axis compared to the event. The draft
as well, even though it
<br>is more vaguely, situates the pro/reac ct on this axis.
<br>This is useful in many/most situations, and IMO MUST be supported.
Let's say that proactive
<br>and reactive belong to a class of ct that we could definitely use,
the timing aware ct (TACT).
<br>Before anybody jumps on me, this is aware, not constrained.
<br>The kiddies I mentioned earlier do not have a strict timing constraint,
more of a best effort
<br>constraint. Call it in-tact, as a symmetric to tact, in being either
a negation (after pro and
<br>re, latin prefixes are edgy nowadays) or indifferent/neutral wrt timing
(asynchronous transfer
<br>mode was already taken :-).&nbsp; Would you allow me to provide some
text in this direction?
<br>If I may go further, the ct itself could be neither tactful nor intact
as a whole, each phase could
<br>have a different characteristic. I'd elaborate on this but I'd like
to see first how the multiphase
<br>support requirement is going to end up wordsmithed.
<br>Cheers,
<p>Cedric.
<br>&nbsp;
<br>&nbsp;
<p>Gary Kenward wrote:
<blockquote TYPE=CITE>&nbsp;<span 
class=900023017-04072001><font face="Comic Sans MS">Kulwinder:</font></span><span 
class=900023017-04072001></span><span class=900023017-04072001><font face="Comic Sans MS">&nbsp;
Sorry if I missed your point in the previous posting, some comments below.</font></span>
<blockquote dir=ltr 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Kulwinder Atwal [<A HREF="mailto:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucotto.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, July 04,
2001 12:01 PM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> Kenward, Gary [WDLN2:AN10:EXCH]</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> 'seamoby'</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> RE: [seamoby] Issue
#4: Clear, unambiguous definitions missing</font></font>
<br>&nbsp;</div>
<span class=340313215-04072001></span>
<blockquote dir=ltr 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
<div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
Message-----</font></font>
<br><font face="Tahoma"><font size=-1><b>From:</b> Gary Kenward [<A HREF="mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</font></font>
<br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, July 04,
2001 11:28 AM</font></font>
<br><font face="Tahoma"><font size=-1><b>To:</b> 'Kulwinder Atwal'</font></font>
<br><font face="Tahoma"><font size=-1><b>Cc:</b> 'seamoby'</font></font>
<br><font face="Tahoma"><font size=-1><b>Subject:</b> RE: [seamoby] Issue
#4: Clear, unambiguous definitions missing</font></font>
<br>&nbsp;</div>
<span class=920001415-04072001><font face="Comic Sans MS">Well, no, CT
does not arrive after the first packet. Not if your aiming</font></span><span class=920001415-04072001><font face="Comic Sans MS">for
seamlessness and you attempt to be proactive.</font></span>&nbsp;<span class=920001415-04072001><font face="Comic Sans MS">This
concept of a "ParentAR" is new to me, as far as I know, it is not&nbsp;</font></span><span class=920001415-04072001><font face="Comic Sans MS">required
for ct. Regardless, ct can start as soon as the network determines</font><span 
    class=340313215-04072001></span></span><span class=920001415-04072001><span 
    class=340313215-04072001></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><font face="Comic Sans MS">[KA]
My point is that it is the network that determines when to start CT.&nbsp;
It is a network's responsibility to determine when to start CT.&nbsp; And,
it is the network's responsibility to ensure that Handover and CT complete
near the same time.&nbsp; It is NOT the CT protocol's responsibility to
ensure this, therefore instisting that CT must complete before Handover
is not a valid requirement.&nbsp; We could just as easily for a particular
network say that we want Handover to complete before CT, and put the requirement
into the Handover Protocol.&nbsp; The End-User would be just as satisfied.&nbsp;
The ordering is inconsequential.</font><span 
    class=900023017-04072001></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>I
didn't see this point in your previous posting.</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>We
do agree.</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>My
only caveat is that I am concerned that if we do not tie ct completion
somehow</span></span></span><span 
    class=920001415-04072001><span class=340313215-04072001><span 
    class=900023017-04072001>
to handover&nbsp;</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>completion,
there will be proposals ctp that have no time limit. We all</span></span></span><span 
    class=920001415-04072001><span class=340313215-04072001><span 
    class=900023017-04072001>
believe ct should finish quickly,&nbsp;</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>and
the essential forwarding context should be installed at the newAR before
handover completion in&nbsp;</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>order
to achieve the best possible handover performance. I think we all agree
that we have to be</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>very
careful about the exceptions to this "ideal" situation. Do we not?</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><font face="Comic Sans MS">It
seems that the greatest difficulty we are experiencing is in capturing
the exceptions without losing the preferred "ideal".</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><font face="Comic Sans MS">[KA]&nbsp;
It is network specific whether to start CT first, or Handover first.&nbsp;
It absolutely does not matter which finishes first.&nbsp; Just as you can
provide examples of when Handover happens first,&nbsp;</span></span><span 
    class=920001415-04072001><span class=340313215-04072001><span 
    class=900023017-04072001></span>I
can<span 
    class=920001415-04072001><span class=340313215-04072001><span 
    class=900023017-04072001></span></span></span>provide
examples where the reverse is true.</font><span 
    class=900023017-04072001></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>It
does matter which completes first. If handover "completes" first (e.g.
packets are sitting in a queue&nbsp;<span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001>>&nbsp;</span></span></span>at
the newAR) but the encryption context has not arrived, then the newAR cannot
forward those&nbsp;<span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001>>&nbsp;</span></span></span>packets.
They will incur an additional delay.&nbsp;</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>Does
it matter if the packets are delayed by 0.0001 seconds waiting for context?
Clearly not, but</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>somehow
we must capture the fact that a 100 ms delay does matter.</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><font face="Comic Sans MS">[KA]&nbsp;
Rather than have people say, " Oh, but we really need CT to happen before
handover.&nbsp; So much so, that we must have it as a MUST requirement",&nbsp;
I would like these same people to show what terrible thing would happen
if the order were reversed by a few milliseconds.</font><span 
    class=900023017-04072001></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>A
few milliseconds, no. A 100 ms yes. As an example, a 100 ms additional
delay incurred by&nbsp;</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>G.729
voice frames in a conversational voice session, and you might as well drop
the frames.&nbsp;</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>Dropping
4-5 sequential voice frames is *very* noticeable to a user, and is clearly
not "seamless".</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><font face="Comic Sans MS">[KA]
We are all interested in having CT happen quickly, so I really don't see
the reason for this unnecessary sequential linkage in a requirements document.</font><span 
    class=900023017-04072001></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>Well,
I do not either. I am trying to come up with some definition that preserves
the flexibility</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>of
the current definition, but answers some peoples concerns. I would, at
this point, like</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>to
toss "proactive" and "reactive" and replace it with a description of t</span></span></span><span 
    class=920001415-04072001><span class=340313215-04072001><span 
    class=900023017-04072001>he
desirable&nbsp;</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><span class=920001415-04072001><span 
    class=340313215-04072001><span 
    class=900023017-04072001><font face="Comic Sans MS">>&nbsp;</span></span></span>timing
characteristics of the ct process - something similar to the concepts you
and</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><font face="Comic Sans MS">>
I are talking about here. I would submit an issue, if there was any hint
of support for</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001><span class=900023017-04072001><font face="Comic Sans MS">>
this change.</font></span></span></span><span class=920001415-04072001><span 
    class=340313215-04072001></span></span><span 
    class=900023017-04072001><font face="Comic Sans MS">Cheers,</font></span><span 
    class=900023017-04072001><font face="Comic Sans MS">Gary</font></span></blockquote>
</blockquote>
</blockquote>
</html>

--------------C25EB0CB61C2F2804AF083F6--



From owner-seamoby@diameter.org  Thu Jul  5 11:07:56 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15956
	for <seamoby-archive@odin.ietf.org>; Thu, 5 Jul 2001 11:07:22 -0400 (EDT)
Received: (qmail 32003 invoked by alias); 5 Jul 2001 14:47:34 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 31997 invoked by uid 200); 5 Jul 2001 14:47:34 -0000
Received: (qmail 31992 invoked from network); 5 Jul 2001 14:47:20 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 5 Jul 2001 14:47:20 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f65EwJb13379
	for <seamoby@diameter.org>; Thu, 5 Jul 2001 10:58:20 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Thu, 5 Jul 2001 10:58:14 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2W6KZ>; Thu, 5 Jul 2001 10:58:15 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DD3@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Cedric Westphal'" <cedric@IPRG.nokia.com>
Cc: "'Kulwinder Atwal'" <kulwinder.atwal@zucotto.com>,
        "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] Timing characteristics Re: [seamoby] Issue #4: Clea r, 
         unambiguous definitions missing
Date: Thu, 5 Jul 2001 10:58:13 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10562.E9E6B770"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10562.E9E6B770
Content-Type: text/plain;
	charset="iso-8859-1"

Cedric:
 
  I like the idea of using a "best effort ct" definition, simply because I
think it
will be intuitively appealing to all. The "timing aware" aspect seems less
crisp.
Perhaps "expedited ct" would be better? ;^} - I'm only half joking: the
problem
spaces are similar, in that we want to optimize timing without being
prohibitively constrained.
 
I must say that I lumped all this behaviour together in my interpretation of
the current definitions, and clearly this is insufficient for others. 
 
So let's both work on some text and see what we can each come up with and
compare
notes. Hopefully we will converge.
 
One last comment: the problem with the wording of issue #4 has to do with
the particular event used. For many networks, this is not the first event
available when a
handover is activated. Once handover is in process, the network can only
react to the
situation, and the ct performance is limited by this condition. 
 
Let me try and clarify with an example: say for a specific network, handover
is accomplished by first establishing a new data path at the link layer to
the new AP, in a 
make-before break scenario; in this scenario, the network can know that a
handover is 
happening, some  time before the MN's traffic starts to be moved to the
newAR. This only an single example, and it presumes that L2 events are used
to trigger ct, but this is not an unusual approach. The significant points
of this example are: the event that causes the network to react to the
handover and initiated a ct is not the first IP packet
arrival at the AR; second, this is clearly not proactive ct, for the network
had no time to
prepare the newAR for the handover, for whatever reasons, and is put in a
mode where 
it must transfer the essential forwarding context as soon as possible. The
difference here in terms of time may only be milliseconds or tens of
milliseconds, but it is a significant difference in terms of the design of
ct.
 
Cheers,
Gary
 
BTW: just to be sure, I don't get to introduce text into the draft on my
own. The
current process is for the text into the issues list. I edit the draft, but
only after
an issue has been raised and a consensus reached. I apologize for being
pedantic,
but with all the important debates going on, I do not want anyone to get the
false
impression that text sent to me should be put into the draft.

-----Original Message-----
From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
Sent: Thursday, July 05, 2001 3:23 AM
To: Kenward, Gary [WDLN2:AN10:EXCH]
Cc: 'Kulwinder Atwal'; 'seamoby'
Subject: [seamoby] Timing characteristics Re: [seamoby] Issue #4: Clear,
unambiguous definitions missing


Gary, 

with respect to your last comment, please do submit an issue about the
timing characteristics 
of the ctp. 
The sticky point of the other thread (neither pro nor reac thread) is
exactly this, so you can count 
it as support for change. Let me explain: proactive/reactive as defined in
Issue#4 (whether 
or not this will be integrated in the draft aside, many people, myself
included, liked these 
crisp and clear definitions) do imply a time frame. Stuff happens _before_
or _after_ some event, 
so it situates them on the time axis compared to the event. The draft as
well, even though it 
is more vaguely, situates the pro/reac ct on this axis. 
This is useful in many/most situations, and IMO MUST be supported. Let's say
that proactive 
and reactive belong to a class of ct that we could definitely use, the
timing aware ct (TACT). 
Before anybody jumps on me, this is aware, not constrained. 
The kiddies I mentioned earlier do not have a strict timing constraint, more
of a best effort 
constraint. Call it in-tact, as a symmetric to tact, in being either a
negation (after pro and 
re, latin prefixes are edgy nowadays) or indifferent/neutral wrt timing
(asynchronous transfer 
mode was already taken :-).  Would you allow me to provide some text in this
direction? 
If I may go further, the ct itself could be neither tactful nor intact as a
whole, each phase could 
have a different characteristic. I'd elaborate on this but I'd like to see
first how the multiphase 
support requirement is going to end up wordsmithed. 
Cheers, 


Cedric. 
  
  


Gary Kenward wrote: 


 Kulwinder:  Sorry if I missed your point in the previous posting, some
comments below. 

-----Original Message----- 
From: Kulwinder Atwal [ mailto:kulwinder.atwal@zucotto.com
<mailto:kulwinder.atwal@zucotto.com> ] 
Sent: Wednesday, July 04, 2001 12:01 PM 
To: Kenward, Gary [WDLN2:AN10:EXCH] 
Cc: 'seamoby' 
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing 
 


-----Original Message----- 
From: Gary Kenward [ mailto:gkenward@nortelnetworks.com
<mailto:gkenward@nortelnetworks.com> ] 
Sent: Wednesday, July 04, 2001 11:28 AM 
To: 'Kulwinder Atwal' 
Cc: 'seamoby' 
Subject: RE: [seamoby] Issue #4: Clear, unambiguous definitions missing 
 
Well, no, CT does not arrive after the first packet. Not if your aimingfor
seamlessness and you attempt to be proactive. This concept of a "ParentAR"
is new to me, as far as I know, it is not required for ct. Regardless, ct
can start as soon as the network determines[KA] My point is that it is the
network that determines when to start CT.  It is a network's responsibility
to determine when to start CT.  And, it is the network's responsibility to
ensure that Handover and CT complete near the same time.  It is NOT the CT
protocol's responsibility to ensure this, therefore instisting that CT must
complete before Handover is not a valid requirement.  We could just as
easily for a particular network say that we want Handover to complete before
CT, and put the requirement into the Handover Protocol.  The End-User would
be just as satisfied.  The ordering is inconsequential.> I didn't see this
point in your previous posting.> We do agree.> My only caveat is that I am
concerned that if we do not tie ct completion somehow to handover >
completion, there will be proposals ctp that have no time limit. We all
believe ct should finish quickly, > and the essential forwarding context
should be installed at the newAR before handover completion in > order to
achieve the best possible handover performance. I think we all agree that we
have to be> very careful about the exceptions to this "ideal" situation. Do
we not?It seems that the greatest difficulty we are experiencing is in
capturing the exceptions without losing the preferred "ideal".[KA]  It is
network specific whether to start CT first, or Handover first.  It
absolutely does not matter which finishes first.  Just as you can provide
examples of when Handover happens first, I canprovide examples where the
reverse is true.> It does matter which completes first. If handover
"completes" first (e.g. packets are sitting in a queue > at the newAR) but
the encryption context has not arrived, then the newAR cannot forward those
> packets. They will incur an additional delay. > Does it matter if the
packets are delayed by 0.0001 seconds waiting for context? Clearly not, but>
somehow we must capture the fact that a 100 ms delay does matter.[KA]
Rather than have people say, " Oh, but we really need CT to happen before
handover.  So much so, that we must have it as a MUST requirement",  I would
like these same people to show what terrible thing would happen if the order
were reversed by a few milliseconds.> A few milliseconds, no. A 100 ms yes.
As an example, a 100 ms additional delay incurred by > G.729 voice frames in
a conversational voice session, and you might as well drop the frames. >
Dropping 4-5 sequential voice frames is *very* noticeable to a user, and is
clearly not "seamless".[KA] We are all interested in having CT happen
quickly, so I really don't see the reason for this unnecessary sequential
linkage in a requirements document.> Well, I do not either. I am trying to
come up with some definition that preserves the flexibility> of the current
definition, but answers some peoples concerns. I would, at this point, like>
to toss "proactive" and "reactive" and replace it with a description of the
desirable > timing characteristics of the ct process - something similar to
the concepts you and> I are talking about here. I would submit an issue, if
there was any hint of support for> this change.Cheers,Gary


------_=_NextPart_001_01C10562.E9E6B770
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001>Cedric:</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>&nbsp; I like the 
idea of using a "best effort ct" definition, simply because I think 
it</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>will be 
intuitively appealing to all. The "timing aware" aspect seems less 
crisp.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>Perhaps 
"expedited ct" would be better? ;^} - I'm only half joking: the 
problem</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>spaces are 
similar, in that we want to optimize timing without being prohibitively 
constrained.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>I must say that I 
lumped all this behaviour together in my interpretation of</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>the current 
definitions, and clearly this is insufficient for others. </SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>So let's both 
work on some text and see what we can each come up with and 
compare</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>notes. Hopefully 
we will converge.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>One last comment: 
the problem with the wording of issue #4 has to do with the particular event 
used. For many networks, this is not the first event available when 
a</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>handover is 
activated. Once handover is in process, the network can only react to 
the</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>situation, and 
the ct performance is limited by this condition. </SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>Let me try and 
clarify</SPAN></FONT><FONT face="Comic Sans MS"><SPAN class=030412214-05072001> 
with an example: say for a specific network, handover is accomplished by 
first</SPAN></FONT><FONT face="Comic Sans MS"><SPAN class=030412214-05072001> 
establishing a new data path at the link layer to the new AP, in a 
</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>make-before break 
scenario; in</SPAN></FONT><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001> this scenario, the network can know that a handover is 
</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>happening, 
some</SPAN></FONT><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001>&nbsp; time before the</SPAN></FONT><FONT 
face="Comic Sans MS"><SPAN class=030412214-05072001> MN's traffic starts to be 
moved to the newAR. This only an single example, and it presumes that L2 events 
are used to trigger ct, but this is not an unusual approach. The significant 
points of this example are: the event that causes the network to react to the 
handover and initiated a ct is not the first IP packet</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>arrival at the 
AR; second, this is clearly not proactive ct, for the network had no time 
to</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>prepare the newAR 
for the handover, for whatever reasons, and is put in a mode where 
</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>it must transfer 
the essential forwarding context as soon as possible. The difference here in 
terms of time may only be milliseconds or tens of milliseconds, but it is a 
significant difference in terms of the design of ct.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001>Cheers,</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001>Gary</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001></SPAN></FONT><FONT face="Comic Sans MS"><SPAN 
class=030412214-05072001>&nbsp;</DIV>
<DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>BTW: just to be 
sure, I don't get to introduce text into the draft on my own. 
The</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>current process 
is for the text into the issues list. I edit the draft, but only 
after</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>an issue has been 
raised and a consensus reached. I apologize for being 
pedantic,</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>but with all the 
important debates going on, I do not want anyone to get the 
false</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=030412214-05072001>impression that 
text sent to me should be put into the 
draft.</SPAN></FONT></DIV></SPAN></FONT></DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Cedric Westphal 
  [mailto:cedric@IPRG.nokia.com]<BR><B>Sent:</B> Thursday, July 05, 2001 3:23 
  AM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]<BR><B>Cc:</B> 'Kulwinder 
  Atwal'; 'seamoby'<BR><B>Subject:</B> [seamoby] Timing characteristics Re: 
  [seamoby] Issue #4: Clear, unambiguous definitions 
  missing<BR><BR></DIV></FONT>Gary, 
  <P>with respect to your last comment, please do submit an issue about the 
  timing characteristics <BR>of the ctp. <BR>The sticky point of the other 
  thread (neither pro nor reac thread) is exactly this, so you can count <BR>it 
  as support for change. Let me explain: proactive/reactive as defined in 
  Issue#4 (whether <BR>or not this will be integrated in the draft aside, many 
  people, myself included, liked these <BR>crisp and clear definitions) do imply 
  a time frame. Stuff happens _before_ or _after_ some event, <BR>so it situates 
  them on the time axis compared to the event. The draft as well, even though it 
  <BR>is more vaguely, situates the pro/reac ct on this axis. <BR>This is useful 
  in many/most situations, and IMO MUST be supported. Let's say that proactive 
  <BR>and reactive belong to a class of ct that we could definitely use, the 
  timing aware ct (TACT). <BR>Before anybody jumps on me, this is aware, not 
  constrained. <BR>The kiddies I mentioned earlier do not have a strict timing 
  constraint, more of a best effort <BR>constraint. Call it in-tact, as a 
  symmetric to tact, in being either a negation (after pro and <BR>re, latin 
  prefixes are edgy nowadays) or indifferent/neutral wrt timing (asynchronous 
  transfer <BR>mode was already taken :-).&nbsp; Would you allow me to provide 
  some text in this direction? <BR>If I may go further, the ct itself could be 
  neither tactful nor intact as a whole, each phase could <BR>have a different 
  characteristic. I'd elaborate on this but I'd like to see first how the 
  multiphase <BR>support requirement is going to end up wordsmithed. <BR>Cheers, 

  <P>Cedric. <BR>&nbsp; <BR>&nbsp; 
  <P>Gary Kenward wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp;<SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS">Kulwinder:</FONT></SPAN><SPAN 
    class=900023017-04072001></SPAN><SPAN class=900023017-04072001><FONT 
    face="Comic Sans MS">&nbsp; Sorry if I missed your point in the previous 
    posting, some comments below.</FONT></SPAN> 
    <BLOCKQUOTE dir=ltr 
    style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
      <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
      size=-1>-----Original Message-----</FONT></FONT> <BR><FONT 
      face=Tahoma><FONT size=-1><B>From:</B> Kulwinder Atwal [<A 
      href="mailto:kulwinder.atwal@zucotto.com">mailto:kulwinder.atwal@zucotto.com</A>]</FONT></FONT> 
      <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Wednesday, July 04, 2001 
      12:01 PM</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> 
      Kenward, Gary [WDLN2:AN10:EXCH]</FONT></FONT> <BR><FONT face=Tahoma><FONT 
      size=-1><B>Cc:</B> 'seamoby'</FONT></FONT> <BR><FONT face=Tahoma><FONT 
      size=-1><B>Subject:</B> RE: [seamoby] Issue #4: Clear, unambiguous 
      definitions missing</FONT></FONT> <BR>&nbsp;</DIV><SPAN 
      class=340313215-04072001></SPAN>
      <BLOCKQUOTE dir=ltr 
      style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
        <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
        size=-1>-----Original Message-----</FONT></FONT> <BR><FONT 
        face=Tahoma><FONT size=-1><B>From:</B> Gary Kenward [<A 
        href="mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</FONT></FONT> 
        <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Wednesday, July 04, 
        2001 11:28 AM</FONT></FONT> <BR><FONT face=Tahoma><FONT 
        size=-1><B>To:</B> 'Kulwinder Atwal'</FONT></FONT> <BR><FONT 
        face=Tahoma><FONT size=-1><B>Cc:</B> 'seamoby'</FONT></FONT> <BR><FONT 
        face=Tahoma><FONT size=-1><B>Subject:</B> RE: [seamoby] Issue #4: Clear, 
        unambiguous definitions missing</FONT></FONT> <BR>&nbsp;</DIV><SPAN 
        class=920001415-04072001><FONT face="Comic Sans MS">Well, no, CT does 
        not arrive after the first packet. Not if your aiming</FONT></SPAN><SPAN 
        class=920001415-04072001><FONT face="Comic Sans MS">for seamlessness and 
        you attempt to be proactive.</FONT></SPAN>&nbsp;<SPAN 
        class=920001415-04072001><FONT face="Comic Sans MS">This concept of a 
        "ParentAR" is new to me, as far as I know, it is 
        not&nbsp;</FONT></SPAN><SPAN class=920001415-04072001><FONT 
        face="Comic Sans MS">required for ct. Regardless, ct can start as soon 
        as the network determines</FONT><SPAN 
        class=340313215-04072001></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN 
        class=340313215-04072001></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><FONT 
        face="Comic Sans MS">[KA] My point is that it is the network that 
        determines when to start CT.&nbsp; It is a network's responsibility to 
        determine when to start CT.&nbsp; And, it is the network's 
        responsibility to ensure that Handover and CT complete near the same 
        time.&nbsp; It is NOT the CT protocol's responsibility to ensure this, 
        therefore instisting that CT must complete before Handover is not a 
        valid requirement.&nbsp; We could just as easily for a particular 
        network say that we want Handover to complete before CT, and put the 
        requirement into the Handover Protocol.&nbsp; The End-User would be just 
        as satisfied.&nbsp; The ordering is inconsequential.</FONT><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>I didn't see this 
        point in your previous posting.</FONT></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>We do 
        agree.</FONT></SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>My only caveat is 
        that I am concerned that if we do not tie ct completion 
        somehow</SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001> to 
        handover&nbsp;</FONT></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>completion, there 
        will be proposals ctp that have no time limit. We 
        all</SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001> believe ct 
        should finish quickly,&nbsp;</FONT></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>and the essential 
        forwarding context should be installed at the newAR before handover 
        completion in&nbsp;</FONT></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>order to achieve the 
        best possible handover performance. I think we all agree that we have to 
        be</FONT></SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>very careful about 
        the exceptions to this "ideal" situation. Do we 
        not?</FONT></SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><FONT face="Comic Sans MS">It seems that the 
        greatest difficulty we are experiencing is in capturing the exceptions 
        without losing the preferred "ideal".</FONT></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN 
        class=340313215-04072001></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><FONT 
        face="Comic Sans MS">[KA]&nbsp; It is network specific whether to start 
        CT first, or Handover first.&nbsp; It absolutely does not matter which 
        finishes first.&nbsp; Just as you can provide examples of when Handover 
        happens first,&nbsp;</SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001></SPAN>I 
        can<SPAN class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN>provide examples where the 
        reverse is true.</FONT><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>It does matter which 
        completes first. If handover "completes" first (e.g. packets are sitting 
        in a queue&nbsp;<SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN 
        class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN>at the newAR) 
        but the encryption context has not arrived, then the newAR cannot 
        forward those&nbsp;<SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN 
        class=900023017-04072001>&gt;&nbsp;</SPAN></SPAN></SPAN>packets. They 
        will incur an additional delay.&nbsp;</FONT></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>Does it matter if 
        the packets are delayed by 0.0001 seconds waiting for context? Clearly 
        not, but</FONT></SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>somehow we must 
        capture the fact that a 100 ms delay does 
        matter.</FONT></SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><FONT 
        face="Comic Sans MS">[KA]&nbsp; Rather than have people say, " Oh, but 
        we really need CT to happen before handover.&nbsp; So much so, that we 
        must have it as a MUST requirement",&nbsp; I would like these same 
        people to show what terrible thing would happen if the order were 
        reversed by a few milliseconds.</FONT><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>A few milliseconds, 
        no. A 100 ms yes. As an example, a 100 ms additional delay incurred 
        by&nbsp;</FONT></SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>G.729 voice frames 
        in a conversational voice session, and you might as well drop the 
        frames.&nbsp;</FONT></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>Dropping 4-5 
        sequential voice frames is *very* noticeable to a user, and is clearly 
        not "seamless".</FONT></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN 
        class=340313215-04072001></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><FONT 
        face="Comic Sans MS">[KA] We are all interested in having CT happen 
        quickly, so I really don't see the reason for this unnecessary 
        sequential linkage in a requirements document.</FONT><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>Well, I do not 
        either. I am trying to come up with some definition that preserves the 
        flexibility</FONT></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>of the current 
        definition, but answers some peoples concerns. I would, at this point, 
        like</FONT></SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>to toss "proactive" 
        and "reactive" and replace it with a description of 
        t</SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001>he 
        desirable&nbsp;</FONT></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN class=340313215-04072001><SPAN 
        class=900023017-04072001><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt;&nbsp;</SPAN></SPAN></SPAN>timing 
        characteristics of the ct process - something similar to the concepts 
        you and</FONT></SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt; I are talking about here. I would submit an 
        issue, if there was any hint of support 
        for</FONT></SPAN></SPAN></SPAN><SPAN class=920001415-04072001><SPAN 
        class=340313215-04072001><SPAN class=900023017-04072001><FONT 
        face="Comic Sans MS">&gt; this change.</FONT></SPAN></SPAN></SPAN><SPAN 
        class=920001415-04072001><SPAN 
        class=340313215-04072001></SPAN></SPAN><SPAN 
        class=900023017-04072001><FONT 
        face="Comic Sans MS">Cheers,</FONT></SPAN><SPAN 
        class=900023017-04072001><FONT 
      face="Comic Sans MS">Gary</FONT></SPAN></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C10562.E9E6B770--


From owner-seamoby@diameter.org  Fri Jul  6 13:14:04 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13064
	for <seamoby-archive@odin.ietf.org>; Fri, 6 Jul 2001 13:14:03 -0400 (EDT)
Received: (qmail 3966 invoked by alias); 6 Jul 2001 17:01:53 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 3960 invoked by uid 200); 6 Jul 2001 17:01:53 -0000
Received: (qmail 3955 invoked from network); 6 Jul 2001 17:01:52 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jul 2001 17:01:52 -0000
Received: from centralmail1.Central.Sun.COM ([129.147.62.10])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13754
	for <seamoby@cdma-2000.org>; Fri, 6 Jul 2001 10:13:41 -0700 (PDT)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA13497;
	Fri, 6 Jul 2001 11:13:41 -0600 (MDT)
Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id LAA07473; Fri, 6 Jul 2001 11:18:15 -0600
Message-Id: <5.0.0.25.0.20010706220851.01f18030@localhost>
X-Sender: 5883@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 06 Jul 2001 22:13:26 -0700
To: mobile-ip@sunroof.eng.sun.com, mobile-ip@sunroof.eng.sun.com,
        seamoby@cdma-2000.org
From: James Kempf <james.kempf@sun.com>
Subject: [seamoby] Re: [mobile-ip] L2 API (WAS: Ext. for FMIPv6 - comments)
In-Reply-To: <01D91AFB08B6D211BFD00008C7EABAE10680B265@eseis04nok>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-seamoby@diameter.org
Precedence: bulk

John,

(Folks, sorry for the cross posting, please try to respond on
one or the other list unless the topic affects both...)

There is a draft in preparation with people from both Seamoby
and MIP on the author list. These are people with whom
I have talked and who have expressed interest in working on such a
draft over the last year. The draft has a section on L2 triggers
that came out of the MIP fast handoff work, then a section
that describes connections with Seamoby context transfer.
I expect we will have it complete by next Fri.'s 00 deadline.

We have already talked to the MIP WG chairs about getting
time on the agenda to discuss the draft, what I'd like
to suggest is that we do the same for Seamoby. That
will give both WGs the opportunity to review and comment
on the draft. I will talk with Pat about that when he gets
back from vacation.

                 jak

At 10:13 AM 7/4/01 +0300, john.loughney@nokia.com wrote:
>Hi James,
>
> > In fact, I am preparing just such a draft as we speak. The
> > intent is to take the material from the BETH draft and from
> > the FMIPv4 draft and perhaps add something on the link with
> > Seamoby context transfer.
>
>I think this would be extremely worthwhile.  It seems that
>SeaMoby is currently struggling over terminology about
>triggers, etc. with respect to handovers.  I'd even suggest
>that interested parties from both MIP & SeaMoby get together
>in London to discuss how to move forward.  Perhaps it would
>be a good thing if MIP & SeaMoby could work together on this
>issue - in order to assure that the resultant work suits both
>groups.
>
>best regards,
>John



From owner-seamoby@diameter.org  Fri Jul  6 13:25:16 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13342
	for <seamoby-archive@odin.ietf.org>; Fri, 6 Jul 2001 13:25:15 -0400 (EDT)
Received: (qmail 4445 invoked by alias); 6 Jul 2001 17:13:06 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 4439 invoked by uid 200); 6 Jul 2001 17:13:06 -0000
Received: (qmail 4434 invoked from network); 6 Jul 2001 17:13:05 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 6 Jul 2001 17:13:05 -0000
Received: from centralmail1.Central.Sun.COM ([129.147.62.10])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA15431;
	Fri, 6 Jul 2001 10:24:50 -0700 (PDT)
Received: from esun1as-mm. (esun1as-mm.Central.Sun.COM [129.147.34.144])
	by centralmail1.Central.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA15094;
	Fri, 6 Jul 2001 11:24:49 -0600 (MDT)
Received: from sunyata.sun.com by esun1as-mm. (SMI-8.6/SMI-SVR4)
	id LAA07622; Fri, 6 Jul 2001 11:29:22 -0600
Message-Id: <5.0.0.25.0.20010706222323.01f18340@localhost>
X-Sender: 5883@localhost
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Fri, 06 Jul 2001 22:24:30 -0700
To: "Gary Kenward" <gkenward@nortelnetworks.com>, seamoby@cdma-2000.org
From: James Kempf <james.kempf@sun.com>
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5DC3@zcard031.ca.nortel.
 com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-seamoby@diameter.org
Precedence: bulk

Gary,

I agree that detailed analysis of triggers should be in the protocol doc, not
requirements. The requirements might say something to the effect
that the protocol should use triggers if available.

                 jak

At 09:35 AM 7/4/01 -0400, Gary Kenward wrote:

>   Just a note to cover what I believe is a possible misinterpretation
>that can be made from John's and Madjid's recent emails.
>
>   The issue with triggers has nothing to do with "terminology" (yet).
>The issue with triggers has to do with the fact that there are a
>plethora of possible triggers that can be used. If we identify one
>trigger in the requirements, then we need to identify either all, or a
>comprehensive set of examples. This is not "specmanship" - given
>that these triggers control ct, this is one of the most important
>issues to be resolved.
>
>   I'm still not convinced that it is worthwhile trying to solve it
>in a requirements document.
>
>Gary
>
> > -----Original Message-----
> > From: john.loughney@nokia.com 
> [<mailto:john.loughney@nokia.com>mailto:john.loughney@nokia.com]
> > Sent: Wednesday, July 04, 2001 3:14 AM
> > To: mobile-ip@sunroof.eng.sun.com; seamoby@cdma-2000.org
> > Subject: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> >
> >
> > Hi James,
> >
> > > In fact, I am preparing just such a draft as we speak. The
> > > intent is to take the material from the BETH draft and from
> > > the FMIPv4 draft and perhaps add something on the link with
> > > Seamoby context transfer.
> >
> > I think this would be extremely worthwhile.  It seems that
> > SeaMoby is currently struggling over terminology about
> > triggers, etc. with respect to handovers.  I'd even suggest
> > that interested parties from both MIP & SeaMoby get together
> > in London to discuss how to move forward.  Perhaps it would
> > be a good thing if MIP & SeaMoby could work together on this
> > issue - in order to assure that the resultant work suits both
> > groups.
> >
> > best regards,
> > John
> >



From owner-seamoby@diameter.org  Fri Jul  6 22:25:33 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26795
	for <seamoby-archive@odin.ietf.org>; Fri, 6 Jul 2001 22:25:32 -0400 (EDT)
Received: (qmail 6198 invoked by alias); 7 Jul 2001 02:13:46 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6192 invoked by uid 200); 7 Jul 2001 02:13:45 -0000
Received: (qmail 6187 invoked from network); 7 Jul 2001 02:13:44 -0000
Received: from unknown (HELO localhost.localdomain) (root@211.237.39.111)
  by c900656-a.plstn1.sfba.home.com with SMTP; 7 Jul 2001 02:13:44 -0000
Received: from Jascha ([211.237.39.99])
	by localhost.localdomain (8.9.3/8.9.3) with SMTP id LAA16960
	for <seamoby@cdma-2000.org>; Sat, 7 Jul 2001 11:21:33 +0900
Message-ID: <003101c1068c$4e084f00$6327edd3@Jascha>
From: "ShinHyun" <yangsh@imnetpia.com>
To: <seamoby@cdma-2000.org>
Subject: [seamoby] 
Date: Sat, 7 Jul 2001 11:27:01 +0900
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ks_c_5601-1987"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by ietf.org id WAA26795

subscribe seamoby yangsh@imnetpia.com


From owner-seamoby@diameter.org  Sat Jul  7 23:30:58 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA26995
	for <seamoby-archive@odin.ietf.org>; Sat, 7 Jul 2001 23:30:57 -0400 (EDT)
Received: (qmail 8053 invoked by alias); 8 Jul 2001 03:18:51 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 8047 invoked by uid 200); 8 Jul 2001 03:18:51 -0000
Message-ID: <20010708031851.8046.qmail@charizard.diameter.org>
Received: (qmail 8042 invoked from network); 8 Jul 2001 03:18:49 -0000
Received: from cd-179-62.ra30.dc.capu.net (HELO yourwebsite.com) (64.50.179.62)
  by c900656-a.plstn1.sfba.home.com with SMTP; 8 Jul 2001 03:18:49 -0000
Reply-To: lprice@capu.net
From: lprice@capu.net
To: seamoby@cdma-2000.org
Subject: [seamoby] Ride the Wave of Success!!/FREE MEMBERSHIP!!! 
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Sat, 7 Jul 2001 23:26:31 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk


JOIN NOW FOR FREE!!!
          
SERIOUS ONLINE INCOME:

 NO PRODUCTS TO SELL, NO MEETING TO ATTEND, NO MONTHLY QUOTAS

We are a  FOUR 4 YEAR OLD INTERNET BUSINESS AND GROWING VERY FAST. WE HAD OVER  
60,000 VIPS SIGNUP COMPANY WIDE IN THE MONTH OF JUNE 2001. SEE WHY THOUSANDS OF 
PEOPLE FROM ALL OVER THE WORLD ARE JOINING US AT RECORD RATES.;
 
    THE  MEMBERSHIP IS FREE at. 
                             
http://onlineprofits.50megs.com.    . Enter your first and last name and email address.

Afterwards you will start recieving various emails about company and the business opportunity.  Also, you will  
become a  FREE MEMBER  and you can START SHOPPING  from at least 70 brand name online stores and 
BE ENTERED in our monthly $100 shopping spree!.  Take your time and review our company's benefits and 
opportunities.
       . GUARANTEED  minimum commission every month
       . you can get 200 members a month added to you downline
       . Free Software
       . and a strong team support

Now remember anybody that signs up after you will be in your downline. This is very important if you want join 
our company  and get a monthly check. Don't pass this one up. 
GET YOUR FREE MEMBERSHIP AT:  
http://onlineprofits.50megs.com --- type in your name and email address and hit the submit botton.
We will talk soon,
        
GIVIE IT A TRY, YOU HAVE NOTHING TO LOSE AND POSSIBLE A LOT TO GAIN.  


From owner-seamoby@diameter.org  Mon Jul  9 02:49:51 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA04910
	for <seamoby-archive@odin.ietf.org>; Mon, 9 Jul 2001 02:49:50 -0400 (EDT)
Received: (qmail 15067 invoked by alias); 9 Jul 2001 06:37:30 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15061 invoked by uid 200); 9 Jul 2001 06:37:29 -0000
Received: (qmail 15056 invoked from network); 9 Jul 2001 06:37:27 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jul 2001 06:37:27 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f696nkI13097
	for <seamoby@cdma-2000.org>; Mon, 9 Jul 2001 09:49:46 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54a37d45a0ac158f2313e2@esvir03nok.nokia.com>;
 Mon, 9 Jul 2001 09:49:08 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS46LKX>; Mon, 9 Jul 2001 09:49:08 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094009@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: james.kempf@sun.com, mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
Subject: [seamoby] Re: L2 API (WAS: Ext. for FMIPv6 - comments)
Date: Mon, 9 Jul 2001 09:48:56 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi James,

> There is a draft in preparation with people from both Seamoby
> and MIP on the author list. These are people with whom
> I have talked and who have expressed interest in working on such a
> draft over the last year. The draft has a section on L2 triggers
> that came out of the MIP fast handoff work, then a section
> that describes connections with Seamoby context transfer.
> I expect we will have it complete by next Fri.'s 00 deadline.
> 
> We have already talked to the MIP WG chairs about getting
> time on the agenda to discuss the draft, what I'd like
> to suggest is that we do the same for Seamoby. That
> will give both WGs the opportunity to review and comment
> on the draft. I will talk with Pat about that when he gets
> back from vacation.

I think that is a good idea & I'm glad to see that authors
from both MIP & SeaMoby are on it.  That's enough for me.
I look forward to the draft.

br,
John


From owner-seamoby@diameter.org  Mon Jul  9 02:56:14 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05305
	for <seamoby-archive@odin.ietf.org>; Mon, 9 Jul 2001 02:56:13 -0400 (EDT)
Received: (qmail 15545 invoked by alias); 9 Jul 2001 06:43:54 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15539 invoked by uid 200); 9 Jul 2001 06:43:54 -0000
Received: (qmail 15534 invoked from network); 9 Jul 2001 06:43:52 -0000
Received: from mgw-x2.nokia.com (131.228.20.22)
  by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jul 2001 06:43:52 -0000
Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f696u3324582
	for <seamoby@cdma-2000.org>; Mon, 9 Jul 2001 09:56:03 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54a383415fac158f22077@esvir02nok.nokia.com>;
 Mon, 9 Jul 2001 09:55:41 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS46LTY>; Mon, 9 Jul 2001 09:55:41 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09400A@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: james.kempf@sun.com, gkenward@nortelnetworks.com, seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Date: Mon, 9 Jul 2001 09:55:36 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi James & Gary,

> I agree that detailed analysis of triggers should be in the 
> protocol doc, not requirements. The requirements might say 
> something to the effect that the protocol should use triggers 
> if available.

Agreed.

> At 09:35 AM 7/4/01 -0400, Gary Kenward wrote:
> 
> >   Just a note to cover what I believe is a possible 
> > misinterpretation that can be made from John's and Madjid's 
> > recent emails.
> >
> >   The issue with triggers has nothing to do with 
> > "terminology" (yet). The issue with triggers has to do with the 
> > fact that there are a plethora of possible triggers that can be
> > used. If we identify one trigger in the requirements, then we need to 
> > identify either all, or a comprehensive set of examples. This is not 
> > "specmanship" - given that these triggers control ct, this is one of 
> > the most important issues to be resolved.
> >
> >   I'm still not convinced that it is worthwhile trying to solve it
> > in a requirements document.

I think the use of triggers (which events, etc) and what to call them
should be left to an other document.  In reductive mode, this is 
what I see:

	1) Something starts a process in an AR to transfer some
	blob to another AR.  

That is what context transfer means to me!

I think (if someone wants to produce it), a document which outlines the
different 'something' which starts the CT off, would be a good document.
If such a document would be fairly complete, we could then examine what
we would need when it came to design a protocol.

Could I suggest that we try a new way of working within SeaMoby?  We
keep the documents thin.  I think if we had several documents, each
outlining an issue, we would then have a robust set of issues & 
documents to go forward with.  

best regards,
John


From owner-seamoby@diameter.org  Mon Jul  9 07:07:49 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09271
	for <seamoby-archive@odin.ietf.org>; Mon, 9 Jul 2001 07:07:48 -0400 (EDT)
Received: (qmail 16389 invoked by alias); 9 Jul 2001 10:55:12 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16383 invoked by uid 200); 9 Jul 2001 10:55:12 -0000
Received: (qmail 16378 invoked from network); 9 Jul 2001 10:55:10 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jul 2001 10:55:10 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08955;
	Mon, 9 Jul 2001 07:06:21 -0400 (EDT)
Message-Id: <200107091106.HAA08955@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: seamoby@cdma-2000.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [seamoby] I-D ACTION:draft-ietf-seamoby-context-transfer-problem-stat-02.txt
Date: Mon, 09 Jul 2001 07:06:20 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Context Transfer, Handoff Candidate Discovery and Dormant Mode Host Alerting Working Group of the IETF.

	Title		: Problem Description: Reasons For Performing Context 
                          Transfers Between Nodes in an IP Access Network
	Author(s)	: O. Levkowetz, P. Calhoun et al.
	Filename	: draft-ietf-seamoby-context-
                          transfer-problem-stat-02.txt
	Pages		: 14
	Date		: 06-Jul-01
	
There are a large number of IP access networks that support mobility 
of hosts. For example, wireless Personal Area Networks (PANs), 
wireless LANs, satellite WANs and cellular WANs. The nature of this 
mobility is such that the communication path to the host changes 
frequently and rapidly.  
This Internet-Draft describes the problem encountered during 
mobility that requires the exchange of IP context between different 
forwarding nodes in an access network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-seamoby-context-transfer-problem-stat-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-seamoby-context-transfer-problem-stat-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-seamoby-context-transfer-problem-stat-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010706135010.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-seamoby-context-transfer-problem-stat-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-seamoby-context-transfer-problem-stat-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010706135010.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-seamoby@diameter.org  Mon Jul  9 11:21:55 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17992
	for <seamoby-archive@odin.ietf.org>; Mon, 9 Jul 2001 11:21:50 -0400 (EDT)
Received: (qmail 1114 invoked by alias); 9 Jul 2001 15:08:59 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 1108 invoked by uid 200); 9 Jul 2001 15:08:58 -0000
Received: (qmail 1103 invoked from network); 9 Jul 2001 15:08:55 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jul 2001 15:08:55 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f69Ekrb10830
	for <seamoby@cdma-2000.org>; Mon, 9 Jul 2001 10:46:54 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 9 Jul 2001 10:46:53 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2YBMZ>; Mon, 9 Jul 2001 10:46:56 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DF2@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>, james.kempf@sun.com,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Date: Mon, 9 Jul 2001 10:46:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10885.FA170610"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10885.FA170610
Content-Type: text/plain;
	charset="iso-8859-1"

John:

  I agree, particularly with your definition of ct (although I'm
not sure where "reductive mode" came from). 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.

  The completion of ct, regardless of the mode, is as soon as
possible for the context to be used in forwarding the MNs packets.
Completion can be define relative to a particular even such as
the first packet arrival, but it cannot be synchronized to any
event because of the reality of the physics of wireless handover.

  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.

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Monday, July 09, 2001 2:56 AM
> To: james.kempf@sun.com; Kenward, Gary [WDLN2:AN10:EXCH];
> seamoby@cdma-2000.org
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> 
> 
> Hi James & Gary,
> 
> > I agree that detailed analysis of triggers should be in the 
> > protocol doc, not requirements. The requirements might say 
> > something to the effect that the protocol should use triggers 
> > if available.
> 
> Agreed.
> 
> > At 09:35 AM 7/4/01 -0400, Gary Kenward wrote:
> > 
> > >   Just a note to cover what I believe is a possible 
> > > misinterpretation that can be made from John's and Madjid's 
> > > recent emails.
> > >
> > >   The issue with triggers has nothing to do with 
> > > "terminology" (yet). The issue with triggers has to do with the 
> > > fact that there are a plethora of possible triggers that can be
> > > used. If we identify one trigger in the requirements, 
> then we need to 
> > > identify either all, or a comprehensive set of examples. 
> This is not 
> > > "specmanship" - given that these triggers control ct, 
> this is one of 
> > > the most important issues to be resolved.
> > >
> > >   I'm still not convinced that it is worthwhile trying to solve it
> > > in a requirements document.
> 
> I think the use of triggers (which events, etc) and what to call them
> should be left to an other document.  In reductive mode, this is 
> what I see:
> 
> 	1) Something starts a process in an AR to transfer some
> 	blob to another AR.  
> 
> That is what context transfer means to me!
> 
> I think (if someone wants to produce it), a document which 
> outlines the
> different 'something' which starts the CT off, would be a 
> good document.
> If such a document would be fairly complete, we could then 
> examine what
> we would need when it came to design a protocol.
> 
> Could I suggest that we try a new way of working within SeaMoby?  We
> keep the documents thin.  I think if we had several documents, each
> outlining an issue, we would then have a robust set of issues & 
> documents to go forward with.  
> 
> best regards,
> John
> 

------_=_NextPart_001_01C10885.FA170610
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>John:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I agree, particularly with your definition of ct (although I'm</FONT>
<BR><FONT SIZE=2>not sure where &quot;reductive mode&quot; came from). In thinking through</FONT>
<BR><FONT SIZE=2>the overall discussion, I am realize that the big difference </FONT>
<BR><FONT SIZE=2>between &quot;reactive&quot; and &quot;proactive&quot; is how they are triggered. </FONT>
<BR><FONT SIZE=2>&quot;proactive&quot; assumes that there is a trigger available early</FONT>
<BR><FONT SIZE=2>on that permits some context transfer in advance of an actual</FONT>
<BR><FONT SIZE=2>handover.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; The completion of ct, regardless of the mode, is as soon as</FONT>
<BR><FONT SIZE=2>possible for the context to be used in forwarding the MNs packets.</FONT>
<BR><FONT SIZE=2>Completion can be define relative to a particular even such as</FONT>
<BR><FONT SIZE=2>the first packet arrival, but it cannot be synchronized to any</FONT>
<BR><FONT SIZE=2>event because of the reality of the physics of wireless handover.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I do believe the current wording for proactive is wrong. Now that</FONT>
<BR><FONT SIZE=2>I have had time to contemplate the wording, it does not define what </FONT>
<BR><FONT SIZE=2>I have always believed proactive ct should be about. I'm hoping</FONT>
<BR><FONT SIZE=2>that if we fix that wording, we can move on to the important part</FONT>
<BR><FONT SIZE=2>of designing ctp.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: john.loughney@nokia.com [<A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Monday, July 09, 2001 2:56 AM</FONT>
<BR><FONT SIZE=2>&gt; To: james.kempf@sun.com; Kenward, Gary [WDLN2:AN10:EXCH];</FONT>
<BR><FONT SIZE=2>&gt; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi James &amp; Gary,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I agree that detailed analysis of triggers should be in the </FONT>
<BR><FONT SIZE=2>&gt; &gt; protocol doc, not requirements. The requirements might say </FONT>
<BR><FONT SIZE=2>&gt; &gt; something to the effect that the protocol should use triggers </FONT>
<BR><FONT SIZE=2>&gt; &gt; if available.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Agreed.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; At 09:35 AM 7/4/01 -0400, Gary Kenward wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp; Just a note to cover what I believe is a possible </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; misinterpretation that can be made from John's and Madjid's </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; recent emails.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp; The issue with triggers has nothing to do with </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &quot;terminology&quot; (yet). The issue with triggers has to do with the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; fact that there are a plethora of possible triggers that can be</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; used. If we identify one trigger in the requirements, </FONT>
<BR><FONT SIZE=2>&gt; then we need to </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; identify either all, or a comprehensive set of examples. </FONT>
<BR><FONT SIZE=2>&gt; This is not </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &quot;specmanship&quot; - given that these triggers control ct, </FONT>
<BR><FONT SIZE=2>&gt; this is one of </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; the most important issues to be resolved.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp; I'm still not convinced that it is worthwhile trying to solve it</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; in a requirements document.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think the use of triggers (which events, etc) and what to call them</FONT>
<BR><FONT SIZE=2>&gt; should be left to an other document.&nbsp; In reductive mode, this is </FONT>
<BR><FONT SIZE=2>&gt; what I see:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1) Something starts a process in an AR to transfer some</FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; blob to another AR.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; That is what context transfer means to me!</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think (if someone wants to produce it), a document which </FONT>
<BR><FONT SIZE=2>&gt; outlines the</FONT>
<BR><FONT SIZE=2>&gt; different 'something' which starts the CT off, would be a </FONT>
<BR><FONT SIZE=2>&gt; good document.</FONT>
<BR><FONT SIZE=2>&gt; If such a document would be fairly complete, we could then </FONT>
<BR><FONT SIZE=2>&gt; examine what</FONT>
<BR><FONT SIZE=2>&gt; we would need when it came to design a protocol.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Could I suggest that we try a new way of working within SeaMoby?&nbsp; We</FONT>
<BR><FONT SIZE=2>&gt; keep the documents thin.&nbsp; I think if we had several documents, each</FONT>
<BR><FONT SIZE=2>&gt; outlining an issue, we would then have a robust set of issues &amp; </FONT>
<BR><FONT SIZE=2>&gt; documents to go forward with.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; best regards,</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10885.FA170610--


From owner-seamoby@diameter.org  Mon Jul  9 12:53:43 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21560
	for <seamoby-archive@odin.ietf.org>; Mon, 9 Jul 2001 12:53:42 -0400 (EDT)
Received: (qmail 2561 invoked by alias); 9 Jul 2001 16:42:43 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2554 invoked by uid 200); 9 Jul 2001 16:42:42 -0000
Received: (qmail 2549 invoked from network); 9 Jul 2001 16:42:40 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jul 2001 16:42:40 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA29987
	for <seamoby@diameter.org>; Mon, 9 Jul 2001 09:53:01 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA17477
	for <seamoby@diameter.org>; Mon, 9 Jul 2001 09:53:00 -0700 (PDT)
Message-Id: <200107091653.JAA17477@heliopolis.eng.sun.com>
Date: Mon, 9 Jul 2001 09:53:00 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [seamoby] 3GPP IP Paging Hack
To: seamoby@diameter.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: WRzmjsZgH9v3CIvLLFs7Pw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

I'm told that, in the absence of a well defined IP paging
protocol, 3GPP has decided to adopt a hack involving SMS and WAP
to do push services notification from the core network. I don't
have many details, but I think the idea is that where there is no
active PDP context, the core issues an SMS message including some
WAP content that causes the MN to wake up and smell the coffee.

Is there anyone out there who regularly attends 3GPP meetings that
has more information on this? Unfortunatly, I am unable to attend
any 3GPP meetings because Sun has a very strict travel ban in
place, but if anybody on the Seamoby list goes, perhaps we can
come up with a contribution that compares the Seamoby paging
requirements for 3GPP's? We also have at least one candidate
protocol.

BTW, for those of you who doubted the wisdom of making the protocol
independent of mobile IP, this is an example of why. 3GPP doesn't
use MIP except for inter-domain handover. If the paging protocol
is independent of MIP, it will work for them too.

		jak




From owner-seamoby@diameter.org  Mon Jul  9 13:53:21 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23773
	for <seamoby-archive@odin.ietf.org>; Mon, 9 Jul 2001 13:53:19 -0400 (EDT)
Received: (qmail 3133 invoked by alias); 9 Jul 2001 17:30:51 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 3127 invoked by uid 200); 9 Jul 2001 17:30:50 -0000
Received: (qmail 3122 invoked from network); 9 Jul 2001 17:30:48 -0000
Received: from motgate3.mot.com (144.189.100.103)
  by c900656-a.plstn1.sfba.home.com with SMTP; 9 Jul 2001 17:30:48 -0000
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate3.mot.com (motgate3 2.1) with ESMTP id KAA12180 for <seamoby@diameter.org>; Mon, 9 Jul 2001 10:34:24 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA02718 for <seamoby@diameter.org>; Mon, 9 Jul 2001 10:41:27 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <N53YYV9P>; Mon, 9 Jul 2001 12:41:27 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E6B@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Cedric Westphal'" <cedric@IPRG.nokia.com>,
        Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] RE: Need for support of neither pro nor reactive ct
	. was: Re: [se amoby] Issue #4: Clear, unambiguous definitions missing
Date: Mon, 9 Jul 2001 12:41:18 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1089E.5C23CE70"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1089E.5C23CE70
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Why isn't the meeting in London gonna happen?=20
I hope the mention of Utah is just the marriage "joke", I don't want to =
see the requirement
work  drag on to Utah, unless we are ready to pack to another =
projects!!!

-----Original Message-----
From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
Sent: Wednesday, July 04, 2001 10:21 AM
To: Gary Kenward
Cc: 'seamoby'
Subject: Re: [seamoby] RE: Need for support of neither pro nor reactive =
ct. was: Re: [se amoby] Issue #4: Clear, unambiguous definitions =
missing


Gary,=20

here again you tell me I want to scrap the proactive/reactive terms. =
How=20
many times do I have to tell you I like the definitions, I love =
proactive CT,=20
I love reactive CT, I want to marry them in Utah and have a nice menage =

a trois (plus c'est LA meme chose, by the way).=20
What's missing it the little kiddie of proactive and reactive, but you =
are=20
right, there is no point continuing this discussion this way. Meeting =
in London=20
ain't gonna happen, but I'll take up your offer and try to work it in=20
the wording.=20
Cheers,=20


Cedric.=20


Gary Kenward wrote:=20


 Cedric:  All of us our busy. It is regrettable that you wasted your =
timeexplaining something which did not need explaining. You are =
missingmy point, which is, to be blunt, that proactive/reactive does =
coverthe case you are so concerned about, at least as far as I am =
concerned.If you bother to check through the archives you will see that =
I havestated this many times, in many ways.  'nuff said. I now agree =
with Pat. This will take at least a meeting atIETF 51 to work out; at =
least. I may or may not be there. My onlycaution is that exchanging one =
set of terms for another will likelynot resolve the real issue, just =
bury it until someone comes up withmore detail to argue. I have no =
great love for the terms "proactive"and "reactive", but I am fully =
convinced that choosing new terminologywill set us back to January of =
this year, when Seamoby had the discussionof "soft" versus "hard", =
"make-before-break" versus "break-before-make".  As I tried to indicate =
in my previous posting, if you believe your case needsemphasis, then =
let's work it into the wording of the current draft. Until someclearly =
superior terminology arises, let's work with what we have. GaryPlus ca =
change, plus c'est le m=EAme chose.=20

-----Original Message-----=20
From: Cedric Westphal [ mailto:cedric@iprg.nokia.com =
<mailto:cedric@iprg.nokia.com> ]=20
Sent: Wednesday, July 04, 2001 3:24 AM=20
To: Kenward, Gary [WDLN2:AN10:EXCH]=20
Cc: 'seamoby'=20
Subject: Need for support of neither pro nor reactive ct. was: Re: =
[seamoby] Issue #4: Clear, unambiguous definitions missing=20
=20
Gary:=20

I read your reply, and I have the feeling that you are trying to =
convince me that=20
proactive and reactive cts are indeed required. I think you are missing =
my point.=20
First, for the record: I an convinced both proactive and reactive ct =
are required,=20
and the definition proposed in this issue #4 are satisfying in this =
respect. They=20
are necessary. Agreed. They are not sufficient.=20
I am not going to comment point by point, I don't have time for this, =
but sum up:=20
-in a previous mail, you said Rajeev's definitions (that you attributed =
to Pat) were=20
good for you.=20
-they are good definition for proactive and reactive. They do not =
consider a mixed situation,=20
initiated prior to arrival and completed after.=20
-the draft mentions the support of only proactive or reactive. The =
draft as well prohibits=20
a mixed situation. A proactive ct that completes after whatever event =
is a failed proactive ct.=20
It is a proactive that turns into a reactive (or should a fresh =
reactive ct be initiated if the proactive=20
ct does not completes before the event, not so clear in the draft). =
There was not much=20
point to comment before hand, since, as you say, the draft is =
ambiguous, and could be read any way.=20
But since the clarification issue has been raised, we should address =
its consequences.=20


Please consider the situation where MN at some point in the future  =
will go from oldAR to=20
some identified newAR. I have this context that I want to transfer. =
However, it is of no critical value=20
to the MN at newAR. I have the choice of: (a) proactive: I start =
transfering now, and pray it=20
is established at newAR before (draft quote: 'it is required to forward =
the first packet arrival=20
in the MN's traffic', new definition quote: 'the arrival of MN's packet =
at target AR). (b) reactive:=20
I wait (new definition quote: 'subsequent to the arrival of MN's packet =
at target AR) until=20
(draft mentions: 'initiation of a handover or soon after initiation').=20
Please explain to me why, since I have no critical deadline, I should =
still make a choice between=20
(a) or (b), that is, to simplify (a) ensure that all my context is =
transfered before handoff, or=20
(b) wait until I handoff to transfer. Where is (c): I take a leisurely =
transfer around the handoff,=20
I start before, but take it easy, dude, whenever I get there is when I =
get there.=20
You might see this as a terminology issue, (what do you call (c) since =
it is not proactive nor reactive).=20
I think it is more a requirement issue. If the requirement draft =
specifies (a) and (b), does not=20
mention any other possibility, explains that if (a) fails, then use (b) =
as the only choice of combined/=20
mixed/soft ct, then it seems to imply that it excludes (c).=20
I agree with (a) MUST be supported, (b) MUST be supported, tell me why =
(c) SHOULD NOT=20
be supported as a requirement?=20
Thanks,=20


Cedric.=20
 =20


=20


------_=_NextPart_001_01C1089E.5C23CE70
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">


<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=408153917-09072001>Why 
isn't the meeting in London gonna happen? </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=408153917-09072001>I hope 
the mention of Utah is just the marriage "joke", I don't want to see the 
requirement</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=408153917-09072001>work&nbsp;&nbsp;drag on to Utah, unless we are ready to 
pack to another projects!!!</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Cedric Westphal 
  [mailto:cedric@IPRG.nokia.com]<BR><B>Sent:</B> Wednesday, July 04, 2001 10:21 
  AM<BR><B>To:</B> Gary Kenward<BR><B>Cc:</B> 'seamoby'<BR><B>Subject:</B> Re: 
  [seamoby] RE: Need for support of neither pro nor reactive ct. was: Re: [se 
  amoby] Issue #4: Clear, unambiguous definitions 
  missing<BR><BR></DIV></FONT>Gary, 
  <P>here again you tell me I want to scrap the proactive/reactive terms. How 
  <BR>many times do I have to tell you I like the definitions, I love proactive 
  CT, <BR>I love reactive CT, I want to marry them in Utah and have a nice 
  menage <BR>a trois (plus c'est LA meme chose, by the way). <BR>What's missing 
  it the little kiddie of proactive and reactive, but you are <BR>right, there 
  is no point continuing this discussion this way. Meeting in London <BR>ain't 
  gonna happen, but I'll take up your offer and try to work it in <BR>the 
  wording. <BR>Cheers, 
  <P>Cedric. 
  <P>Gary Kenward wrote: 
  <BLOCKQUOTE TYPE="CITE">&nbsp;<SPAN class=850370713-04072001><FONT 
    face="Comic Sans MS">Cedric:</FONT></SPAN><SPAN 
    class=850370713-04072001></SPAN><SPAN class=850370713-04072001><FONT 
    face="Comic Sans MS">&nbsp; All of us our busy. It is regrettable that you 
    wasted your time</FONT></SPAN><SPAN class=850370713-04072001><FONT 
    face="Comic Sans MS">explaining something which did not need explaining. You 
    are missing</FONT></SPAN><SPAN class=850370713-04072001><FONT 
    face="Comic Sans MS">my point, which is, to be blunt, that 
    proactive/reactive does cover</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">the case you are so 
    concerned about, at least as far as I am concerned.</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">If you bother to check 
    through the archives you will see that I have</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">stated this many times, 
    in many ways.</FONT></SPAN><SPAN class=850370713-04072001></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">&nbsp; 'nuff said. I now 
    agree with Pat. This will take at least a meeting at</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">IETF 51 to work out; at 
    least. I may or may not be there. My only</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">caution is that 
    exchanging one set of terms for another will likely</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">not resolve the real 
    issue, just bury it until someone comes up with</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">more detail to argue. I 
    have no great love for the terms "proactive"</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">and "reactive", but I am 
    fully convinced that choosing new terminology</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">will set us back to 
    January of this year, when Seamoby had the discussion</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">of "soft" versus "hard", 
    "make-before-break" versus "break-before-make".</FONT></SPAN><SPAN 
    class=850370713-04072001></SPAN><SPAN class=850370713-04072001><FONT 
    face="Comic Sans MS">&nbsp; As I tried to indicate in my previous posting, 
    if you believe your case needs</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">emphasis, then let's 
    work it into the wording of the current draft. Until some</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">clearly superior 
    terminology arises, let's work with what we have.</FONT></SPAN>&nbsp;<SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">Gary</FONT></SPAN><SPAN 
    class=850370713-04072001><FONT face="Comic Sans MS">Plus ca change, plus 
    c'est le même chose.</FONT></SPAN> 
    <BLOCKQUOTE 
    style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
      <DIV class=OutlookMessageHeader dir=ltr><FONT face=Tahoma><FONT 
      size=-1>-----Original Message-----</FONT></FONT> <BR><FONT 
      face=Tahoma><FONT size=-1><B>From:</B> Cedric Westphal [<A 
      href="mailto:cedric@iprg.nokia.com">mailto:cedric@iprg.nokia.com</A>]</FONT></FONT> 
      <BR><FONT face=Tahoma><FONT size=-1><B>Sent:</B> Wednesday, July 04, 2001 
      3:24 AM</FONT></FONT> <BR><FONT face=Tahoma><FONT size=-1><B>To:</B> 
      Kenward, Gary [WDLN2:AN10:EXCH]</FONT></FONT> <BR><FONT face=Tahoma><FONT 
      size=-1><B>Cc:</B> 'seamoby'</FONT></FONT> <BR><FONT face=Tahoma><FONT 
      size=-1><B>Subject:</B> Need for support of neither pro nor reactive ct. 
      was: Re: [seamoby] Issue #4: Clear, unambiguous definitions 
      missing</FONT></FONT> <BR>&nbsp;</DIV>Gary: 
      <P>I read your reply, and I have the feeling that you are trying to 
      convince me that <BR>proactive and reactive cts are indeed required. I 
      think you are missing my point. <BR>First, for the record: I an convinced 
      both proactive and reactive ct are required, <BR>and the definition 
      proposed in this issue #4 are satisfying in this respect. They <BR>are 
      necessary. Agreed. They are not sufficient. <BR>I am not going to comment 
      point by point, I don't have time for this, but sum up: <BR>-in a previous 
      mail, you said Rajeev's definitions (that you attributed to Pat) were 
      <BR>good for you. <BR>-they are good definition for proactive and 
      reactive. They do not consider a mixed situation, <BR>initiated prior to 
      arrival and completed after. <BR>-the draft mentions the support of only 
      proactive or reactive. The draft as well prohibits <BR>a mixed situation. 
      A proactive ct that completes after whatever event is a failed proactive 
      ct. <BR>It is a proactive that turns into a reactive (or should a fresh 
      reactive ct be initiated if the proactive <BR>ct does not completes before 
      the event, not so clear in the draft). There was not much <BR>point to 
      comment before hand, since, as you say, the draft is ambiguous, and could 
      be read any way. <BR>But since the clarification issue has been raised, we 
      should address its consequences. 
      <P>Please consider the situation where MN at some point in the 
      future&nbsp; will go from oldAR to <BR>some identified newAR. I have this 
      context that I want to transfer. However, it is of no critical value 
      <BR>to the MN at newAR. I have the choice of: (a) proactive: I start 
      transfering now, and pray it <BR>is established at newAR before (draft 
      quote: 'it is required to forward the first packet arrival <BR>in the MN's 
      traffic', new definition quote: 'the arrival of MN's packet at target AR). 
      (b) reactive: <BR>I wait (new definition quote: 'subsequent to the arrival 
      of MN's packet at target AR) until <BR>(draft mentions: 'initiation of a 
      handover or soon after initiation'). <BR>Please explain to me why, since I 
      have no critical deadline, I should still make a choice between <BR>(a) or 
      (b), that is, to simplify (a) ensure that all my context is transfered 
      before handoff, or <BR>(b) wait until I handoff to transfer. Where is (c): 
      I take a leisurely transfer around the handoff, <BR>I start before, but 
      take it easy, dude, whenever I get there is when I get there. <BR>You 
      might see this as a terminology issue, (what do you call (c) since it is 
      not proactive nor reactive). <BR>I think it is more a requirement issue. 
      If the requirement draft specifies (a) and (b), does not <BR>mention any 
      other possibility, explains that if (a) fails, then use (b) as the only 
      choice of combined/ <BR>mixed/soft ct, then it seems to imply that it 
      excludes (c). <BR>I agree with (a) MUST be supported, (b) MUST be 
      supported, tell me why (c) SHOULD NOT <BR>be supported as a requirement? 
      <BR>Thanks, 
      <P>Cedric. <BR>&nbsp; 
      <BLOCKQUOTE 
TYPE="CITE">&nbsp;</BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1089E.5C23CE70--


From owner-seamoby@diameter.org  Tue Jul 10 01:59:57 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16219
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 01:59:56 -0400 (EDT)
Received: (qmail 5194 invoked by alias); 10 Jul 2001 05:48:16 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5188 invoked by uid 200); 10 Jul 2001 05:48:15 -0000
Received: (qmail 5183 invoked from network); 10 Jul 2001 05:48:13 -0000
Received: from mgw-x4.nokia.com (131.228.20.27)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 05:48:13 -0000
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6A61fG21193
	for <seamoby@cdma-2000.org>; Tue, 10 Jul 2001 09:01:41 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54a8758bcfac158f24077@esvir04nok.ntc.nokia.com>;
 Tue, 10 Jul 2001 08:58:48 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS471LM>; Tue, 10 Jul 2001 08:58:48 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094010@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: gkenward@nortelnetworks.com, seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Date: Tue, 10 Jul 2001 08:58:32 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

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 owner-seamoby@diameter.org  Tue Jul 10 10:07:40 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29749
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 10:07:39 -0400 (EDT)
Received: (qmail 6248 invoked by alias); 10 Jul 2001 13:46:35 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6241 invoked by uid 200); 10 Jul 2001 13:46:35 -0000
Received: (qmail 6230 invoked by uid 500); 10 Jul 2001 13:46:33 -0000
Date: Tue, 10 Jul 2001 06:46:33 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: "'Rajeev Koodli'" <rajeev@iprg.nokia.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>,
        "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
        "'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>
Subject: Re: FW: [seamoby] CT trigger or CT completion? was:  proactive an d re active CT definitions
Message-ID: <20010710064633.H1062@charizard.diameter.org>
Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
	'Rajeev Koodli' <rajeev@iprg.nokia.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>,
	"'Charles E. Perkins'" <charliep@iprg.nokia.com>,
	"'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>
References: <35DBB8B7AC89D4118E98009027B1009B017A9E42@IL27EXM10.cig.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B017A9E42@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Mon, Jul 02, 2001 at 01:52:25PM -0500
Sender: owner-seamoby@diameter.org
Precedence: bulk

back from vacation. Sorry for the latency.

On Mon, Jul 02, 2001 at 01:52:25PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote:
> Pat, if I misunderstood the scope of CT, please let me know,
> I thought CT is scoped handle AR-AR only.

well, I am not sure that I know the scope more than you do, but
I don't see a reason to restrict its usage to AR-AR only. An AP
implementor could use our protocol to transfer state as well.

Thanks,

PatC


From owner-seamoby@diameter.org  Tue Jul 10 10:48:51 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01856
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 10:48:50 -0400 (EDT)
Received: (qmail 7639 invoked by alias); 10 Jul 2001 14:36:20 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 7633 invoked by uid 200); 10 Jul 2001 14:36:20 -0000
Received: (qmail 7628 invoked from network); 10 Jul 2001 14:36:18 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 14:36:18 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6ADr9b15843
	for <seamoby@cdma-2000.org>; Tue, 10 Jul 2001 09:53:10 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Tue, 10 Jul 2001 09:53:13 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2YSK5>; Tue, 10 Jul 2001 09:53:14 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5DFE@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Date: Tue, 10 Jul 2001 09:53:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10947.A65F0E60"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10947.A65F0E60
Content-Type: text/plain;
	charset="iso-8859-1"

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: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Tuesday, July 10, 2001 1:59 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org
> 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
> 

------_=_NextPart_001_01C10947.A65F0E60
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>John:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; I have been contemplating removing the &quot;reactive&quot;/&quot;proactive&quot;</FONT>
<BR><FONT SIZE=2>definitions from the requirements also, but I really do hope we</FONT>
<BR><FONT SIZE=2>do not lose the concept of starting ct as early as possible. Being</FONT>
<BR><FONT SIZE=2>proactive with ct has been a fundamental component to ct since the </FONT>
<BR><FONT SIZE=2>problem statement draft, and, to me, a critical tool for providing </FONT>
<BR><FONT SIZE=2>seamless service handover.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; There are those who, rightfully, have no interest in proactive</FONT>
<BR><FONT SIZE=2>ct for their networks. If we lose the requirement, it may be very</FONT>
<BR><FONT SIZE=2>difficult for the wg to proceed with a ctp design that supports </FONT>
<BR><FONT SIZE=2>this mode.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; I'll wait for your issue to be generated. Some of us are also</FONT>
<BR><FONT SIZE=2>struggling with some alterative wording of the definitions</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: john.loughney@nokia.com [<A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Tuesday, July 10, 2001 1:59 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Gary,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; I agree, particularly with your definition of ct (although I'm </FONT>
<BR><FONT SIZE=2>&gt; &gt; not sure where &quot;reductive mode&quot; came from). </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Ooops, I meant that I was in &quot;reductive mode&quot; (trying to</FONT>
<BR><FONT SIZE=2>&gt; simplify &amp; get back to the basics).&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; In thinking through the overall discussion, I am realize that the </FONT>
<BR><FONT SIZE=2>&gt; &gt; big difference between &quot;reactive&quot; and &quot;proactive&quot; is how they are </FONT>
<BR><FONT SIZE=2>&gt; &gt; triggered. &quot;proactive&quot; assumes that there is a trigger available </FONT>
<BR><FONT SIZE=2>&gt; &gt; early on that permits some context transfer in advance of an actual </FONT>
<BR><FONT SIZE=2>&gt; &gt; handover. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I agree. My thoughts are that the discussion of reactive and proactive</FONT>
<BR><FONT SIZE=2>&gt; (&amp; triggering, etc.) get quite close to protocol design.&nbsp; I think</FONT>
<BR><FONT SIZE=2>&gt; that is one reason that the discussion became so heavy on the</FONT>
<BR><FONT SIZE=2>&gt; the requirements.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; I do believe the current wording for proactive is wrong. Now that </FONT>
<BR><FONT SIZE=2>&gt; &gt; I have had time to contemplate the wording, it does not define what </FONT>
<BR><FONT SIZE=2>&gt; &gt; I have always believed proactive ct should be about. I'm hoping </FONT>
<BR><FONT SIZE=2>&gt; &gt; that if we fix that wording, we can move on to the important part </FONT>
<BR><FONT SIZE=2>&gt; &gt; of designing ctp. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; My suggestion would be to cut-out of the requirements document the</FONT>
<BR><FONT SIZE=2>&gt; discussion about proactive &amp; reactive text.&nbsp; I will try to make an</FONT>
<BR><FONT SIZE=2>&gt; issue for this later in the day.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; thanks,</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10947.A65F0E60--


From owner-seamoby@diameter.org  Tue Jul 10 10:57:57 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02208
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 10:57:49 -0400 (EDT)
Received: (qmail 8142 invoked by alias); 10 Jul 2001 14:45:45 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 8136 invoked by uid 200); 10 Jul 2001 14:45:45 -0000
Received: (qmail 8131 invoked from network); 10 Jul 2001 14:45:39 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 14:45:39 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6AEtVb26845
	for <seamoby@cdma-2000.org>; Tue, 10 Jul 2001 10:55:31 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 10 Jul 2001 10:55:23 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Y431>; Tue, 10 Jul 2001 10:55:25 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E03@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: "'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>
Subject: RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re 
         active CT definitions
Date: Tue, 10 Jul 2001 10:55:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10950.58F57700"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10950.58F57700
Content-Type: text/plain;
	charset="iso-8859-1"

The problem statement did (at one time I believe) try to cover
different possible scenarios for ct. The controversy over the
interpretation of "AP" led me to change the names of the ct
peers to "forwarding node" to encompass any two IP forwarding
nodes of a like nature. By definition, the FNs have to be of a
like nature in order for the receiving FN to understand the context
of a sending FN. "Of a like nature" is rather fuzzy, but I don't
believe that we need to be more specific (it really means that
the features at the two FNs have to match in order for the ct to
work, how's that for a tautology).

HOWEVER, unless there is a new wg definition of "AP" out there, the
original definition of an AP identified it as a layer 2 device.
I believe we did decided that ctp would only work with layer 3 entities
(although it may transfer layer 2 context blobs). This does not
stop someone from putting an IP protocol stack at an AP simply for
the purpose of supporting ctp of layer 2 context blobs, but, it
also means that ctp does resides at layer 3, and it's operation is
conditioned not by layer 2 requirements, but by accepted practices
for IP protocols (e.g, as a counter example, ctp will not run 
synchronously between two nodes, as would be required if the 
context blobs contained layer 2 power control information).

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Tuesday, July 10, 2001 9:47 AM
> To: Nakhjiri Madjid-MNAKHJI1
> Cc: 'Rajeev Koodli'; 'Pat Calhoun'; 'Charles E. Perkins';
> 'seamoby@cdma-2000.org'
> Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> an d re active CT definitions
> 
> 
> back from vacation. Sorry for the latency.
> 
> On Mon, Jul 02, 2001 at 01:52:25PM -0500, Nakhjiri 
> Madjid-MNAKHJI1 wrote:
> > Pat, if I misunderstood the scope of CT, please let me know,
> > I thought CT is scoped handle AR-AR only.
> 
> well, I am not sure that I know the scope more than you do, but
> I don't see a reason to restrict its usage to AR-AR only. An AP
> implementor could use our protocol to transfer state as well.
> 
> Thanks,
> 
> PatC
> 

------_=_NextPart_001_01C10950.58F57700
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: FW: [seamoby] CT trigger or CT completion? was: proactive an d re  active CT definitions</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>The problem statement did (at one time I believe) try to cover</FONT>
<BR><FONT SIZE=2>different possible scenarios for ct. The controversy over the</FONT>
<BR><FONT SIZE=2>interpretation of &quot;AP&quot; led me to change the names of the ct</FONT>
<BR><FONT SIZE=2>peers to &quot;forwarding node&quot; to encompass any two IP forwarding</FONT>
<BR><FONT SIZE=2>nodes of a like nature. By definition, the FNs have to be of a</FONT>
<BR><FONT SIZE=2>like nature in order for the receiving FN to understand the context</FONT>
<BR><FONT SIZE=2>of a sending FN. &quot;Of a like nature&quot; is rather fuzzy, but I don't</FONT>
<BR><FONT SIZE=2>believe that we need to be more specific (it really means that</FONT>
<BR><FONT SIZE=2>the features at the two FNs have to match in order for the ct to</FONT>
<BR><FONT SIZE=2>work, how's that for a tautology).</FONT>
</P>

<P><FONT SIZE=2>HOWEVER, unless there is a new wg definition of &quot;AP&quot; out there, the</FONT>
<BR><FONT SIZE=2>original definition of an AP identified it as a layer 2 device.</FONT>
<BR><FONT SIZE=2>I believe we did decided that ctp would only work with layer 3 entities</FONT>
<BR><FONT SIZE=2>(although it may transfer layer 2 context blobs). This does not</FONT>
<BR><FONT SIZE=2>stop someone from putting an IP protocol stack at an AP simply for</FONT>
<BR><FONT SIZE=2>the purpose of supporting ctp of layer 2 context blobs, but, it</FONT>
<BR><FONT SIZE=2>also means that ctp does resides at layer 3, and it's operation is</FONT>
<BR><FONT SIZE=2>conditioned not by layer 2 requirements, but by accepted practices</FONT>
<BR><FONT SIZE=2>for IP protocols (e.g, as a counter example, ctp will not run </FONT>
<BR><FONT SIZE=2>synchronously between two nodes, as would be required if the </FONT>
<BR><FONT SIZE=2>context blobs contained layer 2 power control information).</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Pat Calhoun [<A HREF="mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Tuesday, July 10, 2001 9:47 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Nakhjiri Madjid-MNAKHJI1</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'Rajeev Koodli'; 'Pat Calhoun'; 'Charles E. Perkins';</FONT>
<BR><FONT SIZE=2>&gt; 'seamoby@cdma-2000.org'</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive</FONT>
<BR><FONT SIZE=2>&gt; an d re active CT definitions</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; back from vacation. Sorry for the latency.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; On Mon, Jul 02, 2001 at 01:52:25PM -0500, Nakhjiri </FONT>
<BR><FONT SIZE=2>&gt; Madjid-MNAKHJI1 wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; Pat, if I misunderstood the scope of CT, please let me know,</FONT>
<BR><FONT SIZE=2>&gt; &gt; I thought CT is scoped handle AR-AR only.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; well, I am not sure that I know the scope more than you do, but</FONT>
<BR><FONT SIZE=2>&gt; I don't see a reason to restrict its usage to AR-AR only. An AP</FONT>
<BR><FONT SIZE=2>&gt; implementor could use our protocol to transfer state as well.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10950.58F57700--


From owner-seamoby@diameter.org  Tue Jul 10 11:08:15 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02862
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 11:08:14 -0400 (EDT)
Received: (qmail 8629 invoked by alias); 10 Jul 2001 14:56:35 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 8623 invoked by uid 200); 10 Jul 2001 14:56:35 -0000
Received: (qmail 8616 invoked by uid 500); 10 Jul 2001 14:56:34 -0000
Date: Tue, 10 Jul 2001 07:56:34 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Message-ID: <20010710075633.K1062@charizard.diameter.org>
Mail-Followup-To: Gary Kenward <gkenward@nortelnetworks.com>,
	"'john.loughney@nokia.com'" <john.loughney@nokia.com>,
	seamoby@cdma-2000.org
References: <9FBD322B7824D511B36900508BF93C9C9F5DFE@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5DFE@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Tue, Jul 10, 2001 at 09:53:08AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Tue, Jul 10, 2001 at 09:53:08AM -0400, Gary Kenward wrote:
> 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.

My view, Gary, is this that reactive/proactive is simply a method of
using CTP. I don't see how the protocol could be that different when
used in either mode. Perhaps some text at the beginning of the protocol
specification detailing its use in proactive and reactive modes would
be sufficient.

This really comes down to the triggers available for CTP, and is not
a CTP protocol issue.

PatC
>    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: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > Sent: Tuesday, July 10, 2001 1:59 AM
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org
> > 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 owner-seamoby@diameter.org  Tue Jul 10 11:20:42 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03347
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 11:20:32 -0400 (EDT)
Received: (qmail 9641 invoked by alias); 10 Jul 2001 15:07:15 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 9635 invoked by uid 200); 10 Jul 2001 15:07:14 -0000
Received: (qmail 9630 invoked from network); 10 Jul 2001 15:07:12 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 15:07:12 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6AFGvb00139
	for <seamoby@cdma-2000.org>; Tue, 10 Jul 2001 11:16:57 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Tue, 10 Jul 2001 11:16:44 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2YVFV>; Tue, 10 Jul 2001 11:16:45 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E0A@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Date: Tue, 10 Jul 2001 11:16:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10953.536ECB30"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10953.536ECB30
Content-Type: text/plain;
	charset="iso-8859-1"

I tend to agree with you Pat, however, without a ctp design
we really do not know. The fundamental issue I have is for
us not to lose the concept of doing things as early as possible.
It would be quite easy to define a ct protocol that could not
be proactive - e.g. a ctp that was triggered by the first packet
arrival at the new AR.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Tuesday, July 10, 2001 10:57 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
> Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> 
> 
> On Tue, Jul 10, 2001 at 09:53:08AM -0400, Gary Kenward wrote:
> > 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.
> 
> My view, Gary, is this that reactive/proactive is simply a method of
> using CTP. I don't see how the protocol could be that different when
> used in either mode. Perhaps some text at the beginning of 
> the protocol
> specification detailing its use in proactive and reactive modes would
> be sufficient.
> 
> This really comes down to the triggers available for CTP, and is not
> a CTP protocol issue.
> 
> PatC
> >    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: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > > Sent: Tuesday, July 10, 2001 1:59 AM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org
> > > 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
> > > 
> 

------_=_NextPart_001_01C10953.536ECB30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I tend to agree with you Pat, however, without a ctp =
design</FONT>
<BR><FONT SIZE=3D2>we really do not know. The fundamental issue I have =
is for</FONT>
<BR><FONT SIZE=3D2>us not to lose the concept of doing things as early =
as possible.</FONT>
<BR><FONT SIZE=3D2>It would be quite easy to define a ct protocol that =
could not</FONT>
<BR><FONT SIZE=3D2>be proactive - e.g. a ctp that was triggered by the =
first packet</FONT>
<BR><FONT SIZE=3D2>arrival at the new AR.</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Pat Calhoun [<A =
HREF=3D"mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, July 10, 2001 10:57 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'john.loughney@nokia.com'; =
seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [seamoby] L2 API (WAS: Ext. for =
FMIPv6 - comments)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; On Tue, Jul 10, 2001 at 09:53:08AM -0400, Gary =
Kenward wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; John:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; I have been =
contemplating removing the =
&quot;reactive&quot;/&quot;proactive&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; definitions from the requirements also, =
but I really do hope we</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; do not lose the concept of starting ct as =
early as possible. Being</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; proactive with ct has been a fundamental =
component to ct since the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; problem statement draft, and, to me, a =
critical tool for providing </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; seamless service handover.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; My view, Gary, is this that reactive/proactive =
is simply a method of</FONT>
<BR><FONT SIZE=3D2>&gt; using CTP. I don't see how the protocol could =
be that different when</FONT>
<BR><FONT SIZE=3D2>&gt; used in either mode. Perhaps some text at the =
beginning of </FONT>
<BR><FONT SIZE=3D2>&gt; the protocol</FONT>
<BR><FONT SIZE=3D2>&gt; specification detailing its use in proactive =
and reactive modes would</FONT>
<BR><FONT SIZE=3D2>&gt; be sufficient.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; This really comes down to the triggers =
available for CTP, and is not</FONT>
<BR><FONT SIZE=3D2>&gt; a CTP protocol issue.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; PatC</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; There are those who, =
rightfully, have no interest in proactive</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ct for their networks. If we lose the =
requirement, it may be very</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; difficult for the wg to proceed with a ctp =
design that supports </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; this mode.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp; I'll wait for your issue =
to be generated. Some of us are also</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; struggling with some alterative wording of =
the definitions</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Gary</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: john.loughney@nokia.com [<A =
HREF=3D"mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</=
A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Tuesday, July 10, 2001 1:59 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; =
seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: RE: [seamoby] L2 API (WAS: =
Ext. for FMIPv6 - comments)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Hi Gary,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&nbsp; I agree, particularly with =
your definition of ct (although I'm </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; not sure where &quot;reductive =
mode&quot; came from). </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Ooops, I meant that I was in =
&quot;reductive mode&quot; (trying to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; simplify &amp; get back to the =
basics).&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; In thinking through the overall =
discussion, I am </FONT>
<BR><FONT SIZE=3D2>&gt; realize that the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; big difference between =
&quot;reactive&quot; and &quot;proactive&quot; is </FONT>
<BR><FONT SIZE=3D2>&gt; how they are </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; triggered. &quot;proactive&quot; =
assumes that there is a trigger </FONT>
<BR><FONT SIZE=3D2>&gt; available </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; early on that permits some =
context transfer in advance </FONT>
<BR><FONT SIZE=3D2>&gt; of an actual </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; handover. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I agree. My thoughts are that the =
discussion of reactive </FONT>
<BR><FONT SIZE=3D2>&gt; and proactive</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (&amp; triggering, etc.) get quite =
close to protocol design.&nbsp; I think</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; that is one reason that the =
discussion became so heavy on the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the requirements.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&nbsp;&nbsp; I do believe the =
current wording for proactive is </FONT>
<BR><FONT SIZE=3D2>&gt; wrong. Now that </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; I have had time to contemplate =
the wording, it does not </FONT>
<BR><FONT SIZE=3D2>&gt; define what </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; I have always believed proactive =
ct should be about. I'm hoping </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; that if we fix that wording, we =
can move on to the </FONT>
<BR><FONT SIZE=3D2>&gt; important part </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; of designing ctp. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; My suggestion would be to cut-out of =
the requirements document the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; discussion about proactive &amp; =
reactive text.&nbsp; I will try to make an</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; issue for this later in the =
day.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; John</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10953.536ECB30--


From owner-seamoby@diameter.org  Tue Jul 10 11:28:33 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03686
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 11:28:32 -0400 (EDT)
Received: (qmail 10134 invoked by alias); 10 Jul 2001 15:16:33 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 10128 invoked by uid 200); 10 Jul 2001 15:16:33 -0000
Received: (qmail 10122 invoked from network); 10 Jul 2001 15:16:32 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 15:16:32 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id IAA11875;
	Tue, 10 Jul 2001 08:26:45 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6AFQih12916;
	Tue, 10 Jul 2001 08:26:44 -0700
X-mProtect:  Tue, 10 Jul 2001 08:26:44 -0700 Nokia Silicon Valley Messaging Protection
Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdZh8yoa; Tue, 10 Jul 2001 08:26:42 PDT
Message-ID: <3B4B1EA4.606E5A6D@iprg.nokia.com>
Date: Tue, 10 Jul 2001 08:26:29 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>
CC: seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
References: <9FBD322B7824D511B36900508BF93C9C9F5DFE@zcard031.ca.nortel.com> <20010710075633.K1062@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

Pat Calhoun wrote:

> On Tue, Jul 10, 2001 at 09:53:08AM -0400, Gary Kenward wrote:
> > 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.
>
> My view, Gary, is this that reactive/proactive is simply a method of
> using CTP. I don't see how the protocol could be that different when
> used in either mode. Perhaps some text at the beginning of the protocol
> specification detailing its use in proactive and reactive modes would
> be sufficient.
>
> This really comes down to the triggers available for CTP, and is not
> a CTP protocol issue.
>
> PatC

I do not agree with this. Let me give you an example: MN wants to use
proactive
CT for header compression state relocation. MN moves to new access router.
If the ctp is same for proactive and reactive, then MN can only _hope_ that
the header compression state is in place. So it transmits with a full header,
and loses
some of the benefit of the context transfer.
If proactive and reactive ct are different (and they don't necessarily have to
be very
different, consider just an Ack from newAR to MN via oldAR that context is in
place, or whatever, this is solution space) then MN can distinguish and use
compressed
header right away.
Take care,

Cedric.



>
> >    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: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > > Sent: Tuesday, July 10, 2001 1:59 AM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org
> > > 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 owner-seamoby@diameter.org  Tue Jul 10 11:30:55 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03846
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 11:30:54 -0400 (EDT)
Received: (qmail 8934 invoked by alias); 10 Jul 2001 14:58:46 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 8926 invoked by uid 200); 10 Jul 2001 14:58:45 -0000
Received: (qmail 8910 invoked by uid 500); 10 Jul 2001 14:58:42 -0000
Date: Tue, 10 Jul 2001 07:58:42 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>
Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive an d re active CT definitions
Message-ID: <20010710075842.L1062@charizard.diameter.org>
Mail-Followup-To: Gary Kenward <gkenward@nortelnetworks.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>,
	Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
	"'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>
References: <9FBD322B7824D511B36900508BF93C9C9F5E03@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E03@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Tue, Jul 10, 2001 at 10:55:23AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

Gary,

I agree. If one wants to support CTP in an AP, it must support IP.
My point was that although we are envisioning CTP being used in ARs,
we must not specifically prohibit its use in other devices.

PatC
On Tue, Jul 10, 2001 at 10:55:23AM -0400, Gary Kenward wrote:
> The problem statement did (at one time I believe) try to cover
> different possible scenarios for ct. The controversy over the
> interpretation of "AP" led me to change the names of the ct
> peers to "forwarding node" to encompass any two IP forwarding
> nodes of a like nature. By definition, the FNs have to be of a
> like nature in order for the receiving FN to understand the context
> of a sending FN. "Of a like nature" is rather fuzzy, but I don't
> believe that we need to be more specific (it really means that
> the features at the two FNs have to match in order for the ct to
> work, how's that for a tautology).
> 
> HOWEVER, unless there is a new wg definition of "AP" out there, the
> original definition of an AP identified it as a layer 2 device.
> I believe we did decided that ctp would only work with layer 3 entities
> (although it may transfer layer 2 context blobs). This does not
> stop someone from putting an IP protocol stack at an AP simply for
> the purpose of supporting ctp of layer 2 context blobs, but, it
> also means that ctp does resides at layer 3, and it's operation is
> conditioned not by layer 2 requirements, but by accepted practices
> for IP protocols (e.g, as a counter example, ctp will not run 
> synchronously between two nodes, as would be required if the 
> context blobs contained layer 2 power control information).
> 
> Gary
> 
> > -----Original Message-----
> > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> > Sent: Tuesday, July 10, 2001 9:47 AM
> > To: Nakhjiri Madjid-MNAKHJI1
> > Cc: 'Rajeev Koodli'; 'Pat Calhoun'; 'Charles E. Perkins';
> > 'seamoby@cdma-2000.org'
> > Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
> > an d re active CT definitions
> > 
> > 
> > back from vacation. Sorry for the latency.
> > 
> > On Mon, Jul 02, 2001 at 01:52:25PM -0500, Nakhjiri 
> > Madjid-MNAKHJI1 wrote:
> > > Pat, if I misunderstood the scope of CT, please let me know,
> > > I thought CT is scoped handle AR-AR only.
> > 
> > well, I am not sure that I know the scope more than you do, but
> > I don't see a reason to restrict its usage to AR-AR only. An AP
> > implementor could use our protocol to transfer state as well.
> > 
> > Thanks,
> > 
> > PatC
> > 


From owner-seamoby@diameter.org  Tue Jul 10 11:40:06 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04169
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 11:40:05 -0400 (EDT)
Received: (qmail 10730 invoked by alias); 10 Jul 2001 15:29:12 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 10724 invoked by uid 200); 10 Jul 2001 15:29:12 -0000
Received: (qmail 10715 invoked by uid 500); 10 Jul 2001 15:29:09 -0000
Date: Tue, 10 Jul 2001 08:29:09 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Cedric Westphal <cedric@IPRG.nokia.com>
Cc: Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Message-ID: <20010710082909.B10676@charizard.diameter.org>
Mail-Followup-To: Cedric Westphal <cedric@IPRG.nokia.com>,
	Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
References: <9FBD322B7824D511B36900508BF93C9C9F5DFE@zcard031.ca.nortel.com> <20010710075633.K1062@charizard.diameter.org> <3B4B1EA4.606E5A6D@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B4B1EA4.606E5A6D@iprg.nokia.com>; from cedric@IPRG.nokia.com on Tue, Jul 10, 2001 at 08:26:29AM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Tue, Jul 10, 2001 at 08:26:29AM -0700, Cedric Westphal wrote:
> > This really comes down to the triggers available for CTP, and is not
> > a CTP protocol issue.
> I do not agree with this. Let me give you an example: MN wants to use
> proactive
> CT for header compression state relocation. MN moves to new access router.
> If the ctp is same for proactive and reactive, then MN can only _hope_ that
> the header compression state is in place. So it transmits with a full header,
> and loses
> some of the benefit of the context transfer.
> If proactive and reactive ct are different (and they don't necessarily have to
> be very
> different, consider just an Ack from newAR to MN via oldAR that context is in
> place, or whatever, this is solution space) then MN can distinguish and use
> compressed
> header right away.

so a bit set in the CTP would inform the receiver that the packet's
IP header is compressed? I'm not sure that I follow your example :(

The MN can initiate a CTP in proactive or reactive mode, but I still
think that the packet format would be identical.


PatC


From owner-seamoby@diameter.org  Tue Jul 10 13:26:50 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09991
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 13:26:50 -0400 (EDT)
Received: (qmail 13013 invoked by alias); 10 Jul 2001 17:15:26 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 13007 invoked by uid 200); 10 Jul 2001 17:15:25 -0000
Received: (qmail 13001 invoked from network); 10 Jul 2001 17:15:23 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 17:15:23 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA21121;
	Tue, 10 Jul 2001 10:25:33 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6AHPWS28489;
	Tue, 10 Jul 2001 10:25:32 -0700
X-mProtect:  Tue, 10 Jul 2001 10:25:32 -0700 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd2v8EVV; Tue, 10 Jul 2001 10:25:29 PDT
Message-ID: <3B4B3A7A.84FAD10C@iprg.nokia.com>
Date: Tue, 10 Jul 2001 10:25:14 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>
CC: seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
References: <9FBD322B7824D511B36900508BF93C9C9F5DFE@zcard031.ca.nortel.com> <20010710075633.K1062@charizard.diameter.org> <3B4B1EA4.606E5A6D@iprg.nokia.com> <20010710082909.B10676@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



Pat Calhoun wrote:

> On Tue, Jul 10, 2001 at 08:26:29AM -0700, Cedric Westphal wrote:
> > > This really comes down to the triggers available for CTP, and is not
> > > a CTP protocol issue.
> > I do not agree with this. Let me give you an example: MN wants to use
> > proactive
> > CT for header compression state relocation. MN moves to new access router.
> > If the ctp is same for proactive and reactive, then MN can only _hope_ that
> > the header compression state is in place. So it transmits with a full header,
> > and loses
> > some of the benefit of the context transfer.
> > If proactive and reactive ct are different (and they don't necessarily have to
> > be very
> > different, consider just an Ack from newAR to MN via oldAR that context is in
> > place, or whatever, this is solution space) then MN can distinguish and use
> > compressed
> > header right away.
>
> so a bit set in the CTP would inform the receiver that the packet's
> IP header is compressed? I'm not sure that I follow your example :(

Well, I did not elaborate the example since, as I said, it is solution space.
All I am trying to convey is that there is value in knowing before, say, releasing
connection
to oldAR, that the C is T'ed. And thus there is a difference (at least in the
requirement) between proactive and reactive.

>
>
> The MN can initiate a CTP in proactive or reactive mode, but I still
> think that the packet format would be identical.

I agree with that. Packet format should be the same. But is the ctp only a matter of
defining a packet format? Or is it a ct protocol?
In my little example:
MN                                            oldAR
newAR
    will handoff to new AR-->                      transfer ct---->
                                                                 <-------Ack, ct
received
    <----------------Ack ct there

If MN is still connected to oldAR when the Ack gets back, then it is proactive, and
it knows it
can use, say compressed header right away.
If MN is not connected to oldAR when the Ack gets back, then MN knows it has not
received
it, and by default, it is reactive, and it uses full header with newAR.

I agree with you that the arrow    'transfer ct---->' should be the same, whether
it's proactive or
reactive. Now,  I am not sure it is the only arrow that is needed.

Take care,

Cedric.

>
>
> PatC



From owner-seamoby@diameter.org  Tue Jul 10 13:47:16 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11070
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 13:47:15 -0400 (EDT)
Received: (qmail 14234 invoked by alias); 10 Jul 2001 17:35:53 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 14228 invoked by uid 200); 10 Jul 2001 17:35:52 -0000
Received: (qmail 14218 invoked by uid 500); 10 Jul 2001 17:35:50 -0000
Date: Tue, 10 Jul 2001 10:35:50 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Cedric Westphal <cedric@IPRG.nokia.com>
Cc: Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Message-ID: <20010710103550.O10676@charizard.diameter.org>
Mail-Followup-To: Cedric Westphal <cedric@IPRG.nokia.com>,
	Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
References: <9FBD322B7824D511B36900508BF93C9C9F5DFE@zcard031.ca.nortel.com> <20010710075633.K1062@charizard.diameter.org> <3B4B1EA4.606E5A6D@iprg.nokia.com> <20010710082909.B10676@charizard.diameter.org> <3B4B3A7A.84FAD10C@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B4B3A7A.84FAD10C@iprg.nokia.com>; from cedric@IPRG.nokia.com on Tue, Jul 10, 2001 at 10:25:14AM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Tue, Jul 10, 2001 at 10:25:14AM -0700, Cedric Westphal wrote:
> 
> 
> Pat Calhoun wrote:
> 
> > On Tue, Jul 10, 2001 at 08:26:29AM -0700, Cedric Westphal wrote:
> > > > This really comes down to the triggers available for CTP, and is not
> > > > a CTP protocol issue.
> > > I do not agree with this. Let me give you an example: MN wants to use
> > > proactive
> > > CT for header compression state relocation. MN moves to new access router.
> > > If the ctp is same for proactive and reactive, then MN can only _hope_ that
> > > the header compression state is in place. So it transmits with a full header,
> > > and loses
> > > some of the benefit of the context transfer.
> > > If proactive and reactive ct are different (and they don't necessarily have to
> > > be very
> > > different, consider just an Ack from newAR to MN via oldAR that context is in
> > > place, or whatever, this is solution space) then MN can distinguish and use
> > > compressed
> > > header right away.
> >
> > so a bit set in the CTP would inform the receiver that the packet's
> > IP header is compressed? I'm not sure that I follow your example :(
> 
> Well, I did not elaborate the example since, as I said, it is solution space.
> All I am trying to convey is that there is value in knowing before, say, releasing
> connection
> to oldAR, that the C is T'ed. And thus there is a difference (at least in the
> requirement) between proactive and reactive.
> 
> >
> >
> > The MN can initiate a CTP in proactive or reactive mode, but I still
> > think that the packet format would be identical.
> 
> I agree with that. Packet format should be the same. But is the ctp only a matter of
> defining a packet format? Or is it a ct protocol?
> In my little example:
> MN                                            oldAR
> newAR
>     will handoff to new AR-->                      transfer ct---->
>                                                                  <-------Ack, ct
> received
>     <----------------Ack ct there
> 
> If MN is still connected to oldAR when the Ack gets back, then it is proactive, and
> it knows it
> can use, say compressed header right away.
> If MN is not connected to oldAR when the Ack gets back, then MN knows it has not
> received
> it, and by default, it is reactive, and it uses full header with newAR.
> 
> I agree with you that the arrow    'transfer ct---->' should be the same, whether
> it's proactive or
> reactive. Now,  I am not sure it is the only arrow that is needed.

Good, I think we are making progress.

So, the main difference above between proactive and reactive is the
presence of the header compression state blob. We couldn't, however,
mandate that particular blobs be present in proactive vs. reactive,
but as we discussed earlier, could require that certain blobs be
defined as high priority, which would be used in the initial CTP message
(in a multi-phasic sense) - the equivalent of proactive.

PatC


From owner-seamoby@diameter.org  Tue Jul 10 14:55:55 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14756
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 14:55:53 -0400 (EDT)
Received: (qmail 14924 invoked by alias); 10 Jul 2001 18:44:17 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 14918 invoked by uid 200); 10 Jul 2001 18:44:16 -0000
Received: (qmail 14912 invoked from network); 10 Jul 2001 18:44:14 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 18:44:14 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA29103;
	Tue, 10 Jul 2001 11:54:27 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6AIsRI05823;
	Tue, 10 Jul 2001 11:54:27 -0700
X-mProtect:  Tue, 10 Jul 2001 11:54:27 -0700 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdzJnqBw; Tue, 10 Jul 2001 11:54:24 PDT
Message-ID: <3B4B4F48.5601FFEF@iprg.nokia.com>
Date: Tue, 10 Jul 2001 11:54:01 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
References: <9FBD322B7824D511B36900508BF93C9C9F5DFE@zcard031.ca.nortel.com> <20010710075633.K1062@charizard.diameter.org> <3B4B1EA4.606E5A6D@iprg.nokia.com> <20010710082909.B10676@charizard.diameter.org> <3B4B3A7A.84FAD10C@iprg.nokia.com> <20010710103550.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



Pat Calhoun wrote:

> On Tue, Jul 10, 2001 at 10:25:14AM -0700, Cedric Westphal wrote:
> >
> >
> > Pat Calhoun wrote:
> >
> > > On Tue, Jul 10, 2001 at 08:26:29AM -0700, Cedric Westphal wrote:
> > > > > This really comes down to the triggers available for CTP, and is not
> > > > > a CTP protocol issue.
> > > > I do not agree with this. Let me give you an example: MN wants to use
> > > > proactive
> > > > CT for header compression state relocation. MN moves to new access router.
> > > > If the ctp is same for proactive and reactive, then MN can only _hope_ that
> > > > the header compression state is in place. So it transmits with a full header,
> > > > and loses
> > > > some of the benefit of the context transfer.
> > > > If proactive and reactive ct are different (and they don't necessarily have to
> > > > be very
> > > > different, consider just an Ack from newAR to MN via oldAR that context is in
> > > > place, or whatever, this is solution space) then MN can distinguish and use
> > > > compressed
> > > > header right away.
> > >
> > > so a bit set in the CTP would inform the receiver that the packet's
> > > IP header is compressed? I'm not sure that I follow your example :(
> >
> > Well, I did not elaborate the example since, as I said, it is solution space.
> > All I am trying to convey is that there is value in knowing before, say, releasing
> > connection
> > to oldAR, that the C is T'ed. And thus there is a difference (at least in the
> > requirement) between proactive and reactive.
> >
> > >
> > >
> > > The MN can initiate a CTP in proactive or reactive mode, but I still
> > > think that the packet format would be identical.
> >
> > I agree with that. Packet format should be the same. But is the ctp only a matter of
> > defining a packet format? Or is it a ct protocol?
> > In my little example:
> > MN                                            oldAR
> > newAR
> >     will handoff to new AR-->                      transfer ct---->
> >                                                                  <-------Ack, ct
> > received
> >     <----------------Ack ct there
> >
> > If MN is still connected to oldAR when the Ack gets back, then it is proactive, and
> > it knows it
> > can use, say compressed header right away.
> > If MN is not connected to oldAR when the Ack gets back, then MN knows it has not
> > received
> > it, and by default, it is reactive, and it uses full header with newAR.
> >
> > I agree with you that the arrow    'transfer ct---->' should be the same, whether
> > it's proactive or
> > reactive. Now,  I am not sure it is the only arrow that is needed.
>
> Good, I think we are making progress.
>
> So, the main difference above between proactive and reactive is the
> presence of the header compression state blob. We couldn't, however,
> mandate that particular blobs be present in proactive vs. reactive,
> but as we discussed earlier, could require that certain blobs be
> defined as high priority, which would be used in the initial CTP message
> (in a multi-phasic sense) - the equivalent of proactive.
>
> PatC

Pat,

sorry for using a header compression example, I think it is getting more confusing
that anything. The difference between proactive vs. reactive is not one of presence
of particular blobs.
What you mean here is a _relative_ timing of the different context establishments at
new AR, higher priority blobs arriving before lower priority blobs. This is not what
proactive vs. reactive is.
The way I see proactive, it is an _absolute_ timing of the event with respect to a time
reference outside of the context transfer. MN wants context to be in place before
MN's packets arrive at newAR, so MN requests proactive ct. MN needs to know whether
proactive has succeeded (be it by some acknowledgement, or whatever, solution space,
later). If not, then MN can make use of this information (by not getting the
acknowledgement,
or whatever).
If you can do everything, proactive and reactive, with the same protocol, it is fine with
me, but
this is a requirement phase, and I think you have a solution  in mind (and a
prioritization of
phases is only a solution to the relative ct timing problem).

Cheers,

Cedric.



From owner-seamoby@diameter.org  Tue Jul 10 15:47:46 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17932
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 15:47:45 -0400 (EDT)
Received: (qmail 15561 invoked by alias); 10 Jul 2001 19:36:37 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15554 invoked by uid 200); 10 Jul 2001 19:36:37 -0000
Received: (qmail 15545 invoked by uid 500); 10 Jul 2001 19:36:34 -0000
Date: Tue, 10 Jul 2001 12:36:34 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Cedric Westphal <cedric@IPRG.nokia.com>
Cc: Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Message-ID: <20010710123634.S10676@charizard.diameter.org>
Mail-Followup-To: Cedric Westphal <cedric@IPRG.nokia.com>,
	Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
References: <9FBD322B7824D511B36900508BF93C9C9F5DFE@zcard031.ca.nortel.com> <20010710075633.K1062@charizard.diameter.org> <3B4B1EA4.606E5A6D@iprg.nokia.com> <20010710082909.B10676@charizard.diameter.org> <3B4B3A7A.84FAD10C@iprg.nokia.com> <20010710103550. <3B4B4F48.5601FFEF@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B4B4F48.5601FFEF@iprg.nokia.com>; from cedric@IPRG.nokia.com on Tue, Jul 10, 2001 at 11:54:01AM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Tue, Jul 10, 2001 at 11:54:01AM -0700, Cedric Westphal wrote:
> >
> > Good, I think we are making progress.
> >
> > So, the main difference above between proactive and reactive is the
> > presence of the header compression state blob. We couldn't, however,
> > mandate that particular blobs be present in proactive vs. reactive,
> > but as we discussed earlier, could require that certain blobs be
> > defined as high priority, which would be used in the initial CTP message
> > (in a multi-phasic sense) - the equivalent of proactive.
> >
> > PatC
> 
> Pat,
> 
> sorry for using a header compression example, I think it is getting more confusing
> that anything. The difference between proactive vs. reactive is not one of presence
> of particular blobs.
> What you mean here is a _relative_ timing of the different context establishments at
> new AR, higher priority blobs arriving before lower priority blobs. This is not what
> proactive vs. reactive is.
> The way I see proactive, it is an _absolute_ timing of the event with respect to a time
> reference outside of the context transfer. MN wants context to be in place before
> MN's packets arrive at newAR, so MN requests proactive ct. MN needs to know whether
> proactive has succeeded (be it by some acknowledgement, or whatever, solution space,
> later). If not, then MN can make use of this information (by not getting the
> acknowledgement,
> or whatever).
> If you can do everything, proactive and reactive, with the same protocol, it is fine with
> me, but
> this is a requirement phase, and I think you have a solution  in mind (and a
> prioritization of
> phases is only a solution to the relative ct timing problem).

yes, you are correct. My thiking is in the solution space. Perhaps leaving
the distinction in the requirements can be useful during protocol design,
but I am still convinced that all that will be required are two sections 
decribing the timing of CTP, and no protocol changes.

PatC


From owner-seamoby@diameter.org  Tue Jul 10 15:55:05 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18843
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 15:54:55 -0400 (EDT)
Received: (qmail 16053 invoked by alias); 10 Jul 2001 19:40:25 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16047 invoked by uid 200); 10 Jul 2001 19:40:24 -0000
Received: (qmail 16038 invoked from network); 10 Jul 2001 19:40:22 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 19:40:22 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6AJoDb09107
	for <seamoby@cdma-2000.org>; Tue, 10 Jul 2001 15:50:13 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Tue, 10 Jul 2001 15:50:15 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Y7YB>; Tue, 10 Jul 2001 15:50:17 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E0C@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Cedric Westphal'" <cedric@IPRG.nokia.com>,
        Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Date: Tue, 10 Jul 2001 15:50:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10979.87B9D440"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10979.87B9D440
Content-Type: text/plain;
	charset="iso-8859-1"

Cedric:

  So, I think here that you are agreeing with the original point,
which is that there is no requirement for two versions of ctp,
but there is a requirement for early and almost late (proactive
and reactive) ct.

  That there is no requirement simply means that we should not
embed this concept into the reqs draft. It does not prohibit
tailoring the ct protocol during the design phase for different
modes of operation.

Gary

> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> Sent: Tuesday, July 10, 2001 2:54 PM
> To: Pat Calhoun; seamoby@cdma-2000.org
> Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> 
> 
> 
> 
> Pat Calhoun wrote:
> 
> > On Tue, Jul 10, 2001 at 10:25:14AM -0700, Cedric Westphal wrote:
> > >
> > >
> > > Pat Calhoun wrote:
> > >
> > > > On Tue, Jul 10, 2001 at 08:26:29AM -0700, Cedric Westphal wrote:
> > > > > > This really comes down to the triggers available 
> for CTP, and is not
> > > > > > a CTP protocol issue.
> > > > > I do not agree with this. Let me give you an example: 
> MN wants to use
> > > > > proactive
> > > > > CT for header compression state relocation. MN moves 
> to new access router.
> > > > > If the ctp is same for proactive and reactive, then 
> MN can only _hope_ that
> > > > > the header compression state is in place. So it 
> transmits with a full header,
> > > > > and loses
> > > > > some of the benefit of the context transfer.
> > > > > If proactive and reactive ct are different (and they 
> don't necessarily have to
> > > > > be very
> > > > > different, consider just an Ack from newAR to MN via 
> oldAR that context is in
> > > > > place, or whatever, this is solution space) then MN 
> can distinguish and use
> > > > > compressed
> > > > > header right away.
> > > >
> > > > so a bit set in the CTP would inform the receiver that 
> the packet's
> > > > IP header is compressed? I'm not sure that I follow 
> your example :(
> > >
> > > Well, I did not elaborate the example since, as I said, 
> it is solution space.
> > > All I am trying to convey is that there is value in 
> knowing before, say, releasing
> > > connection
> > > to oldAR, that the C is T'ed. And thus there is a 
> difference (at least in the
> > > requirement) between proactive and reactive.
> > >
> > > >
> > > >
> > > > The MN can initiate a CTP in proactive or reactive 
> mode, but I still
> > > > think that the packet format would be identical.
> > >
> > > I agree with that. Packet format should be the same. But 
> is the ctp only a matter of
> > > defining a packet format? Or is it a ct protocol?
> > > In my little example:
> > > MN                                            oldAR
> > > newAR
> > >     will handoff to new AR-->                      
> transfer ct---->
> > >                                                           
>        <-------Ack, ct
> > > received
> > >     <----------------Ack ct there
> > >
> > > If MN is still connected to oldAR when the Ack gets back, 
> then it is proactive, and
> > > it knows it
> > > can use, say compressed header right away.
> > > If MN is not connected to oldAR when the Ack gets back, 
> then MN knows it has not
> > > received
> > > it, and by default, it is reactive, and it uses full 
> header with newAR.
> > >
> > > I agree with you that the arrow    'transfer ct---->' 
> should be the same, whether
> > > it's proactive or
> > > reactive. Now,  I am not sure it is the only arrow that is needed.
> >
> > Good, I think we are making progress.
> >
> > So, the main difference above between proactive and reactive is the
> > presence of the header compression state blob. We couldn't, however,
> > mandate that particular blobs be present in proactive vs. reactive,
> > but as we discussed earlier, could require that certain blobs be
> > defined as high priority, which would be used in the 
> initial CTP message
> > (in a multi-phasic sense) - the equivalent of proactive.
> >
> > PatC
> 
> Pat,
> 
> sorry for using a header compression example, I think it is 
> getting more confusing
> that anything. The difference between proactive vs. reactive 
> is not one of presence
> of particular blobs.
> What you mean here is a _relative_ timing of the different 
> context establishments at
> new AR, higher priority blobs arriving before lower priority 
> blobs. This is not what
> proactive vs. reactive is.
> The way I see proactive, it is an _absolute_ timing of the 
> event with respect to a time
> reference outside of the context transfer. MN wants context 
> to be in place before
> MN's packets arrive at newAR, so MN requests proactive ct. MN 
> needs to know whether
> proactive has succeeded (be it by some acknowledgement, or 
> whatever, solution space,
> later). If not, then MN can make use of this information (by 
> not getting the
> acknowledgement,
> or whatever).
> If you can do everything, proactive and reactive, with the 
> same protocol, it is fine with
> me, but
> this is a requirement phase, and I think you have a solution  
> in mind (and a
> prioritization of
> phases is only a solution to the relative ct timing problem).
> 
> Cheers,
> 
> Cedric.
> 
> 

------_=_NextPart_001_01C10979.87B9D440
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Cedric:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; So, I think here that you are agreeing with the original point,</FONT>
<BR><FONT SIZE=2>which is that there is no requirement for two versions of ctp,</FONT>
<BR><FONT SIZE=2>but there is a requirement for early and almost late (proactive</FONT>
<BR><FONT SIZE=2>and reactive) ct.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; That there is no requirement simply means that we should not</FONT>
<BR><FONT SIZE=2>embed this concept into the reqs draft. It does not prohibit</FONT>
<BR><FONT SIZE=2>tailoring the ct protocol during the design phase for different</FONT>
<BR><FONT SIZE=2>modes of operation.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Cedric Westphal [<A HREF="mailto:cedric@IPRG.nokia.com">mailto:cedric@IPRG.nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Tuesday, July 10, 2001 2:54 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Pat Calhoun; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Pat Calhoun wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; On Tue, Jul 10, 2001 at 10:25:14AM -0700, Cedric Westphal wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Pat Calhoun wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; On Tue, Jul 10, 2001 at 08:26:29AM -0700, Cedric Westphal wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; This really comes down to the triggers available </FONT>
<BR><FONT SIZE=2>&gt; for CTP, and is not</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; a CTP protocol issue.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; I do not agree with this. Let me give you an example: </FONT>
<BR><FONT SIZE=2>&gt; MN wants to use</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; proactive</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; CT for header compression state relocation. MN moves </FONT>
<BR><FONT SIZE=2>&gt; to new access router.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; If the ctp is same for proactive and reactive, then </FONT>
<BR><FONT SIZE=2>&gt; MN can only _hope_ that</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; the header compression state is in place. So it </FONT>
<BR><FONT SIZE=2>&gt; transmits with a full header,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; and loses</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; some of the benefit of the context transfer.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; If proactive and reactive ct are different (and they </FONT>
<BR><FONT SIZE=2>&gt; don't necessarily have to</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; be very</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; different, consider just an Ack from newAR to MN via </FONT>
<BR><FONT SIZE=2>&gt; oldAR that context is in</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; place, or whatever, this is solution space) then MN </FONT>
<BR><FONT SIZE=2>&gt; can distinguish and use</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; compressed</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; header right away.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; so a bit set in the CTP would inform the receiver that </FONT>
<BR><FONT SIZE=2>&gt; the packet's</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; IP header is compressed? I'm not sure that I follow </FONT>
<BR><FONT SIZE=2>&gt; your example :(</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Well, I did not elaborate the example since, as I said, </FONT>
<BR><FONT SIZE=2>&gt; it is solution space.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; All I am trying to convey is that there is value in </FONT>
<BR><FONT SIZE=2>&gt; knowing before, say, releasing</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; connection</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; to oldAR, that the C is T'ed. And thus there is a </FONT>
<BR><FONT SIZE=2>&gt; difference (at least in the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; requirement) between proactive and reactive.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; The MN can initiate a CTP in proactive or reactive </FONT>
<BR><FONT SIZE=2>&gt; mode, but I still</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; think that the packet format would be identical.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; I agree with that. Packet format should be the same. But </FONT>
<BR><FONT SIZE=2>&gt; is the ctp only a matter of</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; defining a packet format? Or is it a ct protocol?</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; In my little example:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; MN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; oldAR</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; newAR</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; will handoff to new AR--&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; transfer ct----&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;-------Ack, ct</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; received</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; &lt;----------------Ack ct there</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; If MN is still connected to oldAR when the Ack gets back, </FONT>
<BR><FONT SIZE=2>&gt; then it is proactive, and</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; it knows it</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; can use, say compressed header right away.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; If MN is not connected to oldAR when the Ack gets back, </FONT>
<BR><FONT SIZE=2>&gt; then MN knows it has not</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; received</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; it, and by default, it is reactive, and it uses full </FONT>
<BR><FONT SIZE=2>&gt; header with newAR.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; I agree with you that the arrow&nbsp;&nbsp;&nbsp; 'transfer ct----&gt;' </FONT>
<BR><FONT SIZE=2>&gt; should be the same, whether</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; it's proactive or</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; reactive. Now,&nbsp; I am not sure it is the only arrow that is needed.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Good, I think we are making progress.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; So, the main difference above between proactive and reactive is the</FONT>
<BR><FONT SIZE=2>&gt; &gt; presence of the header compression state blob. We couldn't, however,</FONT>
<BR><FONT SIZE=2>&gt; &gt; mandate that particular blobs be present in proactive vs. reactive,</FONT>
<BR><FONT SIZE=2>&gt; &gt; but as we discussed earlier, could require that certain blobs be</FONT>
<BR><FONT SIZE=2>&gt; &gt; defined as high priority, which would be used in the </FONT>
<BR><FONT SIZE=2>&gt; initial CTP message</FONT>
<BR><FONT SIZE=2>&gt; &gt; (in a multi-phasic sense) - the equivalent of proactive.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Pat,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; sorry for using a header compression example, I think it is </FONT>
<BR><FONT SIZE=2>&gt; getting more confusing</FONT>
<BR><FONT SIZE=2>&gt; that anything. The difference between proactive vs. reactive </FONT>
<BR><FONT SIZE=2>&gt; is not one of presence</FONT>
<BR><FONT SIZE=2>&gt; of particular blobs.</FONT>
<BR><FONT SIZE=2>&gt; What you mean here is a _relative_ timing of the different </FONT>
<BR><FONT SIZE=2>&gt; context establishments at</FONT>
<BR><FONT SIZE=2>&gt; new AR, higher priority blobs arriving before lower priority </FONT>
<BR><FONT SIZE=2>&gt; blobs. This is not what</FONT>
<BR><FONT SIZE=2>&gt; proactive vs. reactive is.</FONT>
<BR><FONT SIZE=2>&gt; The way I see proactive, it is an _absolute_ timing of the </FONT>
<BR><FONT SIZE=2>&gt; event with respect to a time</FONT>
<BR><FONT SIZE=2>&gt; reference outside of the context transfer. MN wants context </FONT>
<BR><FONT SIZE=2>&gt; to be in place before</FONT>
<BR><FONT SIZE=2>&gt; MN's packets arrive at newAR, so MN requests proactive ct. MN </FONT>
<BR><FONT SIZE=2>&gt; needs to know whether</FONT>
<BR><FONT SIZE=2>&gt; proactive has succeeded (be it by some acknowledgement, or </FONT>
<BR><FONT SIZE=2>&gt; whatever, solution space,</FONT>
<BR><FONT SIZE=2>&gt; later). If not, then MN can make use of this information (by </FONT>
<BR><FONT SIZE=2>&gt; not getting the</FONT>
<BR><FONT SIZE=2>&gt; acknowledgement,</FONT>
<BR><FONT SIZE=2>&gt; or whatever).</FONT>
<BR><FONT SIZE=2>&gt; If you can do everything, proactive and reactive, with the </FONT>
<BR><FONT SIZE=2>&gt; same protocol, it is fine with</FONT>
<BR><FONT SIZE=2>&gt; me, but</FONT>
<BR><FONT SIZE=2>&gt; this is a requirement phase, and I think you have a solution&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; in mind (and a</FONT>
<BR><FONT SIZE=2>&gt; prioritization of</FONT>
<BR><FONT SIZE=2>&gt; phases is only a solution to the relative ct timing problem).</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cheers,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cedric.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10979.87B9D440--


From owner-seamoby@diameter.org  Tue Jul 10 16:05:40 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19979
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 16:05:37 -0400 (EDT)
Received: (qmail 16546 invoked by alias); 10 Jul 2001 19:53:02 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16540 invoked by uid 200); 10 Jul 2001 19:53:02 -0000
Received: (qmail 16535 invoked from network); 10 Jul 2001 19:53:00 -0000
Received: from softdnserror (HELO lochinvar.ece.neu.edu) (129.10.60.82)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 19:53:00 -0000
Received: from runner.ece.neu.edu (runner.ece.neu.edu [129.10.60.136])
	by lochinvar.ece.neu.edu (8.9.3/8.9.3) with ESMTP id QAA23697;
	Tue, 10 Jul 2001 16:04:55 -0400 (EDT)
Received: from localhost by runner.ece.neu.edu (8.9.3/8.9.3) with ESMTP id QAA01317;
	Tue, 10 Jul 2001 16:02:56 -0400 (EDT)
X-Authentication-Warning: runner.ece.neu.edu: mcdonald owned process doing -bs
Date: Tue, 10 Jul 2001 16:02:56 -0400 (EDT)
From: "A. Bruce McDonald" <mcdonald@ECE.NEU.EDU>
X-Sender: mcdonald@runner
To: "A. Bruce McDonald" <mcdonald@ECE.NEU.EDU>
Subject: [seamoby] Announcement: CFP CNDS Modeling and Simulation Conf 2002 
Message-ID: <Pine.GSO.4.21.0107101557160.1151-100000@runner>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk


                    ANNOUNCEMENT AND CALL FOR PAPERS

			       CNDS'2002

-----------------------------------------------------------------------
	Please Accept Our Sincere Apologies Should you Receive 
                      Multiple Copies of this CFP
-----------------------------------------------------------------------

    
  The Society for Modeling and Simulation International (SCS) presents:

             COMMUNICATION NETWORKS AND DISTRIBUTED SYSTEMS
                   MODELING AND SIMULATION CONFERENCE
                                  2002


                          January 27-31, 2002

                Four Points Sheraton Hotel, Riverwalk North
                           San Antonio, Texas

       Please Visit the Conference Web Site for Additional Information

	          http://www.ece.neu.edu/conf/CNDS/2002/


Part of the 2002 SCS Western Multiconference on Computer Simulation

	The objective of this conference is to serve as a forum for the
exchange of ideas among a talented group of international researchers on
advances in the design and performance analysis of communication networks
and distributed systems.  The conference emphasizes modeling, technical
advances and unique applications in the areas of high speed networking,
wireless communications, multimedia applications, computer architecture
and distributed, parallel and mobile computing systems. The structure of
the conference is designed to facilitate collegiality and continuity of
discussion among the conference speakers and attendees on the topics
covered during the week.

      Paper sessions are designed to promote discussion of concepts and
methodologies based on the presentation of results and innovative 
modeling, simulation or analysis techniques. The conference grew out of 
the need to improve the efficiency and quality of models of increasingly
complex networks and distributed systems. In addition to the technical
sessions, the conference includes an invited keynote speaker, and there
will be vendor presentations and exhibits arranged in conjunction with the
2002 SCS Western Simulation Multiconference (WMC). 

	Original, high-quality technical papers, addressing significant
aspects of the design, modeling, or performance analysis of communication
networks and distributed systems are solicited for review, possible
presentation and subsequent publication in the conference proceedings. 
Papers that include well-conceived or innovative simulation modeling
techniques with strong results and analysis are especially sought.

Papers are solicited from not limited to the following topics:

	* Performance Modeling and Analysis 	
	* Mobile and Nomadic Computing 
	* Distributed and Wireless Multimedia Systems  
	* QoS Support for Wireless Ad Hoc Network Applications
	* Routing and Mobility Management in Wireless Networks
	* Power Control in Wireless Computer Systems
	* Distributed and Intelligent Sensor Networks
	* Wearable Computer Systems		
	* Resource Allocation in High Speed Networks
	* Switch and Processor Architectures for High Speed Routers
	* Advances in Computer Architecture and Memory Systems
        * Network and Parallel Computing
	* Storage Area Networks		
	* Content Based Image Retrieval Systems
	* Real-Time and Mobile Web-Based Computing
	* Reliable Multicast Routing and Group Communications  
	* Network and Application Security and Availability                
	* Web Caching and Switching 
        * Scalable and Reliable Distributed Servers
        * Load Balancing in Distributed Systems 


IMPORTANT DATES:

* The CDNS'02 deadline has been extended from September 15, 2001 to 
  September 21, 2001 in order to match a misprint in a recently distributed 
  WCN'02 brochure. Please make a note of the new date(s). 

September 21, 2001		Paper Submission Deadline.
October   21, 2001		Acceptance Notification.
November  21, 2001		Camera Ready Paper Deadline.


Authors are requested to submit manuscripts electronically to the Program
Chair by 11:00 pm (Eastern Time) of the due date via Anonymous ftp  
directly: ftp.ece.neu.edu:/pub/conf/CNDS/2002/Submissions. Papers can
also be uploaded using the Web Site: www.ece.neu.edu/conf/CNDS/2002/.
*Please check the web site again prior to making your submission as we 
are hoping to install conference management software that will alter 
the procedures and ease the task for everyone.) 
Papers must be in English and submitted files must be in Postscript or PDF
format with all figures and tables included. Files names must be unique
and reflect the name of the primary author, his or her primary
affiliation, the version number of the file and an extension indicating
the file type. Multiple versions may be uploaded; however, only the most
recent will be reviewed. Filenames are not readable once the file transfer
has been completed. Confirmations will be sent to the contact author when
the file has been retrieved and successfully viewed or printed. Only
original unpublished material will be considered for publication.

This year's International TPC is outstanding. Its members represent a
broad spectrum of interrelated interests and technical expertise relevent
to CNDS including performance analysis, simulation, communications
networks, both wired and wireless, mobile computing, computer 
architecture, distributed systems and more. The TPC consists of newcomers
and veterans of CNDS from Universities and Research Labs around the
world. Each member is committed to ensure that all submissions are fully
refereed for accuracy, technical content, and relevance, and to make this
year's conference an exciting International forum for the presentation of
high quality work and the exchange of ideas. Papers should be limited to
20 double-spaced pages (camera-ready versions are limited to 6
single-spaced pages). Authors must include a single page which includes
all the authors' names, titles and affiliations, a paper abstract, list of
top three relevant topics and contact person information (complete
address, email, phone, and fax). Accepted papers will appear in the
Conference's Proceedings to be published by the Society for Computer
Simulation. Instructions for submitting camera ready papers will be sent
to authors following paper acceptance. An award will be presented to the
best paper presented at WMC'02. Authors of top papers will also be
encouraged to submit a follow-on paper to the International Journal in
Computer Simulation. Authors must obtain employer, client, or government
releases prior to submittal of the final manuscript.

Please do not hesitate to contact the Program Chair, Prof. McDonald via
email (mcdonald@ece.neu.edu), or telephone ((617) 373-3028) with any
questions concerning the paper submission and review process, or questions
regarding the relevance of a paper to the conference. 


   General Chair                       Program Chair 

Dr. Taieb F. Znati                 Prof. A. Bruce McDonald
Senior Program Director            Dept. of Electrical and Computer Eng.
National Science Foundation        417 Dana Research Center
ANIR and  			   Northeastern University
Computer Science Department        360 Huntington Avenue
University of Pittsburgh           Boston, MA 15221
Pittsburgh, PA 15260               U.S.A.
U.S.A.      

Phone:  +1(412)624-8417            Phone:  +1(617)328-3028
FAX:    +1(412)624-8854            FAX:    +1(617)328-8970
E_Mail: znati@cs.pitt.edu          E_Mail: mcdonald@ece.neu.edu


Please visit the conference Web Site for up-to-date information and to see
a list of the distinguished  members of the International Technical
Program Commmittee: 

	    http://www.ece.neu.edu/conf/CNDS/2002/

	      
--------------------------------------------
A. Bruce McDonald	f:617.373.8970
Zraket Assistant Prof.	v:617.373.3028
ECE Dept., 417 Dana     mcdonald@ece.neu.edu
360 Huntington Ave.
Northeastern University
Boston, MA 02115
--------------------------------------------
















From owner-seamoby@diameter.org  Tue Jul 10 18:11:27 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26980
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 18:11:27 -0400 (EDT)
Received: (qmail 18106 invoked by alias); 10 Jul 2001 22:00:29 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18100 invoked by uid 200); 10 Jul 2001 22:00:28 -0000
Received: (qmail 18093 invoked by uid 500); 10 Jul 2001 22:00:25 -0000
Date: Tue, 10 Jul 2001 15:00:25 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Cedric Westphal <cedric@IPRG.nokia.com>
Cc: Gary Kenward <gkenward@nortelnetworks.com>,
        "'seamoby'" <seamoby@diameter.org>
Subject: Re: [seamoby] Issue #4: Clear, unambiguous definitions missing
Message-ID: <20010710150025.B10676@charizard.diameter.org>
Mail-Followup-To: Cedric Westphal <cedric@IPRG.nokia.com>,
	Gary Kenward <gkenward@nortelnetworks.com>,
	'seamoby' <seamoby@diameter.org>
References: <9FBD322B7824D511B36900508BF93C9C9F5DBB@zcard031.ca.nortel.com> <3B41EA2B.3D9E377A@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B41EA2B.3D9E377A@iprg.nokia.com>; from cedric@IPRG.nokia.com on Tue, Jul 03, 2001 at 08:52:11AM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

All,

I agree with Cedric that the multi-phasic requirement should use
time sensitive, as opposed to urgent or important. I think this
would guide the implementor in a better direction than having to
determine whether a blob is important or not (chances are, they are
all important).

PatC


From owner-seamoby@diameter.org  Tue Jul 10 18:23:12 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27341
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 18:23:09 -0400 (EDT)
Received: (qmail 18638 invoked by alias); 10 Jul 2001 22:10:50 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18632 invoked by uid 200); 10 Jul 2001 22:10:49 -0000
Received: (qmail 18627 invoked from network); 10 Jul 2001 22:10:48 -0000
Received: from motgate4.mot.com (144.189.100.102)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 22:10:48 -0000
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id PAA11713 for <seamoby@cdma-2000.org>; Tue, 10 Jul 2001 15:21:31 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA12096 for <seamoby@cdma-2000.org>; Tue, 10 Jul 2001 15:14:21 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3LL2KBGT>; Tue, 10 Jul 2001 17:21:31 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E7F@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>, seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Date: Tue, 10 Jul 2001 17:21:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1098E.AB5ADFB0"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1098E.AB5ADFB0
Content-Type: text/plain;
	charset="iso-8859-1"

Since my name was mentioned :) Actually, I think the issue of triggers
IS important for how you define proactive and reactive, especially if the 
definition is based on an starting event for CT, as opposed to based on when
CT ends.
 
I agree that we might not be interested in specifying a specific
L2 signal (since it would be technology independent) but we 
cannot set  CT timing requirements (if that is the goal here) without 
knowing when the CT starts.
 
Madjid

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Wednesday, July 04, 2001 8:35 AM
To: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)



  Just a note to cover what I believe is a possible misinterpretation 
that can be made from John's and Madjid's recent emails. 

  The issue with triggers has nothing to do with "terminology" (yet). 
The issue with triggers has to do with the fact that there are a 
plethora of possible triggers that can be used. If we identify one 
trigger in the requirements, then we need to identify either all, or a 
comprehensive set of examples. This is not "specmanship" - given 
that these triggers control ct, this is one of the most important 
issues to be resolved. 

  I'm still not convinced that it is worthwhile trying to solve it 
in a requirements document. 

Gary 

> -----Original Message----- 
> From: john.loughney@nokia.com [ mailto:john.loughney@nokia.com
<mailto:john.loughney@nokia.com> ] 
> Sent: Wednesday, July 04, 2001 3:14 AM 
> To: mobile-ip@sunroof.eng.sun.com; seamoby@cdma-2000.org 
> Subject: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) 
> 
> 
> Hi James, 
> 
> > In fact, I am preparing just such a draft as we speak. The 
> > intent is to take the material from the BETH draft and from 
> > the FMIPv4 draft and perhaps add something on the link with 
> > Seamoby context transfer. 
> 
> I think this would be extremely worthwhile.  It seems that 
> SeaMoby is currently struggling over terminology about 
> triggers, etc. with respect to handovers.  I'd even suggest 
> that interested parties from both MIP & SeaMoby get together 
> in London to discuss how to move forward.  Perhaps it would 
> be a good thing if MIP & SeaMoby could work together on this 
> issue - in order to assure that the resultant work suits both 
> groups. 
> 
> best regards, 
> John 
> 


------_=_NextPart_001_01C1098E.AB5ADFB0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=550221822-10072001>Since 
my name was mentioned :) Actually, I think the issue of 
triggers</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=550221822-10072001>IS 
important for how you define proactive and reactive, especially if the 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=550221822-10072001>definition is based on an starting event for CT, as 
opposed to based on when</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=550221822-10072001>CT 
ends.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=550221822-10072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=550221822-10072001>I 
agree that we might not be interested in specifying a 
specific</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=550221822-10072001>L2 
signal (since it would be technology independent) but we </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=550221822-10072001>cannot 
set&nbsp; CT timing requirements (if that is the goal here) without 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=550221822-10072001>knowing when the CT starts.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=550221822-10072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=550221822-10072001>Madjid</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, July 04, 2001 
  8:35 AM<BR><B>To:</B> seamoby@cdma-2000.org<BR><B>Subject:</B> RE: [seamoby] 
  L2 API (WAS: Ext. for FMIPv6 - comments)<BR><BR></DIV></FONT>
  <P><FONT size=2>&nbsp; Just a note to cover what I believe is a possible 
  misinterpretation</FONT> <BR><FONT size=2>that can be made from John's and 
  Madjid's recent emails.</FONT> </P>
  <P><FONT size=2>&nbsp; The issue with triggers has nothing to do with 
  "terminology" (yet). </FONT><BR><FONT size=2>The issue with triggers has to do 
  with the fact that there are a </FONT><BR><FONT size=2>plethora of possible 
  triggers that can be used. If we identify one</FONT> <BR><FONT size=2>trigger 
  in the requirements, then we need to identify either all, or a 
  </FONT><BR><FONT size=2>comprehensive set of examples. This is not 
  "specmanship" - given </FONT><BR><FONT size=2>that these triggers control ct, 
  this is one of the most important </FONT><BR><FONT size=2>issues to be 
  resolved.</FONT> </P>
  <P><FONT size=2>&nbsp; I'm still not convinced that it is worthwhile trying to 
  solve it </FONT><BR><FONT size=2>in a requirements document.</FONT> </P>
  <P><FONT size=2>Gary</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: john.loughney@nokia.com [<A 
  href="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Wednesday, July 04, 2001 3:14 AM</FONT> <BR><FONT 
  size=2>&gt; To: mobile-ip@sunroof.eng.sun.com; seamoby@cdma-2000.org</FONT> 
  <BR><FONT size=2>&gt; Subject: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
  comments)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Hi James,</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt; In fact, I am preparing just such a draft as 
  we speak. The </FONT><BR><FONT size=2>&gt; &gt; intent is to take the material 
  from the BETH draft and from </FONT><BR><FONT size=2>&gt; &gt; the FMIPv4 
  draft and perhaps add something on the link with </FONT><BR><FONT size=2>&gt; 
  &gt; Seamoby context transfer.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; I think this would be extremely worthwhile.&nbsp; It seems that 
  </FONT><BR><FONT size=2>&gt; SeaMoby is currently struggling over terminology 
  about</FONT> <BR><FONT size=2>&gt; triggers, etc. with respect to 
  handovers.&nbsp; I'd even suggest</FONT> <BR><FONT size=2>&gt; that interested 
  parties from both MIP &amp; SeaMoby get together</FONT> <BR><FONT size=2>&gt; 
  in London to discuss how to move forward.&nbsp; Perhaps it would 
  </FONT><BR><FONT size=2>&gt; be a good thing if MIP &amp; SeaMoby could work 
  together on this</FONT> <BR><FONT size=2>&gt; issue - in order to assure that 
  the resultant work suits both</FONT> <BR><FONT size=2>&gt; groups.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; best regards,</FONT> 
  <BR><FONT size=2>&gt; John</FONT> <BR><FONT size=2>&gt; 
</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1098E.AB5ADFB0--


From owner-seamoby@diameter.org  Tue Jul 10 18:27:06 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27479
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 18:27:05 -0400 (EDT)
Received: (qmail 18965 invoked by alias); 10 Jul 2001 22:14:13 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18959 invoked by uid 200); 10 Jul 2001 22:14:12 -0000
Received: (qmail 18945 invoked from network); 10 Jul 2001 22:14:09 -0000
Received: from motgate3.mot.com (144.189.100.103)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 22:14:09 -0000
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA18862 for <seamoby@cdma-2000.org>; Tue, 10 Jul 2001 15:17:44 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA06751 for <seamoby@cdma-2000.org>; Tue, 10 Jul 2001 15:24:49 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3LL2KBKH>; Tue, 10 Jul 2001 17:24:49 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E80@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: "'Rajeev Koodli'" <rajeev@iprg.nokia.com>,
        "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
        "'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>
Subject: RE: FW: [seamoby] CT trigger or CT completion? was:  proactive an
	 d re active CT definitions
Date: Tue, 10 Jul 2001 17:24:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

Thanks for the verification, I thought so too.

I was making the point that, we don't need to consider CT 
for cases where L2 changes but AR doesn't. I hope we agree on this.

Madjid

-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: Tuesday, July 10, 2001 8:47 AM
To: Nakhjiri Madjid-MNAKHJI1
Cc: 'Rajeev Koodli'; 'Pat Calhoun'; 'Charles E. Perkins';
'seamoby@cdma-2000.org'
Subject: Re: FW: [seamoby] CT trigger or CT completion? was: proactive
an d re active CT definitions


back from vacation. Sorry for the latency.

On Mon, Jul 02, 2001 at 01:52:25PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote:
> Pat, if I misunderstood the scope of CT, please let me know,
> I thought CT is scoped handle AR-AR only.

well, I am not sure that I know the scope more than you do, but
I don't see a reason to restrict its usage to AR-AR only. An AP
implementor could use our protocol to transfer state as well.

Thanks,

PatC


From owner-seamoby@diameter.org  Tue Jul 10 18:33:24 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27759
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 18:33:23 -0400 (EDT)
Received: (qmail 19598 invoked by alias); 10 Jul 2001 22:22:38 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 19592 invoked by uid 200); 10 Jul 2001 22:22:38 -0000
Received: (qmail 19587 invoked by uid 500); 10 Jul 2001 22:22:36 -0000
Date: Tue, 10 Jul 2001 15:22:36 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: seamoby@cdma-2000.org
Subject: [seamoby] Seamoby Agenda
Message-ID: <20010710152236.C10676@charizard.diameter.org>
Mail-Followup-To: seamoby@cdma-2000.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-seamoby@diameter.org
Precedence: bulk

All,

I am starting to put together the agenda for the London meeting,
and would like to solicit for slots requests. Before you respond, however,
I'd like to remind folks that we do not take scarce session time
to "present" Internet Drafts. It is assumed that everyone has already
read the draft, and the slot is used to discuss items that require 
face-to-face time. BTW, it is permitted to get up and start a discussion
without an associated powerpoint presentation, but again, it must be
within the confines of the charter.

First, an update on the WG documents:

	draft-ietf-seamoby-mm-problem-01.txt
	   This document is no longer a WG document, but the
	   relevant sections that pertain to handoff candidate
	   discovery will be used to form the new Problem Statement
	   ID.

	draft-ietf-seamoby-context-transfer-problem-stat-02.txt
	   This document has recently been submitted and addresses
	   IESG comments.

	draft-ietf-seamoby-paging-requirements-01.txt
	   This document is in the IESG queue.

	draft-ietf-seamoby-ct-reqs-00.txt
	   This is work in progress.

What I have so far on the agenda is:

1. agenda bashing				chair	5 mins
2. update on WG documents			chair	10 mins
3. milestone review				chair	10 mins
4. Context Transfer Requirements discussions	all	90 mins
   This session is to discuss the *open* CT issues. I will moderate
   the discussion, and ensure that we don't fall within ratholes. The
   idea here is to get some closure, not open up cans of worms.
5. Closure/Next Steps				chair	20 mins

Again, please send your agenda requests to me as soon as possible.
As an aside, I will insist on having all of the presentations at least
one week prior to the IETF meeting, and may require changes if I see 
that the topic doesn't follow the above policy.

Thanks,

PatC


From owner-seamoby@diameter.org  Tue Jul 10 18:35:51 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27849
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 18:35:51 -0400 (EDT)
Received: (qmail 20082 invoked by alias); 10 Jul 2001 22:24:41 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20076 invoked by uid 200); 10 Jul 2001 22:24:41 -0000
Received: (qmail 20065 invoked by uid 500); 10 Jul 2001 22:24:38 -0000
Date: Tue, 10 Jul 2001 15:24:38 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        "'Rajeev Koodli'" <rajeev@iprg.nokia.com>,
        "'Charles E. Perkins'" <charliep@iprg.nokia.com>,
        "'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>
Subject: Re: FW: [seamoby] CT trigger or CT completion? was:  proactive an d re active CT definitions
Message-ID: <20010710152438.D10676@charizard.diameter.org>
Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>,
	'Rajeev Koodli' <rajeev@iprg.nokia.com>,
	"'Charles E. Perkins'" <charliep@iprg.nokia.com>,
	"'seamoby@cdma-2000.org'" <seamoby@cdma-2000.org>
References: <35DBB8B7AC89D4118E98009027B1009B017A9E80@IL27EXM10.cig.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B017A9E80@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Tue, Jul 10, 2001 at 05:24:49PM -0500
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Tue, Jul 10, 2001 at 05:24:49PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote:
> Thanks for the verification, I thought so too.
> 
> I was making the point that, we don't need to consider CT 
> for cases where L2 changes but AR doesn't. I hope we agree on this.

Well if the L2 termination is in the same box as the AR, then yes
we do. However, if the L2 (bridge) is a separate entity, I see no
reason why one couldn't make use of CTP to transfer any possible
state. Again, we aren't designing for this case, but shouldn't
specifically restrict it either.

PatC


From owner-seamoby@diameter.org  Tue Jul 10 18:40:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27984
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 18:40:20 -0400 (EDT)
Received: (qmail 20405 invoked by alias); 10 Jul 2001 22:26:25 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20398 invoked by uid 200); 10 Jul 2001 22:26:25 -0000
Received: (qmail 20385 invoked from network); 10 Jul 2001 22:26:23 -0000
Received: from motgate4.mot.com (144.189.100.102)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 22:26:23 -0000
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id PAA16985 for <seamoby@cdma-2000.org>; Tue, 10 Jul 2001 15:37:06 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA01880 for <seamoby@cdma-2000.org>; Tue, 10 Jul 2001 15:37:06 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3LL2KB41>; Tue, 10 Jul 2001 17:37:06 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E81@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
Date: Tue, 10 Jul 2001 17:37:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C10990.D8AD4820"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10990.D8AD4820
Content-Type: text/plain;
	charset="iso-8859-1"

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:gkenward@nortelnetworks.com]
Sent: Tuesday, July 10, 2001 8:53 AM
To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
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: john.loughney@nokia.com [ mailto:john.loughney@nokia.com
<mailto:john.loughney@nokia.com> ] 
> Sent: Tuesday, July 10, 2001 1:59 AM 
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
> 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 
> 


------_=_NextPart_001_01C10990.D8AD4820
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=154203222-10072001>Gary,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>I 
don't think we should remove the reactive/ proactive definitions out 
of</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=154203222-10072001>requirement, unless there is a consensus for removing 
it.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>If we 
nobody can come up with a better definition than the already</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=154203222-10072001>existing one, either we keep it or declare it as an 
open issue.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=154203222-10072001>Personally I liked the definitions that are based on 
the starting event</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>such 
as link establishment better, but I still can live with the exiting 
</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>one 
(packet arrival) for the time being. Removing the whole 
thing</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>is 
throwing a lot of good thoughts away.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>A 
requirement subject to modifications is better than no 
requirement.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=154203222-10072001>Madjid</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, July 10, 2001 
  8:53 AM<BR><B>To:</B> 'john.loughney@nokia.com'; 
  seamoby@cdma-2000.org<BR><B>Subject:</B> RE: [seamoby] L2 API (WAS: Ext. for 
  FMIPv6 - comments)<BR><BR></DIV></FONT>
  <P><FONT size=2>John:</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; I have been contemplating removing the 
  "reactive"/"proactive"</FONT> <BR><FONT size=2>definitions from the 
  requirements also, but I really do hope we</FONT> <BR><FONT size=2>do not lose 
  the concept of starting ct as early as possible. Being</FONT> <BR><FONT 
  size=2>proactive with ct has been a fundamental component to ct since the 
  </FONT><BR><FONT size=2>problem statement draft, and, to me, a critical tool 
  for providing </FONT><BR><FONT size=2>seamless service handover.</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; There are those who, rightfully, have no interest 
  in proactive</FONT> <BR><FONT size=2>ct for their networks. If we lose the 
  requirement, it may be very</FONT> <BR><FONT size=2>difficult for the wg to 
  proceed with a ctp design that supports </FONT><BR><FONT size=2>this 
  mode.</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; I'll wait for your issue to be generated. Some of 
  us are also</FONT> <BR><FONT size=2>struggling with some alterative wording of 
  the definitions</FONT> </P>
  <P><FONT size=2>Gary</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: john.loughney@nokia.com [<A 
  href="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Tuesday, July 10, 2001 1:59 AM</FONT> <BR><FONT 
  size=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org</FONT> 
  <BR><FONT size=2>&gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
  comments)</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; Hi Gary,</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt;&nbsp; I agree, particularly with your 
  definition of ct (although I'm </FONT><BR><FONT size=2>&gt; &gt; not sure 
  where "reductive mode" came from). </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Ooops, I meant that 
  I was in "reductive mode" (trying to</FONT> <BR><FONT size=2>&gt; simplify 
  &amp; get back to the basics).&nbsp; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt; In thinking through the overall discussion, 
  I am realize that the </FONT><BR><FONT size=2>&gt; &gt; big difference between 
  "reactive" and "proactive" is how they are </FONT><BR><FONT size=2>&gt; &gt; 
  triggered. "proactive" assumes that there is a trigger available 
  </FONT><BR><FONT size=2>&gt; &gt; early on that permits some context transfer 
  in advance of an actual </FONT><BR><FONT size=2>&gt; &gt; handover. 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; I agree. My thoughts 
  are that the discussion of reactive and proactive</FONT> <BR><FONT size=2>&gt; 
  (&amp; triggering, etc.) get quite close to protocol design.&nbsp; I 
  think</FONT> <BR><FONT size=2>&gt; that is one reason that the discussion 
  became so heavy on the</FONT> <BR><FONT size=2>&gt; the requirements.</FONT> 
  <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt;&nbsp;&nbsp; I do 
  believe the current wording for proactive is wrong. Now that </FONT><BR><FONT 
  size=2>&gt; &gt; I have had time to contemplate the wording, it does not 
  define what </FONT><BR><FONT size=2>&gt; &gt; I have always believed proactive 
  ct should be about. I'm hoping </FONT><BR><FONT size=2>&gt; &gt; that if we 
  fix that wording, we can move on to the important part </FONT><BR><FONT 
  size=2>&gt; &gt; of designing ctp. </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; My suggestion would be to cut-out of the 
  requirements document the</FONT> <BR><FONT size=2>&gt; discussion about 
  proactive &amp; reactive text.&nbsp; I will try to make an</FONT> <BR><FONT 
  size=2>&gt; issue for this later in the day.</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; thanks,</FONT> <BR><FONT size=2>&gt; John</FONT> 
  <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C10990.D8AD4820--


From owner-seamoby@diameter.org  Tue Jul 10 20:04:02 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00615
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 20:04:01 -0400 (EDT)
Received: (qmail 22064 invoked by alias); 10 Jul 2001 23:53:00 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 22058 invoked by uid 200); 10 Jul 2001 23:52:59 -0000
Received: (qmail 22051 invoked by uid 500); 10 Jul 2001 23:52:57 -0000
Date: Tue, 10 Jul 2001 16:52:57 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'Cedric Westphal'" <cedric@iprg.nokia.com>,
        "'seamoby'" <seamoby@diameter.org>
Subject: Re: [seamoby] RE: Need for support of neither pro nor reactive ct. was: Re: [se amoby] Issue #4: Clear, unambiguous definitions missing
Message-ID: <20010710165257.A22037@charizard.diameter.org>
Mail-Followup-To: Gary Kenward <gkenward@nortelnetworks.com>,
	'Cedric Westphal' <cedric@iprg.nokia.com>,
	'seamoby' <seamoby@diameter.org>
References: <9FBD322B7824D511B36900508BF93C9C9F5DC2@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5DC2@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Wed, Jul 04, 2001 at 09:26:59AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

>   All of us our busy. It is regrettable that you wasted your time
> explaining something which did not need explaining. You are missing
> my point, which is, to be blunt, that proactive/reactive does cover
> the case you are so concerned about, at least as far as I am concerned.
> If you bother to check through the archives you will see that I have
> stated this many times, in many ways.
>  
>   'nuff said. I now agree with Pat. This will take at least a meeting at
> IETF 51 to work out; at least. I may or may not be there. My only
> caution is that exchanging one set of terms for another will likely
> not resolve the real issue, just bury it until someone comes up with
> more detail to argue. I have no great love for the terms "proactive"
> and "reactive", but I am fully convinced that choosing new terminology
> will set us back to January of this year, when Seamoby had the discussion
> of "soft" versus "hard", "make-before-break" versus "break-before-make".
>  
>   As I tried to indicate in my previous posting, if you believe your case
> needs
> emphasis, then let's work it into the wording of the current draft. Until
> some
> clearly superior terminology arises, let's work with what we have.

Well, I hope that we don't end up just exchanging terminology. I is
obvious from the discussions on the list that this is a difficult issue
to resolve in the list, so I am glad that you agree that a face to face
is the best way.

I do want to enforce the fact that whatever we discuss at the meeting,
we still need concensus on the list. 

PatC


From owner-seamoby@diameter.org  Tue Jul 10 20:06:19 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00739
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 20:06:18 -0400 (EDT)
Received: (qmail 22131 invoked by alias); 10 Jul 2001 23:53:10 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 22124 invoked by uid 200); 10 Jul 2001 23:53:10 -0000
Received: (qmail 22106 invoked from network); 10 Jul 2001 23:53:06 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 10 Jul 2001 23:53:06 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id RAA19855;
	Tue, 10 Jul 2001 17:03:19 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6B03I128528;
	Tue, 10 Jul 2001 17:03:18 -0700
X-mProtect:  Tue, 10 Jul 2001 17:03:18 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdbmaIwa; Tue, 10 Jul 2001 17:03:17 PDT
Message-ID: <3B4B97C5.5446FEA8@iprg.nokia.com>
Date: Tue, 10 Jul 2001 17:03:17 -0700
From: Rajeev Koodli <rajeev@IPRG.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf <james.kempf@sun.com>
CC: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org,
        charliep@IPRG.nokia.com
Subject: [seamoby] Re: Extensions to FMIPv6
References: <5.0.0.25.0.20010706220851.01f18030@localhost>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello James,

I wonder if you had a look at our CT draft:
draft-koodli-seamoby-ctv6-00.txt..

We don't have discussion about L2 triggers in that draft, but,
definitely context transfers and handovers. Indeed, we describe how to
do context transfers with FMIPv6. Our approach clearly separates what a
feature context is from the message in which it is carried so that one
could use them in appropriate messages, including HI and HAck. We plan
to submit a revised version for London IETF.

Regards,

-Rajeev


James Kempf wrote:

> John,
>
> (Folks, sorry for the cross posting, please try to respond on
> one or the other list unless the topic affects both...)
>
> There is a draft in preparation with people from both Seamoby
> and MIP on the author list. These are people with whom
> I have talked and who have expressed interest in working on such a
> draft over the last year. The draft has a section on L2 triggers
> that came out of the MIP fast handoff work, then a section
> that describes connections with Seamoby context transfer.
> I expect we will have it complete by next Fri.'s 00 deadline.
>
> We have already talked to the MIP WG chairs about getting
> time on the agenda to discuss the draft, what I'd like
> to suggest is that we do the same for Seamoby. That
> will give both WGs the opportunity to review and comment
> on the draft. I will talk with Pat about that when he gets
> back from vacation.
>
>                  jak
>
> At 10:13 AM 7/4/01 +0300, john.loughney@nokia.com wrote:
> >Hi James,
> >
> > > In fact, I am preparing just such a draft as we speak. The
> > > intent is to take the material from the BETH draft and from
> > > the FMIPv4 draft and perhaps add something on the link with
> > > Seamoby context transfer.
> >
> >I think this would be extremely worthwhile.  It seems that
> >SeaMoby is currently struggling over terminology about
> >triggers, etc. with respect to handovers.  I'd even suggest
> >that interested parties from both MIP & SeaMoby get together
> >in London to discuss how to move forward.  Perhaps it would
> >be a good thing if MIP & SeaMoby could work together on this
> >issue - in order to assure that the resultant work suits both
> >groups.
> >
> >best regards,
> >John



From owner-seamoby@diameter.org  Tue Jul 10 20:08:47 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00790
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 20:08:47 -0400 (EDT)
Received: (qmail 22377 invoked by alias); 10 Jul 2001 23:54:08 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 22368 invoked by uid 200); 10 Jul 2001 23:54:08 -0000
Received: (qmail 22357 invoked by uid 500); 10 Jul 2001 23:54:05 -0000
Date: Tue, 10 Jul 2001 16:54:05 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Cedric Westphal <cedric@IPRG.nokia.com>
Cc: Gary Kenward <gkenward@nortelnetworks.com>,
        "'seamoby'" <seamoby@diameter.org>
Subject: Re: [seamoby] RE: Need for support of neither pro nor reactive ct. was: Re: [se amoby] Issue #4: Clear, unambiguous definitions missing
Message-ID: <20010710165405.B22037@charizard.diameter.org>
Mail-Followup-To: Cedric Westphal <cedric@IPRG.nokia.com>,
	Gary Kenward <gkenward@nortelnetworks.com>,
	'seamoby' <seamoby@diameter.org>
References: <9FBD322B7824D511B36900508BF93C9C9F5DC2@zcard031.ca.nortel.com> <3B433458.8BFE4345@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B433458.8BFE4345@iprg.nokia.com>; from cedric@IPRG.nokia.com on Wed, Jul 04, 2001 at 08:20:56AM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

> Meeting in
> London
> ain't gonna happen, but I'll take up your offer and try to work it in
> the wording.

Do you mean that a meeting will not solve the issue, or that you cannot
make the meeting?

PatC


From owner-seamoby@diameter.org  Tue Jul 10 20:13:23 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA00938
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 20:13:21 -0400 (EDT)
Received: (qmail 22858 invoked by alias); 10 Jul 2001 23:56:45 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 22851 invoked by uid 200); 10 Jul 2001 23:56:44 -0000
Received: (qmail 22842 invoked by uid 500); 10 Jul 2001 23:56:42 -0000
Date: Tue, 10 Jul 2001 16:56:42 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: "'Cedric Westphal'" <cedric@IPRG.nokia.com>,
        Gary Kenward <gkenward@nortelnetworks.com>,
        "'seamoby'" <seamoby@diameter.org>
Subject: Re: [seamoby] RE: Need for support of neither pro nor reactive ct . was: Re: [se amoby] Issue #4: Clear, unambiguous definitions missing
Message-ID: <20010710165642.C22037@charizard.diameter.org>
Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
	'Cedric Westphal' <cedric@IPRG.nokia.com>,
	Gary Kenward <gkenward@nortelnetworks.com>,
	'seamoby' <seamoby@diameter.org>
References: <35DBB8B7AC89D4118E98009027B1009B017A9E6B@IL27EXM10.cig.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B017A9E6B@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Mon, Jul 09, 2001 at 12:41:18PM -0500
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA00938

On Mon, Jul 09, 2001 at 12:41:18PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote:
> Why isn't the meeting in London gonna happen? 
> I hope the mention of Utah is just the marriage "joke", I don't want to see the requirement
> work  drag on to Utah, unless we are ready to pack to another projects!!!

Have no fear... I don't have plans to keep this going on forever. We
also have an interim on our milestones, and I plan to use it should
we need it.

PatC
> 
> -----Original Message-----
> From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> Sent: Wednesday, July 04, 2001 10:21 AM
> To: Gary Kenward
> Cc: 'seamoby'
> Subject: Re: [seamoby] RE: Need for support of neither pro nor reactive ct. was: Re: [se amoby] Issue #4: Clear, unambiguous definitions missing
> 
> 
> Gary, 
> 
> here again you tell me I want to scrap the proactive/reactive terms. How 
> many times do I have to tell you I like the definitions, I love proactive CT, 
> I love reactive CT, I want to marry them in Utah and have a nice menage 
> a trois (plus c'est LA meme chose, by the way). 
> What's missing it the little kiddie of proactive and reactive, but you are 
> right, there is no point continuing this discussion this way. Meeting in London 
> ain't gonna happen, but I'll take up your offer and try to work it in 
> the wording. 
> Cheers, 
> 
> 
> Cedric. 
> 
> 
> Gary Kenward wrote: 
> 
> 
>  Cedric:  All of us our busy. It is regrettable that you wasted your timeexplaining something which did not need explaining. You are missingmy point, which is, to be blunt, that proactive/reactive does coverthe case you are so concerned about, at least as far as I am concerned.If you bother to check through the archives you will see that I havestated this many times, in many ways.  'nuff said. I now agree with Pat. This will take at least a meeting atIETF 51 to work out; at least. I may or may not be there. My onlycaution is that exchanging one set of terms for another will likelynot resolve the real issue, just bury it until someone comes up withmore detail to argue. I have no great love for the terms "proactive"and "reactive", but I am fully convinced that choosing new terminologywill set us back to January of this year, when Seamoby had the discussionof "soft" versus "hard", "make-before-break" versus "break-before-make".  As I tried to indicate in my previous posting, if you believe your case needsemphasis, then let's work it into the wording of the current draft. Until someclearly superior terminology arises, let's work with what we have. GaryPlus ca change, plus c'est le même chose. 
> 
> -----Original Message----- 
> From: Cedric Westphal [ mailto:cedric@iprg.nokia.com <mailto:cedric@iprg.nokia.com> ] 
> Sent: Wednesday, July 04, 2001 3:24 AM 
> To: Kenward, Gary [WDLN2:AN10:EXCH] 
> Cc: 'seamoby' 
> Subject: Need for support of neither pro nor reactive ct. was: Re: [seamoby] Issue #4: Clear, unambiguous definitions missing 
>  
> Gary: 
> 
> I read your reply, and I have the feeling that you are trying to convince me that 
> proactive and reactive cts are indeed required. I think you are missing my point. 
> First, for the record: I an convinced both proactive and reactive ct are required, 
> and the definition proposed in this issue #4 are satisfying in this respect. They 
> are necessary. Agreed. They are not sufficient. 
> I am not going to comment point by point, I don't have time for this, but sum up: 
> -in a previous mail, you said Rajeev's definitions (that you attributed to Pat) were 
> good for you. 
> -they are good definition for proactive and reactive. They do not consider a mixed situation, 
> initiated prior to arrival and completed after. 
> -the draft mentions the support of only proactive or reactive. The draft as well prohibits 
> a mixed situation. A proactive ct that completes after whatever event is a failed proactive ct. 
> It is a proactive that turns into a reactive (or should a fresh reactive ct be initiated if the proactive 
> ct does not completes before the event, not so clear in the draft). There was not much 
> point to comment before hand, since, as you say, the draft is ambiguous, and could be read any way. 
> But since the clarification issue has been raised, we should address its consequences. 
> 
> 
> Please consider the situation where MN at some point in the future  will go from oldAR to 
> some identified newAR. I have this context that I want to transfer. However, it is of no critical value 
> to the MN at newAR. I have the choice of: (a) proactive: I start transfering now, and pray it 
> is established at newAR before (draft quote: 'it is required to forward the first packet arrival 
> in the MN's traffic', new definition quote: 'the arrival of MN's packet at target AR). (b) reactive: 
> I wait (new definition quote: 'subsequent to the arrival of MN's packet at target AR) until 
> (draft mentions: 'initiation of a handover or soon after initiation'). 
> Please explain to me why, since I have no critical deadline, I should still make a choice between 
> (a) or (b), that is, to simplify (a) ensure that all my context is transfered before handoff, or 
> (b) wait until I handoff to transfer. Where is (c): I take a leisurely transfer around the handoff, 
> I start before, but take it easy, dude, whenever I get there is when I get there. 
> You might see this as a terminology issue, (what do you call (c) since it is not proactive nor reactive). 
> I think it is more a requirement issue. If the requirement draft specifies (a) and (b), does not 
> mention any other possibility, explains that if (a) fails, then use (b) as the only choice of combined/ 
> mixed/soft ct, then it seems to imply that it excludes (c). 
> I agree with (a) MUST be supported, (b) MUST be supported, tell me why (c) SHOULD NOT 
> be supported as a requirement? 
> Thanks, 
> 
> 
> Cedric. 
>   
> 
> 
>  
> 


From owner-seamoby@diameter.org  Tue Jul 10 21:12:47 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02344
	for <seamoby-archive@odin.ietf.org>; Tue, 10 Jul 2001 21:12:46 -0400 (EDT)
Received: (qmail 24197 invoked by alias); 11 Jul 2001 01:02:01 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 24191 invoked by uid 200); 11 Jul 2001 01:02:01 -0000
Received: (qmail 24184 invoked by uid 500); 11 Jul 2001 01:01:59 -0000
Date: Tue, 10 Jul 2001 18:01:59 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: "'Gary Kenward'" <gkenward@nortelnetworks.com>, seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-  Phase CT
Message-ID: <20010710180159.C24010@charizard.diameter.org>
Mail-Followup-To: Phillip Neumiller <PNeumiller@MeshNetworks.com>,
	'Gary Kenward' <gkenward@nortelnetworks.com>, seamoby@cdma-2000.org
References: <0DF9FBC42474A24CA50F7A27FB08E048445576@meshpdc.meshnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E048445576@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Tue, Jul 03, 2001 at 09:57:59AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Tue, Jul 03, 2001 at 09:57:59AM -0400, Phillip Neumiller wrote:
> I guess I have come full circle on this one Gary.  I don't think its
> a sin to build MIP friendly stuff into CT, in fact it is desirable at this
> point, especially for FMIPv6++ which looks to be a great improvement.
> Until there ARE other mobility protocols in the IETF or somebody 
> can point me to some other one they are going to use, it seems
> quite illogical to NOT support MIP whole heartedly.

Glad to hear you like FMIPv6++, but I still don't see much of a
benefit in combining CT within the MIP message.

> I do agree that MIP has problems.  With some patience and diligence
> these things will be worked out over time.  With this being said,
> and the L2 trigger work going on in FMIP, it also seems logical
> to have a L2 trigger that is used by both MIP for handover and
> SeaMoby for CT.  The next step is combine the events to optimize
> the design IMHO.

I agree that combining events is a good thing, but that doesn't
necessarily require combining messages within a single packet.

PatC


From owner-seamoby@diameter.org  Wed Jul 11 03:22:09 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27051
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 03:22:09 -0400 (EDT)
Received: (qmail 25440 invoked by alias); 11 Jul 2001 07:11:22 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 25434 invoked by uid 200); 11 Jul 2001 07:11:21 -0000
Received: (qmail 25425 invoked from network); 11 Jul 2001 07:11:19 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 07:11:19 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA11482;
	Wed, 11 Jul 2001 00:21:34 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6B7LYY07424;
	Wed, 11 Jul 2001 00:21:34 -0700
X-mProtect:  Wed, 11 Jul 2001 00:21:34 -0700 Nokia Silicon Valley Messaging Protection
Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdboH93e; Wed, 11 Jul 2001 00:21:32 PDT
Message-ID: <3B4BFE74.2AF93D4@iprg.nokia.com>
Date: Wed, 11 Jul 2001 00:21:24 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>, seamoby@diameter.org
Subject: Re: [seamoby] RE: Need for support of neither pro nor reactive ct. was: 
 Re: [se amoby] Issue #4: Clear, unambiguous definitions missing
References: <9FBD322B7824D511B36900508BF93C9C9F5DC2@zcard031.ca.nortel.com> <3B433458.8BFE4345@iprg.nokia.com> <20010710165405.B22037@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

I don't think I'll be able to be in London. A meeting can only help the
issues forward. As far as I am concerned, my only way to provide any
input is the mailing list.

Cedric.

Pat Calhoun wrote:

> > Meeting in
> > London
> > ain't gonna happen, but I'll take up your offer and try to work it in
> > the wording.
>
> Do you mean that a meeting will not solve the issue, or that you cannot
> make the meeting?
>
> PatC



From owner-seamoby@diameter.org  Wed Jul 11 03:46:00 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA27402
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 03:45:50 -0400 (EDT)
Received: (qmail 26007 invoked by alias); 11 Jul 2001 07:31:16 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26001 invoked by uid 200); 11 Jul 2001 07:31:16 -0000
Received: (qmail 25995 invoked from network); 11 Jul 2001 07:31:14 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 07:31:14 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA12083;
	Wed, 11 Jul 2001 00:41:26 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6B7fQi14510;
	Wed, 11 Jul 2001 00:41:26 -0700
X-mProtect:  Wed, 11 Jul 2001 00:41:26 -0700 Nokia Silicon Valley Messaging Protection
Received: from hed040-193.research.nokia.com (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd1mtU0F; Wed, 11 Jul 2001 00:41:22 PDT
Message-ID: <3B4C0317.38C72CFA@iprg.nokia.com>
Date: Wed, 11 Jul 2001 00:41:12 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Gary Kenward <gkenward@nortelnetworks.com>
CC: Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
References: <9FBD322B7824D511B36900508BF93C9C9F5E0C@zcard031.ca.nortel.com>
Content-Type: multipart/alternative;
 boundary="------------B6B619FDBA55FF9BB12616DE"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------B6B619FDBA55FF9BB12616DE
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Gary Kenward wrote:

>
>
> Cedric:
>
>   So, I think here that you are agreeing with the original point,
> which is that there is no requirement for two versions of ctp,
> but there is a requirement for early and almost late (proactive
> and reactive) ct.

Gary,

I think we agree, but I want to rephrase it just to make sure I
understand.
First, I lost track of the original point you mention. Also, I agree
that
the requirement is not on 'versions of ctp', but on the 'proactive' and
'reactive' ct. How these different requirements on 'proactive' and
'reactive'
play out when designing a protocol that satisfies these requirements is
a design issue.

>
>
>   That there is no requirement simply means that we should not
> embed this concept into the reqs draft. It does not prohibit
> tailoring the ct protocol during the design phase for different
> modes of operation.

Then again, I think I agree, but just for clarity: I don't think the
concept of
different versions of ctp should be embedded in the draft. I do think
the
requirement on proactive and reactive should. I agree with you that
these requirements can be satisfied by different modes of operation of
the
ctp.

Here is the executive summary. Gary: yes.
Cheers,

C.

>
>
> Gary
>
> > -----Original Message-----
> > From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
> > Sent: Tuesday, July 10, 2001 2:54 PM
> > To: Pat Calhoun; seamoby@cdma-2000.org
> > Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> >
> >
> >
> >
> > Pat Calhoun wrote:
> >
> > > On Tue, Jul 10, 2001 at 10:25:14AM -0700, Cedric Westphal wrote:
> > > >
> > > >
> > > > Pat Calhoun wrote:
> > > >
> > > > > On Tue, Jul 10, 2001 at 08:26:29AM -0700, Cedric Westphal
> wrote:
> > > > > > > This really comes down to the triggers available
> > for CTP, and is not
> > > > > > > a CTP protocol issue.
> > > > > > I do not agree with this. Let me give you an example:
> > MN wants to use
> > > > > > proactive
> > > > > > CT for header compression state relocation. MN moves
> > to new access router.
> > > > > > If the ctp is same for proactive and reactive, then
> > MN can only _hope_ that
> > > > > > the header compression state is in place. So it
> > transmits with a full header,
> > > > > > and loses
> > > > > > some of the benefit of the context transfer.
> > > > > > If proactive and reactive ct are different (and they
> > don't necessarily have to
> > > > > > be very
> > > > > > different, consider just an Ack from newAR to MN via
> > oldAR that context is in
> > > > > > place, or whatever, this is solution space) then MN
> > can distinguish and use
> > > > > > compressed
> > > > > > header right away.
> > > > >
> > > > > so a bit set in the CTP would inform the receiver that
> > the packet's
> > > > > IP header is compressed? I'm not sure that I follow
> > your example :(
> > > >
> > > > Well, I did not elaborate the example since, as I said,
> > it is solution space.
> > > > All I am trying to convey is that there is value in
> > knowing before, say, releasing
> > > > connection
> > > > to oldAR, that the C is T'ed. And thus there is a
> > difference (at least in the
> > > > requirement) between proactive and reactive.
> > > >
> > > > >
> > > > >
> > > > > The MN can initiate a CTP in proactive or reactive
> > mode, but I still
> > > > > think that the packet format would be identical.
> > > >
> > > > I agree with that. Packet format should be the same. But
> > is the ctp only a matter of
> > > > defining a packet format? Or is it a ct protocol?
> > > > In my little example:
> > > > MN                                            oldAR
> > > > newAR
> > > >     will handoff to new AR-->
> > transfer ct---->
> > > >
> >        <-------Ack, ct
> > > > received
> > > >     <----------------Ack ct there
> > > >
> > > > If MN is still connected to oldAR when the Ack gets back,
> > then it is proactive, and
> > > > it knows it
> > > > can use, say compressed header right away.
> > > > If MN is not connected to oldAR when the Ack gets back,
> > then MN knows it has not
> > > > received
> > > > it, and by default, it is reactive, and it uses full
> > header with newAR.
> > > >
> > > > I agree with you that the arrow    'transfer ct---->'
> > should be the same, whether
> > > > it's proactive or
> > > > reactive. Now,  I am not sure it is the only arrow that is
> needed.
> > >
> > > Good, I think we are making progress.
> > >
> > > So, the main difference above between proactive and reactive is
> the
> > > presence of the header compression state blob. We couldn't,
> however,
> > > mandate that particular blobs be present in proactive vs.
> reactive,
> > > but as we discussed earlier, could require that certain blobs be
> > > defined as high priority, which would be used in the
> > initial CTP message
> > > (in a multi-phasic sense) - the equivalent of proactive.
> > >
> > > PatC
> >
> > Pat,
> >
> > sorry for using a header compression example, I think it is
> > getting more confusing
> > that anything. The difference between proactive vs. reactive
> > is not one of presence
> > of particular blobs.
> > What you mean here is a _relative_ timing of the different
> > context establishments at
> > new AR, higher priority blobs arriving before lower priority
> > blobs. This is not what
> > proactive vs. reactive is.
> > The way I see proactive, it is an _absolute_ timing of the
> > event with respect to a time
> > reference outside of the context transfer. MN wants context
> > to be in place before
> > MN's packets arrive at newAR, so MN requests proactive ct. MN
> > needs to know whether
> > proactive has succeeded (be it by some acknowledgement, or
> > whatever, solution space,
> > later). If not, then MN can make use of this information (by
> > not getting the
> > acknowledgement,
> > or whatever).
> > If you can do everything, proactive and reactive, with the
> > same protocol, it is fine with
> > me, but
> > this is a requirement phase, and I think you have a solution
> > in mind (and a
> > prioritization of
> > phases is only a solution to the relative ct timing problem).
> >
> > Cheers,
> >
> > Cedric.
> >
> >

--------------B6B619FDBA55FF9BB12616DE
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Gary Kenward wrote:
<blockquote TYPE=CITE>&nbsp;
<p><font size=-1>Cedric:</font>
<p><font size=-1>&nbsp; So, I think here that you are agreeing with the
original point,</font>
<br><font size=-1>which is that there is no requirement for two versions
of ctp,</font>
<br><font size=-1>but there is a requirement for early and almost late
(proactive</font>
<br><font size=-1>and reactive) ct.</font></blockquote>
Gary,
<p>I think we agree, but I want to rephrase it just to make sure I
<br>understand.
<br>First, I lost track of the original point you mention. Also, I agree
that
<br>the requirement is not on 'versions of ctp', but on the 'proactive'
and
<br>'reactive' ct. How these different requirements on 'proactive' and
'reactive'
<br>play out when designing a protocol that satisfies these requirements
is
<br>a design issue.
<blockquote TYPE=CITE><font size=-1></font>&nbsp;
<p><font size=-1>&nbsp; That there is no requirement simply means that
we should not</font>
<br><font size=-1>embed this concept into the reqs draft. It does not prohibit</font>
<br><font size=-1>tailoring the ct protocol during the design phase for
different</font>
<br><font size=-1>modes of operation.</font></blockquote>
Then again, I think I agree, but just for clarity: I don't think the concept
of
<br>different versions of ctp should be embedded in the draft. I do think
the
<br>requirement on proactive and reactive should. I agree with you that
<br>these requirements can be satisfied by different modes of operation
of the
<br>ctp.
<p>Here is the executive summary. Gary: yes.
<br>Cheers,
<p>C.
<blockquote TYPE=CITE><font size=-1></font>&nbsp;
<p><font size=-1>Gary</font>
<p><font size=-1>> -----Original Message-----</font>
<br><font size=-1>> From: Cedric Westphal [<a href="mailto:cedric@IPRG.nokia.com">mailto:cedric@IPRG.nokia.com</a>]</font>
<br><font size=-1>> Sent: Tuesday, July 10, 2001 2:54 PM</font>
<br><font size=-1>> To: Pat Calhoun; seamoby@cdma-2000.org</font>
<br><font size=-1>> Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6
- comments)</font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>></font>
<br><font size=-1>> Pat Calhoun wrote:</font>
<br><font size=-1>></font>
<br><font size=-1>> > On Tue, Jul 10, 2001 at 10:25:14AM -0700, Cedric
Westphal wrote:</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > Pat Calhoun wrote:</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > > On Tue, Jul 10, 2001 at 08:26:29AM -0700, Cedric
Westphal wrote:</font>
<br><font size=-1>> > > > > > This really comes down to the triggers available</font>
<br><font size=-1>> for CTP, and is not</font>
<br><font size=-1>> > > > > > a CTP protocol issue.</font>
<br><font size=-1>> > > > > I do not agree with this. Let me give you an
example:</font>
<br><font size=-1>> MN wants to use</font>
<br><font size=-1>> > > > > proactive</font>
<br><font size=-1>> > > > > CT for header compression state relocation.
MN moves</font>
<br><font size=-1>> to new access router.</font>
<br><font size=-1>> > > > > If the ctp is same for proactive and reactive,
then</font>
<br><font size=-1>> MN can only _hope_ that</font>
<br><font size=-1>> > > > > the header compression state is in place. So
it</font>
<br><font size=-1>> transmits with a full header,</font>
<br><font size=-1>> > > > > and loses</font>
<br><font size=-1>> > > > > some of the benefit of the context transfer.</font>
<br><font size=-1>> > > > > If proactive and reactive ct are different
(and they</font>
<br><font size=-1>> don't necessarily have to</font>
<br><font size=-1>> > > > > be very</font>
<br><font size=-1>> > > > > different, consider just an Ack from newAR
to MN via</font>
<br><font size=-1>> oldAR that context is in</font>
<br><font size=-1>> > > > > place, or whatever, this is solution space)
then MN</font>
<br><font size=-1>> can distinguish and use</font>
<br><font size=-1>> > > > > compressed</font>
<br><font size=-1>> > > > > header right away.</font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > so a bit set in the CTP would inform the receiver
that</font>
<br><font size=-1>> the packet's</font>
<br><font size=-1>> > > > IP header is compressed? I'm not sure that I
follow</font>
<br><font size=-1>> your example :(</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > Well, I did not elaborate the example since, as
I said,</font>
<br><font size=-1>> it is solution space.</font>
<br><font size=-1>> > > All I am trying to convey is that there is value
in</font>
<br><font size=-1>> knowing before, say, releasing</font>
<br><font size=-1>> > > connection</font>
<br><font size=-1>> > > to oldAR, that the C is T'ed. And thus there is
a</font>
<br><font size=-1>> difference (at least in the</font>
<br><font size=-1>> > > requirement) between proactive and reactive.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > ></font>
<br><font size=-1>> > > > The MN can initiate a CTP in proactive or reactive</font>
<br><font size=-1>> mode, but I still</font>
<br><font size=-1>> > > > think that the packet format would be identical.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > I agree with that. Packet format should be the
same. But</font>
<br><font size=-1>> is the ctp only a matter of</font>
<br><font size=-1>> > > defining a packet format? Or is it a ct protocol?</font>
<br><font size=-1>> > > In my little example:</font>
<br><font size=-1>> > > MN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
oldAR</font>
<br><font size=-1>> > > newAR</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp; will handoff to new AR--></font>
<br><font size=-1>> transfer ct----></font>
<br><font size=-1>> > ></font>
<br><font size=-1>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &lt;-------Ack,
ct</font>
<br><font size=-1>> > > received</font>
<br><font size=-1>> > >&nbsp;&nbsp;&nbsp;&nbsp; &lt;----------------Ack
ct there</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > If MN is still connected to oldAR when the Ack
gets back,</font>
<br><font size=-1>> then it is proactive, and</font>
<br><font size=-1>> > > it knows it</font>
<br><font size=-1>> > > can use, say compressed header right away.</font>
<br><font size=-1>> > > If MN is not connected to oldAR when the Ack gets
back,</font>
<br><font size=-1>> then MN knows it has not</font>
<br><font size=-1>> > > received</font>
<br><font size=-1>> > > it, and by default, it is reactive, and it uses
full</font>
<br><font size=-1>> header with newAR.</font>
<br><font size=-1>> > ></font>
<br><font size=-1>> > > I agree with you that the arrow&nbsp;&nbsp;&nbsp;
'transfer ct---->'</font>
<br><font size=-1>> should be the same, whether</font>
<br><font size=-1>> > > it's proactive or</font>
<br><font size=-1>> > > reactive. Now,&nbsp; I am not sure it is the only
arrow that is needed.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > Good, I think we are making progress.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > So, the main difference above between proactive and
reactive is the</font>
<br><font size=-1>> > presence of the header compression state blob. We
couldn't, however,</font>
<br><font size=-1>> > mandate that particular blobs be present in proactive
vs. reactive,</font>
<br><font size=-1>> > but as we discussed earlier, could require that certain
blobs be</font>
<br><font size=-1>> > defined as high priority, which would be used in
the</font>
<br><font size=-1>> initial CTP message</font>
<br><font size=-1>> > (in a multi-phasic sense) - the equivalent of proactive.</font>
<br><font size=-1>> ></font>
<br><font size=-1>> > PatC</font>
<br><font size=-1>></font>
<br><font size=-1>> Pat,</font>
<br><font size=-1>></font>
<br><font size=-1>> sorry for using a header compression example, I think
it is</font>
<br><font size=-1>> getting more confusing</font>
<br><font size=-1>> that anything. The difference between proactive vs.
reactive</font>
<br><font size=-1>> is not one of presence</font>
<br><font size=-1>> of particular blobs.</font>
<br><font size=-1>> What you mean here is a _relative_ timing of the different</font>
<br><font size=-1>> context establishments at</font>
<br><font size=-1>> new AR, higher priority blobs arriving before lower
priority</font>
<br><font size=-1>> blobs. This is not what</font>
<br><font size=-1>> proactive vs. reactive is.</font>
<br><font size=-1>> The way I see proactive, it is an _absolute_ timing
of the</font>
<br><font size=-1>> event with respect to a time</font>
<br><font size=-1>> reference outside of the context transfer. MN wants
context</font>
<br><font size=-1>> to be in place before</font>
<br><font size=-1>> MN's packets arrive at newAR, so MN requests proactive
ct. MN</font>
<br><font size=-1>> needs to know whether</font>
<br><font size=-1>> proactive has succeeded (be it by some acknowledgement,
or</font>
<br><font size=-1>> whatever, solution space,</font>
<br><font size=-1>> later). If not, then MN can make use of this information
(by</font>
<br><font size=-1>> not getting the</font>
<br><font size=-1>> acknowledgement,</font>
<br><font size=-1>> or whatever).</font>
<br><font size=-1>> If you can do everything, proactive and reactive, with
the</font>
<br><font size=-1>> same protocol, it is fine with</font>
<br><font size=-1>> me, but</font>
<br><font size=-1>> this is a requirement phase, and I think you have a
solution</font>
<br><font size=-1>> in mind (and a</font>
<br><font size=-1>> prioritization of</font>
<br><font size=-1>> phases is only a solution to the relative ct timing
problem).</font>
<br><font size=-1>></font>
<br><font size=-1>> Cheers,</font>
<br><font size=-1>></font>
<br><font size=-1>> Cedric.</font>
<br><font size=-1>></font>
<br><font size=-1>></font></blockquote>
</html>

--------------B6B619FDBA55FF9BB12616DE--



From owner-seamoby@diameter.org  Wed Jul 11 09:58:37 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03614
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 09:58:37 -0400 (EDT)
Received: (qmail 27582 invoked by alias); 11 Jul 2001 13:47:42 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27576 invoked by uid 200); 11 Jul 2001 13:47:41 -0000
Received: (qmail 27568 invoked from network); 11 Jul 2001 13:47:39 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 13:47:39 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1KNF5>; Wed, 11 Jul 2001 09:57:48 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E04844558E@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: "'Gary Kenward'" <gkenward@nortelnetworks.com>, seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
	 lti-  Phase CT
Date: Wed, 11 Jul 2001 09:57:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

> Glad to hear you like FMIPv6++, but I still don't see much of a
> benefit in combining CT within the MIP message.

I have not heard one technical reason why NOT.  This is just YOUR
opinion Pat.  In fact I DONT like your poly-phasic idea and I have
stated technical reasons why.  Why don't you give me a "technical"
reason why rather than "I don't see much of a benefit" stuff?

BTW, I have not seen any real support for your polyphasic CT on
the list but it remains a requirement in your mind for some reason.

Thanks,

Phil


From owner-seamoby@diameter.org  Wed Jul 11 10:20:16 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04368
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 10:20:15 -0400 (EDT)
Received: (qmail 28193 invoked by alias); 11 Jul 2001 14:09:28 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28187 invoked by uid 200); 11 Jul 2001 14:09:27 -0000
Received: (qmail 28178 invoked by uid 500); 11 Jul 2001 14:09:26 -0000
Date: Wed, 11 Jul 2001 07:09:26 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Cedric Westphal <cedric@IPRG.nokia.com>
Cc: Pat Calhoun <pcalhoun@diameter.org>, seamoby@diameter.org
Subject: Re: [seamoby] RE: Need for support of neither pro nor reactive ct. was: Re: [se amoby] Issue #4: Clear, unambiguous definitions missing
Message-ID: <20010711070926.I27470@charizard.diameter.org>
Mail-Followup-To: Cedric Westphal <cedric@IPRG.nokia.com>,
	Pat Calhoun <pcalhoun@diameter.org>, seamoby@diameter.org
References: <9FBD322B7824D511B36900508BF93C9C9F5DC2@zcard031.ca.nortel.com> <3B433458.8BFE4345@iprg.nokia.com> <20010710165405.B22037@charizard.diameter.org> <3B4BFE74.2AF93D4@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B4BFE74.2AF93D4@iprg.nokia.com>; from cedric@IPRG.nokia.com on Wed, Jul 11, 2001 at 12:21:24AM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Wed, Jul 11, 2001 at 12:21:24AM -0700, Cedric Westphal wrote:
> I don't think I'll be able to be in London. A meeting can only help the
> issues forward. As far as I am concerned, my only way to provide any
> input is the mailing list.
Ah, well as I stated earlier, we don't make decisions in IETF meetings. The
list will be used to discuss what we agreed upon at the meeting, and we can then
take it from there, and I'll have to determine consensus.

Thanks,

PatC


From owner-seamoby@diameter.org  Wed Jul 11 10:27:12 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05080
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 10:26:55 -0400 (EDT)
Received: (qmail 28468 invoked by alias); 11 Jul 2001 14:10:29 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28461 invoked by uid 200); 11 Jul 2001 14:10:29 -0000
Received: (qmail 28447 invoked from network); 11 Jul 2001 14:10:26 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 14:10:26 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6BEKIb08965
	for <seamoby@cdma-2000.org>; Wed, 11 Jul 2001 10:20:18 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 11 Jul 2001 10:20:21 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2ZFX9>; Wed, 11 Jul 2001 10:20:23 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E15@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Wed, 11 Jul 2001 10:20:20 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10A14.9DE15AE0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10A14.9DE15AE0
Content-Type: text/plain;
	charset="iso-8859-1"

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:Madjid.Nakhjiri@motorola.com]
Sent: Tuesday, July 10, 2001 6:37 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';
seamoby@cdma-2000.org
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:gkenward@nortelnetworks.com]
Sent: Tuesday, July 10, 2001 8:53 AM
To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
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: john.loughney@nokia.com [ mailto:john.loughney@nokia.com
<mailto:john.loughney@nokia.com> ] 
> Sent: Tuesday, July 10, 2001 1:59 AM 
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
> 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 
> 


------_=_NextPart_001_01C10A14.9DE15AE0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=480580214-11072001>Madjid:</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>&nbsp;&nbsp; I'm 
glad you feel this way. I guess this discussion began as a result of 
</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>Issue #4, which 
proposes an alternate wording.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=480580214-11072001>&nbsp;&nbsp;&nbsp; After a few exchanges with Cedric, I 
reviewed the current text, and</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>I realized that 
it indicates that proactive is deadline driven, which I 
really</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>believe is a bad 
thing to require.&nbsp; All I want to ensure is that there is a 
</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>capability with 
ctp to start a ct sometime before the actually traffic 
handover</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>is initiated. 
Why? Because there are many networks that provide "warnings"</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>that a handover 
may be imminent (actually, most RF systems can be designed</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>to do this, and 
should). How? Well, the actual trigger event will change</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>depending upon 
the L2 design, but typically, the mechanism starts with the</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>base receiver 
sensing&nbsp;transmission from a mobile, and then usually many other 
</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>mechanisms that 
kick in to identify the mobile at L1/L2.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>&nbsp;&nbsp; So, 
I would also like to keep the current text, for the same reason. I 
would</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>like to remove 
the deadline, or at least change it so that it is clearly a 
desirable</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>deadline, but not 
a requirement (we cannot make it a requirement because the 
physics</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>of wireless 
handover make the timing of any forewarning event completely 
un-</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=480580214-11072001>predictable).</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>&nbsp;&nbsp; 
Maybe I've said this all before, and maybe my view is clear to everyone. 
Sorry</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>for being 
repetitive.</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=480580214-11072001>Gary</SPAN></FONT></DIV>
<DIV><FONT face="Comic Sans MS"><SPAN 
class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Nakhjiri Madjid-MNAKHJI1 
  [mailto:Madjid.Nakhjiri@motorola.com]<BR><B>Sent:</B> Tuesday, July 10, 2001 
  6:37 PM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; 
  'john.loughney@nokia.com'; seamoby@cdma-2000.org<BR><B>Subject:</B> RE: 
  [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=154203222-10072001>Gary,</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>I 
  don't think we should remove the reactive/ proactive definitions out 
  of</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=154203222-10072001>requirement, unless there is a consensus for removing 
  it.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>If 
  we nobody can come up with a better definition than the 
  already</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=154203222-10072001>existing one, either we keep it or declare it as an 
  open issue.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=154203222-10072001>Personally I liked the definitions that are based on 
  the starting event</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>such 
  as link establishment better, but I still can live with the exiting 
  </SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>one 
  (packet arrival) for the time being. Removing the whole 
  thing</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>is 
  throwing a lot of good thoughts away.</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>A 
  requirement subject to modifications is better than no 
  requirement.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=154203222-10072001>Madjid</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
    [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, July 10, 2001 
    8:53 AM<BR><B>To:</B> 'john.loughney@nokia.com'; 
    seamoby@cdma-2000.org<BR><B>Subject:</B> RE: [seamoby] L2 API (WAS: Ext. for 
    FMIPv6 - comments)<BR><BR></DIV></FONT>
    <P><FONT size=2>John:</FONT> </P>
    <P><FONT size=2>&nbsp;&nbsp; I have been contemplating removing the 
    "reactive"/"proactive"</FONT> <BR><FONT size=2>definitions from the 
    requirements also, but I really do hope we</FONT> <BR><FONT size=2>do not 
    lose the concept of starting ct as early as possible. Being</FONT> <BR><FONT 
    size=2>proactive with ct has been a fundamental component to ct since the 
    </FONT><BR><FONT size=2>problem statement draft, and, to me, a critical tool 
    for providing </FONT><BR><FONT size=2>seamless service handover.</FONT> </P>
    <P><FONT size=2>&nbsp;&nbsp; There are those who, rightfully, have no 
    interest in proactive</FONT> <BR><FONT size=2>ct for their networks. If we 
    lose the requirement, it may be very</FONT> <BR><FONT size=2>difficult for 
    the wg to proceed with a ctp design that supports </FONT><BR><FONT 
    size=2>this mode.</FONT> </P>
    <P><FONT size=2>&nbsp;&nbsp; I'll wait for your issue to be generated. Some 
    of us are also</FONT> <BR><FONT size=2>struggling with some alterative 
    wording of the definitions</FONT> </P>
    <P><FONT size=2>Gary</FONT> </P>
    <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
    From: john.loughney@nokia.com [<A 
    href="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT> 
    <BR><FONT size=2>&gt; Sent: Tuesday, July 10, 2001 1:59 AM</FONT> <BR><FONT 
    size=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; 
    seamoby@cdma-2000.org</FONT> <BR><FONT size=2>&gt; Subject: RE: [seamoby] L2 
    API (WAS: Ext. for FMIPv6 - comments)</FONT> <BR><FONT size=2>&gt; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Hi Gary,</FONT> 
    <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt;&nbsp; I agree, 
    particularly with your definition of ct (although I'm </FONT><BR><FONT 
    size=2>&gt; &gt; not sure where "reductive mode" came from). 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; Ooops, I meant that I was in "reductive mode" (trying to</FONT> 
    <BR><FONT size=2>&gt; simplify &amp; get back to the basics).&nbsp; 
    </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; In thinking 
    through the overall discussion, I am realize that the </FONT><BR><FONT 
    size=2>&gt; &gt; big difference between "reactive" and "proactive" is how 
    they are </FONT><BR><FONT size=2>&gt; &gt; triggered. "proactive" assumes 
    that there is a trigger available </FONT><BR><FONT size=2>&gt; &gt; early on 
    that permits some context transfer in advance of an actual </FONT><BR><FONT 
    size=2>&gt; &gt; handover. </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; I agree. My thoughts are that the discussion of reactive and 
    proactive</FONT> <BR><FONT size=2>&gt; (&amp; triggering, etc.) get quite 
    close to protocol design.&nbsp; I think</FONT> <BR><FONT size=2>&gt; that is 
    one reason that the discussion became so heavy on the</FONT> <BR><FONT 
    size=2>&gt; the requirements.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
    size=2>&gt; &gt;&nbsp;&nbsp; I do believe the current wording for proactive 
    is wrong. Now that </FONT><BR><FONT size=2>&gt; &gt; I have had time to 
    contemplate the wording, it does not define what </FONT><BR><FONT 
    size=2>&gt; &gt; I have always believed proactive ct should be about. I'm 
    hoping </FONT><BR><FONT size=2>&gt; &gt; that if we fix that wording, we can 
    move on to the important part </FONT><BR><FONT size=2>&gt; &gt; of designing 
    ctp. </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; My suggestion 
    would be to cut-out of the requirements document the</FONT> <BR><FONT 
    size=2>&gt; discussion about proactive &amp; reactive text.&nbsp; I will try 
    to make an</FONT> <BR><FONT size=2>&gt; issue for this later in the 
    day.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
    thanks,</FONT> <BR><FONT size=2>&gt; John</FONT> <BR><FONT size=2>&gt; 
    </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C10A14.9DE15AE0--


From owner-seamoby@diameter.org  Wed Jul 11 10:34:05 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05441
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 10:34:05 -0400 (EDT)
Received: (qmail 28994 invoked by alias); 11 Jul 2001 14:18:36 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28988 invoked by uid 200); 11 Jul 2001 14:18:36 -0000
Received: (qmail 28979 invoked by uid 500); 11 Jul 2001 14:18:34 -0000
Date: Wed, 11 Jul 2001 07:18:34 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>, seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-  Phase CT
Message-ID: <20010711071834.J27470@charizard.diameter.org>
Mail-Followup-To: Phillip Neumiller <PNeumiller@MeshNetworks.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>,
	'Gary Kenward' <gkenward@nortelnetworks.com>, seamoby@cdma-2000.org
References: <0DF9FBC42474A24CA50F7A27FB08E04844558E@meshpdc.meshnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E04844558E@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Wed, Jul 11, 2001 at 09:57:43AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Wed, Jul 11, 2001 at 09:57:43AM -0400, Phillip Neumiller wrote:
> > Glad to hear you like FMIPv6++, but I still don't see much of a
> > benefit in combining CT within the MIP message.
> 
> I have not heard one technical reason why NOT.  This is just YOUR
> opinion Pat.  In fact I DONT like your poly-phasic idea and I have
> stated technical reasons why.  Why don't you give me a "technical"
> reason why rather than "I don't see much of a benefit" stuff?

well, the IESG has already stated that their desire was to NOT tie 
CTP to MIP (and if memory serves, that was your position until just
recently too). There are other mobility management protocols out there,
and I'd hate to see them have to ignore CTP just because it is part of
the MIP baggage. 

Further, what are the benefits? Sending a single packet, as opposed to two?
Where's the benefit there? I can have two threads work separately in
transmitting the MIP and CT packets. That would reduce the number of locks
required, and introduces modularity. Great benefits IMHO.

> 
> BTW, I have not seen any real support for your polyphasic CT on
> the list but it remains a requirement in your mind for some reason.

hmmm... well, so far I've only seen this e-mail stating that poly-phasic
is not desired. Perhaps I missed your technical reason for it, which is 
possible since my e-mails been overflowing. Could you perhaps send those
reasons again, or a pointer to the archives?

If there isn't support, then I agree that we need to remove it. I am not
trying to circumvent the process here. I genuinely thought there was
support.

PatC


From owner-seamoby@diameter.org  Wed Jul 11 10:37:02 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05548
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 10:37:01 -0400 (EDT)
Received: (qmail 29025 invoked by alias); 11 Jul 2001 14:18:55 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 29019 invoked by uid 200); 11 Jul 2001 14:18:54 -0000
Received: (qmail 29010 invoked from network); 11 Jul 2001 14:18:50 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 14:18:50 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6BESfb10278;
	Wed, 11 Jul 2001 10:28:41 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 11 Jul 2001 10:28:33 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2ZGAN>; Wed, 11 Jul 2001 10:28:34 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E16@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Cedric Westphal <cedric@IPRG.nokia.com>
Cc: "'seamoby'" <seamoby@diameter.org>
Subject: RE: [seamoby] RE: Need for support of neither pro nor reactive ct . 
         was: Re: [se amoby] Issue #4: Clear, unambiguous definitions missing
Date: Wed, 11 Jul 2001 10:28:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10A15.C43E4210"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10A15.C43E4210
Content-Type: text/plain;
	charset="iso-8859-1"

Hello. This confusion is of my doing.
Originally I was not planning to attend, and conveyed this to Cedric.

In short, a different meeting.

Gary

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Tuesday, July 10, 2001 7:54 PM
> To: Cedric Westphal
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; 'seamoby'
> Subject: Re: [seamoby] RE: Need for support of neither pro 
> nor reactive
> ct. was: Re: [se amoby] Issue #4: Clear, unambiguous 
> definitions missing
> 
> 
> > Meeting in
> > London
> > ain't gonna happen, but I'll take up your offer and try to 
> work it in
> > the wording.
> 
> Do you mean that a meeting will not solve the issue, or that 
> you cannot
> make the meeting?
> 
> PatC
> 

------_=_NextPart_001_01C10A15.C43E4210
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [seamoby] RE: Need for support of neither pro nor reactive =
ct.  was: Re: [se amoby] Issue #4: Clear, unambiguous definitions =
missing</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello. This confusion is of my doing.</FONT>
<BR><FONT SIZE=3D2>Originally I was not planning to attend, and =
conveyed this to Cedric.</FONT>
</P>

<P><FONT SIZE=3D2>In short, a different meeting.</FONT>
</P>

<P><FONT SIZE=3D2>Gary</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Pat Calhoun [<A =
HREF=3D"mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Tuesday, July 10, 2001 7:54 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Cedric Westphal</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Kenward, Gary [WDLN2:AN10:EXCH]; =
'seamoby'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: [seamoby] RE: Need for support of =
neither pro </FONT>
<BR><FONT SIZE=3D2>&gt; nor reactive</FONT>
<BR><FONT SIZE=3D2>&gt; ct. was: Re: [se amoby] Issue #4: Clear, =
unambiguous </FONT>
<BR><FONT SIZE=3D2>&gt; definitions missing</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Meeting in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; London</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ain't gonna happen, but I'll take up your =
offer and try to </FONT>
<BR><FONT SIZE=3D2>&gt; work it in</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the wording.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Do you mean that a meeting will not solve the =
issue, or that </FONT>
<BR><FONT SIZE=3D2>&gt; you cannot</FONT>
<BR><FONT SIZE=3D2>&gt; make the meeting?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; PatC</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10A15.C43E4210--


From owner-seamoby@diameter.org  Wed Jul 11 10:45:19 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05880
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 10:45:14 -0400 (EDT)
Received: (qmail 30153 invoked by alias); 11 Jul 2001 14:32:59 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30147 invoked by uid 200); 11 Jul 2001 14:32:59 -0000
Received: (qmail 30139 invoked from network); 11 Jul 2001 14:32:51 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 14:32:51 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6BEgob12394
	for <seamoby@cdma-2000.org>; Wed, 11 Jul 2001 10:42:50 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 11 Jul 2001 10:42:37 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2ZGPF>; Wed, 11 Jul 2001 10:42:38 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E17@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
         Phase CT
Date: Wed, 11 Jul 2001 10:42:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10A17.B849E2A0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10A17.B849E2A0
Content-Type: text/plain;
	charset="iso-8859-1"

Phil:

 There is a technical reason for "polyphasic" ct (although I 
don't really like the term) and I believe it was offered up on
the list. Interestingly enough, the phases reverse themselves
for pct and rat:

   - proactive ct: it *may* be advantageous to transfer all the
     "static" context early; the dynamic, or state dependent 
     context can be transferred early on, but then there is the
     real likelihood that the state context at the old AR will 
     change and the state context at the new AR will have to
     be synchronize; OR, ctp could wait until the handover begins
     to happen to transfer the dynamic context.

   - reactive ct: the situation is somewhat reversed (although it
     is too simplistic to say the two phases of context transfer
     are in reverse order); it *may* be possible to provide a 
     close to seamless forwarding of the traffic quickly by 
     transferring critical forwarding context immediately and 
     deferring the transfer of context that is not critical to 
     forwarding; the selection of critical/non-critical is the
     tricky bit, and probably contentious.

  Of course, if all the context is easily extracted at the old
AR and fits into one MTU, then the whole rationale for two phase
ct disappears.

Gary

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Wednesday, July 11, 2001 9:58 AM
> To: 'Pat Calhoun'
> Cc: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org
> Subject: RE: CT reliability model was RE: [seamoby] [Issue] 
> Support for
> Mu lti- Phase CT
> 
> 
> > Glad to hear you like FMIPv6++, but I still don't see much of a
> > benefit in combining CT within the MIP message.
> 
> I have not heard one technical reason why NOT.  This is just YOUR
> opinion Pat.  In fact I DONT like your poly-phasic idea and I have
> stated technical reasons why.  Why don't you give me a "technical"
> reason why rather than "I don't see much of a benefit" stuff?
> 
> BTW, I have not seen any real support for your polyphasic CT on
> the list but it remains a requirement in your mind for some reason.
> 
> Thanks,
> 
> Phil
> 

------_=_NextPart_001_01C10A17.B849E2A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-  Phase CT</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Phil:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;There is a technical reason for &quot;polyphasic&quot; ct (although I </FONT>
<BR><FONT SIZE=2>don't really like the term) and I believe it was offered up on</FONT>
<BR><FONT SIZE=2>the list. Interestingly enough, the phases reverse themselves</FONT>
<BR><FONT SIZE=2>for pct and rat:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; - proactive ct: it *may* be advantageous to transfer all the</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; &quot;static&quot; context early; the dynamic, or state dependent </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; context can be transferred early on, but then there is the</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; real likelihood that the state context at the old AR will </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; change and the state context at the new AR will have to</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; be synchronize; OR, ctp could wait until the handover begins</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; to happen to transfer the dynamic context.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; - reactive ct: the situation is somewhat reversed (although it</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; is too simplistic to say the two phases of context transfer</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; are in reverse order); it *may* be possible to provide a </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; close to seamless forwarding of the traffic quickly by </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; transferring critical forwarding context immediately and </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; deferring the transfer of context that is not critical to </FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; forwarding; the selection of critical/non-critical is the</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp; tricky bit, and probably contentious.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Of course, if all the context is easily extracted at the old</FONT>
<BR><FONT SIZE=2>AR and fits into one MTU, then the whole rationale for two phase</FONT>
<BR><FONT SIZE=2>ct disappears.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phillip Neumiller [<A HREF="mailto:PNeumiller@MeshNetworks.com">mailto:PNeumiller@MeshNetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, July 11, 2001 9:58 AM</FONT>
<BR><FONT SIZE=2>&gt; To: 'Pat Calhoun'</FONT>
<BR><FONT SIZE=2>&gt; Cc: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: CT reliability model was RE: [seamoby] [Issue] </FONT>
<BR><FONT SIZE=2>&gt; Support for</FONT>
<BR><FONT SIZE=2>&gt; Mu lti- Phase CT</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Glad to hear you like FMIPv6++, but I still don't see much of a</FONT>
<BR><FONT SIZE=2>&gt; &gt; benefit in combining CT within the MIP message.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I have not heard one technical reason why NOT.&nbsp; This is just YOUR</FONT>
<BR><FONT SIZE=2>&gt; opinion Pat.&nbsp; In fact I DONT like your poly-phasic idea and I have</FONT>
<BR><FONT SIZE=2>&gt; stated technical reasons why.&nbsp; Why don't you give me a &quot;technical&quot;</FONT>
<BR><FONT SIZE=2>&gt; reason why rather than &quot;I don't see much of a benefit&quot; stuff?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; BTW, I have not seen any real support for your polyphasic CT on</FONT>
<BR><FONT SIZE=2>&gt; the list but it remains a requirement in your mind for some reason.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Phil</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10A17.B849E2A0--


From owner-seamoby@diameter.org  Wed Jul 11 10:50:05 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05987
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 10:50:04 -0400 (EDT)
Received: (qmail 30309 invoked by alias); 11 Jul 2001 14:34:21 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30303 invoked by uid 200); 11 Jul 2001 14:34:20 -0000
Received: (qmail 30297 invoked by uid 500); 11 Jul 2001 14:34:19 -0000
Date: Wed, 11 Jul 2001 07:34:19 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)
Message-ID: <20010711073419.K27470@charizard.diameter.org>
Mail-Followup-To: Gary Kenward <gkenward@nortelnetworks.com>,
	'Nakhjiri Madjid-MNAKHJI1' <Madjid.Nakhjiri@motorola.com>,
	"'john.loughney@nokia.com'" <john.loughney@nokia.com>,
	seamoby@cdma-2000.org
References: <9FBD322B7824D511B36900508BF93C9C9F5E15@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E15@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Wed, Jul 11, 2001 at 10:20:20AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

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:Madjid.Nakhjiri@motorola.com]
> Sent: Tuesday, July 10, 2001 6:37 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';
> seamoby@cdma-2000.org
> 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:gkenward@nortelnetworks.com]
> Sent: Tuesday, July 10, 2001 8:53 AM
> To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
> 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: john.loughney@nokia.com [ mailto:john.loughney@nokia.com
> <mailto:john.loughney@nokia.com> ] 
> > Sent: Tuesday, July 10, 2001 1:59 AM 
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
> > 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 owner-seamoby@diameter.org  Wed Jul 11 10:55:45 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06201
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 10:55:45 -0400 (EDT)
Received: (qmail 31044 invoked by alias); 11 Jul 2001 14:41:48 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 31038 invoked by uid 200); 11 Jul 2001 14:41:47 -0000
Received: (qmail 31027 invoked by uid 500); 11 Jul 2001 14:41:45 -0000
Date: Wed, 11 Jul 2001 07:41:45 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- Phase CT
Message-ID: <20010711074145.L27470@charizard.diameter.org>
Mail-Followup-To: Gary Kenward <gkenward@nortelnetworks.com>,
	'Phillip Neumiller' <PNeumiller@MeshNetworks.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>, seamoby@cdma-2000.org
References: <9FBD322B7824D511B36900508BF93C9C9F5E17@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E17@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Wed, Jul 11, 2001 at 10:42:33AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Wed, Jul 11, 2001 at 10:42:33AM -0400, Gary Kenward wrote:
> Phil:
> 
>  There is a technical reason for "polyphasic" ct (although I 
> don't really like the term) and I believe it was offered up on
> the list. Interestingly enough, the phases reverse themselves
> for pct and rat:
> 
>    - proactive ct: it *may* be advantageous to transfer all the
>      "static" context early; the dynamic, or state dependent 
>      context can be transferred early on, but then there is the
>      real likelihood that the state context at the old AR will 
>      change and the state context at the new AR will have to
>      be synchronize; OR, ctp could wait until the handover begins
>      to happen to transfer the dynamic context.
> 
>    - reactive ct: the situation is somewhat reversed (although it
>      is too simplistic to say the two phases of context transfer
>      are in reverse order); it *may* be possible to provide a 
>      close to seamless forwarding of the traffic quickly by 
>      transferring critical forwarding context immediately and 
>      deferring the transfer of context that is not critical to 
>      forwarding; the selection of critical/non-critical is the
>      tricky bit, and probably contentious.
> 
>   Of course, if all the context is easily extracted at the old
> AR and fits into one MTU, then the whole rationale for two phase
> ct disappears.

I think that two phases are needed, regardless of the MTU size. I
believe that in order to achieve a seamless handoff, it is necessary
to transfer time sensitive context blobs as soon as possible (e.g.
header compression, L2 keying info, L3 SAs). These are necessary
in order to exchange packets with the mobile, but there may be other
time sensitive blobs that I haven't thought of as well. Non-time sensitive
blobs (e.g. accounting session id) are not needed to send/receive packets
and therefore do not need to be sent right away.

Mind you, if you have a platform (or service) where these blobs can be
sent in a single transmission really fast, then multi-phasic may not
be desirable, and shouldn't be mandatory. Even if multi-phasic exists,
the protocol should allow for all blobs to be sent in the first
transmission.

PatC


From owner-seamoby@diameter.org  Wed Jul 11 11:47:24 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08492
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 11:47:23 -0400 (EDT)
Received: (qmail 31876 invoked by alias); 11 Jul 2001 15:36:24 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 31870 invoked by uid 200); 11 Jul 2001 15:36:24 -0000
Received: (qmail 31847 invoked from network); 11 Jul 2001 15:36:21 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 15:36:21 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA26915;
	Wed, 11 Jul 2001 08:47:05 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA22595;
	Wed, 11 Jul 2001 08:47:04 -0700 (PDT)
Message-Id: <200107111547.IAA22595@heliopolis.eng.sun.com>
Date: Wed, 11 Jul 2001 08:47:03 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-  Phase CT
To: PNeumiller@MeshNetworks.com, pcalhoun@diameter.org
Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com, seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: yO+AuBO+QLCpj7HSzipARw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Pat,

>well, the IESG has already stated that their desire was to NOT tie 
>CTP to MIP (and if memory serves, that was your position until just
>recently too). There are other mobility management protocols out there,
>and I'd hate to see them have to ignore CTP just because it is part of
>the MIP baggage. 
>
>Further, what are the benefits? Sending a single packet, as opposed to two?
>Where's the benefit there? I can have two threads work separately in
>transmitting the MIP and CT packets. That would reduce the number of locks
>required, and introduces modularity. Great benefits IMHO.
>

I think there may be some benefits to linking CT with the handover
messaging. 

If you send the context and the mobility protocol handover messaging in separate 
packets, you generate a synchronization problem on the new AR. Furthermore,
you increase the risk that a packet could be delayed or lost, disrupting
the handover. Suppose that the packets arrive out of order, that is, the CT 
packet arrives before the handover messaging. The AR must then arrange to buffer 
and potentially drop the CT packet if no handover messaging arrives within
a certain interval. The resulting implementation on the AR becomes more
complex, and thus subject to potential failure in more places.

Note here that I've said "the mobility protocol", not MIP. I think it
should be possible to define the CT messaging so that it is independent
of MIP but still can be added to a mobility protocol as an  extention,
with a binding to that particular mobility protocol. I can easily see
how it might work with the network assisted FMIP extensions, and potentially
also with (excuse my language) GPRS, as much as I know about it. 

		jak




From owner-seamoby@diameter.org  Wed Jul 11 11:54:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08790
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 11:54:30 -0400 (EDT)
Received: (qmail 32405 invoked by alias); 11 Jul 2001 15:43:26 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 32399 invoked by uid 200); 11 Jul 2001 15:43:26 -0000
Received: (qmail 32389 invoked from network); 11 Jul 2001 15:43:24 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 15:43:24 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA08885;
	Wed, 11 Jul 2001 09:54:08 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA22913;
	Wed, 11 Jul 2001 08:54:09 -0700 (PDT)
Message-Id: <200107111554.IAA22913@heliopolis.eng.sun.com>
Date: Wed, 11 Jul 2001 08:54:09 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- Phase CT
To: gkenward@nortelnetworks.com, pcalhoun@diameter.org
Cc: PNeumiller@MeshNetworks.com, pcalhoun@diameter.org, seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ikHO/vOH1eITx7uZ7W+2YA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk


>
>I think that two phases are needed, regardless of the MTU size. I
>believe that in order to achieve a seamless handoff, it is necessary
>to transfer time sensitive context blobs as soon as possible (e.g.
>header compression, L2 keying info, L3 SAs). These are necessary
>in order to exchange packets with the mobile, but there may be other
>time sensitive blobs that I haven't thought of as well. Non-time sensitive
>blobs (e.g. accounting session id) are not needed to send/receive packets
>and therefore do not need to be sent right away.
>
>Mind you, if you have a platform (or service) where these blobs can be
>sent in a single transmission really fast, then multi-phasic may not
>be desirable, and shouldn't be mandatory. Even if multi-phasic exists,
>the protocol should allow for all blobs to be sent in the first
>transmission.
>
>

Could the time critical phase be framed as a mobility protocol
extention, so it could be bound to a mobility protocol?

		jak



From owner-seamoby@diameter.org  Wed Jul 11 14:16:53 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14339
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 14:16:51 -0400 (EDT)
Received: (qmail 947 invoked by alias); 11 Jul 2001 18:05:41 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 941 invoked by uid 200); 11 Jul 2001 18:05:41 -0000
Received: (qmail 936 invoked from network); 11 Jul 2001 18:05:38 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 18:05:38 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA16585;
	Wed, 11 Jul 2001 11:15:49 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6BIFmF09468;
	Wed, 11 Jul 2001 11:15:48 -0700
X-mProtect:  Wed, 11 Jul 2001 11:15:48 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd4haS5M; Wed, 11 Jul 2001 11:15:47 PDT
Message-ID: <3B4C97D3.7F876F9@iprg.nokia.com>
Date: Wed, 11 Jul 2001 11:15:47 -0700
From: Rajeev Koodli <rajeev@IPRG.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf <James.Kempf@Sun.COM>
CC: seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-  
 Phase CT
References: <200107111547.IAA22595@heliopolis.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello,

I agree that there is much to gain from doing CT _with_ handover signaling. In
fact, I have raised this issue of potential state inconsistency (what James calls
synchronization problem below) a *few times* already in the mailing list. However,
the value of CT should not be tied to MIP handovers alone. So, the way to make use
of CT for MIP handovers is to separate the feature contexts from the actual
signaling messages. This is outlined in draft-koodli-seamoby-ctv6-00.txt.

Regards,

-Rajeev


James Kempf wrote:

> Hi Pat,
>
> >well, the IESG has already stated that their desire was to NOT tie
> >CTP to MIP (and if memory serves, that was your position until just
> >recently too). There are other mobility management protocols out there,
> >and I'd hate to see them have to ignore CTP just because it is part of
> >the MIP baggage.
> >
> >Further, what are the benefits? Sending a single packet, as opposed to two?
> >Where's the benefit there? I can have two threads work separately in
> >transmitting the MIP and CT packets. That would reduce the number of locks
> >required, and introduces modularity. Great benefits IMHO.
> >
>
> I think there may be some benefits to linking CT with the handover
> messaging.
>
> If you send the context and the mobility protocol handover messaging in separate
> packets, you generate a synchronization problem on the new AR. Furthermore,
> you increase the risk that a packet could be delayed or lost, disrupting
> the handover. Suppose that the packets arrive out of order, that is, the CT
> packet arrives before the handover messaging. The AR must then arrange to buffer
> and potentially drop the CT packet if no handover messaging arrives within
> a certain interval. The resulting implementation on the AR becomes more
> complex, and thus subject to potential failure in more places.
>
> Note here that I've said "the mobility protocol", not MIP. I think it
> should be possible to define the CT messaging so that it is independent
> of MIP but still can be added to a mobility protocol as an  extention,
> with a binding to that particular mobility protocol. I can easily see
> how it might work with the network assisted FMIP extensions, and potentially
> also with (excuse my language) GPRS, as much as I know about it.
>
>                 jak



From owner-seamoby@diameter.org  Wed Jul 11 15:07:46 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16445
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 15:07:32 -0400 (EDT)
Received: (qmail 1560 invoked by alias); 11 Jul 2001 18:51:14 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 1554 invoked by uid 200); 11 Jul 2001 18:51:13 -0000
Received: (qmail 1549 invoked from network); 11 Jul 2001 18:50:41 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 18:50:41 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6BJ0db17869
	for <seamoby@cdma-2000.org>; Wed, 11 Jul 2001 15:00:39 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 11 Jul 2001 15:00:37 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2ZN93>; Wed, 11 Jul 2001 15:00:38 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E24@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Wed, 11 Jul 2001 15:00:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10A3B.C29CF8E0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10A3B.C29CF8E0
Content-Type: text/plain;
	charset="iso-8859-1"

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:pcalhoun@diameter.org]
> Sent: Wednesday, July 11, 2001 10:34 AM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';
> seamoby@cdma-2000.org
> 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:Madjid.Nakhjiri@motorola.com]
> > Sent: Tuesday, July 10, 2001 6:37 PM
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';
> > seamoby@cdma-2000.org
> > 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:gkenward@nortelnetworks.com]
> > Sent: Tuesday, July 10, 2001 8:53 AM
> > To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
> > 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: john.loughney@nokia.com [ mailto:john.loughney@nokia.com
> > <mailto:john.loughney@nokia.com> ] 
> > > Sent: Tuesday, July 10, 2001 1:59 AM 
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
> > > 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 
> > > 
> > 
> 

------_=_NextPart_001_01C10A3B.C29CF8E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  RE: Issue #4)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Pat:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;The oAR does not need to know when the first packet arrival</FONT>
<BR><FONT SIZE=2>at the newAR may occur. Indeed, for proactive to be effective,</FONT>
<BR><FONT SIZE=2>the oAR must initiate a ct based upon an event that is only indicates</FONT>
<BR><FONT SIZE=2>a possible handover.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Here is the scenario: the MN traffic is passing through, say, AR3.</FONT>
<BR><FONT SIZE=2>The RF subsystem (aka the link layer, aka L2) &quot;determines&quot; (through L1/l2</FONT>
<BR><FONT SIZE=2>mechanisms) that AR5, AR19, and AR11 are potential candidates for handover.</FONT>
<BR><FONT SIZE=2>AR3 receives an event from L2 that instructs it to transfer context to</FONT>
<BR><FONT SIZE=2>AR5, AR19, AR11. The three &quot;target&quot; ARs in this example are thus ready to</FONT>
<BR><FONT SIZE=2>receive a handover of the MNs traffic, if it is required to maintain the</FONT>
<BR><FONT SIZE=2>traffic flow. Note that this approach does not completely prevent the MN</FONT>
<BR><FONT SIZE=2>from unexpectedly appearing in the coverage domain of a different AR - </FONT>
<BR><FONT SIZE=2>that's the nature of wireless, however, it goes a long way to improving</FONT>
<BR><FONT SIZE=2>the situation.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Nothing in the above refers to a deadline event. Of course, it is </FONT>
<BR><FONT SIZE=2>the objective to have the context in place before it is needed at the</FONT>
<BR><FONT SIZE=2>new AR. But ct must still work if this deadline is not met, and, because</FONT>
<BR><FONT SIZE=2>we all know how unpredictably handovers can be, the requirements and</FONT>
<BR><FONT SIZE=2>design should explicitly address this situation. In other words, in</FONT>
<BR><FONT SIZE=2>wireless handover, the exception is the rule.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; As I have stated, I want to change that text to clarify that ct completion</FONT>
<BR><FONT SIZE=2>before the first packet arrival is a goal, not a requirement. Or, perhaps,</FONT>
<BR><FONT SIZE=2>it is a SHOULD, not a MUST.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>Note: the ct scheme we are working on is a little different then that</FONT>
<BR><FONT SIZE=2>described above, but hte principle is the same. I did not want to get into</FONT>
<BR><FONT SIZE=2>all the details in this email.</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Pat Calhoun [<A HREF="mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, July 11, 2001 10:34 AM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';</FONT>
<BR><FONT SIZE=2>&gt; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; comments) (SHOULD</FONT>
<BR><FONT SIZE=2>&gt; be , RE: Issue #4)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If we end up deciding that we want to keep most of the current</FONT>
<BR><FONT SIZE=2>&gt; text, I will follow the WG's desire, but I do have some</FONT>
<BR><FONT SIZE=2>&gt; concern with the fact that it currently uses the arrival of</FONT>
<BR><FONT SIZE=2>&gt; a packet destined for the MN as the main difference between both</FONT>
<BR><FONT SIZE=2>&gt; modes of operation. My issue here is in source triggers (meaning oAP</FONT>
<BR><FONT SIZE=2>&gt; initiates CTP), oAP has no way of knowing when the first packet will</FONT>
<BR><FONT SIZE=2>&gt; be received, and therefore doesn't know whether a proactive or</FONT>
<BR><FONT SIZE=2>&gt; reactive CTP should be initiated. This is why I am convinced that this</FONT>
<BR><FONT SIZE=2>&gt; is just informational, and not a protocol thing.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; On Wed, Jul 11, 2001 at 10:20:20AM -0400, Gary Kenward wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; Madjid:</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; I'm glad you feel this way. I guess this discussion </FONT>
<BR><FONT SIZE=2>&gt; began as a result of </FONT>
<BR><FONT SIZE=2>&gt; &gt; Issue #4, which proposes an alternate wording.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; After a few exchanges with Cedric, I reviewed the </FONT>
<BR><FONT SIZE=2>&gt; current text, and</FONT>
<BR><FONT SIZE=2>&gt; &gt; I realized that it indicates that proactive is deadline </FONT>
<BR><FONT SIZE=2>&gt; driven, which I</FONT>
<BR><FONT SIZE=2>&gt; &gt; really</FONT>
<BR><FONT SIZE=2>&gt; &gt; believe is a bad thing to require.&nbsp; All I want to ensure is </FONT>
<BR><FONT SIZE=2>&gt; that there is a </FONT>
<BR><FONT SIZE=2>&gt; &gt; capability with ctp to start a ct sometime before the </FONT>
<BR><FONT SIZE=2>&gt; actually traffic</FONT>
<BR><FONT SIZE=2>&gt; &gt; handover</FONT>
<BR><FONT SIZE=2>&gt; &gt; is initiated. Why? Because there are many networks that </FONT>
<BR><FONT SIZE=2>&gt; provide &quot;warnings&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; that a handover may be imminent (actually, most RF systems </FONT>
<BR><FONT SIZE=2>&gt; can be designed</FONT>
<BR><FONT SIZE=2>&gt; &gt; to do this, and should). How? Well, the actual trigger </FONT>
<BR><FONT SIZE=2>&gt; event will change</FONT>
<BR><FONT SIZE=2>&gt; &gt; depending upon the L2 design, but typically, the mechanism </FONT>
<BR><FONT SIZE=2>&gt; starts with the</FONT>
<BR><FONT SIZE=2>&gt; &gt; base receiver sensing transmission from a mobile, and then </FONT>
<BR><FONT SIZE=2>&gt; usually many</FONT>
<BR><FONT SIZE=2>&gt; &gt; other </FONT>
<BR><FONT SIZE=2>&gt; &gt; mechanisms that kick in to identify the mobile at L1/L2.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; So, I would also like to keep the current text, for the </FONT>
<BR><FONT SIZE=2>&gt; same reason. I</FONT>
<BR><FONT SIZE=2>&gt; &gt; would</FONT>
<BR><FONT SIZE=2>&gt; &gt; like to remove the deadline, or at least change it so that </FONT>
<BR><FONT SIZE=2>&gt; it is clearly a</FONT>
<BR><FONT SIZE=2>&gt; &gt; desirable</FONT>
<BR><FONT SIZE=2>&gt; &gt; deadline, but not a requirement (we cannot make it a </FONT>
<BR><FONT SIZE=2>&gt; requirement because the</FONT>
<BR><FONT SIZE=2>&gt; &gt; physics</FONT>
<BR><FONT SIZE=2>&gt; &gt; of wireless handover make the timing of any forewarning </FONT>
<BR><FONT SIZE=2>&gt; event completely un-</FONT>
<BR><FONT SIZE=2>&gt; &gt; predictable).</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; Maybe I've said this all before, and maybe my view is </FONT>
<BR><FONT SIZE=2>&gt; clear to everyone.</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sorry</FONT>
<BR><FONT SIZE=2>&gt; &gt; for being repetitive.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Gary</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Nakhjiri Madjid-MNAKHJI1 [<A HREF="mailto:Madjid.Nakhjiri@motorola.com">mailto:Madjid.Nakhjiri@motorola.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Tuesday, July 10, 2001 6:37 PM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';</FONT>
<BR><FONT SIZE=2>&gt; &gt; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Gary,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I don't think we should remove the reactive/ proactive </FONT>
<BR><FONT SIZE=2>&gt; definitions out of</FONT>
<BR><FONT SIZE=2>&gt; &gt; requirement, unless there is a consensus for removing it.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; If we nobody can come up with a better definition than the already</FONT>
<BR><FONT SIZE=2>&gt; &gt; existing one, either we keep it or declare it as an open issue.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Personally I liked the definitions that are based on the </FONT>
<BR><FONT SIZE=2>&gt; starting event</FONT>
<BR><FONT SIZE=2>&gt; &gt; such as link establishment better, but I still can live </FONT>
<BR><FONT SIZE=2>&gt; with the exiting </FONT>
<BR><FONT SIZE=2>&gt; &gt; one (packet arrival) for the time being. Removing the whole thing</FONT>
<BR><FONT SIZE=2>&gt; &gt; is throwing a lot of good thoughts away.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; A requirement subject to modifications is better than no </FONT>
<BR><FONT SIZE=2>&gt; requirement.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Madjid</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Gary Kenward [<A HREF="mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Tuesday, July 10, 2001 8:53 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; John: </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; I have been contemplating removing the &quot;reactive&quot;/&quot;proactive&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt; definitions from the requirements also, but I really do hope we </FONT>
<BR><FONT SIZE=2>&gt; &gt; do not lose the concept of starting ct as early as possible. Being </FONT>
<BR><FONT SIZE=2>&gt; &gt; proactive with ct has been a fundamental component to ct since the </FONT>
<BR><FONT SIZE=2>&gt; &gt; problem statement draft, and, to me, a critical tool for providing </FONT>
<BR><FONT SIZE=2>&gt; &gt; seamless service handover. </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; There are those who, rightfully, have no interest in proactive </FONT>
<BR><FONT SIZE=2>&gt; &gt; ct for their networks. If we lose the requirement, it may be very </FONT>
<BR><FONT SIZE=2>&gt; &gt; difficult for the wg to proceed with a ctp design that supports </FONT>
<BR><FONT SIZE=2>&gt; &gt; this mode. </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp; I'll wait for your issue to be generated. Some of us are also </FONT>
<BR><FONT SIZE=2>&gt; &gt; struggling with some alterative wording of the definitions </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Gary </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; -----Original Message----- </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; From: john.loughney@nokia.com [ <A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A></FONT>
<BR><FONT SIZE=2>&gt; &gt; &lt;<A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>&gt; ] </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Sent: Tuesday, July 10, 2001 1:59 AM </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Hi Gary, </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; I agree, particularly with your definition of ct (although I'm </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; not sure where &quot;reductive mode&quot; came from). </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Ooops, I meant that I was in &quot;reductive mode&quot; (trying to </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; simplify &amp; get back to the basics).&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; In thinking through the overall discussion, I am </FONT>
<BR><FONT SIZE=2>&gt; realize that the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; big difference between &quot;reactive&quot; and &quot;proactive&quot; is </FONT>
<BR><FONT SIZE=2>&gt; how they are </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; triggered. &quot;proactive&quot; assumes that there is a trigger </FONT>
<BR><FONT SIZE=2>&gt; available </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; early on that permits some context transfer in advance </FONT>
<BR><FONT SIZE=2>&gt; of an actual </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; handover. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; I agree. My thoughts are that the discussion of reactive </FONT>
<BR><FONT SIZE=2>&gt; and proactive </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; (&amp; triggering, etc.) get quite close to protocol design.&nbsp; I think </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; that is one reason that the discussion became so heavy on the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; the requirements. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp;&nbsp; I do believe the current wording for proactive is </FONT>
<BR><FONT SIZE=2>&gt; wrong. Now that </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; I have had time to contemplate the wording, it does not </FONT>
<BR><FONT SIZE=2>&gt; define what </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; I have always believed proactive ct should be about. I'm hoping </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; that if we fix that wording, we can move on to the </FONT>
<BR><FONT SIZE=2>&gt; important part </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; of designing ctp. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; My suggestion would be to cut-out of the requirements </FONT>
<BR><FONT SIZE=2>&gt; document the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; discussion about proactive &amp; reactive text.&nbsp; I will try </FONT>
<BR><FONT SIZE=2>&gt; to make an </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; issue for this later in the day. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; thanks, </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; John </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10A3B.C29CF8E0--


From owner-seamoby@diameter.org  Wed Jul 11 15:16:02 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16683
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 15:16:01 -0400 (EDT)
Received: (qmail 1656 invoked by alias); 11 Jul 2001 18:53:06 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 1650 invoked by uid 200); 11 Jul 2001 18:53:06 -0000
Received: (qmail 1642 invoked from network); 11 Jul 2001 18:52:59 -0000
Received: from femail16.sdc1.sfba.home.com (24.0.95.143)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 18:52:59 -0000
Received: from cr851003a ([24.157.232.166]) by femail16.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010711190334.JBH12729.femail16.sdc1.sfba.home.com@cr851003a>;
          Wed, 11 Jul 2001 12:03:34 -0700
Message-ID: <00bc01c10aa3$49e55d80$a6e89d18@slnt1.on.wave.home.com>
From: "Kulwinder Atwal" <katawal2200@home.com>
To: "Rajeev Koodli" <rajeev@IPRG.nokia.com>,
        "James Kempf" <James.Kempf@Sun.COM>
Cc: <seamoby@cdma-2000.org>
References: <200107111547.IAA22595@heliopolis.eng.sun.com> <3B4C97D3.7F876F9@iprg.nokia.com>
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-   Phase CT
Date: Thu, 12 Jul 2001 03:21:37 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Also, depending on round trip times between parentAR and oldAR/newAR, the
oldAR may not need to forward packets for the MN (FMIP).

If the signalling delay is a few microseconds or milliseconds, the parentAR
may switch the forwarding path first, followed by the oldAR/newAR/MN
performing CT.

I think we need to allow for this by not linking CT to IP level handover of
a particular mobility solution.  The establishment of the new forwarding
path by the parentAR could be used as a Trigger to start CT.

- Kulwinder.

----- Original Message -----
From: "Rajeev Koodli" <rajeev@IPRG.nokia.com>
To: "James Kempf" <James.Kempf@Sun.COM>
Cc: <seamoby@cdma-2000.org>
Sent: Wednesday, July 11, 2001 2:15 PM
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu
lti- Phase CT


>
> Hello,
>
> I agree that there is much to gain from doing CT _with_ handover
signaling. In
> fact, I have raised this issue of potential state inconsistency (what
James calls
> synchronization problem below) a *few times* already in the mailing list.
However,
> the value of CT should not be tied to MIP handovers alone. So, the way to
make use
> of CT for MIP handovers is to separate the feature contexts from the
actual
> signaling messages. This is outlined in draft-koodli-seamoby-ctv6-00.txt.
>
> Regards,
>
> -Rajeev
>
>
> James Kempf wrote:
>
> > Hi Pat,
> >
> > >well, the IESG has already stated that their desire was to NOT tie
> > >CTP to MIP (and if memory serves, that was your position until just
> > >recently too). There are other mobility management protocols out there,
> > >and I'd hate to see them have to ignore CTP just because it is part of
> > >the MIP baggage.
> > >
> > >Further, what are the benefits? Sending a single packet, as opposed to
two?
> > >Where's the benefit there? I can have two threads work separately in
> > >transmitting the MIP and CT packets. That would reduce the number of
locks
> > >required, and introduces modularity. Great benefits IMHO.
> > >
> >
> > I think there may be some benefits to linking CT with the handover
> > messaging.
> >
> > If you send the context and the mobility protocol handover messaging in
separate
> > packets, you generate a synchronization problem on the new AR.
Furthermore,
> > you increase the risk that a packet could be delayed or lost, disrupting
> > the handover. Suppose that the packets arrive out of order, that is, the
CT
> > packet arrives before the handover messaging. The AR must then arrange
to buffer
> > and potentially drop the CT packet if no handover messaging arrives
within
> > a certain interval. The resulting implementation on the AR becomes more
> > complex, and thus subject to potential failure in more places.
> >
> > Note here that I've said "the mobility protocol", not MIP. I think it
> > should be possible to define the CT messaging so that it is independent
> > of MIP but still can be added to a mobility protocol as an  extention,
> > with a binding to that particular mobility protocol. I can easily see
> > how it might work with the network assisted FMIP extensions, and
potentially
> > also with (excuse my language) GPRS, as much as I know about it.
> >
> >                 jak
>



From owner-seamoby@diameter.org  Wed Jul 11 15:19:42 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16818
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 15:19:42 -0400 (EDT)
Received: (qmail 2008 invoked by alias); 11 Jul 2001 19:02:44 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2002 invoked by uid 200); 11 Jul 2001 19:02:43 -0000
Received: (qmail 1992 invoked from network); 11 Jul 2001 19:02:35 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 19:02:35 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA18212;
	Wed, 11 Jul 2001 13:13:14 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA03927;
	Wed, 11 Jul 2001 12:13:15 -0700 (PDT)
Message-Id: <200107111913.MAA03927@heliopolis.eng.sun.com>
Date: Wed, 11 Jul 2001 12:13:14 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-   Phase CT
To: rajeev@IPRG.nokia.com, James.Kempf@Sun.COM, katawal2200@home.com
Cc: seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: NCz2TBYjutfQJ7QL+LyQ0Q==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk


>I think we need to allow for this by not linking CT to IP level handover of
>a particular mobility solution.  The establishment of the new forwarding
>path by the parentAR could be used as a Trigger to start CT.
>

What about making it possible to define a binding between a particular
mobility solution and CT, and have a general framework?

		jak



From owner-seamoby@diameter.org  Wed Jul 11 15:23:52 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16939
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 15:23:48 -0400 (EDT)
Received: (qmail 2032 invoked by alias); 11 Jul 2001 19:02:54 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2025 invoked by uid 200); 11 Jul 2001 19:02:53 -0000
Received: (qmail 2018 invoked from network); 11 Jul 2001 19:02:48 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 19:02:48 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6BJCfb19848
	for <seamoby@cdma-2000.org>; Wed, 11 Jul 2001 15:12:41 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 11 Jul 2001 15:12:46 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Z3J3>; Wed, 11 Jul 2001 15:12:48 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E26@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Rajeev Koodli'" <rajeev@IPRG.nokia.com>,
        James Kempf <James.Kempf@Sun.COM>
Cc: seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
         Phase CT
Date: Wed, 11 Jul 2001 15:12:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10A3D.7895F1A0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10A3D.7895F1A0
Content-Type: text/plain;
	charset="iso-8859-1"

Rajeev:

I am curious as to what "state" is established by the mobility
protocol that could not be synchronized easily with the end of
ct completion (and visa versa).

I am not saying there you are wrong in suggesting this may be a
problem, it's just that I cannot think of a real example.

Gary

> -----Original Message-----
> From: Rajeev Koodli [mailto:rajeev@IPRG.nokia.com]
> Sent: Wednesday, July 11, 2001 2:16 PM
> To: James Kempf
> Cc: seamoby@cdma-2000.org
> Subject: Re: CT reliability model was RE: [seamoby] [Issue] 
> Support for
> Mu lti- Phase CT
> 
> 
> 
> Hello,
> 
> I agree that there is much to gain from doing CT _with_ 
> handover signaling. In
> fact, I have raised this issue of potential state 
> inconsistency (what James calls
> synchronization problem below) a *few times* already in the 
> mailing list. However,
> the value of CT should not be tied to MIP handovers alone. 
> So, the way to make use
> of CT for MIP handovers is to separate the feature contexts 
> from the actual
> signaling messages. This is outlined in 
> draft-koodli-seamoby-ctv6-00.txt.
> 
> Regards,
> 
> -Rajeev
> 
> 
> James Kempf wrote:
> 
> > Hi Pat,
> >
> > >well, the IESG has already stated that their desire was to NOT tie
> > >CTP to MIP (and if memory serves, that was your position until just
> > >recently too). There are other mobility management 
> protocols out there,
> > >and I'd hate to see them have to ignore CTP just because 
> it is part of
> > >the MIP baggage.
> > >
> > >Further, what are the benefits? Sending a single packet, 
> as opposed to two?
> > >Where's the benefit there? I can have two threads work 
> separately in
> > >transmitting the MIP and CT packets. That would reduce the 
> number of locks
> > >required, and introduces modularity. Great benefits IMHO.
> > >
> >
> > I think there may be some benefits to linking CT with the handover
> > messaging.
> >
> > If you send the context and the mobility protocol handover 
> messaging in separate
> > packets, you generate a synchronization problem on the new 
> AR. Furthermore,
> > you increase the risk that a packet could be delayed or 
> lost, disrupting
> > the handover. Suppose that the packets arrive out of order, 
> that is, the CT
> > packet arrives before the handover messaging. The AR must 
> then arrange to buffer
> > and potentially drop the CT packet if no handover messaging 
> arrives within
> > a certain interval. The resulting implementation on the AR 
> becomes more
> > complex, and thus subject to potential failure in more places.
> >
> > Note here that I've said "the mobility protocol", not MIP. 
> I think it
> > should be possible to define the CT messaging so that it is 
> independent
> > of MIP but still can be added to a mobility protocol as an  
> extention,
> > with a binding to that particular mobility protocol. I can 
> easily see
> > how it might work with the network assisted FMIP 
> extensions, and potentially
> > also with (excuse my language) GPRS, as much as I know about it.
> >
> >                 jak
> 
> 

------_=_NextPart_001_01C10A3D.7895F1A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-  Phase CT</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Rajeev:</FONT>
</P>

<P><FONT SIZE=2>I am curious as to what &quot;state&quot; is established by the mobility</FONT>
<BR><FONT SIZE=2>protocol that could not be synchronized easily with the end of</FONT>
<BR><FONT SIZE=2>ct completion (and visa versa).</FONT>
</P>

<P><FONT SIZE=2>I am not saying there you are wrong in suggesting this may be a</FONT>
<BR><FONT SIZE=2>problem, it's just that I cannot think of a real example.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Rajeev Koodli [<A HREF="mailto:rajeev@IPRG.nokia.com">mailto:rajeev@IPRG.nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, July 11, 2001 2:16 PM</FONT>
<BR><FONT SIZE=2>&gt; To: James Kempf</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: CT reliability model was RE: [seamoby] [Issue] </FONT>
<BR><FONT SIZE=2>&gt; Support for</FONT>
<BR><FONT SIZE=2>&gt; Mu lti- Phase CT</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hello,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I agree that there is much to gain from doing CT _with_ </FONT>
<BR><FONT SIZE=2>&gt; handover signaling. In</FONT>
<BR><FONT SIZE=2>&gt; fact, I have raised this issue of potential state </FONT>
<BR><FONT SIZE=2>&gt; inconsistency (what James calls</FONT>
<BR><FONT SIZE=2>&gt; synchronization problem below) a *few times* already in the </FONT>
<BR><FONT SIZE=2>&gt; mailing list. However,</FONT>
<BR><FONT SIZE=2>&gt; the value of CT should not be tied to MIP handovers alone. </FONT>
<BR><FONT SIZE=2>&gt; So, the way to make use</FONT>
<BR><FONT SIZE=2>&gt; of CT for MIP handovers is to separate the feature contexts </FONT>
<BR><FONT SIZE=2>&gt; from the actual</FONT>
<BR><FONT SIZE=2>&gt; signaling messages. This is outlined in </FONT>
<BR><FONT SIZE=2>&gt; draft-koodli-seamoby-ctv6-00.txt.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Regards,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -Rajeev</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; James Kempf wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Hi Pat,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;well, the IESG has already stated that their desire was to NOT tie</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;CTP to MIP (and if memory serves, that was your position until just</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;recently too). There are other mobility management </FONT>
<BR><FONT SIZE=2>&gt; protocols out there,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;and I'd hate to see them have to ignore CTP just because </FONT>
<BR><FONT SIZE=2>&gt; it is part of</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;the MIP baggage.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Further, what are the benefits? Sending a single packet, </FONT>
<BR><FONT SIZE=2>&gt; as opposed to two?</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;Where's the benefit there? I can have two threads work </FONT>
<BR><FONT SIZE=2>&gt; separately in</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;transmitting the MIP and CT packets. That would reduce the </FONT>
<BR><FONT SIZE=2>&gt; number of locks</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;required, and introduces modularity. Great benefits IMHO.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; I think there may be some benefits to linking CT with the handover</FONT>
<BR><FONT SIZE=2>&gt; &gt; messaging.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; If you send the context and the mobility protocol handover </FONT>
<BR><FONT SIZE=2>&gt; messaging in separate</FONT>
<BR><FONT SIZE=2>&gt; &gt; packets, you generate a synchronization problem on the new </FONT>
<BR><FONT SIZE=2>&gt; AR. Furthermore,</FONT>
<BR><FONT SIZE=2>&gt; &gt; you increase the risk that a packet could be delayed or </FONT>
<BR><FONT SIZE=2>&gt; lost, disrupting</FONT>
<BR><FONT SIZE=2>&gt; &gt; the handover. Suppose that the packets arrive out of order, </FONT>
<BR><FONT SIZE=2>&gt; that is, the CT</FONT>
<BR><FONT SIZE=2>&gt; &gt; packet arrives before the handover messaging. The AR must </FONT>
<BR><FONT SIZE=2>&gt; then arrange to buffer</FONT>
<BR><FONT SIZE=2>&gt; &gt; and potentially drop the CT packet if no handover messaging </FONT>
<BR><FONT SIZE=2>&gt; arrives within</FONT>
<BR><FONT SIZE=2>&gt; &gt; a certain interval. The resulting implementation on the AR </FONT>
<BR><FONT SIZE=2>&gt; becomes more</FONT>
<BR><FONT SIZE=2>&gt; &gt; complex, and thus subject to potential failure in more places.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt; Note here that I've said &quot;the mobility protocol&quot;, not MIP. </FONT>
<BR><FONT SIZE=2>&gt; I think it</FONT>
<BR><FONT SIZE=2>&gt; &gt; should be possible to define the CT messaging so that it is </FONT>
<BR><FONT SIZE=2>&gt; independent</FONT>
<BR><FONT SIZE=2>&gt; &gt; of MIP but still can be added to a mobility protocol as an&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; extention,</FONT>
<BR><FONT SIZE=2>&gt; &gt; with a binding to that particular mobility protocol. I can </FONT>
<BR><FONT SIZE=2>&gt; easily see</FONT>
<BR><FONT SIZE=2>&gt; &gt; how it might work with the network assisted FMIP </FONT>
<BR><FONT SIZE=2>&gt; extensions, and potentially</FONT>
<BR><FONT SIZE=2>&gt; &gt; also with (excuse my language) GPRS, as much as I know about it.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; jak</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10A3D.7895F1A0--


From owner-seamoby@diameter.org  Wed Jul 11 15:30:07 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17171
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 15:29:53 -0400 (EDT)
Received: (qmail 2113 invoked by alias); 11 Jul 2001 19:04:40 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2106 invoked by uid 200); 11 Jul 2001 19:04:40 -0000
Received: (qmail 2094 invoked from network); 11 Jul 2001 19:04:36 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 19:04:36 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA08691;
	Wed, 11 Jul 2001 12:15:13 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA04069;
	Wed, 11 Jul 2001 12:15:13 -0700 (PDT)
Message-Id: <200107111915.MAA04069@heliopolis.eng.sun.com>
Date: Wed, 11 Jul 2001 12:15:12 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
To: pcalhoun@diameter.org, gkenward@nortelnetworks.com
Cc: Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: eoCCbQ534324lP4ffwtlaw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

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: seamoby-list@charizard.diameter.org
>From: "Gary Kenward" <gkenward@nortelnetworks.com>
>To: "'Pat Calhoun'" <pcalhoun@diameter.org>
>Cc: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>, 
"'john.loughney@nokia.com'" <john.loughney@nokia.com>, seamoby@cdma-2000.org
>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:pcalhoun@diameter.org]
>> Sent: Wednesday, July 11, 2001 10:34 AM
>> To: Kenward, Gary [WDLN2:AN10:EXCH]
>> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';
>> seamoby@cdma-2000.org
>> 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:Madjid.Nakhjiri@motorola.com]
>> > Sent: Tuesday, July 10, 2001 6:37 PM
>> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';
>> > seamoby@cdma-2000.org
>> > 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:gkenward@nortelnetworks.com]
>> > Sent: Tuesday, July 10, 2001 8:53 AM
>> > To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
>> > 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: john.loughney@nokia.com [ mailto:john.loughney@nokia.com
>> > <mailto:john.loughney@nokia.com> ] 
>> > > Sent: Tuesday, July 10, 2001 1:59 AM 
>> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
>> > > 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 owner-seamoby@diameter.org  Wed Jul 11 15:41:22 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17457
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 15:41:07 -0400 (EDT)
Received: (qmail 2634 invoked by alias); 11 Jul 2001 19:08:02 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2627 invoked by uid 200); 11 Jul 2001 19:08:01 -0000
Received: (qmail 2608 invoked from network); 11 Jul 2001 19:07:56 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 19:07:56 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6BJHsb20505
	for <seamoby@cdma-2000.org>; Wed, 11 Jul 2001 15:17:55 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 11 Jul 2001 15:17:55 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Z33G>; Wed, 11 Jul 2001 15:17:56 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E28@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'James Kempf'" <James.Kempf@Sun.COM>, pcalhoun@diameter.org
Cc: Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Wed, 11 Jul 2001 15:17:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10A3E.2E3D8B80"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10A3E.2E3D8B80
Content-Type: text/plain;
	charset="iso-8859-1"

James:

 Sure, but this presumes a specific handover solution.

Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Wednesday, July 11, 2001 3:15 PM
> To: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;
> seamoby@cdma-2000.org
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> 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: seamoby-list@charizard.diameter.org
> >From: "Gary Kenward" <gkenward@nortelnetworks.com>
> >To: "'Pat Calhoun'" <pcalhoun@diameter.org>
> >Cc: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>, 
> "'john.loughney@nokia.com'" <john.loughney@nokia.com>, 
> seamoby@cdma-2000.org
> >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:pcalhoun@diameter.org]
> >> Sent: Wednesday, July 11, 2001 10:34 AM
> >> To: Kenward, Gary [WDLN2:AN10:EXCH]
> >> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';
> >> seamoby@cdma-2000.org
> >> 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:Madjid.Nakhjiri@motorola.com]
> >> > Sent: Tuesday, July 10, 2001 6:37 PM
> >> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';
> >> > seamoby@cdma-2000.org
> >> > 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:gkenward@nortelnetworks.com]
> >> > Sent: Tuesday, July 10, 2001 8:53 AM
> >> > To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
> >> > 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: john.loughney@nokia.com [ mailto:john.loughney@nokia.com
> >> > <mailto:john.loughney@nokia.com> ] 
> >> > > Sent: Tuesday, July 10, 2001 1:59 AM 
> >> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
> >> > > 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 
> >> > > 
> >> > 
> >> 
> 
> 

------_=_NextPart_001_01C10A3E.2E3D8B80
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  RE: Issue #4)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>James:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;Sure, but this presumes a specific handover solution.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

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

</BODY>
</HTML>
------_=_NextPart_001_01C10A3E.2E3D8B80--


From owner-seamoby@diameter.org  Wed Jul 11 15:52:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17712
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 15:52:31 -0400 (EDT)
Received: (qmail 4044 invoked by alias); 11 Jul 2001 19:24:31 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 4038 invoked by uid 200); 11 Jul 2001 19:24:31 -0000
Received: (qmail 4032 invoked from network); 11 Jul 2001 19:24:26 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 19:24:26 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA23478;
	Wed, 11 Jul 2001 12:34:24 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6BJYOt03189;
	Wed, 11 Jul 2001 12:34:24 -0700
X-mProtect:  Wed, 11 Jul 2001 12:34:24 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(P1.5 smtpdusbZE0; Wed, 11 Jul 2001 12:34:22 PDT
Message-ID: <3B4CAA3E.53767C96@cs.ucl.ac.uk>
Date: Wed, 11 Jul 2001 12:34:22 -0700
From: Theo Pagtzis <tpagtzis@cs.ucl.ac.uk>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: seamoby@diameter.org, seamoby_context@standards.nortelnetworks.com
Subject: [seamoby] New Internet Draft on proactive mobility over Mobile IPv6
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

   here is the link for our draft specification submitted yesterday to
the Internet drafts management group of IETF.

The draft specification is mainly targeting the MobileIP group, but it
bears great relevance to the Seamoby group and in particular the context
transfer design team. Hence the cross-posting.

The draft comprizes of two documents due to the complexity of schematics
and a formulae that accompany the design specified. For this reason the
reader is invited to read the ascii version but consult the postscript
version for schematics and formulae.

The postscript version is self contained while we are striving towards
making the ASCII version a stand alone document with its own text art
schematics and formulae.

Both ASCII and Postscript version of the draft can be found at


http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html

with details as follows:


        Title           :  A Framework for Proactive Mobility in Mobile
IPv6.
        Author(s)    :  Theo Pagtzis and Peter Kirstein
        Filename    :  draft-pagtzis-mobileip-proactivev6-00.txt/.ps
        Pages         :   78 (ASCII), 81 (postscript)
        Date           : 10-Jul-01



Any comments would be highly appreciated.


Many Thanks

Theo

UCL/Mobile Systems



From owner-seamoby@diameter.org  Wed Jul 11 16:17:30 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18731
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 16:17:13 -0400 (EDT)
Received: (qmail 5151 invoked by alias); 11 Jul 2001 20:03:57 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5145 invoked by uid 200); 11 Jul 2001 20:03:57 -0000
Received: (qmail 5140 invoked from network); 11 Jul 2001 20:03:55 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 20:03:55 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00274;
	Wed, 11 Jul 2001 14:14:39 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA07579;
	Wed, 11 Jul 2001 13:14:36 -0700 (PDT)
Message-Id: <200107112014.NAA07579@heliopolis.eng.sun.com>
Date: Wed, 11 Jul 2001 13:14:36 -0700 (PDT)
From: James Kempf <James.Kempf@sun.com>
Reply-To: James Kempf <James.Kempf@sun.com>
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
To: James.Kempf@sun.com, pcalhoun@diameter.org, gkenward@nortelnetworks.com
Cc: Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 4Lym7DhcX/MoCRRkvtemqQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

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

>From: "Gary Kenward" <gkenward@nortelnetworks.com>
>To: "'James Kempf'" <James.Kempf@sun.com>, pcalhoun@diameter.org
>Cc: Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com, 
seamoby@cdma-2000.org
>Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  
RE: Issue #4)
>Date: Wed, 11 Jul 2001 15:17:52 -0400
>
>James:
>
> Sure, but this presumes a specific handover solution.
>
>Gary
>
>> -----Original Message-----
>> From: James Kempf [mailto:James.Kempf@Sun.COM]
>> Sent: Wednesday, July 11, 2001 3:15 PM
>> To: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH]
>> Cc: Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;
>> seamoby@cdma-2000.org
>> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
>> comments) (SHOULD
>> be , RE: Issue #4)
>> 
>> 
>> 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: seamoby-list@charizard.diameter.org
>> >From: "Gary Kenward" <gkenward@nortelnetworks.com>
>> >To: "'Pat Calhoun'" <pcalhoun@diameter.org>
>> >Cc: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>, 
>> "'john.loughney@nokia.com'" <john.loughney@nokia.com>, 
>> seamoby@cdma-2000.org
>> >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:pcalhoun@diameter.org]
>> >> Sent: Wednesday, July 11, 2001 10:34 AM
>> >> To: Kenward, Gary [WDLN2:AN10:EXCH]
>> >> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';
>> >> seamoby@cdma-2000.org
>> >> 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:Madjid.Nakhjiri@motorola.com]
>> >> > Sent: Tuesday, July 10, 2001 6:37 PM
>> >> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';
>> >> > seamoby@cdma-2000.org
>> >> > 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:gkenward@nortelnetworks.com]
>> >> > Sent: Tuesday, July 10, 2001 8:53 AM
>> >> > To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
>> >> > 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: john.loughney@nokia.com [ mailto:john.loughney@nokia.com
>> >> > <mailto:john.loughney@nokia.com> ] 
>> >> > > Sent: Tuesday, July 10, 2001 1:59 AM 
>> >> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
>> >> > > 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 owner-seamoby@diameter.org  Wed Jul 11 16:38:46 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19389
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 16:37:45 -0400 (EDT)
Received: (qmail 5704 invoked by alias); 11 Jul 2001 20:17:22 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5698 invoked by uid 200); 11 Jul 2001 20:17:22 -0000
Received: (qmail 5693 invoked from network); 11 Jul 2001 20:17:18 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 20:17:18 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6BKRDb28681
	for <seamoby@cdma-2000.org>; Wed, 11 Jul 2001 16:27:13 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 11 Jul 2001 16:27:15 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2ZQFF>; Wed, 11 Jul 2001 16:27:17 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E2D@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'James Kempf'" <James.Kempf@sun.com>, pcalhoun@diameter.org
Cc: Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Wed, 11 Jul 2001 16:27:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10A47.E0F0FC90"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10A47.E0F0FC90
Content-Type: text/plain;
	charset="iso-8859-1"

James:

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.

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.

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 missing the critical state relationship between ct and ho
that you are alluding to.

Gary


> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@sun.com]
> Sent: Wednesday, July 11, 2001 4:15 PM
> To: James.Kempf@sun.com; pcalhoun@diameter.org; Kenward, Gary
> [WDLN2:AN10:EXCH]
> Cc: Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;
> seamoby@cdma-2000.org
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> 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
> 
> >From: "Gary Kenward" <gkenward@nortelnetworks.com>
> >To: "'James Kempf'" <James.Kempf@sun.com>, pcalhoun@diameter.org
> >Cc: Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com, 
> seamoby@cdma-2000.org
> >Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD be ,  
> RE: Issue #4)
> >Date: Wed, 11 Jul 2001 15:17:52 -0400
> >
> >James:
> >
> > Sure, but this presumes a specific handover solution.
> >
> >Gary
> >
> >> -----Original Message-----
> >> From: James Kempf [mailto:James.Kempf@Sun.COM]
> >> Sent: Wednesday, July 11, 2001 3:15 PM
> >> To: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH]
> >> Cc: Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;
> >> seamoby@cdma-2000.org
> >> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> >> comments) (SHOULD
> >> be , RE: Issue #4)
> >> 
> >> 
> >> 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: seamoby-list@charizard.diameter.org
> >> >From: "Gary Kenward" <gkenward@nortelnetworks.com>
> >> >To: "'Pat Calhoun'" <pcalhoun@diameter.org>
> >> >Cc: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>, 
> >> "'john.loughney@nokia.com'" <john.loughney@nokia.com>, 
> >> seamoby@cdma-2000.org
> >> >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:pcalhoun@diameter.org]
> >> >> Sent: Wednesday, July 11, 2001 10:34 AM
> >> >> To: Kenward, Gary [WDLN2:AN10:EXCH]
> >> >> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';
> >> >> seamoby@cdma-2000.org
> >> >> 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:Madjid.Nakhjiri@motorola.com]
> >> >> > Sent: Tuesday, July 10, 2001 6:37 PM
> >> >> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 
> 'john.loughney@nokia.com';
> >> >> > seamoby@cdma-2000.org
> >> >> > 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:gkenward@nortelnetworks.com]
> >> >> > Sent: Tuesday, July 10, 2001 8:53 AM
> >> >> > To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
> >> >> > 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: john.loughney@nokia.com [ 
mailto:john.loughney@nokia.com
>> >> > <mailto:john.loughney@nokia.com> ] 
>> >> > > Sent: Tuesday, July 10, 2001 1:59 AM 
>> >> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
>> >> > > 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 
>> >> > > 
>> >> > 
>> >> 
>> 
>> 


------_=_NextPart_001_01C10A47.E0F0FC90
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  RE: Issue #4)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>James:</FONT>
</P>

<P><FONT SIZE=2>Err, no. That's not what I was agreeing to. </FONT>
<BR><FONT SIZE=2>Once again, proactive ct should be driven by the initiation</FONT>
<BR><FONT SIZE=2>event, not the deadline event. It is preferable that context</FONT>
<BR><FONT SIZE=2>be installed before the traffic arrives at the newAR, but it's</FONT>
<BR><FONT SIZE=2>not a MUST requirement, and it certainly does not dictate that</FONT>
<BR><FONT SIZE=2>ho and ct protocols must be synchronous.</FONT>
</P>

<P><FONT SIZE=2>And I see no reason for requiring handover signalling to complete</FONT>
<BR><FONT SIZE=2>before ct (MIP may require it, but that's would be a potential </FONT>
<BR><FONT SIZE=2>MIP weakness, were it true). Even if this is true, it applies only</FONT>
<BR><FONT SIZE=2>to reactive ct, and contradicts the purpose of proactive ct.</FONT>
</P>

<P><FONT SIZE=2>You seem to be implying that there is some dire consequence to be</FONT>
<BR><FONT SIZE=2>realized if a ct happens but an ho doesn't. At best, the new AR</FONT>
<BR><FONT SIZE=2>will be holding onto useless context. At worse, the new AR may</FONT>
<BR><FONT SIZE=2>reserve resources that could be used elsewhere. Either situation </FONT>
<BR><FONT SIZE=2>seems resolvable with some sort of &quot;life timer&quot; and garbage </FONT>
<BR><FONT SIZE=2>collection. It does not imply that the two protocols be </FONT>
<BR><FONT SIZE=2>synchronous.</FONT>
</P>

<P><FONT SIZE=2>I'm missing the critical state relationship between ct and ho</FONT>
<BR><FONT SIZE=2>that you are alluding to.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>
<BR>

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

</BODY>
</HTML>
------_=_NextPart_001_01C10A47.E0F0FC90--


From owner-seamoby@diameter.org  Wed Jul 11 16:54:13 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19883
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 16:53:46 -0400 (EDT)
Received: (qmail 6043 invoked by alias); 11 Jul 2001 20:30:21 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6037 invoked by uid 200); 11 Jul 2001 20:30:20 -0000
Received: (qmail 6029 invoked by uid 500); 11 Jul 2001 20:30:16 -0000
Date: Wed, 11 Jul 2001 13:30:16 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)
Message-ID: <20010711133016.D5588@charizard.diameter.org>
Mail-Followup-To: Gary Kenward <gkenward@nortelnetworks.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>,
	'Nakhjiri Madjid-MNAKHJI1' <Madjid.Nakhjiri@motorola.com>,
	"'john.loughney@nokia.com'" <john.loughney@nokia.com>,
	seamoby@cdma-2000.org
References: <9FBD322B7824D511B36900508BF93C9C9F5E24@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E24@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Wed, Jul 11, 2001 at 03:00:32PM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Wed, Jul 11, 2001 at 03:00:32PM -0400, Gary Kenward wrote:
> 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.

Good. So far we are in agreement.

> 
>   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?

PatC
> 
> 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:pcalhoun@diameter.org]
> > Sent: Wednesday, July 11, 2001 10:34 AM
> > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';
> > seamoby@cdma-2000.org
> > 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:Madjid.Nakhjiri@motorola.com]
> > > Sent: Tuesday, July 10, 2001 6:37 PM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';
> > > seamoby@cdma-2000.org
> > > 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:gkenward@nortelnetworks.com]
> > > Sent: Tuesday, July 10, 2001 8:53 AM
> > > To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
> > > 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: john.loughney@nokia.com [ mailto:john.loughney@nokia.com
> > > <mailto:john.loughney@nokia.com> ] 
> > > > Sent: Tuesday, July 10, 2001 1:59 AM 
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
> > > > 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 owner-seamoby@diameter.org  Wed Jul 11 17:01:15 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20426
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 17:01:11 -0400 (EDT)
Received: (qmail 6093 invoked by alias); 11 Jul 2001 20:31:42 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6087 invoked by uid 200); 11 Jul 2001 20:31:41 -0000
Received: (qmail 6078 invoked by uid 500); 11 Jul 2001 20:31:37 -0000
Date: Wed, 11 Jul 2001 13:31:37 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'James Kempf'" <James.Kempf@sun.com>, pcalhoun@diameter.org,
        Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)
Message-ID: <20010711133137.E5588@charizard.diameter.org>
Mail-Followup-To: Gary Kenward <gkenward@nortelnetworks.com>,
	'James Kempf' <James.Kempf@sun.com>, pcalhoun@diameter.org,
	Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
	seamoby@cdma-2000.org
References: <9FBD322B7824D511B36900508BF93C9C9F5E2D@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E2D@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Wed, Jul 11, 2001 at 04:27:17PM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

I second Gary's comment below.

PatC
On Wed, Jul 11, 2001 at 04:27:17PM -0400, Gary Kenward wrote:
> James:
> 
> 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.
> 
> 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.
> 
> 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 missing the critical state relationship between ct and ho
> that you are alluding to.
> 
> Gary
> 
> 
> > -----Original Message-----
> > From: James Kempf [mailto:James.Kempf@sun.com]
> > Sent: Wednesday, July 11, 2001 4:15 PM
> > To: James.Kempf@sun.com; pcalhoun@diameter.org; Kenward, Gary
> > [WDLN2:AN10:EXCH]
> > Cc: Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;
> > seamoby@cdma-2000.org
> > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> > comments) (SHOULD
> > be , RE: Issue #4)
> > 
> > 
> > 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
> > 
> > >From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > >To: "'James Kempf'" <James.Kempf@sun.com>, pcalhoun@diameter.org
> > >Cc: Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com, 
> > seamoby@cdma-2000.org
> > >Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> > comments) (SHOULD be ,  
> > RE: Issue #4)
> > >Date: Wed, 11 Jul 2001 15:17:52 -0400
> > >
> > >James:
> > >
> > > Sure, but this presumes a specific handover solution.
> > >
> > >Gary
> > >
> > >> -----Original Message-----
> > >> From: James Kempf [mailto:James.Kempf@Sun.COM]
> > >> Sent: Wednesday, July 11, 2001 3:15 PM
> > >> To: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH]
> > >> Cc: Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;
> > >> seamoby@cdma-2000.org
> > >> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> > >> comments) (SHOULD
> > >> be , RE: Issue #4)
> > >> 
> > >> 
> > >> 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: seamoby-list@charizard.diameter.org
> > >> >From: "Gary Kenward" <gkenward@nortelnetworks.com>
> > >> >To: "'Pat Calhoun'" <pcalhoun@diameter.org>
> > >> >Cc: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>, 
> > >> "'john.loughney@nokia.com'" <john.loughney@nokia.com>, 
> > >> seamoby@cdma-2000.org
> > >> >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:pcalhoun@diameter.org]
> > >> >> Sent: Wednesday, July 11, 2001 10:34 AM
> > >> >> To: Kenward, Gary [WDLN2:AN10:EXCH]
> > >> >> Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';
> > >> >> seamoby@cdma-2000.org
> > >> >> 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:Madjid.Nakhjiri@motorola.com]
> > >> >> > Sent: Tuesday, July 10, 2001 6:37 PM
> > >> >> > To: Kenward, Gary [WDLN2:AN10:EXCH]; 
> > 'john.loughney@nokia.com';
> > >> >> > seamoby@cdma-2000.org
> > >> >> > 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:gkenward@nortelnetworks.com]
> > >> >> > Sent: Tuesday, July 10, 2001 8:53 AM
> > >> >> > To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
> > >> >> > 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: john.loughney@nokia.com [ 
> mailto:john.loughney@nokia.com
> >> >> > <mailto:john.loughney@nokia.com> ] 
> >> >> > > Sent: Tuesday, July 10, 2001 1:59 AM 
> >> >> > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
> >> >> > > 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 owner-seamoby@diameter.org  Wed Jul 11 17:06:47 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20624
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 17:06:47 -0400 (EDT)
Received: (qmail 6141 invoked by alias); 11 Jul 2001 20:33:04 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6135 invoked by uid 200); 11 Jul 2001 20:33:03 -0000
Received: (qmail 6130 invoked by uid 500); 11 Jul 2001 20:33:01 -0000
Date: Wed, 11 Jul 2001 13:33:01 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: James Kempf <James.Kempf@Sun.COM>
Cc: rajeev@IPRG.nokia.com, katawal2200@home.com, seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-   Phase CT
Message-ID: <20010711133301.F5588@charizard.diameter.org>
Mail-Followup-To: James Kempf <James.Kempf@Sun.COM>, rajeev@IPRG.nokia.com,
	katawal2200@home.com, seamoby@cdma-2000.org
References: <200107111913.MAA03927@heliopolis.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200107111913.MAA03927@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Wed, Jul 11, 2001 at 12:13:14PM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Wed, Jul 11, 2001 at 12:13:14PM -0700, James Kempf wrote:
> 
> >I think we need to allow for this by not linking CT to IP level handover of
> >a particular mobility solution.  The establishment of the new forwarding
> >path by the parentAR could be used as a Trigger to start CT.
> >
> 
> What about making it possible to define a binding between a particular
> mobility solution and CT, and have a general framework?

Right, that's what I was proposing some time back. A profile could
be written up for each mobility solution, which describes how 
relationship, how CT is invoked, etc.

PatC


From owner-seamoby@diameter.org  Wed Jul 11 17:09:23 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20719
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 17:09:23 -0400 (EDT)
Received: (qmail 6169 invoked by alias); 11 Jul 2001 20:33:36 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6162 invoked by uid 200); 11 Jul 2001 20:33:35 -0000
Received: (qmail 6153 invoked from network); 11 Jul 2001 20:33:28 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 20:33:28 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA16294;
	Wed, 11 Jul 2001 13:44:00 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA09231;
	Wed, 11 Jul 2001 13:43:51 -0700 (PDT)
Message-Id: <200107112043.NAA09231@heliopolis.eng.sun.com>
Date: Wed, 11 Jul 2001 13:43:51 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
To: James.Kempf@Sun.COM, pcalhoun@diameter.org, gkenward@nortelnetworks.com
Cc: Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: aPvZ/YGWCFoXKSrTX7UuLg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

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 owner-seamoby@diameter.org  Wed Jul 11 17:14:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20771
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 17:14:09 -0400 (EDT)
Received: (qmail 6293 invoked by alias); 11 Jul 2001 20:38:30 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6287 invoked by uid 200); 11 Jul 2001 20:38:29 -0000
Received: (qmail 6279 invoked from network); 11 Jul 2001 20:38:24 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 20:38:24 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA28671;
	Wed, 11 Jul 2001 13:48:30 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6BKmTM17665;
	Wed, 11 Jul 2001 13:48:29 -0700
X-mProtect:  Wed, 11 Jul 2001 13:48:29 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(P1.5 smtpdbx0AgH; Wed, 11 Jul 2001 13:48:27 PDT
Message-ID: <3B4CBB9C.5676AB95@cs.ucl.ac.uk>
Date: Wed, 11 Jul 2001 13:48:28 -0700
From: Theo Pagtzis <tpagtzis@cs.ucl.ac.uk>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
CC: seamoby-context@cdma-2000.org, mobile-ip@sunroof.eng.sun.com,
        seamoby@diameter.org
Subject: [seamoby] Re: [seamoby-context] New Internet Draft on proactive mobility over 
 Mobile IPv6
References: <35DBB8B7AC89D4118E98009027B1009B017A9E86@IL27EXM10.cig.mot.com>
Content-Type: multipart/alternative;
 boundary="------------AE337E9F71088DBE75784F69"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------AE337E9F71088DBE75784F69
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Madjid,

    Strange since it worked for me in my unix box in the US.

Anyway, it should also be reachable by accessing:

http://www.cs.ucl.ac.uk/staff/t.pagtzis/


then select the Docs section

and from that select the draft either ASCII or Postscript version.


Cheers


Theo

UCL/Mobile Systems


Nakhjiri Madjid-MNAKHJI1 wrote:

> Theo,
>
> your link doesn't work.
>
> Madjid
>
> -----Original Message-----
> From: Theo Pagtzis [mailto:tpagtzis@cs.ucl.ac.uk]
> Sent: Wednesday, July 11, 2001 2:56 PM
> To: seamoby-context@cdma-2000.org
> Subject: [seamoby-context] New Internet Draft on proactive mobility over
> Mobile IPv6
>
> Hi all,
>
>    here is the link for our draft specification submitted yesterday to
> the Internet drafts management group of IETF.
>
> The draft specification is mainly targeting the MobileIP group, but it
> bears great relevance to the Seamoby group and in particular the context
> transfer design team.
>
> The draft comprizes of two documents due to the complexity of schematics
> and a formulae that accompany the design specified. For this reason the
> reader is invited to read the ascii version but consult the postscript
> version for schematics and formulae.
>
> The postscript version is self contained while we are striving towards
> making the ASCII version a stand alone document with its own text art
> schematics and formulae.
>
> Both ASCII and Postscript version of the draft can be found at
>
> http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html
>
> with details as follows:
>
>         Title     :  A Framework for Proactive Mobility in Mobile IPv6.
>         Author(s) :  Theo Pagtzis and Peter Kirstein
>         Filename  :  draft-pagtzis-mobileip-proactivev6-00.txt/.ps
>         Pages     :  78 (ASCII), 81 (postscript)
>         Date      :  10-Jul-01
>
> Any comments would be highly appreciated.
>
> Many Thanks
>
> Theo
>
> UCL/Mobile Systems

--------------AE337E9F71088DBE75784F69
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#330000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Hi Madjid,
<p>&nbsp;&nbsp;&nbsp; Strange since it worked for me in my unix box in
the US.
<p>Anyway, it should also be reachable by accessing:
<p><a href="http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html">http://www.cs.ucl.ac.uk/staff/t.pagtzis/</a>
<br><a href="http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html"></a>&nbsp;
<p>then select the Docs section
<p>and from that select the draft either ASCII or Postscript version.
<br>&nbsp;
<p>Cheers
<br>&nbsp;
<p>Theo
<p>UCL/Mobile Systems
<br>&nbsp;
<p>Nakhjiri Madjid-MNAKHJI1 wrote:
<blockquote TYPE=CITE>Theo,
<p>your link doesn't work.
<p>Madjid
<p>-----Original Message-----
<br>From: Theo Pagtzis [<a href="mailto:tpagtzis@cs.ucl.ac.uk">mailto:tpagtzis@cs.ucl.ac.uk</a>]
<br>Sent: Wednesday, July 11, 2001 2:56 PM
<br>To: seamoby-context@cdma-2000.org
<br>Subject: [seamoby-context] New Internet Draft on proactive mobility
over
<br>Mobile IPv6
<p>Hi all,
<p>&nbsp;&nbsp; here is the link for our draft specification submitted
yesterday to
<br>the Internet drafts management group of IETF.
<p>The draft specification is mainly targeting the MobileIP group, but
it
<br>bears great relevance to the Seamoby group and in particular the context
<br>transfer design team.
<p>The draft comprizes of two documents due to the complexity of schematics
<br>and a formulae that accompany the design specified. For this reason
the
<br>reader is invited to read the ascii version but consult the postscript
<br>version for schematics and formulae.
<p>The postscript version is self contained while we are striving towards
<br>making the ASCII version a stand alone document with its own text art
<br>schematics and formulae.
<p>Both ASCII and Postscript version of the draft can be found at
<p><a href="http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html">http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html</a>
<p>with details as follows:
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp; A Framework for Proactive Mobility in Mobile IPv6.
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Author(s) :&nbsp; Theo Pagtzis
and Peter Kirstein
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filename&nbsp; :&nbsp; draft-pagtzis-mobileip-proactivev6-00.txt/.ps
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp; 78 (ASCII), 81 (postscript)
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:&nbsp; 10-Jul-01
<p>Any comments would be highly appreciated.
<p>Many Thanks
<p>Theo
<p>UCL/Mobile Systems</blockquote>

</body>
</html>

--------------AE337E9F71088DBE75784F69--



From owner-seamoby@diameter.org  Wed Jul 11 17:18:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20821
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 17:18:08 -0400 (EDT)
Received: (qmail 6509 invoked by alias); 11 Jul 2001 20:41:44 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6503 invoked by uid 200); 11 Jul 2001 20:41:44 -0000
Received: (qmail 6491 invoked by uid 500); 11 Jul 2001 20:41:41 -0000
Date: Wed, 11 Jul 2001 13:41:41 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: James Kempf <James.Kempf@Sun.COM>
Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com,
        Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
Message-ID: <20010711134140.G5588@charizard.diameter.org>
Mail-Followup-To: James Kempf <James.Kempf@Sun.COM>, pcalhoun@diameter.org,
	gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
	john.loughney@nokia.com, seamoby@cdma-2000.org
References: <200107112043.NAA09231@heliopolis.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200107112043.NAA09231@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Wed, Jul 11, 2001 at 01:43:51PM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

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 owner-seamoby@diameter.org  Wed Jul 11 17:23:34 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20963
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 17:23:33 -0400 (EDT)
Received: (qmail 9070 invoked by alias); 11 Jul 2001 21:07:43 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 9063 invoked by uid 200); 11 Jul 2001 21:07:42 -0000
Received: (qmail 9044 invoked from network); 11 Jul 2001 21:07:36 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 21:07:36 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1KNXQ>; Wed, 11 Jul 2001 17:17:51 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445591@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'James Kempf'" <James.Kempf@Sun.COM>, pcalhoun@diameter.org,
        gkenward@nortelnetworks.com
Cc: Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,          RE: Issue #4)
Date: Wed, 11 Jul 2001 17:17:47 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

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 owner-seamoby@diameter.org  Wed Jul 11 18:07:02 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22353
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 18:07:00 -0400 (EDT)
Received: (qmail 10102 invoked by alias); 11 Jul 2001 21:55:20 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 10096 invoked by uid 200); 11 Jul 2001 21:55:20 -0000
Received: (qmail 10091 invoked from network); 11 Jul 2001 21:55:18 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 21:55:18 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA22508;
	Wed, 11 Jul 2001 15:06:04 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA13748;
	Wed, 11 Jul 2001 15:05:57 -0700 (PDT)
Message-Id: <200107112205.PAA13748@heliopolis.eng.sun.com>
Date: Wed, 11 Jul 2001 15:05:57 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
To: James.Kempf@Sun.COM, pcalhoun@diameter.org
Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com,
        Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Ryv1n0BK/TqITf+0yGW+Zw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

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)
or together is an implementation decision. I suppose whoever does
the MIP binding will determine that.

		jak

>Delivered-To: seamoby-list@charizard.diameter.org
>Date: Wed, 11 Jul 2001 13:41:41 -0700
>From: Pat Calhoun <pcalhoun@diameter.org>
>To: James Kempf <James.Kempf@Sun.COM>
>Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com, 
Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com, seamoby@cdma-2000.org
>Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,    
      RE: Issue #4)
>Mail-Followup-To: James Kempf <James.Kempf@Sun.COM>, pcalhoun@diameter.org, 
gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com, 
john.loughney@nokia.com, seamoby@cdma-2000.org
>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 owner-seamoby@diameter.org  Wed Jul 11 18:20:40 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22598
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 18:20:38 -0400 (EDT)
Received: (qmail 10651 invoked by alias); 11 Jul 2001 22:09:25 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 10645 invoked by uid 200); 11 Jul 2001 22:09:25 -0000
Received: (qmail 10640 invoked from network); 11 Jul 2001 22:09:23 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 22:09:23 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA27938;
	Wed, 11 Jul 2001 15:20:08 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA14645;
	Wed, 11 Jul 2001 15:20:07 -0700 (PDT)
Message-Id: <200107112220.PAA14645@heliopolis.eng.sun.com>
Date: Wed, 11 Jul 2001 15:20:07 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [seamoby] Re: Extensions to FMIPv6
To: james.kempf@Sun.COM, rajeev@iprg.nokia.com
Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org,
        charliep@iprg.nokia.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 07fVpQjy+luxwXZ4m7WgXw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Rajeev,

I have not looked at it in a while, but I will again. Thanx.

		jak
		
>X-mProtect: Tue, 10 Jul 2001 17:03:18 -0700 Nokia Silicon Valley Messaging 
Protection
>Date: Tue, 10 Jul 2001 17:03:17 -0700
>From: Rajeev Koodli <rajeev@iprg.nokia.com>
>To: James Kempf <james.kempf@Sun.COM>
>CC: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org, 
charliep@iprg.nokia.com
>Subject: Re: Extensions to FMIPv6
>
>
>Hello James,
>
>I wonder if you had a look at our CT draft:
>draft-koodli-seamoby-ctv6-00.txt..
>
>We don't have discussion about L2 triggers in that draft, but,
>definitely context transfers and handovers. Indeed, we describe how to
>do context transfers with FMIPv6. Our approach clearly separates what a
>feature context is from the message in which it is carried so that one
>could use them in appropriate messages, including HI and HAck. We plan
>to submit a revised version for London IETF.
>
>Regards,
>
>-Rajeev
>
>
>James Kempf wrote:
>
>> John,
>>
>> (Folks, sorry for the cross posting, please try to respond on
>> one or the other list unless the topic affects both...)
>>
>> There is a draft in preparation with people from both Seamoby
>> and MIP on the author list. These are people with whom
>> I have talked and who have expressed interest in working on such a
>> draft over the last year. The draft has a section on L2 triggers
>> that came out of the MIP fast handoff work, then a section
>> that describes connections with Seamoby context transfer.
>> I expect we will have it complete by next Fri.'s 00 deadline.
>>
>> We have already talked to the MIP WG chairs about getting
>> time on the agenda to discuss the draft, what I'd like
>> to suggest is that we do the same for Seamoby. That
>> will give both WGs the opportunity to review and comment
>> on the draft. I will talk with Pat about that when he gets
>> back from vacation.
>>
>>                  jak
>>
>> At 10:13 AM 7/4/01 +0300, john.loughney@nokia.com wrote:
>> >Hi James,
>> >
>> > > In fact, I am preparing just such a draft as we speak. The
>> > > intent is to take the material from the BETH draft and from
>> > > the FMIPv4 draft and perhaps add something on the link with
>> > > Seamoby context transfer.
>> >
>> >I think this would be extremely worthwhile.  It seems that
>> >SeaMoby is currently struggling over terminology about
>> >triggers, etc. with respect to handovers.  I'd even suggest
>> >that interested parties from both MIP & SeaMoby get together
>> >in London to discuss how to move forward.  Perhaps it would
>> >be a good thing if MIP & SeaMoby could work together on this
>> >issue - in order to assure that the resultant work suits both
>> >groups.
>> >
>> >best regards,
>> >John
>



From owner-seamoby@diameter.org  Wed Jul 11 18:34:15 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23164
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 18:34:12 -0400 (EDT)
Received: (qmail 11180 invoked by alias); 11 Jul 2001 22:22:14 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 11174 invoked by uid 200); 11 Jul 2001 22:22:14 -0000
Received: (qmail 11166 invoked from network); 11 Jul 2001 22:22:11 -0000
Received: from femail16.sdc1.sfba.home.com (24.0.95.143)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 22:22:11 -0000
Received: from cr851003a ([24.157.232.166]) by femail16.sdc1.sfba.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010711223258.PURA12729.femail16.sdc1.sfba.home.com@cr851003a>;
          Wed, 11 Jul 2001 15:32:58 -0700
Message-ID: <011601c10ac0$8770cdc0$a6e89d18@slnt1.on.wave.home.com>
From: "Kulwinder Atwal" <katawal2200@home.com>
To: "James Kempf" <James.Kempf@Sun.COM>, <pcalhoun@diameter.org>
Cc: <pcalhoun@diameter.org>, <gkenward@nortelnetworks.com>,
        <Madjid.Nakhjiri@motorola.com>, <john.loughney@nokia.com>,
        <seamoby@cdma-2000.org>
References: <200107112205.PAA13748@heliopolis.eng.sun.com>
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
Date: Thu, 12 Jul 2001 06:50:55 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "James Kempf" <James.Kempf@Sun.COM>
To: <James.Kempf@Sun.COM>; <pcalhoun@diameter.org>
Cc: <pcalhoun@diameter.org>; <gkenward@nortelnetworks.com>;
<Madjid.Nakhjiri@motorola.com>; <john.loughney@nokia.com>;
<seamoby@cdma-2000.org>
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
>
> >Delivered-To: seamoby-list@charizard.diameter.org
> >Date: Wed, 11 Jul 2001 13:41:41 -0700
> >From: Pat Calhoun <pcalhoun@diameter.org>
> >To: James Kempf <James.Kempf@Sun.COM>
> >Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com,
> Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
seamoby@cdma-2000.org
> >Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD
be ,
>       RE: Issue #4)
> >Mail-Followup-To: James Kempf <James.Kempf@Sun.COM>,
pcalhoun@diameter.org,
> gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
> john.loughney@nokia.com, seamoby@cdma-2000.org
> >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 owner-seamoby@diameter.org  Wed Jul 11 18:44:30 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23382
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 18:43:37 -0400 (EDT)
Received: (qmail 11707 invoked by alias); 11 Jul 2001 22:31:27 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 11701 invoked by uid 200); 11 Jul 2001 22:31:26 -0000
Received: (qmail 11696 invoked from network); 11 Jul 2001 22:31:24 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 22:31:24 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA14123;
	Wed, 11 Jul 2001 16:42:09 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA15903;
	Wed, 11 Jul 2001 15:42:10 -0700 (PDT)
Message-Id: <200107112242.PAA15903@heliopolis.eng.sun.com>
Date: Wed, 11 Jul 2001 15:42:09 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
To: James.Kempf@Sun.COM, pcalhoun@diameter.org, katawal2200@home.com
Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com,
        Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Za4OhER9ePCO24vLIsY6nA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

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,
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" <katawal2200@home.com>
>To: "James Kempf" <James.Kempf@Sun.COM>, <pcalhoun@diameter.org>
>Cc: <pcalhoun@diameter.org>, <gkenward@nortelnetworks.com>, 
<Madjid.Nakhjiri@motorola.com>, <john.loughney@nokia.com>, 
<seamoby@cdma-2000.org>
>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" <James.Kempf@Sun.COM>
>To: <James.Kempf@Sun.COM>; <pcalhoun@diameter.org>
>Cc: <pcalhoun@diameter.org>; <gkenward@nortelnetworks.com>;
><Madjid.Nakhjiri@motorola.com>; <john.loughney@nokia.com>;
><seamoby@cdma-2000.org>
>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
>>
>> >Delivered-To: seamoby-list@charizard.diameter.org
>> >Date: Wed, 11 Jul 2001 13:41:41 -0700
>> >From: Pat Calhoun <pcalhoun@diameter.org>
>> >To: James Kempf <James.Kempf@Sun.COM>
>> >Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com,
>> Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
>seamoby@cdma-2000.org
>> >Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD
>be ,
>>       RE: Issue #4)
>> >Mail-Followup-To: James Kempf <James.Kempf@Sun.COM>,
>pcalhoun@diameter.org,
>> gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
>> john.loughney@nokia.com, seamoby@cdma-2000.org
>> >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 owner-seamoby@diameter.org  Wed Jul 11 18:47:34 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23522
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 18:47:33 -0400 (EDT)
Received: (qmail 11828 invoked by alias); 11 Jul 2001 22:32:21 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 11822 invoked by uid 200); 11 Jul 2001 22:32:21 -0000
Received: (qmail 11811 invoked from network); 11 Jul 2001 22:32:17 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 22:32:17 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA07211;
	Wed, 11 Jul 2001 15:42:32 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6BMgVx07172;
	Wed, 11 Jul 2001 15:42:31 -0700
X-mProtect:  Wed, 11 Jul 2001 15:42:31 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdtweYuR; Wed, 11 Jul 2001 15:42:30 PDT
Message-ID: <3B4CD651.482BFFC4@iprg.nokia.com>
Date: Wed, 11 Jul 2001 15:42:25 -0700
From: Rajeev Koodli <rajeev@IPRG.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: James Kempf <James.Kempf@Sun.COM>
CC: pcalhoun@diameter.org, gkenward@nortelnetworks.com,
        Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org, charliep@IPRG.nokia.com
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be 
 ,          RE: Issue #4)
References: <200107112043.NAA09231@heliopolis.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello James,


James Kempf wrote:

>
> 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
>

Rajeev: We have gone through similar exercises, and we believe that doing CT
along with handover signaling (esp FMIPv6) is beneficial in multiple ways. May
be this is not a requirement, but must not be excluded.

>
> >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,
>

Rajeev: This can be done using HI message.

>         2) The relevent CT for nAR to install,

Rajeev: You can send the contexts as options in the HI message

>
>         3) Tunneled packets until MN gets around to changing its CoA.

Rajeev: In FMIPv6, if the MN has received a F-BAck, it already knows what its
new CoA is. If not, FMIPv6 says you need to send a F-NA which would work.
There are other optmizations that are possible as well.
In any case, the result of HI-HAck sequence is that after the old AR receives
a BU, there is already a tunnel established.

>
>
> 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.
>

Rajeev: All these scenarios can be avoided if you do CT _along-with_ handover
signaling. That does not mean that that's the only way to do CT. We explain
how to do CT with handover signaling in

draft-koodli-seamoby-ctv6-00.txt

which was submitted in February. [FYI, its precursor was submitted to
Pittsburgh IETF] There is also a companion draft

draft-koodli-seamoby-hc-relocate-00.txt

I suggest you take a look at them. They should address a lot of the things you
are referring to.

Regards,

-Rajeev


>
> What am I missing?
>
>                 jak



From owner-seamoby@diameter.org  Wed Jul 11 19:21:34 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24462
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 19:21:33 -0400 (EDT)
Received: (qmail 12860 invoked by alias); 11 Jul 2001 23:10:34 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 12854 invoked by uid 200); 11 Jul 2001 23:10:33 -0000
Received: (qmail 12840 invoked by uid 500); 11 Jul 2001 23:10:28 -0000
Date: Wed, 11 Jul 2001 16:10:28 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: "'James Kempf'" <James.Kempf@Sun.COM>, pcalhoun@diameter.org,
        gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
        john.loughney@nokia.com, seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
Message-ID: <20010711161028.L5588@charizard.diameter.org>
Mail-Followup-To: Phillip Neumiller <PNeumiller@MeshNetworks.com>,
	'James Kempf' <James.Kempf@Sun.COM>, pcalhoun@diameter.org,
	gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
	john.loughney@nokia.com, seamoby@cdma-2000.org
References: <0DF9FBC42474A24CA50F7A27FB08E048445591@meshpdc.meshnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E048445591@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Wed, Jul 11, 2001 at 05:17:47PM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Wed, Jul 11, 2001 at 05:17:47PM -0400, Phillip Neumiller wrote:
> Is there any co-dependence between CT and "succesful" handovers?
> I think so.  Seperating the messages makes handover less reliable.

Only if the network is unreliable.

> 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.

If the link between the ARs are congested, then I would argue
that the single combined MIP/CT message will be subjected to
the same jitter and congestion conditions you'd experience
with a dual approach. So, I have a hard time convincing myself
that we should be looking at tying CT to MIP to get around
poor network design.

PatC


From owner-seamoby@diameter.org  Wed Jul 11 19:48:30 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25113
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 19:48:24 -0400 (EDT)
Received: (qmail 13510 invoked by alias); 11 Jul 2001 23:35:45 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 13504 invoked by uid 200); 11 Jul 2001 23:35:45 -0000
Received: (qmail 13499 invoked from network); 11 Jul 2001 23:35:42 -0000
Received: from femail2.rdc1.on.home.com (24.2.9.89)
  by c900656-a.plstn1.sfba.home.com with SMTP; 11 Jul 2001 23:35:42 -0000
Received: from cr851003a ([24.157.232.166]) by femail2.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010711234623.UGVH21541.femail2.rdc1.on.home.com@cr851003a>;
          Wed, 11 Jul 2001 16:46:23 -0700
Message-ID: <000901c10aca$cf85ab80$a6e89d18@slnt1.on.wave.home.com>
From: "Kulwinder Atwal" <katawal2200@home.com>
To: "James Kempf" <James.Kempf@Sun.COM>, <pcalhoun@diameter.org>
Cc: <pcalhoun@diameter.org>, <gkenward@nortelnetworks.com>,
        <Madjid.Nakhjiri@motorola.com>, <john.loughney@nokia.com>,
        <seamoby@cdma-2000.org>
References: <200107112242.PAA15903@heliopolis.eng.sun.com>
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
Date: Thu, 12 Jul 2001 07:58:42 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "James Kempf" <James.Kempf@Sun.COM>
To: <James.Kempf@Sun.COM>; <pcalhoun@diameter.org>; <katawal2200@home.com>
Cc: <pcalhoun@diameter.org>; <gkenward@nortelnetworks.com>;
<Madjid.Nakhjiri@motorola.com>; <john.loughney@nokia.com>;
<seamoby@cdma-2000.org>
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" <katawal2200@home.com>
> >To: "James Kempf" <James.Kempf@Sun.COM>, <pcalhoun@diameter.org>
> >Cc: <pcalhoun@diameter.org>, <gkenward@nortelnetworks.com>,
> <Madjid.Nakhjiri@motorola.com>, <john.loughney@nokia.com>,
> <seamoby@cdma-2000.org>
> >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" <James.Kempf@Sun.COM>
> >To: <James.Kempf@Sun.COM>; <pcalhoun@diameter.org>
> >Cc: <pcalhoun@diameter.org>; <gkenward@nortelnetworks.com>;
> ><Madjid.Nakhjiri@motorola.com>; <john.loughney@nokia.com>;
> ><seamoby@cdma-2000.org>
> >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
> >>
> >> >Delivered-To: seamoby-list@charizard.diameter.org
> >> >Date: Wed, 11 Jul 2001 13:41:41 -0700
> >> >From: Pat Calhoun <pcalhoun@diameter.org>
> >> >To: James Kempf <James.Kempf@Sun.COM>
> >> >Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com,
> >> Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
> >seamoby@cdma-2000.org
> >> >Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
(SHOULD
> >be ,
> >>       RE: Issue #4)
> >> >Mail-Followup-To: James Kempf <James.Kempf@Sun.COM>,
> >pcalhoun@diameter.org,
> >> gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
> >> john.loughney@nokia.com, seamoby@cdma-2000.org
> >> >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 owner-seamoby@diameter.org  Wed Jul 11 20:16:15 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25759
	for <seamoby-archive@odin.ietf.org>; Wed, 11 Jul 2001 20:16:14 -0400 (EDT)
Received: (qmail 13778 invoked by alias); 11 Jul 2001 23:38:11 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 13771 invoked by uid 200); 11 Jul 2001 23:38:10 -0000
Received: (qmail 13758 invoked by uid 500); 11 Jul 2001 23:38:06 -0000
Date: Wed, 11 Jul 2001 16:38:06 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Kulwinder Atwal <katawal2200@home.com>
Cc: James Kempf <James.Kempf@Sun.COM>, pcalhoun@diameter.org,
        gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
        john.loughney@nokia.com, seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
Message-ID: <20010711163806.P5588@charizard.diameter.org>
Mail-Followup-To: Kulwinder Atwal <katawal2200@home.com>,
	James Kempf <James.Kempf@Sun.COM>, pcalhoun@diameter.org,
	gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
	john.loughney@nokia.com, seamoby@cdma-2000.org
References: <200107112242.PAA15903@heliopolis.eng.sun.com> <000901c10aca$cf85ab80$a6e89d18@slnt1.on.wave.home.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <000901c10aca$cf85ab80$a6e89d18@slnt1.on.wave.home.com>; from katawal2200@home.com on Thu, Jul 12, 2001 at 07:58:42AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

Just in case you didn't notice, you are both in agreement :)

PatC
On Thu, Jul 12, 2001 at 07:58:42AM -0400, Kulwinder Atwal wrote:
> 
> ----- Original Message -----
> From: "James Kempf" <James.Kempf@Sun.COM>
> To: <James.Kempf@Sun.COM>; <pcalhoun@diameter.org>; <katawal2200@home.com>
> Cc: <pcalhoun@diameter.org>; <gkenward@nortelnetworks.com>;
> <Madjid.Nakhjiri@motorola.com>; <john.loughney@nokia.com>;
> <seamoby@cdma-2000.org>
> 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" <katawal2200@home.com>
> > >To: "James Kempf" <James.Kempf@Sun.COM>, <pcalhoun@diameter.org>
> > >Cc: <pcalhoun@diameter.org>, <gkenward@nortelnetworks.com>,
> > <Madjid.Nakhjiri@motorola.com>, <john.loughney@nokia.com>,
> > <seamoby@cdma-2000.org>
> > >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" <James.Kempf@Sun.COM>
> > >To: <James.Kempf@Sun.COM>; <pcalhoun@diameter.org>
> > >Cc: <pcalhoun@diameter.org>; <gkenward@nortelnetworks.com>;
> > ><Madjid.Nakhjiri@motorola.com>; <john.loughney@nokia.com>;
> > ><seamoby@cdma-2000.org>
> > >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
> > >>
> > >> >Delivered-To: seamoby-list@charizard.diameter.org
> > >> >Date: Wed, 11 Jul 2001 13:41:41 -0700
> > >> >From: Pat Calhoun <pcalhoun@diameter.org>
> > >> >To: James Kempf <James.Kempf@Sun.COM>
> > >> >Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com,
> > >> Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
> > >seamoby@cdma-2000.org
> > >> >Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
> (SHOULD
> > >be ,
> > >>       RE: Issue #4)
> > >> >Mail-Followup-To: James Kempf <James.Kempf@Sun.COM>,
> > >pcalhoun@diameter.org,
> > >> gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
> > >> john.loughney@nokia.com, seamoby@cdma-2000.org
> > >> >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 owner-seamoby@diameter.org  Thu Jul 12 04:22:49 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14305
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 04:22:49 -0400 (EDT)
Received: (qmail 16359 invoked by alias); 12 Jul 2001 08:11:35 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16353 invoked by uid 200); 12 Jul 2001 08:11:35 -0000
Received: (qmail 16347 invoked from network); 12 Jul 2001 08:11:33 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 08:11:33 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6C8MlI24638
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 11:22:48 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b345994cac158f2313e2@esvir03nok.nokia.com>;
 Thu, 12 Jul 2001 11:22:15 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS486BC>; Thu, 12 Jul 2001 11:22:11 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BAF6@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: pcalhoun@diameter.org, gkenward@nortelnetworks.com
Cc: PNeumiller@MeshNetworks.com, seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
	 lti- Phase CT
Date: Thu, 12 Jul 2001 11:22:09 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Pat,

> I think that two phases are needed, regardless of the MTU size. I
> believe that in order to achieve a seamless handoff, it is necessary
> to transfer time sensitive context blobs as soon as possible (e.g.
> header compression, L2 keying info, L3 SAs). These are necessary
> in order to exchange packets with the mobile, but there may be other
> time sensitive blobs that I haven't thought of as well. 
> Non-time sensitive blobs (e.g. accounting session id) are not needed 
> to send/receive packets and therefore do not need to be sent right away.

I think that discussing of phases is leading us to a dead end.  What
we need is the following behavior:

1) Ability to send time-critical context
2) Ability to discard stale context
3) Ability to synchronize the context transfer with an additional
   procedure (like a handover)
4) Ability to use different triggers to start the transfer of some 
   contexts.
5) Ability to acknowledge the transfer of some contexts.
6) Ability to group or send seperately contexts.

My feeling is that when we group the behaviors, we may get the different
phases - but I think that there may be more than just 2 phases of 
CT.  Actually, the above behaviors may depend upon the type context
being transfered.  As we have not identified all the possible types
of context to be transfered and all of the situations, I don't
believe that discussing the phases (or modes) of context transfer
is a good idea currently.

I'm writing up an issue on this right now.  I'm happy to contribute
text.

Comments?
John



From owner-seamoby@diameter.org  Thu Jul 12 04:30:39 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA15132
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 04:30:38 -0400 (EDT)
Received: (qmail 16844 invoked by alias); 12 Jul 2001 08:19:09 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16838 invoked by uid 200); 12 Jul 2001 08:19:08 -0000
Received: (qmail 16833 invoked from network); 12 Jul 2001 08:19:06 -0000
Received: from mgw-x4.nokia.com (131.228.20.27)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 08:19:06 -0000
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6C8WiG21581
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 11:32:44 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b34c59ecac158f24077@esvir04nok.ntc.nokia.com>;
 Thu, 12 Jul 2001 11:29:38 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS486KY>; Thu, 12 Jul 2001 11:29:38 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09402E@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: James.Kempf@Sun.COM
Cc: seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
	 lti-  Phase CT
Date: Thu, 12 Jul 2001 11:29:31 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi James,

> I think there may be some benefits to linking CT with the handover
> messaging. 

I agree with your point, so I think we should allow (not require)
context transfer to be linked to some messaging.  

However, this opens a big can of worms.  

If CT is linked with other protocols, then is the job to define
possible parameters & provide a framework on how it is used?
Then, it would be Mobile IP's job (for example) to use the 
parameters.  Or do we want to specify a protocol?  Or do we
specify a protocol seperately from the framework and seperately
from the parameter types.  The parameter types could be re-used by 
other protocols (such as MIP).  If MIP is not available, then
the protocol could be used.  

This I am not sure about, and I'd be happy to see what others 
think.

John



From owner-seamoby@diameter.org  Thu Jul 12 04:40:24 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16257
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 04:40:23 -0400 (EDT)
Received: (qmail 17340 invoked by alias); 12 Jul 2001 08:29:18 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 17334 invoked by uid 200); 12 Jul 2001 08:29:17 -0000
Received: (qmail 17329 invoked from network); 12 Jul 2001 08:29:15 -0000
Received: from mgw-x2.nokia.com (131.228.20.22)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 08:29:15 -0000
Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6C8eL301917
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 11:40:21 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b355c051ac158f22077@esvir02nok.nokia.com>;
 Thu, 12 Jul 2001 11:39:54 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS486WZ>; Thu, 12 Jul 2001 11:39:54 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09402F@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: James.Kempf@Sun.COM, rajeev@IPRG.nokia.com, katawal2200@home.com
Cc: seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
	 lti-   Phase CT
Date: Thu, 12 Jul 2001 11:39:41 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi James,

> What about making it possible to define a binding between a particular
> mobility solution and CT, and have a general framework?

That is one possiblity.  Could another _solution_ be that CT runs as
it's own protocol, but shares a parameter with the handover in
order to synchronize it?

My example would be this.  The mobile node 'sees' 3 potential
handoff targets.  It is not ready to instigate the handover 
yet, but wants to prepare the possible handover candidates,
so it sends some context to them (such as header compression
state).  All three targets get this info (compressor state, 
time-to-live, and synch value).  After some time, the mobile is 
ready to handoff - so it kicks off a handover procedure,
with the CT synch value so that when the new AR gets it,
the new AR knows what context to associate the handover with.
The other 2 targets have the context TTL, so that they can
expire the context that they have.

John


From owner-seamoby@diameter.org  Thu Jul 12 04:43:15 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16557
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 04:43:14 -0400 (EDT)
Received: (qmail 17817 invoked by alias); 12 Jul 2001 08:32:08 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 17811 invoked by uid 200); 12 Jul 2001 08:32:07 -0000
Received: (qmail 17806 invoked from network); 12 Jul 2001 08:32:05 -0000
Received: from mgw-x2.nokia.com (131.228.20.22)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 08:32:05 -0000
Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6C8hB303188
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 11:43:11 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b35873a9ac158f22077@esvir02nok.nokia.com>;
 Thu, 12 Jul 2001 11:42:51 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS486Z8>; Thu, 12 Jul 2001 11:42:51 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094030@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: James.Kempf@sun.com
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,          RE: Issue #4)
Date: Thu, 12 Jul 2001 11:42:44 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

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.
> 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?

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 owner-seamoby@diameter.org  Thu Jul 12 04:51:46 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA17465
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 04:51:42 -0400 (EDT)
Received: (qmail 18834 invoked by alias); 12 Jul 2001 08:40:32 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18828 invoked by uid 200); 12 Jul 2001 08:40:31 -0000
Received: (qmail 18823 invoked from network); 12 Jul 2001 08:40:29 -0000
Received: from mgw-x4.nokia.com (131.228.20.27)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 08:40:29 -0000
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6C8s6G28828
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 11:54:06 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b36005c8ac158f24077@esvir04nok.ntc.nokia.com>;
 Thu, 12 Jul 2001 11:51:07 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS4871P>; Thu, 12 Jul 2001 11:51:07 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BAF7@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: pcalhoun@diameter.org, gkenward@nortelnetworks.com
Cc: Madjid.Nakhjiri@motorola.com, seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 , RE: Issue #4)
Date: Thu, 12 Jul 2001 11:50:59 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

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 owner-seamoby@diameter.org  Thu Jul 12 05:06:45 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19023
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 05:06:44 -0400 (EDT)
Received: (qmail 19363 invoked by alias); 12 Jul 2001 08:55:27 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 19357 invoked by uid 200); 12 Jul 2001 08:55:26 -0000
Received: (qmail 19352 invoked from network); 12 Jul 2001 08:55:24 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 08:55:24 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6C96eI14912
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 12:06:40 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b36dd10dac158f2313e2@esvir03nok.nokia.com> for <seamoby@cdma-2000.org>;
 Thu, 12 Jul 2001 12:06:11 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS487ZL>; Thu, 12 Jul 2001 12:06:11 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094032@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: seamoby@cdma-2000.org
Subject: [seamoby] [CT Requirement] New Issue (7)
Date: Thu, 12 Jul 2001 12:05:59 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi all,

Please find a new issue for the CT Requirements document.

br,
John

==============

Description of issue 

Section 4.4 & 4.5 are potentially limiting.

Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: July 12, 2001 
Comment type: T

Priority: S

Section: Insert_Section_Number_Here 

Rationale/Explanation of issue: 

Currently 4.4 and 4.5 imply that there are two modes of operation.  It is
not so cut & dry.  As seen by the discussion on the list, there are many
differing requirements that may not be satisfied by discussion these modes.
Length description of problem 

Currently, by defining proactive & reactive, the work group may start to
think in terms of these 2 modes of operation.  I don't think that CT is so
black & white.  

DISCLAIMER:  I'm not suggesting that we don't need proactive/reactive, what
I am saying is we should drop down a level in the requirements document and
discuss what are the aspects of proactive/reactive which are needed.  Then
by having these 'building blocks' we can design CT to behave in proactive or
reactive fashion.

Requested change: 

Remove proactive & reactive from the document.  These could be used as
examples in the document, if needed.

Proposal 

Focus on the features & functions of reactive & proactive modes rather.  For
example, everyone will agree that certain context may have a higher priority
(may take precidence over, may be more time sensitive, etc.) than others.
Some context may go stale.  Some context may need to be acknowledged.  

By stating the types of functionality that are needed, the requirements will
allow a more rich protocol.


=============================================

Example (solution space):  

We define these features - this is not the complete set:
(priority, time-to-live, ack-needed, synchonized with ho)

So, I would define the transfer of header compression state
as context transfer that has a high priority, a certain time-to-live, 
ack-needed.

High priority would mean that the AR would send it ASAP.

TTL would indicate that the context would go stale.

Ack-needed would indicate to the mobile node that if the
new AR does not yet have the header compression state, 
then it shouldn't send compressed headers, but attempt to
re-initialize the compressor at the new AR.


From owner-seamoby@diameter.org  Thu Jul 12 07:06:30 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01712
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 07:06:30 -0400 (EDT)
Received: (qmail 20156 invoked by alias); 12 Jul 2001 10:55:04 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20150 invoked by uid 200); 12 Jul 2001 10:55:04 -0000
Received: (qmail 20145 invoked from network); 12 Jul 2001 10:55:02 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 10:55:02 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01268;
	Thu, 12 Jul 2001 07:04:59 -0400 (EDT)
Message-Id: <200107121104.HAA01268@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [seamoby] I-D ACTION:draft-pagtzis-mobileip-proactivev6-00.txt,.ps
Date: Thu, 12 Jul 2001 07:04:59 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: A Framework for Proactive Mobility in Mobile IPv6
	Author(s)	: T. Pagtzis, P. Kirstein
	Filename	: draft-pagtzis-mobileip-proactivev6-00.txt,.ps
	Pages		: 78
	Date		: 11-Jul-01
	
This document specifies a scheme to provide support for proactive
mobility  for IPv6.  It encompasses a novel approach for seamless
handoff and proactive roaming context transfer.  The latter establishes
a generic method for proactive context transfer and manipulation of
different classes of context relating to the state of IP connectivity
for a mobile node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pagtzis-mobileip-proactivev6-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-pagtzis-mobileip-proactivev6-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-pagtzis-mobileip-proactivev6-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010711155549.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-pagtzis-mobileip-proactivev6-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-pagtzis-mobileip-proactivev6-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010711155549.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-seamoby@diameter.org  Thu Jul 12 08:31:04 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12378
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 08:31:03 -0400 (EDT)
Received: (qmail 21731 invoked by alias); 12 Jul 2001 12:20:12 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 21725 invoked by uid 200); 12 Jul 2001 12:20:11 -0000
Received: (qmail 21718 invoked by uid 500); 12 Jul 2001 12:20:09 -0000
Date: Thu, 12 Jul 2001 05:20:09 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: john.loughney@nokia.com
Cc: James.Kempf@Sun.COM, seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-  Phase CT
Message-ID: <20010712052009.E5588@charizard.diameter.org>
Mail-Followup-To: john.loughney@nokia.com, James.Kempf@Sun.COM,
	seamoby@cdma-2000.org
References: <0C1353ABB1DEB74DB067ADFF749C4EEF09402E@esebe004.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF09402E@esebe004.NOE.Nokia.com>; from john.loughney@nokia.com on Thu, Jul 12, 2001 at 11:29:31AM +0300
Sender: owner-seamoby@diameter.org
Precedence: bulk

Yes, it would be possible for CT to define the state blob framing,
how it is encoded, identified, etc. The other mobility management protocols
could simply include the CT framed blobs within their protocol.

The issue, though, is that each mobility management protocol has different
characteristics, and in some circumstances it may be difficult to wedge the
CT blobs within it. An example is MIP. As you probably know, Mobile IPv4
has a max length of 255 octets for any extension data added to the protocol.
This would require fragmentation of the blobs, which gets even more complex.

Another mobility management protocol may use ASN.1, and they may not like
to add a different data encoding scheme (the one CTP uses), and just decide
to mimic CTP using their own encoding scheme.

So, in order for CTP to be universally used, I think it needs to exist on
its own.

My 2 cents,

PatC


From owner-seamoby@diameter.org  Thu Jul 12 09:26:45 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19468
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 09:26:43 -0400 (EDT)
Received: (qmail 22421 invoked by alias); 12 Jul 2001 13:15:29 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 22415 invoked by uid 200); 12 Jul 2001 13:15:28 -0000
Received: (qmail 22407 invoked from network); 12 Jul 2001 13:15:25 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 13:15:25 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1K317>; Thu, 12 Jul 2001 09:23:54 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445593@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: "'James Kempf'" <James.Kempf@Sun.COM>, gkenward@nortelnetworks.com,
        Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,          RE: Issue #4)
Date: Thu, 12 Jul 2001 09:23:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk


> On Wed, Jul 11, 2001 at 05:17:47PM -0400, Phillip Neumiller wrote:
> > Is there any co-dependence between CT and "succesful" handovers?
> > I think so.  Seperating the messages makes handover less reliable.
> 
> Only if the network is unreliable.

ALL networks are unreliable.  When you serialize two co-dependent events
with an unreliable network your transfer is much MORE unreliable.

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.

Lets get rid of this concept of extra baggage being thrown into the CT 
transport because its convenient.  I do believe CT/MIP could provide 
"triggers" for other stuff like AAA if needed.

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.

> 
> > 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.
> 
> If the link between the ARs are congested, then I would argue
> that the single combined MIP/CT message will be subjected to
> the same jitter and congestion conditions you'd experience
> with a dual approach. 

Wrong.  See the posting on reliability models I sent to this list
about two weeks ago.  Two co-dependent messages sent over an 
unreliable link is much worse.

> So, I have a hard time convincing myself
> that we should be looking at tying CT to MIP to get around
> poor network design.

All networks are imperfect.  I have a very hard time convincing
myself we need to stick a bunch of AAA crap into the CT protocol.

Thanks,

Phil


From owner-seamoby@diameter.org  Thu Jul 12 09:42:44 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21484
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 09:42:42 -0400 (EDT)
Received: (qmail 22952 invoked by alias); 12 Jul 2001 13:31:15 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 22946 invoked by uid 200); 12 Jul 2001 13:31:14 -0000
Received: (qmail 22941 invoked from network); 12 Jul 2001 13:31:13 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 13:31:13 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id GAA18855;
	Thu, 12 Jul 2001 06:41:32 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CDfVc22104;
	Thu, 12 Jul 2001 06:41:31 -0700
X-mProtect:  Thu, 12 Jul 2001 06:41:31 -0700 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdmOo1un; Thu, 12 Jul 2001 06:41:29 PDT
Message-ID: <3B4DA8EB.DD58BD8B@iprg.nokia.com>
Date: Thu, 12 Jul 2001 06:41:00 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
CC: seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD 
 be,          RE: Issue #4)
References: <0DF9FBC42474A24CA50F7A27FB08E048445593@meshpdc.meshnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Phil,

if I recall well, I was one of the addressees of that message of two weeks ago

you mention below. That's my excuse to jump in this.

Anyhow, your point in that email of two weeks ago was that it was less
reliable to separate CT and HO. Which is true, but only  if you consider that
the
system is unreliable because of a failed CT.
A CT that is independent of the HO, except for a couple triggers/sync
mechanisms,
would not ADD any unreliability. HO would happen, with its own reliability,
CT would happen, with its own reliability. HO fails, we're in, how would you
put
it, deep crap, CT fails, well you have to re-establish stuff, but it's not the
end of
the world. So reliability of HO+CT = reliability of HO.

Regards,

C.

Phillip Neumiller wrote:

> > On Wed, Jul 11, 2001 at 05:17:47PM -0400, Phillip Neumiller wrote:
> > > Is there any co-dependence between CT and "succesful" handovers?
> > > I think so.  Seperating the messages makes handover less reliable.
> >
> > Only if the network is unreliable.
>
> ALL networks are unreliable.  When you serialize two co-dependent events
> with an unreliable network your transfer is much MORE unreliable.
>
> 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.
>
> Lets get rid of this concept of extra baggage being thrown into the CT
> transport because its convenient.  I do believe CT/MIP could provide
> "triggers" for other stuff like AAA if needed.
>
> 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.
>
> >
> > > 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.
> >
> > If the link between the ARs are congested, then I would argue
> > that the single combined MIP/CT message will be subjected to
> > the same jitter and congestion conditions you'd experience
> > with a dual approach.
>
> Wrong.  See the posting on reliability models I sent to this list
> about two weeks ago.  Two co-dependent messages sent over an
> unreliable link is much worse.
>
> > So, I have a hard time convincing myself
> > that we should be looking at tying CT to MIP to get around
> > poor network design.
>
> All networks are imperfect.  I have a very hard time convincing
> myself we need to stick a bunch of AAA crap into the CT protocol.
>
> Thanks,
>
> Phil



From owner-seamoby@diameter.org  Thu Jul 12 10:11:28 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25350
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 10:11:27 -0400 (EDT)
Received: (qmail 23538 invoked by alias); 12 Jul 2001 14:00:30 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 23532 invoked by uid 200); 12 Jul 2001 14:00:29 -0000
Received: (qmail 23527 invoked from network); 12 Jul 2001 14:00:28 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 14:00:28 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1K3GK>; Thu, 12 Jul 2001 10:10:44 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445595@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Cedric Westphal'" <cedric@iprg.nokia.com>,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD  b
	e,          RE: Issue #4)
Date: Thu, 12 Jul 2001 10:10:32 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

> Anyhow, your point in that email of two weeks ago was that it was less
> reliable to separate CT and HO. Which is true, but only  if 
> you consider that
> the
> system is unreliable because of a failed CT.

Hmm.  If CT provides seamless handover, its pretty damn important.
Why are we treating it like its just some "other" stuff to shuffle
around with the handover.  It "creates the environment" for the
seamless AND hopefully reliable handovers.  I really dont understand
how CT got so far off course with all these other goofy requirements.

We need to get down to the basic requiremetns of handover again and
forget all this wishy-washy:

1).  Weeel, maybe I can do CT before the handover...
2).  Weel Nancy, maybe I can do the CT after the handover...
     [ Phil in his best Ronny Raygun]
3).  Weeeel, maybe I can di it during the handover....

No NO NO!!!!  CT has to be an integral part of the handover if it
is going to do its job.  THAT is the WHOLE POINT!!!

Thanks,

Phil



From owner-seamoby@diameter.org  Thu Jul 12 11:18:18 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04828
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 11:18:17 -0400 (EDT)
Received: (qmail 24248 invoked by alias); 12 Jul 2001 15:07:07 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 24242 invoked by uid 200); 12 Jul 2001 15:07:06 -0000
Received: (qmail 24237 invoked from network); 12 Jul 2001 15:07:04 -0000
Received: from albatross-ext.wise.edt.ericsson.se (194.237.142.116)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 15:07:04 -0000
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6CFHpN10523
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 17:17:51 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt461 ; Thu Jul 12 17:17:49 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <NBW4SP5K>; Thu, 12 Jul 2001 17:17:50 +0200
Message-ID: <034BEFD03799D411A59F00508BDF754603008AD1@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  \(ERA\)" <Hesham.Soliman@era.ericsson.se>
To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>,
        seamoby@cdma-2000.org
Subject: [seamoby] RE: [mobile-ip] Agent Discovery during handover
Date: Thu, 12 Jul 2001 17:17:46 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

Pat, 

Is it strictly AP discovery or is it a mix of AP/AR discovery 
that Seamoby is looking into ?
I think the distinction is important because the solution will
vary considerably. 

Hesham


> -----Original Message-----
> From:	Pat Calhoun [SMTP:pcalhoun@diameter.org]
> Sent:	Thursday, 12 July 2001 4:35
> To:	mobile-ip@sunroof.eng.sun.com
> Subject:	Re: [mobile-ip] Agent Discovery during handover
> 
> The Seamoby WG is working on defining handoff candidates discovery based
> on certain characteristics or required features. In MIP, the fact that 
> you've received an agent advertisement is sufficient.
> 
> So I suggest you send e-mail to the seamoby list.
> 
> Thanks,
> 
> PatC
> On Thu, Jul 12, 2001 at 03:14:26PM +0100, Tanis, Michael (Michael) wrote:
> > Hello all,
> > 
> > I am currently doing my MSc project in simulating the Agent Discovery
> > process in OPNET. There is a critical point where the MN is receiving
> > advertisements from two or more Agents. What should be the reaction of the
> > MN? Should it start registration according to the signal power received,
> > according to the Lifetime field or to the services offered ?
> > 
> > I would really appreciate it if someone could answer the question or point
> > me to the suitable document
> > 
> > Thanks in advance,   
> > 
> > 
> > --------------------------------
> > Michael Tanis
> > 
> > O Lucent Technologies UMTS-SAE
> > Optimus Building
> > Windmill Hill Business Park
> > Swindon
> > Wilts SN5 6PP  
> > United Kingdom
> > 
> > Work Tel: +44 1793 897856
> > Mobile  : +44 7779 032004
> > e-mail  : mtanis@lucent.com
> > 


From owner-seamoby@diameter.org  Thu Jul 12 11:29:43 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06387
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 11:29:34 -0400 (EDT)
Received: (qmail 24754 invoked by alias); 12 Jul 2001 15:16:26 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 24748 invoked by uid 200); 12 Jul 2001 15:16:25 -0000
Received: (qmail 24743 invoked from network); 12 Jul 2001 15:16:23 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 15:16:23 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28160;
	Thu, 12 Jul 2001 08:27:11 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA16523;
	Thu, 12 Jul 2001 08:27:09 -0700 (PDT)
Message-Id: <200107121527.IAA16523@heliopolis.eng.sun.com>
Date: Thu, 12 Jul 2001 08:27:09 -0700 (PDT)
From: James Kempf <James.Kempf@sun.com>
Reply-To: James Kempf <James.Kempf@sun.com>
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
To: James.Kempf@sun.com, pcalhoun@diameter.org, katawal2200@home.com
Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com,
        Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ep6jIXJ8ko2V9AcFseQoSA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

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" <katawal2200@home.com>
>To: "James Kempf" <James.Kempf@sun.com>, <pcalhoun@diameter.org>
>Cc: <pcalhoun@diameter.org>, <gkenward@nortelnetworks.com>, 
<Madjid.Nakhjiri@motorola.com>, <john.loughney@nokia.com>, 
<seamoby@cdma-2000.org>
>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" <James.Kempf@Sun.COM>
>To: <James.Kempf@Sun.COM>; <pcalhoun@diameter.org>; <katawal2200@home.com>
>Cc: <pcalhoun@diameter.org>; <gkenward@nortelnetworks.com>;
><Madjid.Nakhjiri@motorola.com>; <john.loughney@nokia.com>;
><seamoby@cdma-2000.org>
>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" <katawal2200@home.com>
>> >To: "James Kempf" <James.Kempf@Sun.COM>, <pcalhoun@diameter.org>
>> >Cc: <pcalhoun@diameter.org>, <gkenward@nortelnetworks.com>,
>> <Madjid.Nakhjiri@motorola.com>, <john.loughney@nokia.com>,
>> <seamoby@cdma-2000.org>
>> >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" <James.Kempf@Sun.COM>
>> >To: <James.Kempf@Sun.COM>; <pcalhoun@diameter.org>
>> >Cc: <pcalhoun@diameter.org>; <gkenward@nortelnetworks.com>;
>> ><Madjid.Nakhjiri@motorola.com>; <john.loughney@nokia.com>;
>> ><seamoby@cdma-2000.org>
>> >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
>> >>
>> >> >Delivered-To: seamoby-list@charizard.diameter.org
>> >> >Date: Wed, 11 Jul 2001 13:41:41 -0700
>> >> >From: Pat Calhoun <pcalhoun@diameter.org>
>> >> >To: James Kempf <James.Kempf@Sun.COM>
>> >> >Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com,
>> >> Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
>> >seamoby@cdma-2000.org
>> >> >Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)
>(SHOULD
>> >be ,
>> >>       RE: Issue #4)
>> >> >Mail-Followup-To: James Kempf <James.Kempf@Sun.COM>,
>> >pcalhoun@diameter.org,
>> >> gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
>> >> john.loughney@nokia.com, seamoby@cdma-2000.org
>> >> >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 owner-seamoby@diameter.org  Thu Jul 12 11:35:26 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07245
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 11:35:25 -0400 (EDT)
Received: (qmail 25255 invoked by alias); 12 Jul 2001 15:22:24 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 25249 invoked by uid 200); 12 Jul 2001 15:22:24 -0000
Received: (qmail 25242 invoked by uid 500); 12 Jul 2001 15:22:22 -0000
Date: Thu, 12 Jul 2001 08:22:22 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: mobile-ip@sunroof.eng.sun.com
Cc: seamoby@cdma-2000.org
Subject: [seamoby] Re: [mobile-ip] Agent Discovery during handover
Message-ID: <20010712082222.N5588@charizard.diameter.org>
Mail-Followup-To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
References: <034BEFD03799D411A59F00508BDF754603008AD1@esealnt448.al.sw.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <034BEFD03799D411A59F00508BDF754603008AD1@esealnt448.al.sw.ericsson.se>; from Hesham.Soliman@era.ericsson.se on Thu, Jul 12, 2001 at 05:17:46PM +0200
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Thu, Jul 12, 2001 at 05:17:46PM +0200, Hesham Soliman  (ERA) wrote:
> Pat, 
> 
> Is it strictly AP discovery or is it a mix of AP/AR discovery 
> that Seamoby is looking into ?
> I think the distinction is important because the solution will
> vary considerably. 

The problem statement is in the process of being written, so I cannot
answer that question. I would hope that both AP and ARs are supported,
but unfortunately cannot predict the future :)

PatC


From owner-seamoby@diameter.org  Thu Jul 12 11:38:11 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07613
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 11:38:10 -0400 (EDT)
Received: (qmail 25367 invoked by alias); 12 Jul 2001 15:24:08 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 25359 invoked by uid 200); 12 Jul 2001 15:24:07 -0000
Received: (qmail 25341 invoked from network); 12 Jul 2001 15:24:04 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 15:24:04 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA01875;
	Thu, 12 Jul 2001 08:34:50 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA17483;
	Thu, 12 Jul 2001 08:34:40 -0700 (PDT)
Message-Id: <200107121534.IAA17483@heliopolis.eng.sun.com>
Date: Thu, 12 Jul 2001 08:34:40 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu  lti- Phase CT
To: pcalhoun@diameter.org, gkenward@nortelnetworks.com,
        john.loughney@nokia.com
Cc: PNeumiller@MeshNetworks.com, seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 4K1s2VicWhGE0fKGvcZVow==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

John,

An excellent summary of requirements. Depending on the implementation,
some or all of these may or may not be needed.

		jak
		
>Delivered-To: seamoby-list@charizard.diameter.org
>From: john.loughney@nokia.com
>To: pcalhoun@diameter.org, gkenward@nortelnetworks.com
>Cc: PNeumiller@MeshNetworks.com, seamoby@cdma-2000.org
>Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
Phase CT
>Date: Thu, 12 Jul 2001 11:22:09 +0300
>
>Hi Pat,
>
>> I think that two phases are needed, regardless of the MTU size. I
>> believe that in order to achieve a seamless handoff, it is necessary
>> to transfer time sensitive context blobs as soon as possible (e.g.
>> header compression, L2 keying info, L3 SAs). These are necessary
>> in order to exchange packets with the mobile, but there may be other
>> time sensitive blobs that I haven't thought of as well. 
>> Non-time sensitive blobs (e.g. accounting session id) are not needed 
>> to send/receive packets and therefore do not need to be sent right away.
>
>I think that discussing of phases is leading us to a dead end.  What
>we need is the following behavior:
>
>1) Ability to send time-critical context
>2) Ability to discard stale context
>3) Ability to synchronize the context transfer with an additional
>   procedure (like a handover)
>4) Ability to use different triggers to start the transfer of some 
>   contexts.
>5) Ability to acknowledge the transfer of some contexts.
>6) Ability to group or send seperately contexts.
>
>My feeling is that when we group the behaviors, we may get the different
>phases - but I think that there may be more than just 2 phases of 
>CT.  Actually, the above behaviors may depend upon the type context
>being transfered.  As we have not identified all the possible types
>of context to be transfered and all of the situations, I don't
>believe that discussing the phases (or modes) of context transfer
>is a good idea currently.
>
>I'm writing up an issue on this right now.  I'm happy to contribute
>text.
>
>Comments?
>John
>



From owner-seamoby@diameter.org  Thu Jul 12 11:41:13 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08045
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 11:41:12 -0400 (EDT)
Received: (qmail 26177 invoked by alias); 12 Jul 2001 15:29:08 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26169 invoked by uid 200); 12 Jul 2001 15:29:07 -0000
Received: (qmail 26151 invoked from network); 12 Jul 2001 15:29:04 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 15:29:04 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04910;
	Thu, 12 Jul 2001 08:39:51 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA17772;
	Thu, 12 Jul 2001 08:39:45 -0700 (PDT)
Message-Id: <200107121539.IAA17772@heliopolis.eng.sun.com>
Date: Thu, 12 Jul 2001 08:39:44 -0700 (PDT)
From: James Kempf <James.Kempf@sun.com>
Reply-To: James Kempf <James.Kempf@sun.com>
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu  lti-  Phase CT
To: James.Kempf@sun.com, john.loughney@nokia.com
Cc: seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: dYs1qk9wov+VJ8Z1k9N6qg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

John,

I think Seamoby should do a framework that can be bound to a particular
mobility protocol. The framework might, in fact, be fairly detailed
in terms of on the wire representations and such, it would just not,
a priori, be a separate protocol.

Perhaps there should also be a protocol that wraps the framework for
those mobility protocols that don't want to make CT into an extension.

I believe that the requirements should not specify bundling HO and CT,
and also that they should not forbid it.

		jak
		
>From: john.loughney@nokia.com
>To: James.Kempf@sun.com
>Cc: seamoby@cdma-2000.org
>Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
 Phase CT
>Date: Thu, 12 Jul 2001 11:29:31 +0300
>
>Hi James,
>
>> I think there may be some benefits to linking CT with the handover
>> messaging. 
>
>I agree with your point, so I think we should allow (not require)
>context transfer to be linked to some messaging.  
>
>However, this opens a big can of worms.  
>
>If CT is linked with other protocols, then is the job to define
>possible parameters & provide a framework on how it is used?
>Then, it would be Mobile IP's job (for example) to use the 
>parameters.  Or do we want to specify a protocol?  Or do we
>specify a protocol seperately from the framework and seperately
>from the parameter types.  The parameter types could be re-used by 
>other protocols (such as MIP).  If MIP is not available, then
>the protocol could be used.  
>
>This I am not sure about, and I'd be happy to see what others 
>think.
>
>John
>



From owner-seamoby@diameter.org  Thu Jul 12 12:01:52 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11246
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 12:01:51 -0400 (EDT)
Received: (qmail 26872 invoked by alias); 12 Jul 2001 15:50:59 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26866 invoked by uid 200); 12 Jul 2001 15:50:59 -0000
Received: (qmail 26861 invoked from network); 12 Jul 2001 15:50:56 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 15:50:56 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA08238;
	Thu, 12 Jul 2001 10:01:43 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA18856;
	Thu, 12 Jul 2001 09:01:44 -0700 (PDT)
Message-Id: <200107121601.JAA18856@heliopolis.eng.sun.com>
Date: Thu, 12 Jul 2001 09:01:43 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be  ,          RE: Issue #4)
To: pcalhoun@diameter.org, PNeumiller@MeshNetworks.com
Cc: James.Kempf@Sun.COM, gkenward@nortelnetworks.com,
        Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com,
        seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: p+19svQqFelttRDwhT36fQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

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 owner-seamoby@diameter.org  Thu Jul 12 12:39:59 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17108
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 12:39:58 -0400 (EDT)
Received: (qmail 27525 invoked by alias); 12 Jul 2001 16:28:44 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27519 invoked by uid 200); 12 Jul 2001 16:28:44 -0000
Received: (qmail 27514 invoked from network); 12 Jul 2001 16:28:42 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 16:28:42 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA05005;
	Thu, 12 Jul 2001 09:39:25 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA21027;
	Thu, 12 Jul 2001 09:39:18 -0700 (PDT)
Message-Id: <200107121639.JAA21027@heliopolis.eng.sun.com>
Date: Thu, 12 Jul 2001 09:39:18 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [seamoby] RE: [mobile-ip] Agent Discovery during handover
To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org,
        Hesham.Soliman@era.ericsson.se
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 2PBHjS1ulT3OSeVku/yI2A==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hesham,

The current draft focusses on AR discovery, because, from the viewpoint
of an IP network, APs are transparent bridges. Of course, it possible,
even likely, that APs may have an IP address but I think they
would then be likely classified as hosts since they do not perform
a routing function (the subnet is the same on both sides). 

Do you think that APs should be included?

		jak

>Delivered-To: seamoby-list@charizard.diameter.org
>From: "Hesham Soliman  \(ERA\)" <Hesham.Soliman@era.ericsson.se>
>To: "'mobile-ip@sunroof.eng.sun.com'" <mobile-ip@sunroof.eng.sun.com>, 
seamoby@cdma-2000.org
>Subject: [seamoby] RE: [mobile-ip] Agent Discovery during handover
>Date: Thu, 12 Jul 2001 17:17:46 +0200
>
>Pat, 
>
>Is it strictly AP discovery or is it a mix of AP/AR discovery 
>that Seamoby is looking into ?
>I think the distinction is important because the solution will
>vary considerably. 
>
>Hesham
>
>
>> -----Original Message-----
>> From:	Pat Calhoun [SMTP:pcalhoun@diameter.org]
>> Sent:	Thursday, 12 July 2001 4:35
>> To:	mobile-ip@sunroof.eng.sun.com
>> Subject:	Re: [mobile-ip] Agent Discovery during handover
>> 
>> The Seamoby WG is working on defining handoff candidates discovery based
>> on certain characteristics or required features. In MIP, the fact that 
>> you've received an agent advertisement is sufficient.
>> 
>> So I suggest you send e-mail to the seamoby list.
>> 
>> Thanks,
>> 
>> PatC
>> On Thu, Jul 12, 2001 at 03:14:26PM +0100, Tanis, Michael (Michael) wrote:
>> > Hello all,
>> > 
>> > I am currently doing my MSc project in simulating the Agent Discovery
>> > process in OPNET. There is a critical point where the MN is receiving
>> > advertisements from two or more Agents. What should be the reaction of the
>> > MN? Should it start registration according to the signal power received,
>> > according to the Lifetime field or to the services offered ?
>> > 
>> > I would really appreciate it if someone could answer the question or point
>> > me to the suitable document
>> > 
>> > Thanks in advance,   
>> > 
>> > 
>> > --------------------------------
>> > Michael Tanis
>> > 
>> > O Lucent Technologies UMTS-SAE
>> > Optimus Building
>> > Windmill Hill Business Park
>> > Swindon
>> > Wilts SN5 6PP  
>> > United Kingdom
>> > 
>> > Work Tel: +44 1793 897856
>> > Mobile  : +44 7779 032004
>> > e-mail  : mtanis@lucent.com
>> > 



From owner-seamoby@diameter.org  Thu Jul 12 12:52:28 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18747
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 12:52:28 -0400 (EDT)
Received: (qmail 28110 invoked by alias); 12 Jul 2001 16:41:20 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28104 invoked by uid 200); 12 Jul 2001 16:41:20 -0000
Received: (qmail 28099 invoked from network); 12 Jul 2001 16:41:18 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 16:41:18 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA01127;
	Thu, 12 Jul 2001 09:51:36 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CGpah20642;
	Thu, 12 Jul 2001 09:51:36 -0700
X-mProtect:  Thu, 12 Jul 2001 09:51:36 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "cs.ucl.ac.uk")
	by darkstar.iprg.nokia.com(P1.5 smtpdA1mLUI; Thu, 12 Jul 2001 09:51:34 PDT
Message-ID: <3B4DD597.D5264249@cs.ucl.ac.uk>
Date: Thu, 12 Jul 2001 09:51:35 -0700
From: Theo Pagtzis <tpagtzis@cs.ucl.ac.uk>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: seamoby@cdma-2000.org
CC: Phillip Neumiller <PNeumiller@MeshNetworks.com>
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD b e, RE: 
 Issue #4)
References: <0DF9FBC42474A24CA50F7A27FB08E048445595@meshpdc.meshnetworks.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Phil,

   I agree that the CT process must be part of the handover process if
seamlessness is to be effected. BUT, by making integral you rely on the
atomicity of timings with respect to the handover process.

That is, if the handover is happening now then CT must already be
initiated. If on the contrary you make it part of the handover, you can
lossen the timings between which the two can happen, in terms of how close
they happen assuming CT will always happen first (since happening second
won't be to me very seamless anyway).

Don't you think that losening this timing between the two event is crucial
in optimization decisions for the seamlessness of the transition?


Theo

UCL/Mobile Systems

Phillip Neumiller wrote:

> > Anyhow, your point in that email of two weeks ago was that it was less
> > reliable to separate CT and HO. Which is true, but only  if
> > you consider that
> > the
> > system is unreliable because of a failed CT.
>
> Hmm.  If CT provides seamless handover, its pretty damn important.
> Why are we treating it like its just some "other" stuff to shuffle
> around with the handover.  It "creates the environment" for the
> seamless AND hopefully reliable handovers.  I really dont understand
> how CT got so far off course with all these other goofy requirements.
>
> We need to get down to the basic requiremetns of handover again and
> forget all this wishy-washy:
>
> 1).  Weeel, maybe I can do CT before the handover...
> 2).  Weel Nancy, maybe I can do the CT after the handover...
>      [ Phil in his best Ronny Raygun]
> 3).  Weeeel, maybe I can di it during the handover....
>
> No NO NO!!!!  CT has to be an integral part of the handover if it
> is going to do its job.  THAT is the WHOLE POINT!!!
>
> Thanks,
>
> Phil



From owner-seamoby@diameter.org  Thu Jul 12 12:55:20 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19126
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 12:55:19 -0400 (EDT)
Received: (qmail 28502 invoked by alias); 12 Jul 2001 16:43:16 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28494 invoked by uid 200); 12 Jul 2001 16:43:16 -0000
Received: (qmail 28473 invoked from network); 12 Jul 2001 16:43:11 -0000
Received: from penguin-ext.wise.edt.ericsson.se (194.237.142.110)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 16:43:11 -0000
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6CGrwO16497
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 18:53:58 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Jul 12 18:53:57 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <NBW4SRJT>; Thu, 12 Jul 2001 18:53:57 +0200
Message-ID: <034BEFD03799D411A59F00508BDF754603008AD4@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  \(ERA\)" <Hesham.Soliman@era.ericsson.se>
To: "'James Kempf'" <James.Kempf@Sun.COM>, mobile-ip@sunroof.eng.sun.com,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] RE: [mobile-ip] Agent Discovery during handover
Date: Thu, 12 Jul 2001 18:53:54 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

	James, 

> The current draft focusses on AR discovery, because, from the viewpoint
> of an IP network, APs are transparent bridges. 
> 
	=> Sounds good.

> Of course, it possible,
> even likely, that APs may have an IP address but I think they
> would then be likely classified as hosts since they do not perform
> a routing function (the subnet is the same on both sides). 
> 
	=> Right, either they're routers or bridges. If they're routers
	they're covered by what you mentioned above. 

> Do you think that APs should be included?
> 
	=> I'm not really sure !
	The APs can't always give all the necessary information
	anyway. If more than one AP are connected to the same 
	AR then it might be easier to get the information from the 
	AR. The tricky part though is how the AR will be able 
	to send different sets of information to different nodes !

	Sounds like a combination of the L2 API and the L3 
	information from the AR would provide the right sets
	of information for the MN to be able to make an intelligent
	decision. 

	I haven't really gone through all y semoby mail for a while. 
	Can you point me to the problem statement draft if it 
	exists ?

	Cheers,
	Hesham



From owner-seamoby@diameter.org  Thu Jul 12 13:16:03 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21860
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 13:16:02 -0400 (EDT)
Received: (qmail 28502 invoked by alias); 12 Jul 2001 16:43:16 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28494 invoked by uid 200); 12 Jul 2001 16:43:16 -0000
Received: (qmail 28473 invoked from network); 12 Jul 2001 16:43:11 -0000
Received: from penguin-ext.wise.edt.ericsson.se (194.237.142.110)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 16:43:11 -0000
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f6CGrwO16497
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 18:53:58 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Jul 12 18:53:57 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <NBW4SRJT>; Thu, 12 Jul 2001 18:53:57 +0200
Message-ID: <034BEFD03799D411A59F00508BDF754603008AD4@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  \(ERA\)" <Hesham.Soliman@era.ericsson.se>
To: "'James Kempf'" <James.Kempf@Sun.COM>, mobile-ip@sunroof.eng.sun.com,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] RE: [mobile-ip] Agent Discovery during handover
Date: Thu, 12 Jul 2001 18:53:54 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

	James, 

> The current draft focusses on AR discovery, because, from the viewpoint
> of an IP network, APs are transparent bridges. 
> 
	=> Sounds good.

> Of course, it possible,
> even likely, that APs may have an IP address but I think they
> would then be likely classified as hosts since they do not perform
> a routing function (the subnet is the same on both sides). 
> 
	=> Right, either they're routers or bridges. If they're routers
	they're covered by what you mentioned above. 

> Do you think that APs should be included?
> 
	=> I'm not really sure !
	The APs can't always give all the necessary information
	anyway. If more than one AP are connected to the same 
	AR then it might be easier to get the information from the 
	AR. The tricky part though is how the AR will be able 
	to send different sets of information to different nodes !

	Sounds like a combination of the L2 API and the L3 
	information from the AR would provide the right sets
	of information for the MN to be able to make an intelligent
	decision. 

	I haven't really gone through all y semoby mail for a while. 
	Can you point me to the problem statement draft if it 
	exists ?

	Cheers,
	Hesham



From owner-seamoby@diameter.org  Thu Jul 12 13:22:08 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22713
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 13:22:07 -0400 (EDT)
Received: (qmail 29280 invoked by alias); 12 Jul 2001 17:11:08 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 29274 invoked by uid 200); 12 Jul 2001 17:11:08 -0000
Received: (qmail 29269 invoked from network); 12 Jul 2001 17:11:06 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 17:11:06 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA27497;
	Thu, 12 Jul 2001 10:21:51 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA23373;
	Thu, 12 Jul 2001 10:21:48 -0700 (PDT)
Message-Id: <200107121721.KAA23373@heliopolis.eng.sun.com>
Date: Thu, 12 Jul 2001 10:21:47 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: RE: [seamoby] RE: [mobile-ip] Agent Discovery during handover
To: James.Kempf@Sun.COM, mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org,
        Hesham.Soliman@era.ericsson.se
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: BLRg72ec78jisYgkolZEtg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hesham,

>	=> I'm not really sure !
>	The APs can't always give all the necessary information
>	anyway. If more than one AP are connected to the same 
>	AR then it might be easier to get the information from the 
>	AR. The tricky part though is how the AR will be able 
>	to send different sets of information to different nodes !
>

Right, the problem is when there are APs from multiple radio
technologies connected under the same AR. The AR can advertise
that it has multiple radio technology APs, but there isn't really
any way, within IP, for a MN or AR that wants to handoff to a different
technology to do it, because all the MN or AR sees is the AR.

It's different if the AR is also an AP or only has APs of a single
radio technology.

>	Sounds like a combination of the L2 API and the L3 
>	information from the AR would provide the right sets
>	of information for the MN to be able to make an intelligent
>	decision. 
>

Yes, I think that's probably so.

>	I haven't really gone through all y semoby mail for a while. 
>	Can you point me to the problem statement draft if it 
>	exists ?

It hasn't been posted yet. I think Hemant will be posting it today or
tomorrow.

		jak



From owner-seamoby@diameter.org  Thu Jul 12 13:31:25 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23872
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 13:31:18 -0400 (EDT)
Received: (qmail 29776 invoked by alias); 12 Jul 2001 17:16:38 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 29770 invoked by uid 200); 12 Jul 2001 17:16:38 -0000
Received: (qmail 29765 invoked from network); 12 Jul 2001 17:16:35 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 17:16:35 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6CHQVb15171
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 13:26:32 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 12 Jul 2001 13:26:16 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Z8NH>; Thu, 12 Jul 2001 13:26:19 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E36@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'James Kempf'" <James.Kempf@Sun.COM>, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Thu, 12 Jul 2001 13:26:16 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10AF7.C1A35030"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10AF7.C1A35030
Content-Type: text/plain;
	charset="iso-8859-1"

James:

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Wednesday, July 11, 2001 4:44 PM
> To: James.Kempf@Sun.COM; pcalhoun@diameter.org; Kenward, Gary
> [WDLN2:AN10:EXCH]
> Cc: Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;
> seamoby@cdma-2000.org
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> 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.

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.

> 
> >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.

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

> 
> >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

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
> 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. 

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 ;^} ).

> 
> 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?

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
> 
> 		jak
> 
> 

------_=_NextPart_001_01C10AF7.C1A35030
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  RE: Issue #4)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>James:</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: James Kempf [<A HREF="mailto:James.Kempf@Sun.COM">mailto:James.Kempf@Sun.COM</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, July 11, 2001 4:44 PM</FONT>
<BR><FONT SIZE=2>&gt; To: James.Kempf@Sun.COM; pcalhoun@diameter.org; Kenward, Gary</FONT>
<BR><FONT SIZE=2>&gt; [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;</FONT>
<BR><FONT SIZE=2>&gt; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; comments) (SHOULD</FONT>
<BR><FONT SIZE=2>&gt; be , RE: Issue #4)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gary,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;Err, no. That's not what I was agreeing to. </FONT>
<BR><FONT SIZE=2>&gt; &gt;Once again, proactive ct should be driven by the initiation</FONT>
<BR><FONT SIZE=2>&gt; &gt;event, not the deadline event. It is preferable that context</FONT>
<BR><FONT SIZE=2>&gt; &gt;be installed before the traffic arrives at the newAR, but it's</FONT>
<BR><FONT SIZE=2>&gt; &gt;not a MUST requirement, and it certainly does not dictate that</FONT>
<BR><FONT SIZE=2>&gt; &gt;ho and ct protocols must be synchronous.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I'm not sure I understand. If nAR can't deliver packets unless</FONT>
<BR><FONT SIZE=2>&gt; the CT is installed, then how can it not be a MUST requirement?</FONT>
<BR><FONT SIZE=2>&gt; Seems to me, that the completion of the handover is predicated</FONT>
<BR><FONT SIZE=2>&gt; on CT working.</FONT>
</P>

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

<P><FONT SIZE=2>Also, the nAR could buffer the packets, waiting for ct. </FONT>
</P>

<P><FONT SIZE=2>Now, to be clear, I'm re-iterating arguements that have been made by</FONT>
<BR><FONT SIZE=2>others on the list. I believe they are valid arguements for a general</FONT>
<BR><FONT SIZE=2>ct solution. Whether they yeild &quot;seamless&quot; handover or not will only</FONT>
<BR><FONT SIZE=2>be proven through operational experience.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;And I see no reason for requiring handover signalling to complete</FONT>
<BR><FONT SIZE=2>&gt; &gt;before ct (MIP may require it, but that's would be a potential </FONT>
<BR><FONT SIZE=2>&gt; &gt;MIP weakness, were it true). Even if this is true, it applies only</FONT>
<BR><FONT SIZE=2>&gt; &gt;to reactive ct, and contradicts the purpose of proactive ct.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Right, I didn't say it was a general requirement, I only said</FONT>
<BR><FONT SIZE=2>&gt; I see it as a requirement for a particular solution. And I don't</FONT>
<BR><FONT SIZE=2>&gt; necessarily see it as a weakness, if it results in faster </FONT>
<BR><FONT SIZE=2>&gt; handover for MIP.</FONT>
</P>

<P><FONT SIZE=2>Oh, ok. My mistake. Then you are not suggesting that we put it into</FONT>
<BR><FONT SIZE=2>the requirements, given that it is a specific example?</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;You seem to be implying that there is some dire consequence to be</FONT>
<BR><FONT SIZE=2>&gt; &gt;realized if a ct happens but an ho doesn't. At best, the new AR</FONT>
<BR><FONT SIZE=2>&gt; &gt;will be holding onto useless context. At worse, the new AR may</FONT>
<BR><FONT SIZE=2>&gt; &gt;reserve resources that could be used elsewhere. Either situation </FONT>
<BR><FONT SIZE=2>&gt; &gt;seems resolvable with some sort of &quot;life timer&quot; and garbage </FONT>
<BR><FONT SIZE=2>&gt; &gt;collection. It does not imply that the two protocols be </FONT>
<BR><FONT SIZE=2>&gt; &gt;synchronous.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I'm not implying anything, I'm just trying to figure out where</FONT>
<BR><FONT SIZE=2>&gt; you are coming from. I've had my head embedded in this handover</FONT>
<BR><FONT SIZE=2>&gt; problem for a while now, particularly with regard to making</FONT>
<BR><FONT SIZE=2>&gt; MIP handover fast enough for real time streams, and every time</FONT>
<BR><FONT SIZE=2>&gt; I tune into the CT discussion, it seems to be drifting off into</FONT>
<BR><FONT SIZE=2>&gt; philosophy and further away from what IMHO is essential engineering</FONT>
<BR><FONT SIZE=2>&gt; for getting MIP to work fast. I'm sure I'm probably missing</FONT>
</P>

<P><FONT SIZE=2>ct isn't about make MIP work fast (if MIP is slow, I don't think</FONT>
<BR><FONT SIZE=2>ct will improve it ;^} ). </FONT>
</P>

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

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

<P><FONT SIZE=2>&gt; alot of context here (so to speak), and I do admit to a MIP </FONT>
<BR><FONT SIZE=2>&gt; bias, but I'm</FONT>
<BR><FONT SIZE=2>&gt; having some real trouble extracting anything out of this.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;I'm missing the critical state relationship between ct and ho</FONT>
<BR><FONT SIZE=2>&gt; &gt;that you are alluding to.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sure I am. Let's take&nbsp; a specific example. Suppose we are doing</FONT>
<BR><FONT SIZE=2>&gt; network assisted handover in MIP. Suppose that we want to transfer</FONT>
<BR><FONT SIZE=2>&gt; the authentication&nbsp; context and header compression context so that</FONT>
<BR><FONT SIZE=2>&gt; we can start up the real time stream on the MN just as soon as</FONT>
<BR><FONT SIZE=2>&gt; it shows up on the L2 (otherwise the user ends up hearing a half</FONT>
<BR><FONT SIZE=2>&gt; duplex converstation). In order for the handover to successfully</FONT>
<BR><FONT SIZE=2>&gt; conclude, the nAR needs:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1) Signaling from oAR that MN is coming soon,</FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2) The relevent CT for nAR to install,</FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3) Tunneled packets until MN gets around to changing its CoA.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; and it needs them in that order. </FONT>
</P>

<P><FONT SIZE=2>Yes, for an ideal handover. Much of the arguements put forth have </FONT>
<BR><FONT SIZE=2>resisted the idea that ct be constrained by this sequence (c.f. above).</FONT>
</P>

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

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Suppose they do not arrive in that order. Clearly, 3) being out of</FONT>
<BR><FONT SIZE=2>&gt; order first can be ruled out. If 3) arrives before 1, nAR doesn't</FONT>
<BR><FONT SIZE=2>&gt; know that MN is coming. If 2) arrives before 1), nAR can wait for 1),</FONT>
<BR><FONT SIZE=2>&gt; but that implies a timer. If 3) arrives before 2), the proper</FONT>
<BR><FONT SIZE=2>&gt; authentication and header compression state isn't around. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; What am I missing?</FONT>
</P>

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

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

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

<P><FONT SIZE=2>Gary</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; jak</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10AF7.C1A35030--


From owner-seamoby@diameter.org  Thu Jul 12 13:38:37 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24736
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 13:38:36 -0400 (EDT)
Received: (qmail 30066 invoked by alias); 12 Jul 2001 17:22:24 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30062 invoked by uid 200); 12 Jul 2001 17:22:23 -0000
Received: (qmail 30051 invoked from network); 12 Jul 2001 17:22:19 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 17:22:19 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA24231;
	Thu, 12 Jul 2001 11:33:02 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA24139;
	Thu, 12 Jul 2001 10:33:03 -0700 (PDT)
Message-Id: <200107121733.KAA24139@heliopolis.eng.sun.com>
Date: Thu, 12 Jul 2001 10:33:02 -0700 (PDT)
From: James Kempf <James.Kempf@sun.com>
Reply-To: James Kempf <James.Kempf@sun.com>
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
To: James.Kempf@sun.com, pcalhoun@diameter.org, gkenward@nortelnetworks.com
Cc: seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: vzoutWbB6JM0WyoZDYPqkg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Gary,

Thanx for the reply.


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

I don't think an example is needed. Just that the requirements will
support it.

>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.
>

I fully support this! The 90 minutes Pat has scheduled should
hopefully be enough for everybody to get the last word.

>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.
>
>

I understand that MIP is only one of many, but I'm particularly concerned
about MIP. View MIP as a customer. I would like the CT requirements, and,
ultimately, the framework or protocol to support MIP.

		jak



From owner-seamoby@diameter.org  Thu Jul 12 13:48:51 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25993
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 13:48:11 -0400 (EDT)
Received: (qmail 30160 invoked by alias); 12 Jul 2001 17:23:57 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30154 invoked by uid 200); 12 Jul 2001 17:23:56 -0000
Received: (qmail 30141 invoked from network); 12 Jul 2001 17:23:41 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 17:23:41 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6CHXdb16135
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 13:33:39 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 12 Jul 2001 13:33:36 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Z841>; Thu, 12 Jul 2001 13:33:40 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E37@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Thu, 12 Jul 2001 13:33:37 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10AF8.C8BC8610"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10AF8.C8BC8610
Content-Type: text/plain;
	charset="iso-8859-1"

Pat:

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Wednesday, July 11, 2001 4:30 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1';
> 'john.loughney@nokia.com'; seamoby@cdma-2000.org
> Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> On Wed, Jul 11, 2001 at 03:00:32PM -0400, Gary Kenward wrote:
> > 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.
> 
> Good. So far we are in agreement.
> 
> > 
> >   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?

Well, I disagree that there is nothing we can do with the protocol
to meet the goal. We seem to circle over the issue of "timing" quite alot,
and no resolution is in site. I think it is fatuous to create a requirements
document for a mobility protocol, particularly on that is supposed to be
contributing to "seamlessness", that does not in some manner the need
certain
time constraints. Stating that ct should be "fast" or "faster" is, IMHO,
like
saying that a politician must be honest. Good in principle, but ambiguous in
fact. 

On this point, I agree with James' latest posting. 

So, if we do not put some sort of deading goal into the requirements, and
describe
how the protocol is expected to behave to reach that goal, and how it should
behave
if the goal is missed, then what is the point? I could transfer context
using
ftp and a dial up link (don't flame me, I like ftp).

Gary

> 
> PatC
> > 
> > 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:pcalhoun@diameter.org]
> > > Sent: Wednesday, July 11, 2001 10:34 AM
> > > To: Kenward, Gary [WDLN2:AN10:EXCH]
> > > Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';
> > > seamoby@cdma-2000.org
> > > 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:Madjid.Nakhjiri@motorola.com]
> > > > Sent: Tuesday, July 10, 2001 6:37 PM
> > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';
> > > > seamoby@cdma-2000.org
> > > > 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:gkenward@nortelnetworks.com]
> > > > Sent: Tuesday, July 10, 2001 8:53 AM
> > > > To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
> > > > 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: john.loughney@nokia.com [ mailto:john.loughney@nokia.com
> > > > <mailto:john.loughney@nokia.com> ] 
> > > > > Sent: Tuesday, July 10, 2001 1:59 AM 
> > > > > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
> > > > > 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 
> > > > > 
> > > > 
> > > 
> 

------_=_NextPart_001_01C10AF8.C8BC8610
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  RE: Issue #4)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Pat:</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Pat Calhoun [<A HREF="mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, July 11, 2001 4:30 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: 'Pat Calhoun'; 'Nakhjiri Madjid-MNAKHJI1';</FONT>
<BR><FONT SIZE=2>&gt; 'john.loughney@nokia.com'; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; comments) (SHOULD</FONT>
<BR><FONT SIZE=2>&gt; be , RE: Issue #4)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; On Wed, Jul 11, 2001 at 03:00:32PM -0400, Gary Kenward wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; Pat:</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; The oAR does not need to know when the first packet arrival</FONT>
<BR><FONT SIZE=2>&gt; &gt; at the newAR may occur. Indeed, for proactive to be effective,</FONT>
<BR><FONT SIZE=2>&gt; &gt; the oAR must initiate a ct based upon an event that is only </FONT>
<BR><FONT SIZE=2>&gt; indicates</FONT>
<BR><FONT SIZE=2>&gt; &gt; a possible handover.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; Here is the scenario: the MN traffic is passing through, say, AR3.</FONT>
<BR><FONT SIZE=2>&gt; &gt; The RF subsystem (aka the link layer, aka L2) &quot;determines&quot; </FONT>
<BR><FONT SIZE=2>&gt; (through L1/l2</FONT>
<BR><FONT SIZE=2>&gt; &gt; mechanisms) that AR5, AR19, and AR11 are potential </FONT>
<BR><FONT SIZE=2>&gt; candidates for handover.</FONT>
<BR><FONT SIZE=2>&gt; &gt; AR3 receives an event from L2 that instructs it to transfer </FONT>
<BR><FONT SIZE=2>&gt; context to</FONT>
<BR><FONT SIZE=2>&gt; &gt; AR5, AR19, AR11. The three &quot;target&quot; ARs in this example are </FONT>
<BR><FONT SIZE=2>&gt; thus ready to</FONT>
<BR><FONT SIZE=2>&gt; &gt; receive a handover of the MNs traffic, if it is required to </FONT>
<BR><FONT SIZE=2>&gt; maintain the</FONT>
<BR><FONT SIZE=2>&gt; &gt; traffic flow. Note that this approach does not completely </FONT>
<BR><FONT SIZE=2>&gt; prevent the MN</FONT>
<BR><FONT SIZE=2>&gt; &gt; from unexpectedly appearing in the coverage domain of a </FONT>
<BR><FONT SIZE=2>&gt; different AR - </FONT>
<BR><FONT SIZE=2>&gt; &gt; that's the nature of wireless, however, it goes a long way </FONT>
<BR><FONT SIZE=2>&gt; to improving</FONT>
<BR><FONT SIZE=2>&gt; &gt; the situation.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; Nothing in the above refers to a deadline event. Of course, it is </FONT>
<BR><FONT SIZE=2>&gt; &gt; the objective to have the context in place before it is </FONT>
<BR><FONT SIZE=2>&gt; needed at the</FONT>
<BR><FONT SIZE=2>&gt; &gt; new AR. But ct must still work if this deadline is not met, </FONT>
<BR><FONT SIZE=2>&gt; and, because</FONT>
<BR><FONT SIZE=2>&gt; &gt; we all know how unpredictably handovers can be, the requirements and</FONT>
<BR><FONT SIZE=2>&gt; &gt; design should explicitly address this situation. In other words, in</FONT>
<BR><FONT SIZE=2>&gt; &gt; wireless handover, the exception is the rule.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Good. So far we are in agreement.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp;&nbsp; As I have stated, I want to change that text to clarify </FONT>
<BR><FONT SIZE=2>&gt; that ct completion</FONT>
<BR><FONT SIZE=2>&gt; &gt; before the first packet arrival is a goal, not a </FONT>
<BR><FONT SIZE=2>&gt; requirement. Or, perhaps,</FONT>
<BR><FONT SIZE=2>&gt; &gt; it is a SHOULD, not a MUST.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Right but using the above example, there is *nothing* the protocol</FONT>
<BR><FONT SIZE=2>&gt; can do to ensure this happens. This is network engineering, wireless</FONT>
<BR><FONT SIZE=2>&gt; technology capabilities, etc.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So, this requirement is kind of moot, since we agree that the protocol</FONT>
<BR><FONT SIZE=2>&gt; doesn't care, and the packet would be identical regardless of whether</FONT>
<BR><FONT SIZE=2>&gt; the CT occurred prior to the arrival of the first packet. I think it </FONT>
<BR><FONT SIZE=2>&gt; still makes sense to discuss timing in the protocol spec, but this is</FONT>
<BR><FONT SIZE=2>&gt; informative only.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Am I simply confused?</FONT>
</P>

<P><FONT SIZE=2>Well, I disagree that there is nothing we can do with the protocol</FONT>
<BR><FONT SIZE=2>to meet the goal. We seem to circle over the issue of &quot;timing&quot; quite alot,</FONT>
<BR><FONT SIZE=2>and no resolution is in site. I think it is fatuous to create a requirements</FONT>
<BR><FONT SIZE=2>document for a mobility protocol, particularly on that is supposed to be</FONT>
<BR><FONT SIZE=2>contributing to &quot;seamlessness&quot;, that does not in some manner the need certain</FONT>
<BR><FONT SIZE=2>time constraints. Stating that ct should be &quot;fast&quot; or &quot;faster&quot; is, IMHO, like</FONT>
<BR><FONT SIZE=2>saying that a politician must be honest. Good in principle, but ambiguous in</FONT>
<BR><FONT SIZE=2>fact. </FONT>
</P>

<P><FONT SIZE=2>On this point, I agree with James' latest posting. </FONT>
</P>

<P><FONT SIZE=2>So, if we do not put some sort of deading goal into the requirements, and describe</FONT>
<BR><FONT SIZE=2>how the protocol is expected to behave to reach that goal, and how it should behave</FONT>
<BR><FONT SIZE=2>if the goal is missed, then what is the point? I could transfer context using</FONT>
<BR><FONT SIZE=2>ftp and a dial up link (don't flame me, I like ftp).</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Gary</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Note: the ct scheme we are working on is a little different </FONT>
<BR><FONT SIZE=2>&gt; then that</FONT>
<BR><FONT SIZE=2>&gt; &gt; described above, but hte principle is the same. I did not </FONT>
<BR><FONT SIZE=2>&gt; want to get into</FONT>
<BR><FONT SIZE=2>&gt; &gt; all the details in this email.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; From: Pat Calhoun [<A HREF="mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Sent: Wednesday, July 11, 2001 10:34 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; To: Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; comments) (SHOULD</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; be , RE: Issue #4)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; If we end up deciding that we want to keep most of the current</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; text, I will follow the WG's desire, but I do have some</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; concern with the fact that it currently uses the arrival of</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; a packet destined for the MN as the main difference between both</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; modes of operation. My issue here is in source triggers </FONT>
<BR><FONT SIZE=2>&gt; (meaning oAP</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; initiates CTP), oAP has no way of knowing when the first </FONT>
<BR><FONT SIZE=2>&gt; packet will</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; be received, and therefore doesn't know whether a proactive or</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; reactive CTP should be initiated. This is why I am </FONT>
<BR><FONT SIZE=2>&gt; convinced that this</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; is just informational, and not a protocol thing.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; On Wed, Jul 11, 2001 at 10:20:20AM -0400, Gary Kenward wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Madjid:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp; I'm glad you feel this way. I guess this discussion </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; began as a result of </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Issue #4, which proposes an alternate wording.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; After a few exchanges with Cedric, I reviewed the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; current text, and</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; I realized that it indicates that proactive is deadline </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; driven, which I</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; really</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; believe is a bad thing to require.&nbsp; All I want to ensure is </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; that there is a </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; capability with ctp to start a ct sometime before the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; actually traffic</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; handover</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; is initiated. Why? Because there are many networks that </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; provide &quot;warnings&quot;</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; that a handover may be imminent (actually, most RF systems </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; can be designed</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; to do this, and should). How? Well, the actual trigger </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; event will change</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; depending upon the L2 design, but typically, the mechanism </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; starts with the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; base receiver sensing transmission from a mobile, and then </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; usually many</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; other </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; mechanisms that kick in to identify the mobile at L1/L2.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp; So, I would also like to keep the current text, for the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; same reason. I</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; would</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; like to remove the deadline, or at least change it so that </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; it is clearly a</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; desirable</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; deadline, but not a requirement (we cannot make it a </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; requirement because the</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; physics</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; of wireless handover make the timing of any forewarning </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; event completely un-</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; predictable).</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp; Maybe I've said this all before, and maybe my view is </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; clear to everyone.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Sorry</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; for being repetitive.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Gary</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; From: Nakhjiri Madjid-MNAKHJI1 </FONT>
<BR><FONT SIZE=2>&gt; [<A HREF="mailto:Madjid.Nakhjiri@motorola.com">mailto:Madjid.Nakhjiri@motorola.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Sent: Tuesday, July 10, 2001 6:37 PM</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Gary,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; I don't think we should remove the reactive/ proactive </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; definitions out of</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; requirement, unless there is a consensus for removing it.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; If we nobody can come up with a better definition than </FONT>
<BR><FONT SIZE=2>&gt; the already</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; existing one, either we keep it or declare it as an open issue.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Personally I liked the definitions that are based on the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; starting event</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; such as link establishment better, but I still can live </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; with the exiting </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; one (packet arrival) for the time being. Removing the </FONT>
<BR><FONT SIZE=2>&gt; whole thing</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; is throwing a lot of good thoughts away.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; A requirement subject to modifications is better than no </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; requirement.</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Madjid</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; From: Gary Kenward [<A HREF="mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Sent: Tuesday, July 10, 2001 8:53 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; John: </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp; I have been contemplating removing the </FONT>
<BR><FONT SIZE=2>&gt; &quot;reactive&quot;/&quot;proactive&quot; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; definitions from the requirements also, but I really do hope we </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; do not lose the concept of starting ct as early as </FONT>
<BR><FONT SIZE=2>&gt; possible. Being </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; proactive with ct has been a fundamental component to </FONT>
<BR><FONT SIZE=2>&gt; ct since the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; problem statement draft, and, to me, a critical tool </FONT>
<BR><FONT SIZE=2>&gt; for providing </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; seamless service handover. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp; There are those who, rightfully, have no interest in </FONT>
<BR><FONT SIZE=2>&gt; proactive </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; ct for their networks. If we lose the requirement, it </FONT>
<BR><FONT SIZE=2>&gt; may be very </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; difficult for the wg to proceed with a ctp design that supports </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; this mode. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp; I'll wait for your issue to be generated. Some of us </FONT>
<BR><FONT SIZE=2>&gt; are also </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; struggling with some alterative wording of the definitions </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; Gary </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; -----Original Message----- </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; From: john.loughney@nokia.com [ <A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A></FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &lt;<A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>&gt; ] </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; Sent: Tuesday, July 10, 2001 1:59 AM </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; comments) </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; Hi Gary, </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp; I agree, particularly with your definition of ct </FONT>
<BR><FONT SIZE=2>&gt; (although I'm </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; not sure where &quot;reductive mode&quot; came from). </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; Ooops, I meant that I was in &quot;reductive mode&quot; (trying to </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; simplify &amp; get back to the basics).&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; In thinking through the overall discussion, I am </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; realize that the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; big difference between &quot;reactive&quot; and &quot;proactive&quot; is </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; how they are </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; triggered. &quot;proactive&quot; assumes that there is a trigger </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; available </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; early on that permits some context transfer in advance </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; of an actual </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; handover. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; I agree. My thoughts are that the discussion of reactive </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; and proactive </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; (&amp; triggering, etc.) get quite close to protocol </FONT>
<BR><FONT SIZE=2>&gt; design.&nbsp; I think </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; that is one reason that the discussion became so heavy on the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; the requirements. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt;&nbsp;&nbsp; I do believe the current wording for proactive is </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; wrong. Now that </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; I have had time to contemplate the wording, it does not </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; define what </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; I have always believed proactive ct should be </FONT>
<BR><FONT SIZE=2>&gt; about. I'm hoping </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; that if we fix that wording, we can move on to the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; important part </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; &gt; of designing ctp. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; My suggestion would be to cut-out of the requirements </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; document the </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; discussion about proactive &amp; reactive text.&nbsp; I will try </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; to make an </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; issue for this later in the day. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; thanks, </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; John </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10AF8.C8BC8610--


From owner-seamoby@diameter.org  Thu Jul 12 13:59:52 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27514
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 13:59:51 -0400 (EDT)
Received: (qmail 30224 invoked by alias); 12 Jul 2001 17:24:50 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30218 invoked by uid 200); 12 Jul 2001 17:24:50 -0000
Received: (qmail 30213 invoked from network); 12 Jul 2001 17:24:47 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 17:24:47 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1K33V>; Thu, 12 Jul 2001 13:34:47 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445597@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'James Kempf'" <James.Kempf@Sun.COM>, pcalhoun@diameter.org,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com,
        john.loughney@nokia.com, seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	  ,          RE: Issue #4)
Date: Thu, 12 Jul 2001 13:34:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

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) :-)

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Thursday, July 12, 2001 12:02 PM
> 
> 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.

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 owner-seamoby@diameter.org  Thu Jul 12 14:03:16 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27949
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 14:03:14 -0400 (EDT)
Received: (qmail 30423 invoked by alias); 12 Jul 2001 17:27:53 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30414 invoked by uid 200); 12 Jul 2001 17:27:52 -0000
Received: (qmail 30404 invoked from network); 12 Jul 2001 17:27:49 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 17:27:49 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6CHbob16702
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 13:37:50 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Thu, 12 Jul 2001 13:37:46 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Z8YF>; Thu, 12 Jul 2001 13:37:48 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E38@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Thu, 12 Jul 2001 13:37:40 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10AF9.5912BFE0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10AF9.5912BFE0
Content-Type: text/plain;
	charset="iso-8859-1"

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

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Wednesday, July 11, 2001 5:18 PM
> To: 'James Kempf'; pcalhoun@diameter.org; Kenward, Gary
> [WDLN2:AN10:EXCH]
> Cc: Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;
> seamoby@cdma-2000.org
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> 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
> 

------_=_NextPart_001_01C10AF9.5912BFE0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  RE: Issue #4)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Phil:</FONT>
</P>

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

<P><FONT SIZE=2>&nbsp; This, to me, implies greater reliability, not less.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phillip Neumiller [<A HREF="mailto:PNeumiller@MeshNetworks.com">mailto:PNeumiller@MeshNetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, July 11, 2001 5:18 PM</FONT>
<BR><FONT SIZE=2>&gt; To: 'James Kempf'; pcalhoun@diameter.org; Kenward, Gary</FONT>
<BR><FONT SIZE=2>&gt; [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;</FONT>
<BR><FONT SIZE=2>&gt; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; comments) (SHOULD</FONT>
<BR><FONT SIZE=2>&gt; be , RE: Issue #4)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Is there any co-dependence between CT and &quot;succesful&quot; handovers?</FONT>
<BR><FONT SIZE=2>&gt; I think so.&nbsp; Seperating the messages makes handover less reliable.</FONT>
<BR><FONT SIZE=2>&gt; Do we want to build &quot;seamless handover&quot; systems that are less</FONT>
<BR><FONT SIZE=2>&gt; reliable?&nbsp; What about jitter and congestions effect on the timing</FONT>
<BR><FONT SIZE=2>&gt; of multiple messages?&nbsp; Yuck.&nbsp; I don't get your argument Pat.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Best Regards,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Phil</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10AF9.5912BFE0--


From owner-seamoby@diameter.org  Thu Jul 12 14:09:44 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28734
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 14:09:37 -0400 (EDT)
Received: (qmail 30835 invoked by alias); 12 Jul 2001 17:30:01 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30823 invoked by uid 200); 12 Jul 2001 17:29:57 -0000
Received: (qmail 30799 invoked from network); 12 Jul 2001 17:29:52 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 17:29:52 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6CHdlb16997
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 13:39:47 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Thu, 12 Jul 2001 13:39:52 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Z85B>; Thu, 12 Jul 2001 13:39:54 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E39@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'James Kempf'" <James.Kempf@Sun.COM>, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Thu, 12 Jul 2001 13:39:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10AF9.A8188C00"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10AF9.A8188C00
Content-Type: text/plain;
	charset="iso-8859-1"

Me thinks Gary does agree. 

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

Gary

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Wednesday, July 11, 2001 6:06 PM
> To: James.Kempf@Sun.COM; pcalhoun@diameter.org
> Cc: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH];
> Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;
> seamoby@cdma-2000.org
> 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)
> or together is an implementation decision. I suppose whoever does
> the MIP binding will determine that.
> 
> 		jak
> 
> >Delivered-To: seamoby-list@charizard.diameter.org
> >Date: Wed, 11 Jul 2001 13:41:41 -0700
> >From: Pat Calhoun <pcalhoun@diameter.org>
> >To: James Kempf <James.Kempf@Sun.COM>
> >Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com, 
> Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com, 
> seamoby@cdma-2000.org
> >Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD be ,    
>       RE: Issue #4)
> >Mail-Followup-To: James Kempf <James.Kempf@Sun.COM>, 
> pcalhoun@diameter.org, 
> gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com, 
> john.loughney@nokia.com, seamoby@cdma-2000.org
> >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
> >> 
> 
> 

------_=_NextPart_001_01C10AF9.A8188C00
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  RE: Issue #4)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Me thinks Gary does agree. </FONT>
</P>

<P><FONT SIZE=2>At least with the first paragraph. I'm not sure about the</FONT>
<BR><FONT SIZE=2>second paragraph, but it sounds right.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: James Kempf [<A HREF="mailto:James.Kempf@Sun.COM">mailto:James.Kempf@Sun.COM</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Wednesday, July 11, 2001 6:06 PM</FONT>
<BR><FONT SIZE=2>&gt; To: James.Kempf@Sun.COM; pcalhoun@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Cc: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH];</FONT>
<BR><FONT SIZE=2>&gt; Madjid.Nakhjiri@motorola.com; john.loughney@nokia.com;</FONT>
<BR><FONT SIZE=2>&gt; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; comments) (SHOULD</FONT>
<BR><FONT SIZE=2>&gt; be , RE: Issue #4)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Ok, then it does seem we agree (or perhaps Gary doesn't?) that</FONT>
<BR><FONT SIZE=2>&gt; there is an ordering on what's needed for nAR to be primed for</FONT>
<BR><FONT SIZE=2>&gt; that first packet. nAR must have the HO signaling and the CT</FONT>
<BR><FONT SIZE=2>&gt; signaling, and if it doesn't have the first, it must wait </FONT>
<BR><FONT SIZE=2>&gt; for the second, and vice versa. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; IMHO, whether or not that is done by doing the signaling separately</FONT>
<BR><FONT SIZE=2>&gt; (and thus incurs the overhead of maintaining timers on the router)</FONT>
<BR><FONT SIZE=2>&gt; or together is an implementation decision. I suppose whoever does</FONT>
<BR><FONT SIZE=2>&gt; the MIP binding will determine that.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; jak</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;Delivered-To: seamoby-list@charizard.diameter.org</FONT>
<BR><FONT SIZE=2>&gt; &gt;Date: Wed, 11 Jul 2001 13:41:41 -0700</FONT>
<BR><FONT SIZE=2>&gt; &gt;From: Pat Calhoun &lt;pcalhoun@diameter.org&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;To: James Kempf &lt;James.Kempf@Sun.COM&gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com, </FONT>
<BR><FONT SIZE=2>&gt; Madjid.Nakhjiri@motorola.com, john.loughney@nokia.com, </FONT>
<BR><FONT SIZE=2>&gt; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt;Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; comments) (SHOULD be ,&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RE: Issue #4)</FONT>
<BR><FONT SIZE=2>&gt; &gt;Mail-Followup-To: James Kempf &lt;James.Kempf@Sun.COM&gt;, </FONT>
<BR><FONT SIZE=2>&gt; pcalhoun@diameter.org, </FONT>
<BR><FONT SIZE=2>&gt; gkenward@nortelnetworks.com, Madjid.Nakhjiri@motorola.com, </FONT>
<BR><FONT SIZE=2>&gt; john.loughney@nokia.com, seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; &gt;Content-Disposition: inline</FONT>
<BR><FONT SIZE=2>&gt; &gt;User-Agent: Mutt/1.2.5i</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;James,</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;I believe that there are ways around this. One example is a very</FONT>
<BR><FONT SIZE=2>&gt; &gt;simple MIP extension that is sent stating that a CT is forthcoming </FONT>
<BR><FONT SIZE=2>&gt; &gt;(or may have already been sent). At least, this would be enough for</FONT>
<BR><FONT SIZE=2>&gt; &gt;the receiver to know that it must wait for CT before sending packets</FONT>
<BR><FONT SIZE=2>&gt; &gt;to the mobile.</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;PatC</FONT>
<BR><FONT SIZE=2>&gt; &gt;On Wed, Jul 11, 2001 at 01:43:51PM -0700, James Kempf wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; Gary,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;Err, no. That's not what I was agreeing to. </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;Once again, proactive ct should be driven by the initiation</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;event, not the deadline event. It is preferable that context</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;be installed before the traffic arrives at the newAR, but it's</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;not a MUST requirement, and it certainly does not dictate that</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;ho and ct protocols must be synchronous.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; I'm not sure I understand. If nAR can't deliver packets unless</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; the CT is installed, then how can it not be a MUST requirement?</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; Seems to me, that the completion of the handover is predicated</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; on CT working.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;And I see no reason for requiring handover signalling to complete</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;before ct (MIP may require it, but that's would be a potential </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;MIP weakness, were it true). Even if this is true, it applies only</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;to reactive ct, and contradicts the purpose of proactive ct.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; Right, I didn't say it was a general requirement, I only said</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; I see it as a requirement for a particular solution. And I don't</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; necessarily see it as a weakness, if it results in faster </FONT>
<BR><FONT SIZE=2>&gt; handover for MIP.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;You seem to be implying that there is some dire consequence to be</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;realized if a ct happens but an ho doesn't. At best, the new AR</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;will be holding onto useless context. At worse, the new AR may</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;reserve resources that could be used elsewhere. Either situation </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;seems resolvable with some sort of &quot;life timer&quot; and garbage </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;collection. It does not imply that the two protocols be </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;synchronous.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; I'm not implying anything, I'm just trying to figure out where</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; you are coming from. I've had my head embedded in this handover</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; problem for a while now, particularly with regard to making</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; MIP handover fast enough for real time streams, and every time</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; I tune into the CT discussion, it seems to be drifting off into</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; philosophy and further away from what IMHO is essential engineering</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; for getting MIP to work fast. I'm sure I'm probably missing</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; alot of context here (so to speak), and I do admit to a </FONT>
<BR><FONT SIZE=2>&gt; MIP bias, but I'm</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; having some real trouble extracting anything out of this.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;I'm missing the critical state relationship between ct and ho</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;that you are alluding to.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; Sure I am. Let's take&nbsp; a specific example. Suppose we are doing</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; network assisted handover in MIP. Suppose that we want to transfer</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; the authentication&nbsp; context and header compression context so that</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; we can start up the real time stream on the MN just as soon as</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; it shows up on the L2 (otherwise the user ends up hearing a half</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; duplex converstation). In order for the handover to successfully</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; conclude, the nAR needs:</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &nbsp;&nbsp; 1) Signaling from oAR that MN is coming soon,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &nbsp;&nbsp; 2) The relevent CT for nAR to install,</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &nbsp;&nbsp; 3) Tunneled packets until MN gets around to changing its CoA.</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; and it needs them in that order. </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; Suppose they do not arrive in that order. Clearly, 3) being out of</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; order first can be ruled out. If 3) arrives before 1, nAR doesn't</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; know that MN is coming. If 2) arrives before 1), nAR can </FONT>
<BR><FONT SIZE=2>&gt; wait for 1),</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; but that implies a timer. If 3) arrives before 2), the proper</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; authentication and header compression state isn't around. </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; What am I missing?</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; &nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; jak</FONT>
<BR><FONT SIZE=2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10AF9.A8188C00--


From owner-seamoby@diameter.org  Thu Jul 12 14:17:16 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29701
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 14:17:14 -0400 (EDT)
Received: (qmail 30977 invoked by alias); 12 Jul 2001 17:34:18 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30971 invoked by uid 200); 12 Jul 2001 17:34:18 -0000
Received: (qmail 30963 invoked from network); 12 Jul 2001 17:34:14 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 17:34:14 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6CHi1b17761
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 13:44:01 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 12 Jul 2001 13:43:57 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Z89Q>; Thu, 12 Jul 2001 13:44:00 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E3A@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        pcalhoun@diameter.org
Cc: PNeumiller@MeshNetworks.com, seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
         Phase CT
Date: Thu, 12 Jul 2001 13:43:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10AFA.396B4E40"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10AFA.396B4E40
Content-Type: text/plain;
	charset="iso-8859-1"

John:

 I agree. Good analysis. I look forward to reading the issue.

Gary

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Thursday, July 12, 2001 4:22 AM
> To: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: PNeumiller@MeshNetworks.com; seamoby@cdma-2000.org
> Subject: RE: CT reliability model was RE: [seamoby] [Issue] 
> Support for
> Mu lti- Phase CT
> 
> 
> Hi Pat,
> 
> > I think that two phases are needed, regardless of the MTU size. I
> > believe that in order to achieve a seamless handoff, it is necessary
> > to transfer time sensitive context blobs as soon as possible (e.g.
> > header compression, L2 keying info, L3 SAs). These are necessary
> > in order to exchange packets with the mobile, but there may be other
> > time sensitive blobs that I haven't thought of as well. 
> > Non-time sensitive blobs (e.g. accounting session id) are 
> not needed 
> > to send/receive packets and therefore do not need to be 
> sent right away.
> 
> I think that discussing of phases is leading us to a dead end.  What
> we need is the following behavior:
> 
> 1) Ability to send time-critical context
> 2) Ability to discard stale context
> 3) Ability to synchronize the context transfer with an additional
>    procedure (like a handover)
> 4) Ability to use different triggers to start the transfer of some 
>    contexts.
> 5) Ability to acknowledge the transfer of some contexts.
> 6) Ability to group or send seperately contexts.
> 
> My feeling is that when we group the behaviors, we may get 
> the different
> phases - but I think that there may be more than just 2 phases of 
> CT.  Actually, the above behaviors may depend upon the type context
> being transfered.  As we have not identified all the possible types
> of context to be transfered and all of the situations, I don't
> believe that discussing the phases (or modes) of context transfer
> is a good idea currently.
> 
> I'm writing up an issue on this right now.  I'm happy to contribute
> text.
> 
> Comments?
> John
> 
> 

------_=_NextPart_001_01C10AFA.396B4E40
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-  Phase CT</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>John:</FONT>
</P>

<P><FONT SIZE=2>&nbsp;I agree. Good analysis. I look forward to reading the issue.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: john.loughney@nokia.com [<A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, July 12, 2001 4:22 AM</FONT>
<BR><FONT SIZE=2>&gt; To: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: PNeumiller@MeshNetworks.com; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: CT reliability model was RE: [seamoby] [Issue] </FONT>
<BR><FONT SIZE=2>&gt; Support for</FONT>
<BR><FONT SIZE=2>&gt; Mu lti- Phase CT</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Pat,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I think that two phases are needed, regardless of the MTU size. I</FONT>
<BR><FONT SIZE=2>&gt; &gt; believe that in order to achieve a seamless handoff, it is necessary</FONT>
<BR><FONT SIZE=2>&gt; &gt; to transfer time sensitive context blobs as soon as possible (e.g.</FONT>
<BR><FONT SIZE=2>&gt; &gt; header compression, L2 keying info, L3 SAs). These are necessary</FONT>
<BR><FONT SIZE=2>&gt; &gt; in order to exchange packets with the mobile, but there may be other</FONT>
<BR><FONT SIZE=2>&gt; &gt; time sensitive blobs that I haven't thought of as well. </FONT>
<BR><FONT SIZE=2>&gt; &gt; Non-time sensitive blobs (e.g. accounting session id) are </FONT>
<BR><FONT SIZE=2>&gt; not needed </FONT>
<BR><FONT SIZE=2>&gt; &gt; to send/receive packets and therefore do not need to be </FONT>
<BR><FONT SIZE=2>&gt; sent right away.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think that discussing of phases is leading us to a dead end.&nbsp; What</FONT>
<BR><FONT SIZE=2>&gt; we need is the following behavior:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1) Ability to send time-critical context</FONT>
<BR><FONT SIZE=2>&gt; 2) Ability to discard stale context</FONT>
<BR><FONT SIZE=2>&gt; 3) Ability to synchronize the context transfer with an additional</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; procedure (like a handover)</FONT>
<BR><FONT SIZE=2>&gt; 4) Ability to use different triggers to start the transfer of some </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; contexts.</FONT>
<BR><FONT SIZE=2>&gt; 5) Ability to acknowledge the transfer of some contexts.</FONT>
<BR><FONT SIZE=2>&gt; 6) Ability to group or send seperately contexts.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; My feeling is that when we group the behaviors, we may get </FONT>
<BR><FONT SIZE=2>&gt; the different</FONT>
<BR><FONT SIZE=2>&gt; phases - but I think that there may be more than just 2 phases of </FONT>
<BR><FONT SIZE=2>&gt; CT.&nbsp; Actually, the above behaviors may depend upon the type context</FONT>
<BR><FONT SIZE=2>&gt; being transfered.&nbsp; As we have not identified all the possible types</FONT>
<BR><FONT SIZE=2>&gt; of context to be transfered and all of the situations, I don't</FONT>
<BR><FONT SIZE=2>&gt; believe that discussing the phases (or modes) of context transfer</FONT>
<BR><FONT SIZE=2>&gt; is a good idea currently.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I'm writing up an issue on this right now.&nbsp; I'm happy to contribute</FONT>
<BR><FONT SIZE=2>&gt; text.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Comments?</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10AFA.396B4E40--


From owner-seamoby@diameter.org  Thu Jul 12 14:23:49 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00636
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 14:23:48 -0400 (EDT)
Received: (qmail 31199 invoked by alias); 12 Jul 2001 17:40:52 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 31192 invoked by uid 200); 12 Jul 2001 17:40:51 -0000
Received: (qmail 31182 invoked from network); 12 Jul 2001 17:40:45 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 17:40:45 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1K3P2>; Thu, 12 Jul 2001 13:50:37 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445598@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,  RE: Issue #4)
Date: Thu, 12 Jul 2001 13:50:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Gary,
-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
>Phil: 
>
>  Consider this: does requiring ct to complete successfully in 
>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.

>If ct fails (or more likely is delayed), what is the fall back 
>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 owner-seamoby@diameter.org  Thu Jul 12 14:27:51 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01122
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 14:27:48 -0400 (EDT)
Received: (qmail 31242 invoked by alias); 12 Jul 2001 17:41:35 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 31235 invoked by uid 200); 12 Jul 2001 17:41:34 -0000
Received: (qmail 31229 invoked from network); 12 Jul 2001 17:41:29 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 17:41:29 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6CHpNb18941
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 13:51:23 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Thu, 12 Jul 2001 13:51:17 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Z9F3>; Thu, 12 Jul 2001 13:51:20 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E3B@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Thu, 12 Jul 2001 13:51:18 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10AFB.411F8BA0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10AFB.411F8BA0
Content-Type: text/plain;
	charset="iso-8859-1"

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

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Thursday, July 12, 2001 4:51 AM
> To: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: Madjid.Nakhjiri@motorola.com; seamoby@cdma-2000.org
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> 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
> 

------_=_NextPart_001_01C10AFB.411F8BA0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  RE: Issue #4)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>John:</FONT>
</P>

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

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: john.loughney@nokia.com [<A HREF="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, July 12, 2001 4:51 AM</FONT>
<BR><FONT SIZE=2>&gt; To: pcalhoun@diameter.org; Kenward, Gary [WDLN2:AN10:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: Madjid.Nakhjiri@motorola.com; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; comments) (SHOULD</FONT>
<BR><FONT SIZE=2>&gt; be , RE: Issue #4)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Pat,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt;&nbsp;&nbsp; As I have stated, I want to change that text to clarify </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; that ct completion before the first packet arrival is a goal, </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; not a requirement. Or, perhaps, it is a SHOULD, not a MUST.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Right but using the above example, there is *nothing* the protocol</FONT>
<BR><FONT SIZE=2>&gt; &gt; can do to ensure this happens. This is network engineering, wireless</FONT>
<BR><FONT SIZE=2>&gt; &gt; technology capabilities, etc.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; So, this requirement is kind of moot, since we agree that </FONT>
<BR><FONT SIZE=2>&gt; the protocol</FONT>
<BR><FONT SIZE=2>&gt; &gt; doesn't care, and the packet would be identical regardless </FONT>
<BR><FONT SIZE=2>&gt; of whether</FONT>
<BR><FONT SIZE=2>&gt; &gt; the CT occurred prior to the arrival of the first packet. I </FONT>
<BR><FONT SIZE=2>&gt; think it </FONT>
<BR><FONT SIZE=2>&gt; &gt; still makes sense to discuss timing in the protocol spec, </FONT>
<BR><FONT SIZE=2>&gt; but this is</FONT>
<BR><FONT SIZE=2>&gt; &gt; informative only.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Am I simply confused?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I more-or-less agree with you, except on this point (which is </FONT>
<BR><FONT SIZE=2>&gt; debatable).</FONT>
<BR><FONT SIZE=2>&gt; The only way we could make CT completion a before the first </FONT>
<BR><FONT SIZE=2>&gt; packet arrival</FONT>
<BR><FONT SIZE=2>&gt; a MUST would be that we have a CT-completion-ack message.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; When this message</FONT>
<BR><FONT SIZE=2>&gt; is recieved, then the handoff can be instigated.&nbsp; I'm sure that this </FONT>
<BR><FONT SIZE=2>&gt; is a good idea, however.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; More generally, I see the use of different 'triggers' as a way to </FONT>
<BR><FONT SIZE=2>&gt; start context transfers.&nbsp; One trigger could be simply that th</FONT>
<BR><FONT SIZE=2>&gt; mobile node 'sees' a new point of attachment.&nbsp; This could kick off</FONT>
<BR><FONT SIZE=2>&gt; some context transfer.&nbsp; Another trigger could be the initiation of</FONT>
<BR><FONT SIZE=2>&gt; a handover and yet another would be the completion of a handover.</FONT>
<BR><FONT SIZE=2>&gt; However, I'd prefer not to get into the uses of the triggers yet.</FONT>
<BR><FONT SIZE=2>&gt; I think the usage of triggers will be situational - and the CT</FONT>
<BR><FONT SIZE=2>&gt; should be robust enough to handle all situations.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; br,</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10AFB.411F8BA0--


From owner-seamoby@diameter.org  Thu Jul 12 14:36:04 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02245
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 14:36:02 -0400 (EDT)
Received: (qmail 32646 invoked by alias); 12 Jul 2001 18:00:14 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 32640 invoked by uid 200); 12 Jul 2001 18:00:13 -0000
Received: (qmail 32627 invoked from network); 12 Jul 2001 18:00:04 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 18:00:04 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6CI9xb21746
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 14:09:59 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Thu, 12 Jul 2001 14:10:05 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Z9Y6>; Thu, 12 Jul 2001 14:10:07 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E3C@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Thu, 12 Jul 2001 14:10:05 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10AFD.E0AC0CA0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10AFD.E0AC0CA0
Content-Type: text/plain;
	charset="iso-8859-1"

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

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Thursday, July 12, 2001 1:51 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Phillip Neumiller;
> pcalhoun@diameter.org
> Cc: seamoby@cdma-2000.org
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> Hi Gary,
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> >Phil: 
> >
> >  Consider this: does requiring ct to complete successfully in 
> >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.
> 
> >If ct fails (or more likely is delayed), what is the fall back 
> >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
> 
> 

------_=_NextPart_001_01C10AFD.E0AC0CA0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  RE: Issue #4)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Phil:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; If I understand your response, I think that the real issue</FONT>
<BR><FONT SIZE=2>is that ct must support seamlessness, for as you identified,</FONT>
<BR><FONT SIZE=2>that is the purpose of this wg. However, I think the point that</FONT>
<BR><FONT SIZE=2>others have stressed is that ct should not break handover.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; Thus, ct must be completed for seamless handover, but is</FONT>
<BR><FONT SIZE=2>not required (but may be completed) for handover in general.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; And of course, no one but us knows what seamless means ;^}.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phillip Neumiller [<A HREF="mailto:PNeumiller@MeshNetworks.com">mailto:PNeumiller@MeshNetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, July 12, 2001 1:51 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; Phillip Neumiller;</FONT>
<BR><FONT SIZE=2>&gt; pcalhoun@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; comments) (SHOULD</FONT>
<BR><FONT SIZE=2>&gt; be , RE: Issue #4)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Gary,</FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Gary Kenward [<A HREF="mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt;Phil: </FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; Consider this: does requiring ct to complete successfully in </FONT>
<BR><FONT SIZE=2>&gt; &gt;addition to traffic handover make mobility more or less reliable? </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Logically, if we NEED CT to acheive &quot;seamless handover&quot;, i.e. </FONT>
<BR><FONT SIZE=2>&gt; CT &lt;= (only if) seamless, then they are co-dependent.&nbsp; Thus they</FONT>
<BR><FONT SIZE=2>&gt; are inseperable if we are to acheive our goal.&nbsp; The correct </FONT>
<BR><FONT SIZE=2>&gt; question to ask is &quot;do you want CT with your handover?&quot; </FONT>
<BR><FONT SIZE=2>&gt; I prefer the &quot;happy meal&quot; answer myself.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;If ct fails (or more likely is delayed), what is the fall back </FONT>
<BR><FONT SIZE=2>&gt; &gt;position? </FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; A non-seamless handover, a non-goal for this WG right?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;Would it not be useful, in some situations, to allow </FONT>
<BR><FONT SIZE=2>&gt; &gt;for traffic handover to proceed without ct?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Isn't that what we have now???</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; Simply as an option? </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Sure don't use CT with your handover =&gt; no seamlessness. QED</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; This, to me, implies greater reliability, not less. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; You made no reliability argument in the above statements?</FONT>
<BR><FONT SIZE=2>&gt; Flexibility arguments were made.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Phil</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10AFD.E0AC0CA0--


From owner-seamoby@diameter.org  Thu Jul 12 14:42:11 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03172
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 14:42:10 -0400 (EDT)
Received: (qmail 989 invoked by alias); 12 Jul 2001 18:11:27 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 982 invoked by uid 200); 12 Jul 2001 18:11:26 -0000
Received: (qmail 971 invoked from network); 12 Jul 2001 18:11:24 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 18:11:24 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1K3QG>; Thu, 12 Jul 2001 14:21:28 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E048445599@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,  RE: Issue #4)
Date: Thu, 12 Jul 2001 14:21:21 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Yikes!

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, July 12, 2001 2:10 PM
To: 'Phillip Neumiller'; pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,
RE: Issue #4)
>
>
>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.  

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 
>others have stressed is that ct should not break handover. 

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!!!

>  Thus, ct must be completed for seamless handover, but is 
>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 owner-seamoby@diameter.org  Thu Jul 12 14:48:44 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04605
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 14:48:41 -0400 (EDT)
Received: (qmail 2168 invoked by alias); 12 Jul 2001 18:24:47 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2160 invoked by uid 200); 12 Jul 2001 18:24:46 -0000
Received: (qmail 2143 invoked from network); 12 Jul 2001 18:24:42 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 18:24:42 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6CIYfb25508
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 14:34:42 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Thu, 12 Jul 2001 14:34:42 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ2Z0RZ>; Thu, 12 Jul 2001 14:34:44 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E3E@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Thu, 12 Jul 2001 14:34:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10B01.4E92F050"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10B01.4E92F050
Content-Type: text/plain;
	charset="iso-8859-1"

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 ;^} ).

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Thursday, July 12, 2001 2:21 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; Phillip Neumiller;
> pcalhoun@diameter.org
> Cc: seamoby@cdma-2000.org
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> Yikes!
> 
> -----Original Message-----
> From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
> Sent: Thursday, July 12, 2001 2:10 PM
> To: 'Phillip Neumiller'; pcalhoun@diameter.org
> Cc: seamoby@cdma-2000.org
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD be ,
> RE: Issue #4)
> >
> >
> >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.  
> 
> 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 
> >others have stressed is that ct should not break handover. 
> 
> 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!!!
> 
> >  Thus, ct must be completed for seamless handover, but is 
> >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
> 

------_=_NextPart_001_01C10B01.4E92F050
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,  RE: Issue #4)</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Phil:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I did not say that you could perform &quot;seamless handover&quot; without ct, </FONT>
<BR><FONT SIZE=2>I said that ct is not essential to an ordinary handover (&quot;seamy handover&quot;?).</FONT>
<BR><FONT SIZE=2>And thus, a failure to complete ct on time must not cause an </FONT>
<BR><FONT SIZE=2>&quot;ordinary handover&quot; (&quot;best effort handover&quot;?) to fail.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; Some designers want to be able to fall back to a &quot;best effort&quot;</FONT>
<BR><FONT SIZE=2>handover if the seamless handover fails, and yes, the seams will show.</FONT>
<BR><FONT SIZE=2>&nbsp; </FONT>
<BR><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>(PS: we cannot use the word &quot;seamless&quot; in a draft, so it has no</FONT>
<BR><FONT SIZE=2>formal definition ;^{ ; and we have never come up with an alternative</FONT>
<BR><FONT SIZE=2>- nor do I want to get into *that* discussion ;^} ).</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phillip Neumiller [<A HREF="mailto:PNeumiller@MeshNetworks.com">mailto:PNeumiller@MeshNetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, July 12, 2001 2:21 PM</FONT>
<BR><FONT SIZE=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; Phillip Neumiller;</FONT>
<BR><FONT SIZE=2>&gt; pcalhoun@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; comments) (SHOULD</FONT>
<BR><FONT SIZE=2>&gt; be , RE: Issue #4)</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Yikes!</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Gary Kenward [<A HREF="mailto:gkenward@nortelnetworks.com">mailto:gkenward@nortelnetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, July 12, 2001 2:10 PM</FONT>
<BR><FONT SIZE=2>&gt; To: 'Phillip Neumiller'; pcalhoun@diameter.org</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - </FONT>
<BR><FONT SIZE=2>&gt; comments) (SHOULD be ,</FONT>
<BR><FONT SIZE=2>&gt; RE: Issue #4)</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;</FONT>
<BR><FONT SIZE=2>&gt; &gt;Phil: </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; If I understand your response, I think that the real issue </FONT>
<BR><FONT SIZE=2>&gt; &gt;is that ct must support seamlessness, for as you identified, </FONT>
<BR><FONT SIZE=2>&gt; &gt;that is the purpose of this wg.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; NO!&nbsp; CT is &quot;part and parcel&quot; of seamlessness.&nbsp; No CT means you</FONT>
<BR><FONT SIZE=2>&gt; don't have a seamless handover, a non-goal.&nbsp; I thought we were</FONT>
<BR><FONT SIZE=2>&gt; working to design seamless handovers?&nbsp; If that IS the premise,</FONT>
<BR><FONT SIZE=2>&gt; then we should work on the BEST way to do this.&nbsp; The BEST way</FONT>
<BR><FONT SIZE=2>&gt; to do this is not pre-, pro-, or poly, its a requirement that</FONT>
<BR><FONT SIZE=2>&gt; is NOT part of the requirements surprisingly, its DURING as</FONT>
<BR><FONT SIZE=2>&gt; in PART OF as in BUNDLED as in ACTIVE as in any other word</FONT>
<BR><FONT SIZE=2>&gt; I can think of describe &quot;inextricably linked&quot;.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; However, I think the point that </FONT>
<BR><FONT SIZE=2>&gt; &gt;others have stressed is that ct should not break handover. </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; You either have CT and you get seamlessness or you don't have</FONT>
<BR><FONT SIZE=2>&gt; it and you DON'T get seemlessness.&nbsp; I see the other proposals</FONT>
<BR><FONT SIZE=2>&gt; as &quot;threats&quot; that tend to break or weaken the seamless case</FONT>
<BR><FONT SIZE=2>&gt; which is our primary goal!!!</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; Thus, ct must be completed for seamless handover, but is </FONT>
<BR><FONT SIZE=2>&gt; &gt;not required (but may be completed) for handover in general.</FONT>
<BR><FONT SIZE=2>&gt; Right.&nbsp; BUT IT IS REQUIRED FOR A SEAMLESS HANDOVER RIGHT?????</FONT>
<BR><FONT SIZE=2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; &gt;&nbsp; And of course, no one but us knows what seamless means ;^}. </FONT>
<BR><FONT SIZE=2>&gt; huh?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; -pdn</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10B01.4E92F050--


From owner-seamoby@diameter.org  Thu Jul 12 14:53:54 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06075
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 14:53:53 -0400 (EDT)
Received: (qmail 2352 invoked by alias); 12 Jul 2001 18:26:53 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2345 invoked by uid 200); 12 Jul 2001 18:26:52 -0000
Received: (qmail 2334 invoked from network); 12 Jul 2001 18:26:48 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 18:26:48 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA10574;
	Thu, 12 Jul 2001 11:37:06 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CIb5708421;
	Thu, 12 Jul 2001 11:37:05 -0700
X-mProtect:  Thu, 12 Jul 2001 11:37:05 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdcKP08e; Thu, 12 Jul 2001 11:37:03 PDT
Message-ID: <3B4DEE50.6D1687F5@iprg.nokia.com>
Date: Thu, 12 Jul 2001 11:37:04 -0700
From: Theo Pagtzis <tpagtzis@IPRG.nokia.com>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: john.loughney@nokia.com
CC: seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
 Phase CT
References: <0C1353ABB1DEB74DB067ADFF749C4EEF09402F@esebe004.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi John

  Your example is very similar to what we are proposing in the proactive
mobility draft

draft-pagtzis-mobileip-proactivev6-00.txt/.ps

(available http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html)

and provides the right mechanisms to cater for this. We need to emphasize
here the cell bouncing effects that can create serious oscillation effects
in the 'syncronisation' process with the right handoff candidate

    I have a slight reservation about the term used here though. It sounds
to me that it is not syncronisation that is effected, since for that MN the
new AR will received the context superset once and that is it. There is no
continuous streaming of context (even 'multiplexed' ) where the MN needs to
syncronize in the strict sense of syncronisation.

It simply enables connectivity with the proactive forwarding of the
context; isn't that the case you refer to ?

Theo

john.loughney@nokia.com wrote:

> Hi James,
>
> > What about making it possible to define a binding between a particular
> > mobility solution and CT, and have a general framework?
>
> That is one possiblity.  Could another _solution_ be that CT runs as
> it's own protocol, but shares a parameter with the handover in
> order to synchronize it?
>
> My example would be this.  The mobile node 'sees' 3 potential
> handoff targets.  It is not ready to instigate the handover
> yet, but wants to prepare the possible handover candidates,
> so it sends some context to them (such as header compression
> state).  All three targets get this info (compressor state,
> time-to-live, and synch value).  After some time, the mobile is
> ready to handoff - so it kicks off a handover procedure,
> with the CT synch value so that when the new AR gets it,
> the new AR knows what context to associate the handover with.
> The other 2 targets have the context TTL, so that they can
> expire the context that they have.
>
> John



From owner-seamoby@diameter.org  Thu Jul 12 14:58:17 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06829
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 14:58:16 -0400 (EDT)
Received: (qmail 2750 invoked by alias); 12 Jul 2001 18:31:43 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2744 invoked by uid 200); 12 Jul 2001 18:31:42 -0000
Received: (qmail 2732 invoked from network); 12 Jul 2001 18:31:39 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 18:31:39 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1K3RG>; Thu, 12 Jul 2001 14:41:58 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E04844559B@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,  RE: Issue #4)
Date: Thu, 12 Jul 2001 14:41:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C10B02.51995D10"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10B02.51995D10
Content-Type: text/plain;
	charset="iso-8859-1"

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. 

   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. 
  



------_=_NextPart_001_01C10B02.51995D10
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=754103718-12072001>1).&nbsp; Not using "seamless" in a draft is rule 
begging to be broken since it is</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=754103718-12072001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; absolutely 
rediculous.&nbsp; What is this Monty Python's&nbsp;flying 
IETF?</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=754103718-12072001>2).&nbsp; OK I finally understand what you are saying, 
and it makes sense and</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=754103718-12072001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a statement based on 
what your wrote below REALLY NEEDS TO BE</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=754103718-12072001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IN THE 
DRAFT.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=754103718-12072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>i.e. 
Handovers that use CT MAY fall back to best effort handvovers in 
the</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>cases 
where CT fails.&nbsp; My argument is that to make this whole thing 
clean</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>and 
more reliable we should add a requirement like:</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=754103718-12072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>To 
increase the reliability of handovers using CT, the designer MAY 
bundle</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>the CT 
packet with handover signalling such as that used in MIPv4 and 
MIPv6.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=754103718-12072001></SPAN></FONT>&nbsp;</DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <P><FONT size=2><SPAN class=754103718-12072001>&nbsp;</SPAN>I said that ct is 
  not essential to an ordinary handover ("seamy handover"?).</FONT> <BR><FONT 
  size=2>And thus, a failure to complete ct on time must not cause an 
  </FONT><BR><FONT size=2>"ordinary handover" ("best effort handover"?) to 
  fail.</FONT> </P>
  <P><FONT size=2>&nbsp;&nbsp; Some designers want to be able to fall back to a 
  "best effort"</FONT> <BR><FONT size=2>handover if the seamless handover fails, 
  and yes, the seams will show.</FONT>&nbsp;<BR><FONT size=2>&nbsp; 
  </FONT><BR></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C10B02.51995D10--


From owner-seamoby@diameter.org  Thu Jul 12 15:09:03 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08353
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 15:08:54 -0400 (EDT)
Received: (qmail 4524 invoked by alias); 12 Jul 2001 18:52:19 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 4518 invoked by uid 200); 12 Jul 2001 18:52:18 -0000
Received: (qmail 4507 invoked from network); 12 Jul 2001 18:52:10 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 18:52:10 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6CJ27b29211
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 15:02:07 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Thu, 12 Jul 2001 15:02:12 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ25AL2>; Thu, 12 Jul 2001 15:02:14 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E3F@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , 
         RE: Issue #4)
Date: Thu, 12 Jul 2001 15:02:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10B05.261B4D30"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10B05.261B4D30
Content-Type: text/plain;
	charset="iso-8859-1"

 

-----Original Message-----
From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
Sent: Thursday, July 12, 2001 2:42 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; Phillip Neumiller;
pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,
RE: Issue #4)


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?
 
Well, if it was Monty Python's flying IETF, it would at least
be much more entertaining ;^}.
 
I should be more specific: the use of "seamless" was ruled
out of the problem statement by the ADs. The concern was,
I believe, that it was an overused, abused and collectively
misunderstood term (*shrug*, that would seem to me to 
describe the English language)/
 
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 
 
Do you think? I mean, do we really need to be explicit about
every possible outcome? And how can we do this without
a design, even a use case analysis?
 
Right now, we are stumbling from one issue to another as
people identify issues that haven't been captured. When
will it end (he says rhetorically)?
 
I'm not saying the issues are unimportant; I am just concerned
that the requirements will never be done, or more importantly,
that the design will never start. 
 
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 don't see the need, but offer your suggestion to the list as an
issue.
 
Gary 
 

 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. 
  



------_=_NextPart_001_01C10B05.261B4D30
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)</TITLE>

<META content="MSHTML 5.00.2314.1000" name=GENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<BLOCKQUOTE 
style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Phillip Neumiller 
  [mailto:PNeumiller@MeshNetworks.com]<BR><B>Sent:</B> Thursday, July 12, 2001 
  2:42 PM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; Phillip Neumiller; 
  pcalhoun@diameter.org<BR><B>Cc:</B> seamoby@cdma-2000.org<BR><B>Subject:</B> 
  RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue 
  #4)<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>1).&nbsp; Not using "seamless" in a draft is rule 
  begging to be broken since it is</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; absolutely 
  rediculous.&nbsp; What is this Monty Python's&nbsp;flying 
  IETF?</SPAN></FONT><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001></SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>Well, if it was Monty Python's flying IETF, it would 
  at least</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>be much more entertaining 
  ;^}.</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>I should be more specific: the use of "seamless" was 
  ruled</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>out of the problem statement by the ADs. The concern 
  was,</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>I believe, that it was an overused, abused and 
  collectively</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>misunderstood term (*shrug*, that would seem to me to 
  </SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>describe the English 
  language</SPAN></FONT></SPAN></FONT><FONT color=#0000ff face=Arial 
  size=2><SPAN class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" 
  size=3><SPAN class=940004418-12072001>)/</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>&nbsp;</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>2).&nbsp; OK I finally understand what you are 
  saying, and it makes sense and</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a statement based on 
  what your wrote below REALLY NEEDS TO BE</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IN THE 
  DRAFT.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>i.e. 
  Handovers that use CT MAY fall back to best effort handvovers in 
  the</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>cases where CT fails.&nbsp; My argument is that to 
  make this whole thing clean</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>and 
  more reliable we should add a requirement like<FONT color=#000080 
  face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>&nbsp;</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>Do you think? I mean, do we really need 
  to&nbsp;</SPAN></FONT></SPAN></FONT><FONT color=#0000ff face=Arial 
  size=2><SPAN class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" 
  size=3><SPAN class=940004418-12072001>be explicit 
  about</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>every possible outcome? And how can we do this 
  without</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>a design, even a use case 
  analysis?</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>Right now, we are stumbling&nbsp;from one issue to 
  another as</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>people identify&nbsp;issues that haven't been 
  captured. When</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>will it end (he says 
  rhetorically)?</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>I'm not saying the issues are unimportant; I am just 
  concerned</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>that&nbsp;the requirements will never be done, or 
  more importantly,</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>that the design will never 
  start.&nbsp;</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>To 
  increase the reliability of handovers using CT, the designer MAY 
  bundle</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>the 
  CT packet with handover signalling such as that used in MIPv4 and MIPv6.<FONT 
  color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>&nbsp;</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001><BR>I don't see the 
  need,&nbsp;but&nbsp;offer&nbsp;your suggestion&nbsp;to the list as 
  an</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>issue.</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001></SPAN></FONT></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001><FONT color=#000080 face="Comic Sans MS" size=3><SPAN 
  class=940004418-12072001>Gary&nbsp;</SPAN></FONT></SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <P><FONT size=2><SPAN class=754103718-12072001>&nbsp;</SPAN>I said that ct 
    is not essential to an ordinary handover ("seamy handover"?).</FONT> 
    <BR><FONT size=2>And thus, a failure to complete ct on time must not cause 
    an </FONT><BR><FONT size=2>"ordinary handover" ("best effort handover"?) to 
    fail.</FONT> </P>
    <P><FONT size=2>&nbsp;&nbsp; Some designers want to be able to fall back to 
    a "best effort"</FONT> <BR><FONT size=2>handover if the seamless handover 
    fails, and yes, the seams will show.</FONT>&nbsp;<BR><FONT size=2>&nbsp; 
    </FONT><BR></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C10B05.261B4D30--


From owner-seamoby@diameter.org  Thu Jul 12 15:20:48 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10130
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 15:20:48 -0400 (EDT)
Received: (qmail 4990 invoked by alias); 12 Jul 2001 19:02:25 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 4984 invoked by uid 200); 12 Jul 2001 19:02:25 -0000
Received: (qmail 4976 invoked from network); 12 Jul 2001 19:02:22 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 19:02:22 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA13605;
	Thu, 12 Jul 2001 12:12:38 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CJCcC03854;
	Thu, 12 Jul 2001 12:12:38 -0700
X-mProtect:  Thu, 12 Jul 2001 12:12:38 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdIMYcnv; Thu, 12 Jul 2001 12:12:37 PDT
Message-ID: <3B4DF6A5.144ED79D@iprg.nokia.com>
Date: Thu, 12 Jul 2001 12:12:37 -0700
From: Theo Pagtzis <tpagtzis@IPRG.nokia.com>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org,
        seamoby@cdma-2000.org
Subject: [seamoby] Issues leading to the design of the proactive mobility draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat/all,

 The issues that led to the draft specification proposed on proactive
mobility
(draft-pagtzis-mobileip-proactivev6-00.txt/.ps)  was driven by a number
of factors:

1) to effect seamlessness the MN must not wait until it reaches the
overlap area between  two coverage areas before it initiates generation
of IP state, what we call roaming state. For irregular mobility patterns
and high speed movement this is not going to be sufficient for
elimination of disruption in IP 'connectivity'

1.a) since we would not like the MN to wait till the overlap area
between cells is reached, we have considered that a 1-level lookahead of
IP connectivity state should be sufficient for 360 degrees of movement.
That is proactive allocation of roaming state.

However how can you say what is around you in terms of routing entities
that can provide you with this roaming context state? Thus we reached
issue (2)

2) effecting a proactive mobility approach requires that the approach
makes two distinctions

     a mobility neighbourhood - a set of coverage areas. Basically what
the MN 'feels' _first_ when roving around.
     a routing neighbourhood - a set of routing entities. Basically what
the MN 'sees' _apparently first_ when getting IP connectivity.

2.a) This requires that _no_ assumptions are made about specific routing
neighbourhood topologies over a mobility neighbourhood otherwise. This
why we have considered spanning tree topologies as a generich topology
vehicle.

2.b) the need to establish a mapping between the mobility neighbourhood
and the routing neighbourhood so that roaming state is producable
proactively.

2.c) how could we take as example the generation of roaming state
proactively for the generation of other context state
classes/ontologies. I.e. what if it is not just roaming state that we
want to know ahead of time at candidate points of attachement.

3) if roaming state is generate proactively how to proceed in mapping it
in an abstract routing identifier that can determine the existence of
the MN in the mobility neighbourhood of its current point of attachment.
In other words, how to map a plurality of IP (soft) CoA behind an
routing identifier during the period of handoff for 360 degrees.
Multicast was considered as the level of indirection. Attention must be
paid to the fact that such mapping is transparent to the peer entities
of the MN, i.e. it is effected at the point of attachement of the MN.

4) to eliminate cell bouncing between two or more coverage areas.
Movement paths for an MN depending on the mean of transport used is not
usually correlated to the placement pattern of AP. Hence cell-bouncing
is expected to be the first candidate of problems in seamless mobility.

5) How to manage multicast group membership indirectly with respect to
mobility management issues concerning enabling of roaming state behind
this abstract (CoA) routing identifier for a single MN.

6) How to manage the refresh of the roaming state for a single MN so
that it stays valid throughout its mobility pattern within a mobility
neighbourhood.

7) Neighbour discovery issues for indirect mobility management.


These are the issues we have considered as essential in any proactive
mobility design, and thus have driven the specification of this draft.
Based on these issues we would like to hear what the community feels on
the approaches followed.


Theo





From owner-seamoby@diameter.org  Thu Jul 12 15:25:37 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10797
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 15:25:33 -0400 (EDT)
Received: (qmail 5062 invoked by alias); 12 Jul 2001 19:03:22 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5056 invoked by uid 200); 12 Jul 2001 19:03:22 -0000
Received: (qmail 5037 invoked from network); 12 Jul 2001 19:03:12 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 19:03:12 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id MAA13605;
	Thu, 12 Jul 2001 12:12:38 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CJCcC03854;
	Thu, 12 Jul 2001 12:12:38 -0700
X-mProtect:  Thu, 12 Jul 2001 12:12:38 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdIMYcnv; Thu, 12 Jul 2001 12:12:37 PDT
Message-ID: <3B4DF6A5.144ED79D@iprg.nokia.com>
Date: Thu, 12 Jul 2001 12:12:37 -0700
From: Theo Pagtzis <tpagtzis@IPRG.nokia.com>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org,
        seamoby@cdma-2000.org
Subject: [seamoby] Issues leading to the design of the proactive mobility draft
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat/all,

 The issues that led to the draft specification proposed on proactive
mobility
(draft-pagtzis-mobileip-proactivev6-00.txt/.ps)  was driven by a number
of factors:

1) to effect seamlessness the MN must not wait until it reaches the
overlap area between  two coverage areas before it initiates generation
of IP state, what we call roaming state. For irregular mobility patterns
and high speed movement this is not going to be sufficient for
elimination of disruption in IP 'connectivity'

1.a) since we would not like the MN to wait till the overlap area
between cells is reached, we have considered that a 1-level lookahead of
IP connectivity state should be sufficient for 360 degrees of movement.
That is proactive allocation of roaming state.

However how can you say what is around you in terms of routing entities
that can provide you with this roaming context state? Thus we reached
issue (2)

2) effecting a proactive mobility approach requires that the approach
makes two distinctions

     a mobility neighbourhood - a set of coverage areas. Basically what
the MN 'feels' _first_ when roving around.
     a routing neighbourhood - a set of routing entities. Basically what
the MN 'sees' _apparently first_ when getting IP connectivity.

2.a) This requires that _no_ assumptions are made about specific routing
neighbourhood topologies over a mobility neighbourhood otherwise. This
why we have considered spanning tree topologies as a generich topology
vehicle.

2.b) the need to establish a mapping between the mobility neighbourhood
and the routing neighbourhood so that roaming state is producable
proactively.

2.c) how could we take as example the generation of roaming state
proactively for the generation of other context state
classes/ontologies. I.e. what if it is not just roaming state that we
want to know ahead of time at candidate points of attachement.

3) if roaming state is generate proactively how to proceed in mapping it
in an abstract routing identifier that can determine the existence of
the MN in the mobility neighbourhood of its current point of attachment.
In other words, how to map a plurality of IP (soft) CoA behind an
routing identifier during the period of handoff for 360 degrees.
Multicast was considered as the level of indirection. Attention must be
paid to the fact that such mapping is transparent to the peer entities
of the MN, i.e. it is effected at the point of attachement of the MN.

4) to eliminate cell bouncing between two or more coverage areas.
Movement paths for an MN depending on the mean of transport used is not
usually correlated to the placement pattern of AP. Hence cell-bouncing
is expected to be the first candidate of problems in seamless mobility.

5) How to manage multicast group membership indirectly with respect to
mobility management issues concerning enabling of roaming state behind
this abstract (CoA) routing identifier for a single MN.

6) How to manage the refresh of the roaming state for a single MN so
that it stays valid throughout its mobility pattern within a mobility
neighbourhood.

7) Neighbour discovery issues for indirect mobility management.


These are the issues we have considered as essential in any proactive
mobility design, and thus have driven the specification of this draft.
Based on these issues we would like to hear what the community feels on
the approaches followed.


Theo





From owner-seamoby@diameter.org  Thu Jul 12 15:33:06 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11830
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 15:33:05 -0400 (EDT)
Received: (qmail 5279 invoked by alias); 12 Jul 2001 19:09:41 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5272 invoked by uid 200); 12 Jul 2001 19:09:41 -0000
Received: (qmail 5255 invoked from network); 12 Jul 2001 19:09:37 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 19:09:37 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17350;
	Thu, 12 Jul 2001 13:20:24 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA00166;
	Thu, 12 Jul 2001 12:20:26 -0700 (PDT)
Message-Id: <200107121920.MAA00166@heliopolis.eng.sun.com>
Date: Thu, 12 Jul 2001 12:20:25 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [seamoby] Re: [mobile-ip] Issues leading to the design of the proactive mobility draft
To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org,
        seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: U6e0XNiYpNnJ7W3zkbq/FA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Theo,

Thanx for the updates in the thought behind your draft.

The draft is somewhat volumnous and will take some time to assess, but it
looks quite interesting.

		jak
		
		
>X-mProtect: Thu, 12 Jul 2001 12:12:38 -0700 Nokia Silicon Valley Messaging 
Protection
>Date: Thu, 12 Jul 2001 12:12:37 -0700
>From: Theo Pagtzis <tpagtzis@iprg.nokia.com>
>To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org, 
seamoby@cdma-2000.org
>Subject: [mobile-ip] Issues leading to the design of the proactive mobility 
draft
>
>Hi Pat/all,
>
> The issues that led to the draft specification proposed on proactive
>mobility
>(draft-pagtzis-mobileip-proactivev6-00.txt/.ps)  was driven by a number
>of factors:
>
>1) to effect seamlessness the MN must not wait until it reaches the
>overlap area between  two coverage areas before it initiates generation
>of IP state, what we call roaming state. For irregular mobility patterns
>and high speed movement this is not going to be sufficient for
>elimination of disruption in IP 'connectivity'
>
>1.a) since we would not like the MN to wait till the overlap area
>between cells is reached, we have considered that a 1-level lookahead of
>IP connectivity state should be sufficient for 360 degrees of movement.
>That is proactive allocation of roaming state.
>
>However how can you say what is around you in terms of routing entities
>that can provide you with this roaming context state? Thus we reached
>issue (2)
>
>2) effecting a proactive mobility approach requires that the approach
>makes two distinctions
>
>     a mobility neighbourhood - a set of coverage areas. Basically what
>the MN 'feels' _first_ when roving around.
>     a routing neighbourhood - a set of routing entities. Basically what
>the MN 'sees' _apparently first_ when getting IP connectivity.
>
>2.a) This requires that _no_ assumptions are made about specific routing
>neighbourhood topologies over a mobility neighbourhood otherwise. This
>why we have considered spanning tree topologies as a generich topology
>vehicle.
>
>2.b) the need to establish a mapping between the mobility neighbourhood
>and the routing neighbourhood so that roaming state is producable
>proactively.
>
>2.c) how could we take as example the generation of roaming state
>proactively for the generation of other context state
>classes/ontologies. I.e. what if it is not just roaming state that we
>want to know ahead of time at candidate points of attachement.
>
>3) if roaming state is generate proactively how to proceed in mapping it
>in an abstract routing identifier that can determine the existence of
>the MN in the mobility neighbourhood of its current point of attachment.
>In other words, how to map a plurality of IP (soft) CoA behind an
>routing identifier during the period of handoff for 360 degrees.
>Multicast was considered as the level of indirection. Attention must be
>paid to the fact that such mapping is transparent to the peer entities
>of the MN, i.e. it is effected at the point of attachement of the MN.
>
>4) to eliminate cell bouncing between two or more coverage areas.
>Movement paths for an MN depending on the mean of transport used is not
>usually correlated to the placement pattern of AP. Hence cell-bouncing
>is expected to be the first candidate of problems in seamless mobility.
>
>5) How to manage multicast group membership indirectly with respect to
>mobility management issues concerning enabling of roaming state behind
>this abstract (CoA) routing identifier for a single MN.
>
>6) How to manage the refresh of the roaming state for a single MN so
>that it stays valid throughout its mobility pattern within a mobility
>neighbourhood.
>
>7) Neighbour discovery issues for indirect mobility management.
>
>
>These are the issues we have considered as essential in any proactive
>mobility design, and thus have driven the specification of this draft.
>Based on these issues we would like to hear what the community feels on
>the approaches followed.
>
>
>Theo
>
>
>



From owner-seamoby@diameter.org  Thu Jul 12 15:39:17 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12633
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 15:39:17 -0400 (EDT)
Received: (qmail 5292 invoked by alias); 12 Jul 2001 19:09:43 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5286 invoked by uid 200); 12 Jul 2001 19:09:42 -0000
Received: (qmail 5261 invoked from network); 12 Jul 2001 19:09:38 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 19:09:38 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA17350;
	Thu, 12 Jul 2001 13:20:24 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id MAA00166;
	Thu, 12 Jul 2001 12:20:26 -0700 (PDT)
Message-Id: <200107121920.MAA00166@heliopolis.eng.sun.com>
Date: Thu, 12 Jul 2001 12:20:25 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [seamoby] Re: [mobile-ip] Issues leading to the design of the proactive mobility draft
To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org,
        seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: U6e0XNiYpNnJ7W3zkbq/FA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Theo,

Thanx for the updates in the thought behind your draft.

The draft is somewhat volumnous and will take some time to assess, but it
looks quite interesting.

		jak
		
		
>X-mProtect: Thu, 12 Jul 2001 12:12:38 -0700 Nokia Silicon Valley Messaging 
Protection
>Date: Thu, 12 Jul 2001 12:12:37 -0700
>From: Theo Pagtzis <tpagtzis@iprg.nokia.com>
>To: pcalhoun@diameter.org, mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org, 
seamoby@cdma-2000.org
>Subject: [mobile-ip] Issues leading to the design of the proactive mobility 
draft
>
>Hi Pat/all,
>
> The issues that led to the draft specification proposed on proactive
>mobility
>(draft-pagtzis-mobileip-proactivev6-00.txt/.ps)  was driven by a number
>of factors:
>
>1) to effect seamlessness the MN must not wait until it reaches the
>overlap area between  two coverage areas before it initiates generation
>of IP state, what we call roaming state. For irregular mobility patterns
>and high speed movement this is not going to be sufficient for
>elimination of disruption in IP 'connectivity'
>
>1.a) since we would not like the MN to wait till the overlap area
>between cells is reached, we have considered that a 1-level lookahead of
>IP connectivity state should be sufficient for 360 degrees of movement.
>That is proactive allocation of roaming state.
>
>However how can you say what is around you in terms of routing entities
>that can provide you with this roaming context state? Thus we reached
>issue (2)
>
>2) effecting a proactive mobility approach requires that the approach
>makes two distinctions
>
>     a mobility neighbourhood - a set of coverage areas. Basically what
>the MN 'feels' _first_ when roving around.
>     a routing neighbourhood - a set of routing entities. Basically what
>the MN 'sees' _apparently first_ when getting IP connectivity.
>
>2.a) This requires that _no_ assumptions are made about specific routing
>neighbourhood topologies over a mobility neighbourhood otherwise. This
>why we have considered spanning tree topologies as a generich topology
>vehicle.
>
>2.b) the need to establish a mapping between the mobility neighbourhood
>and the routing neighbourhood so that roaming state is producable
>proactively.
>
>2.c) how could we take as example the generation of roaming state
>proactively for the generation of other context state
>classes/ontologies. I.e. what if it is not just roaming state that we
>want to know ahead of time at candidate points of attachement.
>
>3) if roaming state is generate proactively how to proceed in mapping it
>in an abstract routing identifier that can determine the existence of
>the MN in the mobility neighbourhood of its current point of attachment.
>In other words, how to map a plurality of IP (soft) CoA behind an
>routing identifier during the period of handoff for 360 degrees.
>Multicast was considered as the level of indirection. Attention must be
>paid to the fact that such mapping is transparent to the peer entities
>of the MN, i.e. it is effected at the point of attachement of the MN.
>
>4) to eliminate cell bouncing between two or more coverage areas.
>Movement paths for an MN depending on the mean of transport used is not
>usually correlated to the placement pattern of AP. Hence cell-bouncing
>is expected to be the first candidate of problems in seamless mobility.
>
>5) How to manage multicast group membership indirectly with respect to
>mobility management issues concerning enabling of roaming state behind
>this abstract (CoA) routing identifier for a single MN.
>
>6) How to manage the refresh of the roaming state for a single MN so
>that it stays valid throughout its mobility pattern within a mobility
>neighbourhood.
>
>7) Neighbour discovery issues for indirect mobility management.
>
>
>These are the issues we have considered as essential in any proactive
>mobility design, and thus have driven the specification of this draft.
>Based on these issues we would like to hear what the community feels on
>the approaches followed.
>
>
>Theo
>
>
>



From owner-seamoby@diameter.org  Thu Jul 12 15:49:22 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14009
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 15:49:21 -0400 (EDT)
Received: (qmail 6753 invoked by alias); 12 Jul 2001 19:28:16 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6747 invoked by uid 200); 12 Jul 2001 19:28:15 -0000
Received: (qmail 6741 invoked from network); 12 Jul 2001 19:28:12 -0000
Received: from maila.telia.com (194.22.194.231)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 19:28:12 -0000
Received: from parchment (h242n1fls33o801.telia.com [213.64.180.242])
	by maila.telia.com (8.11.2/8.11.0) with SMTP id f6CJcwY09050;
	Thu, 12 Jul 2001 21:38:59 +0200 (CEST)
From: "Henrik Levkowetz" <henrik@levkowetz.com>
To: <seamoby@cdma-2000.org>
Cc: <john.loughney@nokia.com>
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu     lti- Phase CT
Date: Thu, 12 Jul 2001 21:38:58 +0200
Message-ID: <MFEILCGMDFHKIOINEEHEGENFCHAA.henrik@levkowetz.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF09BAF6@esebe004.NOE.Nokia.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ooh, well put, John.

	Best, Henrik

John Loughney wrote:
> 
> Hi Pat,
> 
> > I think that two phases are needed, regardless of the MTU size. I
> > believe that in order to achieve a seamless handoff, it is necessary
> > to transfer time sensitive context blobs as soon as possible (e.g.
> > header compression, L2 keying info, L3 SAs). These are necessary
> > in order to exchange packets with the mobile, but there may be other
> > time sensitive blobs that I haven't thought of as well. 
> > Non-time sensitive blobs (e.g. accounting session id) are not needed 
> > to send/receive packets and therefore do not need to be sent right away.
> 
> I think that discussing of phases is leading us to a dead end.  What
> we need is the following behavior:
> 
> 1) Ability to send time-critical context
> 2) Ability to discard stale context
> 3) Ability to synchronize the context transfer with an additional
>    procedure (like a handover)
> 4) Ability to use different triggers to start the transfer of some 
>    contexts.
> 5) Ability to acknowledge the transfer of some contexts.
> 6) Ability to group or send seperately contexts.
> 
> My feeling is that when we group the behaviors, we may get the different
> phases - but I think that there may be more than just 2 phases of 
> CT.  Actually, the above behaviors may depend upon the type context
> being transfered.  As we have not identified all the possible types
> of context to be transfered and all of the situations, I don't
> believe that discussing the phases (or modes) of context transfer
> is a good idea currently.
> 
> I'm writing up an issue on this right now.  I'm happy to contribute
> text.
> 
> Comments?
> John
> 
> 


From owner-seamoby@diameter.org  Thu Jul 12 16:16:52 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17882
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 16:16:51 -0400 (EDT)
Received: (qmail 7880 invoked by alias); 12 Jul 2001 20:05:33 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 7874 invoked by uid 200); 12 Jul 2001 20:05:33 -0000
Received: (qmail 7869 invoked from network); 12 Jul 2001 20:05:30 -0000
Received: from maild.telia.com (root@194.22.190.101)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 20:05:30 -0000
Received: from parchment (h242n1fls33o801.telia.com [213.64.180.242])
	by maild.telia.com (8.11.2/8.11.0) with SMTP id f6CKGGa14862
	for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 22:16:16 +0200 (CEST)
From: "Henrik Levkowetz" <henrik@levkowetz.com>
To: <seamoby@cdma-2000.org>
Subject: [seamoby] A seamoby sample
Date: Thu, 12 Jul 2001 22:16:16 +0200
Message-ID: <MFEILCGMDFHKIOINEEHECENHCHAA.henrik@levkowetz.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Folks,

	When we worked at the first CT and MM problem statement, I several
times referred to an implementation of context transfer and micro-mobility
handover support we were doing at ABNW. (Yes, I know that the expression
micro-mobility is out of vogue, but that's what we were calling it.. :-) )

	I've held off submitting this protocol while the requirements were
being worked on, and not unexpectedly some of the requirements work has
produced good requirements which were not thought of by us when we designed
our experimental protocol. Nevertheless, I think that although limited in
scope, what we put together might possibly trigger interesting but better
solutions in the coming seamoby design work.

	Although painfully slowly at times, the CT requirements seem to be
converging somewhat, so I've now submitted a draft which describes our
experimental protocol. Note that it is NOT intended as a candidate for
CT protocol, only as a record of what we've been doing, which may to some
degree be of interest to the seamoby work.

	The draft was submitted as draft-levkowetz-seamoby-sample-00.txt,
and you'll hopefully see the announcement on the list shortly.

	Best,
		Henrik




From owner-seamoby@diameter.org  Thu Jul 12 16:48:34 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22043
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 16:48:33 -0400 (EDT)
Received: (qmail 8710 invoked by alias); 12 Jul 2001 20:37:06 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 8704 invoked by uid 200); 12 Jul 2001 20:37:05 -0000
Received: (qmail 8699 invoked from network); 12 Jul 2001 20:37:03 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 20:37:03 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA17099;
	Thu, 12 Jul 2001 14:47:51 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA04838;
	Thu, 12 Jul 2001 13:47:52 -0700 (PDT)
Message-Id: <200107122047.NAA04838@heliopolis.eng.sun.com>
Date: Thu, 12 Jul 2001 13:47:52 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [seamoby] Comments on draft-koodli-seamoby-ctv6-00.txt
To: rajeev.koodli@nokia.com
Cc: seamoby@diameter.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: FOzln+GbWGhmR/YAYarvUg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Rajeev,

I looked over your draft and I have some comments.

1) pg. 5 I like your charaterization of GTP (not the other one) but the
idea that it consists of a type identifier and *state* variables
brings up a fundamental question w.r.t. context transfer. Protocols
usually define the interface between two different network elements.
State variables have to do with implementation. Isn't context
transfer basically asking for implementations to be exposed?

For example, suppose I am SuperWhizzy QoS Router manufacturer and
I have a router that supports the Diffserv  protocols just fine,
so it interoperates, but inside I have my proprietary algorithms
that make my router live up to its name. In order to provide state
transfer, would I need to expose the internals of my algorithms
so I could interoperate?

I'm not sure how to solve this problem, but I think you need to
clarify that these state variables aren't internals of the implementation,
but rather protocol-specified state variables that are part of the
interface.

2) pg. 5 What is the filter and handle alluded to in the last paragraph?
There is not alot of detail as to what these are supposed to do.

3) pg. 7 and the whole discussion of SHIN/SHAK header options. When
I first read this, I thought these were being defined for the purpose
of having the MN do context transfer to the router, which didn't make
any sense to me. After I got to Section 5, however, it became clear
that what you really mean is that the MN signals to the router that
it wants particular context to be transfered. I think you need to
rewrite it to make this clear (but see below for some comments on
the utility of the SHIN/SHAK in the first place).

4) Section 4.3-4.5 I like the idea of the context transfer being an
extension to the HO messaging. Reduces the number of timers required
in the router. And it is possible in IPv6. The only issue here is
there has been some opinion expressed on the list that a reliable
transport might be a better idea for context transfer, which would
not be possible with ICMP extensions.

5) pg. 12 - What happens if a router or MN asks for some context to
be transfered and it is not available?

6) pg 12 - What is an unsolicited SHREP? Up until this point, I don't
think it has been described. You may want to describe it in the
terminology section, or somehow earlier in the paper.

7) pg. 13 Section 5.1 Actually, I think this scenario is pretty
unlikely for slow speed links, or, if it occurs at all, it will probably occur 
when there is almost no traffic between the MN and the network. I think
that any scenario where the MN has to trigger the context transfer
is not likely to occur when there is active traffic because it will involve
messaging over the wireless link, which is the slowest. 

I think it more likely that context transfer occurs as part of the HI/HACK
as described in Section 5.2. I don't think the MN needs to signal over
the air to get the CT to happen (P-SHIN), I think that CT could be 
triggered by the need for a handover. The L2 triggers draft, which
should be out shortly, spells out requirements for L2 triggers to
support CT.

With faster wireless protocols, the over-the-air signaling won't have
as much cost (but it will always have a higher cost than over the wire),
so the option should probably be kept in, but I think for standard
3G scenarios, triggering the context transfer as part of the need
for a handover without any over-the-air signalling is likely to be
much faster.

		jak




From owner-seamoby@diameter.org  Thu Jul 12 17:52:33 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00643
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 17:52:32 -0400 (EDT)
Received: (qmail 9698 invoked by alias); 12 Jul 2001 21:41:09 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 9692 invoked by uid 200); 12 Jul 2001 21:41:09 -0000
Received: (qmail 9684 invoked from network); 12 Jul 2001 21:41:06 -0000
Received: from ftpbox.mot.com (129.188.136.101)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 21:41:06 -0000
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA28486 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 14:51:55 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id OAA08580 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 14:51:55 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3XDBPTZ4>; Thu, 12 Jul 2001 16:51:55 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E97@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: "'Gary Kenward'" <gkenward@nortelnetworks.com>, seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
	 lti-  Phase CT
Date: Thu, 12 Jul 2001 16:51:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Phil,

One technical reason would be that I might not want to
wait until MN sends a ND message to newAR before I start
my CT, that is very late, we can be more "proactive" than that.

your own CNP would have trouble with proactive CT if CT trigger
is based on MIP HO messages.

About The poly-phasic, I really think that might be a natural
thing to do to reduce the packet loss. I don't know why you 
don't like it, maybe I should read the rest of my 60 unread seamoby
mails :)

Madjid

-----Original Message-----
From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
Sent: Wednesday, July 11, 2001 8:58 AM
To: 'Pat Calhoun'
Cc: 'Gary Kenward'; seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for
Mu lti- Phase CT


> Glad to hear you like FMIPv6++, but I still don't see much of a
> benefit in combining CT within the MIP message.

I have not heard one technical reason why NOT.  This is just YOUR
opinion Pat.  In fact I DONT like your poly-phasic idea and I have
stated technical reasons why.  Why don't you give me a "technical"
reason why rather than "I don't see much of a benefit" stuff?

BTW, I have not seen any real support for your polyphasic CT on
the list but it remains a requirement in your mind for some reason.

Thanks,

Phil


From owner-seamoby@diameter.org  Thu Jul 12 18:10:30 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02802
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 18:10:24 -0400 (EDT)
Received: (qmail 10486 invoked by alias); 12 Jul 2001 21:51:53 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 10480 invoked by uid 200); 12 Jul 2001 21:51:52 -0000
Received: (qmail 10469 invoked from network); 12 Jul 2001 21:51:47 -0000
Received: from ftpbox.mot.com (129.188.136.101)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 21:51:47 -0000
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA05121 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 15:02:32 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA08992 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 15:02:31 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19)
	id <NKTAY5ZZ>; Thu, 12 Jul 2001 17:02:31 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E99@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Gary Kenward <gkenward@nortelnetworks.com>
Cc: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 , RE: Issue #4)
Date: Thu, 12 Jul 2001 17:02:10 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk



-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: Wednesday, July 11, 2001 9:34 AM
To: Gary Kenward
Cc: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com';
seamoby@cdma-2000.org
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.

MN>> ok, this is a good point, are we envisioning different CTP
functionality between proactive and reactive case? If yes, then it 
is definitely a problem!!



 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:Madjid.Nakhjiri@motorola.com]
> Sent: Tuesday, July 10, 2001 6:37 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com';
> seamoby@cdma-2000.org
> 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:gkenward@nortelnetworks.com]
> Sent: Tuesday, July 10, 2001 8:53 AM
> To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
> 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: john.loughney@nokia.com [ mailto:john.loughney@nokia.com
> <mailto:john.loughney@nokia.com> ] 
> > Sent: Tuesday, July 10, 2001 1:59 AM 
> > To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
> > 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 owner-seamoby@diameter.org  Thu Jul 12 18:16:48 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03598
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 18:16:47 -0400 (EDT)
Received: (qmail 10929 invoked by alias); 12 Jul 2001 22:00:16 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 10923 invoked by uid 200); 12 Jul 2001 22:00:15 -0000
Received: (qmail 10908 invoked from network); 12 Jul 2001 22:00:12 -0000
Received: from ftpbox.mot.com (129.188.136.101)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 22:00:12 -0000
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA09594 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 15:10:59 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id PAA11228 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 15:10:59 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3XDBP4NK>; Thu, 12 Jul 2001 17:10:59 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E9A@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'James Kempf'" <James.Kempf@Sun.COM>, PNeumiller@MeshNetworks.com,
        pcalhoun@diameter.org
Cc: gkenward@nortelnetworks.com, seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
	 lti-  Phase CT
Date: Thu, 12 Jul 2001 17:10:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk



-----Original Message-----
From: James Kempf [mailto:James.Kempf@Sun.COM]
Sent: Wednesday, July 11, 2001 10:47 AM
To: PNeumiller@MeshNetworks.com; pcalhoun@diameter.org
Cc: pcalhoun@diameter.org; gkenward@nortelnetworks.com;
seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for
Mu lti- Phase CT


Hi Pat,

>well, the IESG has already stated that their desire was to NOT tie 
>CTP to MIP (and if memory serves, that was your position until just
>recently too). There are other mobility management protocols out there,
>and I'd hate to see them have to ignore CTP just because it is part of
>the MIP baggage. 
>
>Further, what are the benefits? Sending a single packet, as opposed to two?
>Where's the benefit there? I can have two threads work separately in
>transmitting the MIP and CT packets. That would reduce the number of locks
>required, and introduces modularity. Great benefits IMHO.
>

I think there may be some benefits to linking CT with the handover
messaging. 

If you send the context and the mobility protocol handover messaging in separate 
packets, you generate a synchronization problem on the new AR. Furthermore,
you increase the risk that a packet could be delayed or lost, disrupting
the handover. Suppose that the packets arrive out of order, that is, the CT 
packet arrives before the handover messaging. The AR must then arrange to buffer 
and potentially drop the CT packet if no handover messaging arrives within
a certain interval. The resulting implementation on the AR becomes more
complex, and thus subject to potential failure in more places.

MN>> James, why is this different than a case where you set up the states
for a call before you actually send the data packets?
In either case the state data might get stale if it is sent too soon and it causes
delay if it is late, this is the general case.
However, the real problem is if you tie the CT trigger to a specific MIP HO signal.
That reduces the number of scenarios where you can do proactive CT.
Don't you agree?

Madjid



Note here that I've said "the mobility protocol", not MIP. I think it
should be possible to define the CT messaging so that it is independent
of MIP but still can be added to a mobility protocol as an  extention,
with a binding to that particular mobility protocol. I can easily see
how it might work with the network assisted FMIP extensions, and potentially
also with (excuse my language) GPRS, as much as I know about it. 

		jak



From owner-seamoby@diameter.org  Thu Jul 12 18:23:12 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04430
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 18:23:10 -0400 (EDT)
Received: (qmail 10181 invoked by alias); 12 Jul 2001 21:45:18 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 10175 invoked by uid 200); 12 Jul 2001 21:45:18 -0000
Received: (qmail 10170 invoked from network); 12 Jul 2001 21:45:16 -0000
Received: from motgate.mot.com (129.188.136.100)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 21:45:16 -0000
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id OAA09272 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 14:56:05 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA13769 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 14:56:05 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3XDBPT9P>; Thu, 12 Jul 2001 16:56:05 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E98@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Gary Kenward'" <gkenward@nortelnetworks.com>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,         RE: Issue #4)
Date: Thu, 12 Jul 2001 16:56:02 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C10B1D.717821A0"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10B1D.717821A0
Content-Type: text/plain;
	charset="iso-8859-1"

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:gkenward@nortelnetworks.com]
Sent: Wednesday, July 11, 2001 9:20 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com'; seamoby@cdma-2000.org
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:Madjid.Nakhjiri@motorola.com]
Sent: Tuesday, July 10, 2001 6:37 PM
To: Kenward, Gary [WDLN2:AN10:EXCH]; 'john.loughney@nokia.com'; seamoby@cdma-2000.org
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:gkenward@nortelnetworks.com]
Sent: Tuesday, July 10, 2001 8:53 AM
To: 'john.loughney@nokia.com'; seamoby@cdma-2000.org
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: john.loughney@nokia.com [ mailto:john.loughney@nokia.com <mailto:john.loughney@nokia.com> ] 
> Sent: Tuesday, July 10, 2001 1:59 AM 
> To: Kenward, Gary [WDLN2:AN10:EXCH]; seamoby@cdma-2000.org 
> 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 
> 


------_=_NextPart_001_01C10B1D.717821A0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=851055221-12072001>Gary,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=851055221-12072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=851055221-12072001>I am 
glad that you realize what the problem is now, a deadline driven definition 
might</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=851055221-12072001>not be 
sufficient. </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=851055221-12072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=851055221-12072001>Again 
as I said I like the link establishment based definition better, since it is a 
trigger</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=851055221-12072001>based 
definition (I don't think that is what the issue 4 said, too lazy to look 
:)</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=851055221-12072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=851055221-12072001>And 
again, the existing definition is better than none.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=851055221-12072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=851055221-12072001>Madjid</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
  [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Wednesday, July 11, 2001 
  9:20 AM<BR><B>To:</B> 'Nakhjiri Madjid-MNAKHJI1'; 'john.loughney@nokia.com'; 
  seamoby@cdma-2000.org<BR><B>Subject:</B> RE: [seamoby] L2 API (WAS: Ext. for 
  FMIPv6 - comments) (SHOULD be , RE: Issue #4)<BR><BR></DIV></FONT>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=480580214-11072001>Madjid:</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>&nbsp;&nbsp; 
  I'm glad you feel this way. I guess this discussion began as a result of 
  </SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>Issue #4, which 
  proposes an alternate wording.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=480580214-11072001>&nbsp;&nbsp;&nbsp; After a few exchanges with Cedric, 
  I reviewed the current text, and</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>I realized that 
  it indicates that proactive is deadline driven, which I 
  really</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>believe is a 
  bad thing to require.&nbsp; All I want to ensure is that there is a 
  </SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>capability with 
  ctp to start a ct sometime before the actually traffic 
  handover</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>is initiated. 
  Why? Because there are many networks that provide 
  "warnings"</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>that a handover 
  may be imminent (actually, most RF systems can be designed</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>to do this, and 
  should). How? Well, the actual trigger event will change</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>depending upon 
  the L2 design, but typically, the mechanism starts with 
the</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>base receiver 
  sensing&nbsp;transmission from a mobile, and then usually many other 
  </SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>mechanisms that 
  kick in to identify the mobile at L1/L2.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>&nbsp;&nbsp; 
  So, I would also like to keep the current text, for the same reason. I 
  would</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>like to remove 
  the deadline, or at least change it so that it is clearly a 
  desirable</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>deadline, but 
  not a requirement (we cannot make it a requirement because the 
  physics</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>of wireless 
  handover make the timing of any forewarning event completely 
  un-</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=480580214-11072001>predictable).</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>&nbsp;&nbsp; 
  Maybe I've said this all before, and maybe my view is clear to everyone. 
  Sorry</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN class=480580214-11072001>for being 
  repetitive.</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=480580214-11072001>Gary</SPAN></FONT></DIV>
  <DIV><FONT face="Comic Sans MS"><SPAN 
  class=480580214-11072001></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #000080 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Nakhjiri Madjid-MNAKHJI1 
    [mailto:Madjid.Nakhjiri@motorola.com]<BR><B>Sent:</B> Tuesday, July 10, 2001 
    6:37 PM<BR><B>To:</B> Kenward, Gary [WDLN2:AN10:EXCH]; 
    'john.loughney@nokia.com'; seamoby@cdma-2000.org<BR><B>Subject:</B> RE: 
    [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments)<BR><BR></DIV></FONT>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001>Gary,</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>I 
    don't think we should remove the reactive/ proactive definitions out 
    of</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001>requirement, unless there is a consensus for 
    removing it.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>If 
    we nobody can come up with a better definition than the 
    already</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001>existing one, either we keep it or declare it as an 
    open issue.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001>Personally I liked the definitions that are based 
    on the starting event</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001>such as link establishment better, but I still can 
    live with the exiting </SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001>one (packet arrival) for the time being. Removing 
    the whole thing</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>is 
    throwing a lot of good thoughts away.</SPAN></FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=154203222-10072001>A 
    requirement subject to modifications is better than no 
    requirement.</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001>Madjid</SPAN></FONT></DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
    class=154203222-10072001></SPAN></FONT>&nbsp;</DIV>
    <BLOCKQUOTE style="MARGIN-RIGHT: 0px">
      <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Gary Kenward 
      [mailto:gkenward@nortelnetworks.com]<BR><B>Sent:</B> Tuesday, July 10, 
      2001 8:53 AM<BR><B>To:</B> 'john.loughney@nokia.com'; 
      seamoby@cdma-2000.org<BR><B>Subject:</B> RE: [seamoby] L2 API (WAS: Ext. 
      for FMIPv6 - comments)<BR><BR></DIV></FONT>
      <P><FONT size=2>John:</FONT> </P>
      <P><FONT size=2>&nbsp;&nbsp; I have been contemplating removing the 
      "reactive"/"proactive"</FONT> <BR><FONT size=2>definitions from the 
      requirements also, but I really do hope we</FONT> <BR><FONT size=2>do not 
      lose the concept of starting ct as early as possible. Being</FONT> 
      <BR><FONT size=2>proactive with ct has been a fundamental component to ct 
      since the </FONT><BR><FONT size=2>problem statement draft, and, to me, a 
      critical tool for providing </FONT><BR><FONT size=2>seamless service 
      handover.</FONT> </P>
      <P><FONT size=2>&nbsp;&nbsp; There are those who, rightfully, have no 
      interest in proactive</FONT> <BR><FONT size=2>ct for their networks. If we 
      lose the requirement, it may be very</FONT> <BR><FONT size=2>difficult for 
      the wg to proceed with a ctp design that supports </FONT><BR><FONT 
      size=2>this mode.</FONT> </P>
      <P><FONT size=2>&nbsp;&nbsp; I'll wait for your issue to be generated. 
      Some of us are also</FONT> <BR><FONT size=2>struggling with some 
      alterative wording of the definitions</FONT> </P>
      <P><FONT size=2>Gary</FONT> </P>
      <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
      size=2>&gt; From: john.loughney@nokia.com [<A 
      href="mailto:john.loughney@nokia.com">mailto:john.loughney@nokia.com</A>]</FONT> 
      <BR><FONT size=2>&gt; Sent: Tuesday, July 10, 2001 1:59 AM</FONT> 
      <BR><FONT size=2>&gt; To: Kenward, Gary [WDLN2:AN10:EXCH]; 
      seamoby@cdma-2000.org</FONT> <BR><FONT size=2>&gt; Subject: RE: [seamoby] 
      L2 API (WAS: Ext. for FMIPv6 - comments)</FONT> <BR><FONT size=2>&gt; 
      </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Hi Gary,</FONT> 
      <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt;&nbsp; I agree, 
      particularly with your definition of ct (although I'm </FONT><BR><FONT 
      size=2>&gt; &gt; not sure where "reductive mode" came from). 
      </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
      size=2>&gt; Ooops, I meant that I was in "reductive mode" (trying 
      to</FONT> <BR><FONT size=2>&gt; simplify &amp; get back to the 
      basics).&nbsp; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
      &gt; In thinking through the overall discussion, I am realize that the 
      </FONT><BR><FONT size=2>&gt; &gt; big difference between "reactive" and 
      "proactive" is how they are </FONT><BR><FONT size=2>&gt; &gt; triggered. 
      "proactive" assumes that there is a trigger available </FONT><BR><FONT 
      size=2>&gt; &gt; early on that permits some context transfer in advance of 
      an actual </FONT><BR><FONT size=2>&gt; &gt; handover. </FONT><BR><FONT 
      size=2>&gt; </FONT><BR><FONT size=2>&gt; I agree. My thoughts are that the 
      discussion of reactive and proactive</FONT> <BR><FONT size=2>&gt; (&amp; 
      triggering, etc.) get quite close to protocol design.&nbsp; I think</FONT> 
      <BR><FONT size=2>&gt; that is one reason that the discussion became so 
      heavy on the</FONT> <BR><FONT size=2>&gt; the requirements.</FONT> 
      <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt;&nbsp;&nbsp; I do 
      believe the current wording for proactive is wrong. Now that 
      </FONT><BR><FONT size=2>&gt; &gt; I have had time to contemplate the 
      wording, it does not define what </FONT><BR><FONT size=2>&gt; &gt; I have 
      always believed proactive ct should be about. I'm hoping </FONT><BR><FONT 
      size=2>&gt; &gt; that if we fix that wording, we can move on to the 
      important part </FONT><BR><FONT size=2>&gt; &gt; of designing ctp. 
      </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; My suggestion 
      would be to cut-out of the requirements document the</FONT> <BR><FONT 
      size=2>&gt; discussion about proactive &amp; reactive text.&nbsp; I will 
      try to make an</FONT> <BR><FONT size=2>&gt; issue for this later in the 
      day.</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
      thanks,</FONT> <BR><FONT size=2>&gt; John</FONT> <BR><FONT size=2>&gt; 
      </FONT></P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C10B1D.717821A0--


From owner-seamoby@diameter.org  Thu Jul 12 18:25:42 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04709
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 18:25:41 -0400 (EDT)
Received: (qmail 11744 invoked by alias); 12 Jul 2001 22:09:21 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 11738 invoked by uid 200); 12 Jul 2001 22:09:20 -0000
Received: (qmail 11733 invoked from network); 12 Jul 2001 22:09:18 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 22:09:18 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA25408;
	Thu, 12 Jul 2001 15:19:37 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6CMJag09133;
	Thu, 12 Jul 2001 15:19:36 -0700
X-mProtect:  Thu, 12 Jul 2001 15:19:36 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdLcXXlk; Thu, 12 Jul 2001 15:19:35 PDT
Message-ID: <3B4E2277.37B2EA41@iprg.nokia.com>
Date: Thu, 12 Jul 2001 15:19:35 -0700
From: Theo Pagtzis <tpagtzis@IPRG.nokia.com>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
CC: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>, seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
 Phase CT
References: <35DBB8B7AC89D4118E98009027B1009B017A9E97@IL27EXM10.cig.mot.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Madjid,

I definetely agree with that !

The handoff process should not be the basic trigger for context
negotiation/preparation over the mobility neighbourhood of the current
point of attachment of the MN.

This is going to be _too_ late considering the unpredictability of the
mobility pattern and potential cell-bouncing.

Please see draft-pagtzis-mobileip-proactivev6-00.txt/.ps

Cheers


Theo

UCL/Mobile Systems


Nakhjiri Madjid-MNAKHJI1 wrote:

> Phil,
>
> One technical reason would be that I might not want to
> wait until MN sends a ND message to newAR before I start
> my CT, that is very late, we can be more "proactive" than that.
>
> your own CNP would have trouble with proactive CT if CT trigger
> is based on MIP HO messages.
>
> About The poly-phasic, I really think that might be a natural
> thing to do to reduce the packet loss. I don't know why you
> don't like it, maybe I should read the rest of my 60 unread seamoby
> mails :)
>
> Madjid
>
> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Wednesday, July 11, 2001 8:58 AM
> To: 'Pat Calhoun'
> Cc: 'Gary Kenward'; seamoby@cdma-2000.org
> Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for
> Mu lti- Phase CT
>
> > Glad to hear you like FMIPv6++, but I still don't see much of a
> > benefit in combining CT within the MIP message.
>
> I have not heard one technical reason why NOT.  This is just YOUR
> opinion Pat.  In fact I DONT like your poly-phasic idea and I have
> stated technical reasons why.  Why don't you give me a "technical"
> reason why rather than "I don't see much of a benefit" stuff?
>
> BTW, I have not seen any real support for your polyphasic CT on
> the list but it remains a requirement in your mind for some reason.
>
> Thanks,
>
> Phil



From owner-seamoby@diameter.org  Thu Jul 12 18:28:48 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05071
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 18:28:47 -0400 (EDT)
Received: (qmail 11805 invoked by alias); 12 Jul 2001 22:11:14 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 11799 invoked by uid 200); 12 Jul 2001 22:11:13 -0000
Received: (qmail 11790 invoked from network); 12 Jul 2001 22:11:10 -0000
Received: from motgate.mot.com (129.188.136.100)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 22:11:10 -0000
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA24061 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 15:22:00 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA18870 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 15:22:00 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3XDBP4WT>; Thu, 12 Jul 2001 17:22:00 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E9B@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'James Kempf'" <James.Kempf@sun.com>, pcalhoun@diameter.org,
        gkenward@nortelnetworks.com
Cc: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        john.loughney@nokia.com, seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,          RE: Issue #4)
Date: Thu, 12 Jul 2001 17:21:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk



-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

Madjid>> James, the timer makes sense, however, the time to live
for each context depends on the feature that the context belongs 
too, maybe such a time to live can be added to the context packets.
Having a universal time to live for all types of context is not
very precise.

Madjid


From owner-seamoby@diameter.org  Thu Jul 12 18:34:12 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05740
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 18:34:11 -0400 (EDT)
Received: (qmail 12832 invoked by alias); 12 Jul 2001 22:22:31 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 12826 invoked by uid 200); 12 Jul 2001 22:22:31 -0000
Received: (qmail 12817 invoked from network); 12 Jul 2001 22:22:28 -0000
Received: from motgate4.mot.com (144.189.100.102)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 22:22:28 -0000
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id PAA08564 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 15:33:18 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA04889 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 15:33:18 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3LL2L53D>; Thu, 12 Jul 2001 17:33:18 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E9C@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Gary Kenward <gkenward@nortelnetworks.com>
Cc: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 , RE: Issue #4)
Date: Thu, 12 Jul 2001 17:33:17 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk


> 
>   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?

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 owner-seamoby@diameter.org  Thu Jul 12 19:01:18 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08741
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 19:01:17 -0400 (EDT)
Received: (qmail 13480 invoked by alias); 12 Jul 2001 22:49:54 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 13474 invoked by uid 200); 12 Jul 2001 22:49:53 -0000
Received: (qmail 13464 invoked from network); 12 Jul 2001 22:49:51 -0000
Received: from motgate4.mot.com (144.189.100.102)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 22:49:50 -0000
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id QAA17847 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 16:00:40 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id QAA00341 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 16:00:40 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3LL2L6BN>; Thu, 12 Jul 2001 18:00:40 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9E9F@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: "'James Kempf'" <James.Kempf@Sun.COM>, gkenward@nortelnetworks.com,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        john.loughney@nokia.com, seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,          RE: Issue #4)
Date: Thu, 12 Jul 2001 18:00:39 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

<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 owner-seamoby@diameter.org  Thu Jul 12 19:12:23 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10145
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 19:12:21 -0400 (EDT)
Received: (qmail 14037 invoked by alias); 12 Jul 2001 23:00:50 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 14034 invoked by uid 200); 12 Jul 2001 23:00:49 -0000
Received: (qmail 14029 invoked from network); 12 Jul 2001 23:00:47 -0000
Received: from motgate.mot.com (129.188.136.100)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 23:00:47 -0000
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA18155 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 16:11:36 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id QAA04131 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 16:11:36 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3LL2L6GV>; Thu, 12 Jul 2001 18:11:36 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9EA0@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,  RE: Issue #4)
Date: Thu, 12 Jul 2001 18:11:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk



-----Original Message-----
From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
Sent: Thursday, July 12, 2001 1:21 PM
To: 'Gary Kenward'; Phillip Neumiller; pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD
be , RE: Issue #4)


Yikes!

-----Original Message-----
From: Gary Kenward [mailto:gkenward@nortelnetworks.com]
Sent: Thursday, July 12, 2001 2:10 PM
To: 'Phillip Neumiller'; pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,
RE: Issue #4)
>
>
>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.  

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".


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 owner-seamoby@diameter.org  Thu Jul 12 19:17:11 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10803
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 19:17:10 -0400 (EDT)
Received: (qmail 14543 invoked by alias); 12 Jul 2001 23:04:49 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 14537 invoked by uid 200); 12 Jul 2001 23:04:49 -0000
Received: (qmail 14529 invoked from network); 12 Jul 2001 23:04:46 -0000
Received: from motgate2.mot.com (136.182.1.10)
  by c900656-a.plstn1.sfba.home.com with SMTP; 12 Jul 2001 23:04:46 -0000
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate2.mot.com (motgate2 2.1) with ESMTP id QAA11565 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 16:15:34 -0700 (MST)]
Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id QAA05610 for <seamoby@cdma-2000.org>; Thu, 12 Jul 2001 16:15:33 -0700 (MST)]
Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3LL2L62V>; Thu, 12 Jul 2001 18:15:33 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9EA1@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>,
        "'Gary Kenward'" <gkenward@nortelnetworks.com>, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,  RE: Issue #4)
Date: Thu, 12 Jul 2001 18:15:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C10B28.8D0A1490"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10B28.8D0A1490
Content-Type: text/plain;
	charset="iso-8859-1"

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 

-----Original Message-----
From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
Sent: Thursday, July 12, 2001 1:42 PM
To: 'Gary Kenward'; Phillip Neumiller; pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,
RE: Issue #4)


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. 

   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. 
  



------_=_NextPart_001_01C10B28.8D0A1490
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=759521223-12072001>I 
actually mentioned this issue long time ago. However, I don't think a fall back 
for CT&nbsp;mean</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=759521223-12072001>bundling&nbsp;everything with MIP. It would mean 
renegotiating the needed context at&nbsp;</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=759521223-12072001>the 
new AR and&nbsp;thinking&nbsp;I don't care how long that takes, since CT failed, 
there is</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=759521223-12072001>nothing I can do.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=759521223-12072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=759521223-12072001>Madjid&nbsp;</SPAN></FONT></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Phillip Neumiller 
  [mailto:PNeumiller@MeshNetworks.com]<BR><B>Sent:</B> Thursday, July 12, 2001 
  1:42 PM<BR><B>To:</B> 'Gary Kenward'; Phillip Neumiller; 
  pcalhoun@diameter.org<BR><B>Cc:</B> seamoby@cdma-2000.org<BR><B>Subject:</B> 
  RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue 
  #4)<BR><BR></DIV></FONT>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>1).&nbsp; Not using "seamless" in a draft is rule 
  begging to be broken since it is</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; absolutely 
  rediculous.&nbsp; What is this Monty Python's&nbsp;flying 
  IETF?</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>2).&nbsp; OK I finally understand what you are 
  saying, and it makes sense and</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a statement based on 
  what your wrote below REALLY NEEDS TO BE</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; IN THE 
  DRAFT.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>i.e. 
  Handovers that use CT MAY fall back to best effort handvovers in 
  the</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001>cases where CT fails.&nbsp; My argument is that to 
  make this whole thing clean</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>and 
  more reliable we should add a requirement like:</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>To 
  increase the reliability of handovers using CT, the designer MAY 
  bundle</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN class=754103718-12072001>the 
  CT packet with handover signalling such as that used in MIPv4 and 
  MIPv6.</SPAN></FONT></DIV>
  <DIV><FONT color=#0000ff face=Arial size=2><SPAN 
  class=754103718-12072001></SPAN></FONT>&nbsp;</DIV>
  <BLOCKQUOTE 
  style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
    <P><FONT size=2><SPAN class=754103718-12072001>&nbsp;</SPAN>I said that ct 
    is not essential to an ordinary handover ("seamy handover"?).</FONT> 
    <BR><FONT size=2>And thus, a failure to complete ct on time must not cause 
    an </FONT><BR><FONT size=2>"ordinary handover" ("best effort handover"?) to 
    fail.</FONT> </P>
    <P><FONT size=2>&nbsp;&nbsp; Some designers want to be able to fall back to 
    a "best effort"</FONT> <BR><FONT size=2>handover if the seamless handover 
    fails, and yes, the seams will show.</FONT>&nbsp;<BR><FONT size=2>&nbsp; 
    </FONT><BR></P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C10B28.8D0A1490--


From owner-seamoby@diameter.org  Thu Jul 12 20:25:15 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19033
	for <seamoby-archive@odin.ietf.org>; Thu, 12 Jul 2001 20:25:15 -0400 (EDT)
Received: (qmail 15436 invoked by alias); 13 Jul 2001 00:13:40 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15430 invoked by uid 200); 13 Jul 2001 00:13:39 -0000
Received: (qmail 15425 invoked from network); 13 Jul 2001 00:13:38 -0000
Received: from unknown (HELO fridge.docomo-usa.com) (216.98.102.228)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 00:13:38 -0000
Received: from localhost (gyj@localhost)
	by fridge.docomo-usa.com (8.11.3/8.11.3) with ESMTP id f6D0Sin26694;
	Thu, 12 Jul 2001 17:28:44 -0700 (PDT)
Date: Thu, 12 Jul 2001 17:28:43 -0700 (PDT)
From: Youngjune Lee Gwon <gyj@dcl.docomo-usa.com>
X-Sender: gyj@fridge.docomo-usa.com
Reply-To: Youngjune Lee Gwon <gyj@isl.stanford.edu>
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
cc: seamoby@cdma-2000.org
Subject: [seamoby] CT trigger/completion
In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B017A9E9B@IL27EXM10.cig.mot.com>
Message-ID: <Pine.BSI.4.05L.10107121721310.26203-100000@fridge.docomo-usa.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi,

This is a quick question regarding CT trigger/completion debate.

Consider if a MN is receiving IP packets from nAR, and the packets are
forwarded (tunneled, e.g. BETH) from the oAR. Are forwarded packets
(CN->oAR->nAR->MN) OK without CT between oAR and nAR? Or, do they still
require that CT should be completed at nAR by the time MN is receiving
them from nAR?

My understanding is that CT does not have to be completed at nAR if
packets are tunneled from oAR. And, oAR can support MN's IP
micro-flow because context info is still there at oAR. Correct?

Youngjune


On Thu, 12 Jul 2001, Nakhjiri Madjid-MNAKHJI1 wrote:

> 
> 
> -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
> 
> Madjid>> James, the timer makes sense, however, the time to live
> for each context depends on the feature that the context belongs 
> too, maybe such a time to live can be added to the context packets.
> Having a universal time to live for all types of context is not
> very precise.
> 
> Madjid
> 



From owner-seamoby@diameter.org  Fri Jul 13 01:55:02 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05161
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 01:55:01 -0400 (EDT)
Received: (qmail 17435 invoked by alias); 13 Jul 2001 05:43:23 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 17429 invoked by uid 200); 13 Jul 2001 05:43:23 -0000
Received: (qmail 17424 invoked from network); 13 Jul 2001 05:43:20 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 05:43:20 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6D5seI07110
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 08:54:40 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b7e45348ac158f2313e2@esvir03nok.nokia.com>;
 Fri, 13 Jul 2001 08:54:06 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS49NXG>; Fri, 13 Jul 2001 08:54:07 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094044@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: James.Kempf@sun.com
Cc: seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
	  lti-  Phase CT
Date: Fri, 13 Jul 2001 08:54:04 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi James,

> I think Seamoby should do a framework that can be bound to a 
> particular mobility protocol. The framework might, in fact, be fairly 
> detailed in terms of on the wire representations and such, it would just 
> not, a priori, be a separate protocol.
> 
> Perhaps there should also be a protocol that wraps the framework for
> those mobility protocols that don't want to make CT into an extension.
> 
> I believe that the requirements should not specify bundling HO and CT,
> and also that they should not forbid it.

I think that works for me. 

John


From owner-seamoby@diameter.org  Fri Jul 13 02:05:39 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12704
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 02:05:38 -0400 (EDT)
Received: (qmail 17935 invoked by alias); 13 Jul 2001 05:53:46 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 17929 invoked by uid 200); 13 Jul 2001 05:53:45 -0000
Received: (qmail 17924 invoked from network); 13 Jul 2001 05:53:43 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 05:53:43 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6D653I10722
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 09:05:03 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b7ede125ac158f2313e2@esvir03nok.nokia.com> for <seamoby@cdma-2000.org>;
 Fri, 13 Jul 2001 09:04:33 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS493BJ>; Fri, 13 Jul 2001 09:04:33 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094045@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: seamoby@cdma-2000.org
Subject: [seamoby] CT Requirements Issue 7
Date: Fri, 13 Jul 2001 09:04:28 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi all,

I sent this yesterday, but it didn't seem to make the list - let me try
again.

====

Description of issue 

Section 4.4 & 4.5 are potentially limiting.

Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: July 12, 2001 
Comment type: T

Priority: S

Section: Insert_Section_Number_Here 

Rationale/Explanation of issue: 

Currently 4.4 and 4.5 imply that there are two modes of operation.  It is
not so cut & dry.  As seen by the discussion on the list, there are many
differing requirements that may not be satisfied by discussion these modes.
Length description of problem 

Currently, by defining proactive & reactive, the work group may start to
think in terms of these 2 modes of operation.  I don't think that CT is so
black & white.  

Requested change: 

Remove proactive & reactive from the document.  These could be used as
examples in the document, if needed.

Disclaimer: I am not saying that proactive, reactive, active, etc. are not
needed - what I am saying is that by defining requirements for more basic
building blocks, we can then use those building blocks to create aggregate
behavior that looks like proactive, reactive, etc.

Proposal 

Focus on the features & functions of reactive & proactive modes rather.  For
example, everyone will agree that certain context may have a higher priority
(may take precidence over, may be more time sensitive, etc.) than others.
Some context may go stale.  Some context may need to be acknowledged.  

By stating the types of functionality that are needed, the requirements will
allow a more rich protocol.


=============================================

Example (solution space):  

We define these features - this is not the complete set:
(priority, time-to-live, ack-needed, synchonized with ho)

So, I would define the transfer of header compression state
as context transfer that has a high priority, a certain time-to-live, 
ack-needed.

High priority would mean that the AR would send it ASAP.

TTL would indicate that the context would go stale.

Ack-needed would indicate to the mobile node that if the
new AR does not yet have the header compression state, 
then it shouldn't send compressed headers, but attempt to
re-initialize the compressor at the new AR.


From owner-seamoby@diameter.org  Fri Jul 13 02:11:20 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15773
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 02:11:19 -0400 (EDT)
Received: (qmail 18427 invoked by alias); 13 Jul 2001 05:57:45 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18421 invoked by uid 200); 13 Jul 2001 05:57:45 -0000
Received: (qmail 18415 invoked from network); 13 Jul 2001 05:57:41 -0000
Received: from mgw-x2.nokia.com (131.228.20.22)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 05:57:41 -0000
Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6D68o315126
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 09:08:50 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b7f1849cac158f22077@esvir02nok.nokia.com>;
 Fri, 13 Jul 2001 09:08:31 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS493FV>; Fri, 13 Jul 2001 09:08:31 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094046@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: gkenward@nortelnetworks.com
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,  RE: Issue #4)
Date: Fri, 13 Jul 2001 09:08:29 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Gary, 

  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). 

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

John



From owner-seamoby@diameter.org  Fri Jul 13 02:15:52 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16259
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 02:15:52 -0400 (EDT)
Received: (qmail 18774 invoked by alias); 13 Jul 2001 06:01:57 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18765 invoked by uid 200); 13 Jul 2001 06:01:51 -0000
Received: (qmail 18745 invoked from network); 13 Jul 2001 06:01:48 -0000
Received: from mgw-x4.nokia.com (131.228.20.27)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 06:01:48 -0000
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6D6FTG12653
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 09:15:29 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b7f537daac158f24077@esvir04nok.ntc.nokia.com>;
 Fri, 13 Jul 2001 09:12:34 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS49324>; Fri, 13 Jul 2001 09:12:33 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094047@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: PNeumiller@MeshNetworks.com
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,  RE: Issue #4)
Date: Fri, 13 Jul 2001 09:12:27 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Phil,

> 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?  

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

John


From owner-seamoby@diameter.org  Fri Jul 13 04:21:44 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29397
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 04:21:43 -0400 (EDT)
Received: (qmail 20075 invoked by alias); 13 Jul 2001 08:10:06 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20069 invoked by uid 200); 13 Jul 2001 08:10:05 -0000
Received: (qmail 20064 invoked from network); 13 Jul 2001 08:10:02 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 08:10:02 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6D8LMI04998
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 11:21:22 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b86aaf86ac158f2313e2@esvir03nok.nokia.com> for <seamoby@cdma-2000.org>;
 Fri, 13 Jul 2001 11:20:52 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS49TBH>; Fri, 13 Jul 2001 11:20:52 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094050@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: tpagtzis@iprg.nokia.com
Cc: seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
	 lti-  Phase CT
Date: Fri, 13 Jul 2001 11:20:45 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Theo,

>   Your example is very similar to what we are proposing in 
> the proactive mobility draft
> 
> draft-pagtzis-mobileip-proactivev6-00.txt/.ps

I've printed this out - but it'll take some time
to digest all of this.

>     I have a slight reservation about the term used here 
> though. It sounds to me that it is not syncronisation that 
> is effected, since for that MN the new AR will received the 
> context superset once and that is it. There is no
> continuous streaming of context (even 'multiplexed' ) where 
> the MN needs to syncronize in the strict sense of syncronisation.
> 
> It simply enables connectivity with the proactive forwarding of the
> context; isn't that the case you refer to ?

Exactly - all I meant by the term was that context would be connected
or associated with a handoff.  Let's call it association id.

I think in the protocol design phase, we can work out the specific details.


In solution space, I would use a 32-bit integer that could be used in 
both CTP and the MIP handoff signaling messages.  The new AR can use
a hash of the association id and the IP address who sent it to save
the context, so that when a HO is completed, the new AR can easily
retrieve the context.

br,
John


From owner-seamoby@diameter.org  Fri Jul 13 09:24:00 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05879
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 09:23:58 -0400 (EDT)
Received: (qmail 23269 invoked by alias); 13 Jul 2001 13:12:38 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 23263 invoked by uid 200); 13 Jul 2001 13:12:38 -0000
Received: (qmail 23254 invoked from network); 13 Jul 2001 13:12:36 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 13:12:36 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1KPDD>; Fri, 13 Jul 2001 09:22:56 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E04844559E@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: seamoby@cdma-2000.org
Subject: [seamoby] Yet another Security RANT was  L2 API (WAS: Ext. for FMIPv6 - com
	ments) (SHOULD be ,          RE: Issue #4)
Date: Fri, 13 Jul 2001 09:22:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Madjid,

I disdain coupling security issues with non-security transport 
design and requirements formulation.  I believe security issues
should be left up to the security WG where the appropriate domain
experts can create general purpose solutions.  IP and the major
transport protocols such as UDP, TCP, and SCTP should be made
secure (perhaps with IPsec).  Users of these off-the-shelf 
protocols could then "feel" safe about doing what they want and
not waste time getting all balled up in security issues.  It
seems like a BAD idea to me to make every single IETF WG jump
through security hoops since:

A).  It dilutes the real "work" the WG is trying to do
B).  It allows for wasted effort on different security solutions
     all over the IETF since they are uncoordinated
C).  The members of many non-security WGs do not have the 
     appropriate domain expertise to solve security problems.

So clearly I disagree with our ADs on this issue.  Is that a 
crime?  This is not the first time (or the first WG) I have
stated this (in).

CASE IN POINT: Handovers.

Handovers can be done with MIP.  They can be done with "local-mobility"
protocols, or perhaps in other ways.  Security of the mobile host is
likely to be done differently by different network operators.  To explicitly
tie some mandated security to the our handover work weakens its 
general applicability.  However, I am all in favor of an
API/signaling/trigger
mechanism/hooks for security/AAA.  My two cents!

Thanks,

Phil

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Thursday, July 12, 2001 7:01 PM
> To: 'Phillip Neumiller'; 'Pat Calhoun'
> Cc: 'James Kempf'; gkenward@nortelnetworks.com; Nakhjiri
> Madjid-MNAKHJI1; john.loughney@nokia.com; seamoby@cdma-2000.org
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> <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 owner-seamoby@diameter.org  Fri Jul 13 09:31:30 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06876
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 09:31:29 -0400 (EDT)
Received: (qmail 23755 invoked by alias); 13 Jul 2001 13:20:11 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 23749 invoked by uid 200); 13 Jul 2001 13:20:11 -0000
Received: (qmail 23744 invoked from network); 13 Jul 2001 13:20:09 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 13:20:09 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1KPDL>; Fri, 13 Jul 2001 09:30:30 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E04844559F@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,  RE: Issue #4)
Date: Fri, 13 Jul 2001 09:30:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi John,

> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Hi Phil,
> 
> > 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?  
> 
> Last I checked, the WG was Seamless Mobility, not Seamless Handover.
> There is a difference.
> 
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 owner-seamoby@diameter.org  Fri Jul 13 10:56:14 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18354
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 10:55:57 -0400 (EDT)
Received: (qmail 25284 invoked by alias); 13 Jul 2001 14:38:38 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 25271 invoked by uid 200); 13 Jul 2001 14:38:36 -0000
Received: (qmail 25260 invoked from network); 13 Jul 2001 14:38:32 -0000
Received: from mgw-dax1.ext.nokia.com (63.78.179.216)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 14:38:32 -0000
Received: from davir04nok.americas.nokia.com (davir04nok.americas.nokia.com [172.18.242.87])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6DEnOi13623;
	Fri, 13 Jul 2001 09:49:24 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir04nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b8168f92ac12f257079@davir04nok.americas.nokia.com>;
 Fri, 13 Jul 2001 09:48:59 -0500
content-class: urn:content-classes:message
Subject: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery
Date: Fri, 13 Jul 2001 09:48:04 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E460440DE01@bseis01nok>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_001_01C10BAA.D216A5D0"
Thread-Topic: Resend:New Draft:Issues in Candidate Access Router Discovery
Thread-Index: AcELqtH0PB48k5rZR16/VPIBCFT0yw==
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
From: <Govind.Krishnamurthi@nokia.com>
To: <mobile-ip@sunroof.eng.sun.com>
Cc: <seamoby@cdma-2000.org>, <seamoby-context@cdma-2000.org>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------_=_NextPart_001_01C10BAA.D216A5D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'm resending the draft to the mailing list as I did not see it appear
in the  archives. Sorry if you receive multiple copies.
BRs,
Govind.

Abstract:
Handoff in IP mobility protocols involves moving a mobile node's
Layer 3 routing reachability information from one access router to
another, before or after the mobile node has established a Layer 2
connection with the radio access point that is covered by the new
access router. In addition, other context information about the
mobile node's packet session may be transferred from the old access
router to the new one, in order to minimize the service disruption
during the handoff process. While the exact details of how this is
accomplished vary depending on the IP mobility and seamless handoff
protocols, one common thread required for seamless handoffs is
identifying the candidate access routers for the mobile node's
handoff. When a collection of candidates has been identified, an
algorithm is run to determine the target access router, and this
router becomes the target of handoff at Layer 3. This document
presents a problem statement describing issues involved in designing
a candidate access router discovery protocol. The document does not
discuss the algorithm by which the actual target router is
identified, nor how the handoff to the target is achieved.



Comments are welcome.

Best Regards,
Govind.




 <<draft-ietf-seamoby-CARdiscovery-issues-00.txt>>=20


------_=_NextPart_001_01C10BAA.D216A5D0
Content-Type: text/plain;
	name="draft-ietf-seamoby-CARdiscovery-issues-00.txt"
Content-Description: draft-ietf-seamoby-CARdiscovery-issues-00.txt
Content-Disposition: attachment;
	filename="draft-ietf-seamoby-CARdiscovery-issues-00.txt"
Content-Transfer-Encoding: base64

SUVURiBTZWFtb2J5IFdvcmtpbmcgR3JvdXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
RGlyayBUcm9zc2VuDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgR292aW5kIEtyaXNobmFtdXJ0aGkNCmRyYWZ0LWlldGYtc2VhbW9ieS1DQVJkaXNjb3Zl
cnktaXNzdWVzLTAwLnR4dCAgICAgICAgICBIZW1hbnQgQ2hhc2thcg0KRXhwaXJlczogSmFudWFy
eSAyMDAyICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5va2lhDQog
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
SmFtZXMgS2VtcGYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgU3VuIE1pY3Jvc3lzdGVtcywgSW5jLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVseSAyMDAxDQoNCiBJc3N1ZXMgaW4gY2Fu
ZGlkYXRlIGFjY2VzcyByb3V0ZXIgZGlzY292ZXJ5IGZvciBzZWFtbGVzcyBJUCBoYW5kb2Zmcw0K
DQpTdGF0dXMgb2YgVGhpcyBNZW1vDQoNCiAgVGhpcyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1E
cmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5jZQ0KICB3aXRoIGFsbCBwcm92aXNpb25zIG9m
IFNlY3Rpb24gMTAgb2YgUkZDMjAyNi4NCg0KICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcg
ZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZw0KICBUYXNrIEZvcmNlIChJRVRG
KSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQNCiAgb3RoZXIg
Z3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQN
CiAgRHJhZnRzLg0KICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBm
b3IgYSBtYXhpbXVtIG9mIHNpeA0KICBtb250aHMgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj
ZWQsIG9yIG1hZGUgb2Jzb2xldGUgYnkgb3RoZXINCiAgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJ
dCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMNCiAgYXMgcmVmZXJlbmNl
IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluDQogIHByb2dy
ZXNzLiINCg0KICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LURyYWZ0cyBjYW4gYmUgYWNj
ZXNzZWQgYXQNCiAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0K
ICBUaGUgIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9yaWVzIGNhbiBiZSBh
Y2Nlc3NlZCBhdA0KICBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQpDb3B5cmln
aHQgTm90aWNlDQoNCiAgQ29weXJpZ2h0IChjKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwMSku
IEFsbCByaWdodHMgcmVzZXJ2ZWQuDQoNCkFCU1RSQUNUDQoNCkhhbmRvZmYgaW4gSVAgbW9iaWxp
dHkgcHJvdG9jb2xzIGludm9sdmVzIG1vdmluZyBhIG1vYmlsZSBub2RlJ3MNCkxheWVyIDMgcm91
dGluZyByZWFjaGFiaWxpdHkgaW5mb3JtYXRpb24gZnJvbSBvbmUgYWNjZXNzIHJvdXRlciB0bw0K
YW5vdGhlciwgYmVmb3JlIG9yIGFmdGVyIHRoZSBtb2JpbGUgbm9kZSBoYXMgZXN0YWJsaXNoZWQg
YSBMYXllciAyDQpjb25uZWN0aW9uIHdpdGggdGhlIHJhZGlvIGFjY2VzcyBwb2ludCB0aGF0IGlz
IGNvdmVyZWQgYnkgdGhlIG5ldw0KYWNjZXNzIHJvdXRlci4gSW4gYWRkaXRpb24sIG90aGVyIGNv
bnRleHQgaW5mb3JtYXRpb24gYWJvdXQgdGhlDQptb2JpbGUgbm9kZSdzIHBhY2tldCBzZXNzaW9u
IG1heSBiZSB0cmFuc2ZlcnJlZCBmcm9tIHRoZSBvbGQgYWNjZXNzDQpyb3V0ZXIgdG8gdGhlIG5l
dyBvbmUsIGluIG9yZGVyIHRvIG1pbmltaXplIHRoZSBzZXJ2aWNlIGRpc3J1cHRpb24NCmR1cmlu
ZyB0aGUgaGFuZG9mZiBwcm9jZXNzLiBXaGlsZSB0aGUgZXhhY3QgZGV0YWlscyBvZiBob3cgdGhp
cyBpcw0KYWNjb21wbGlzaGVkIHZhcnkgZGVwZW5kaW5nIG9uIHRoZSBJUCBtb2JpbGl0eSBhbmQg
c2VhbWxlc3MgaGFuZG9mZg0KcHJvdG9jb2xzLCBvbmUgY29tbW9uIHRocmVhZCByZXF1aXJlZCBm
b3Igc2VhbWxlc3MgaGFuZG9mZnMgaXMNCmlkZW50aWZ5aW5nIHRoZSBjYW5kaWRhdGUgYWNjZXNz
IHJvdXRlcnMgZm9yIHRoZSBtb2JpbGUgbm9kZSdzDQpoYW5kb2ZmLiBXaGVuIGEgY29sbGVjdGlv
biBvZiBjYW5kaWRhdGVzIGhhcyBiZWVuIGlkZW50aWZpZWQsIGFuDQphbGdvcml0aG0gaXMgcnVu
IHRvIGRldGVybWluZSB0aGUgdGFyZ2V0IGFjY2VzcyByb3V0ZXIsIGFuZCB0aGlzDQpyb3V0ZXIg
YmVjb21lcyB0aGUgdGFyZ2V0IG9mIGhhbmRvZmYgYXQgTGF5ZXIgMy4gVGhpcyBkb2N1bWVudA0K
cHJlc2VudHMgYSBwcm9ibGVtIHN0YXRlbWVudCBkZXNjcmliaW5nIGlzc3VlcyBpbnZvbHZlZCBp
biBkZXNpZ25pbmcNCmEgY2FuZGlkYXRlIGFjY2VzcyByb3V0ZXIgZGlzY292ZXJ5IHByb3RvY29s
LiBUaGUgZG9jdW1lbnQgZG9lcyBub3QNCmRpc2N1c3MgdGhlIGFsZ29yaXRobSBieSB3aGljaCB0
aGUgYWN0dWFsIHRhcmdldCByb3V0ZXIgaXMNCmlkZW50aWZpZWQsIG5vciBob3cgdGhlIGhhbmRv
ZmYgdG8gdGhlIHRhcmdldCBpcyBhY2hpZXZlZC4NCg0KVHJvc3NlbiwgS3Jpc2huYW11cnRoaSwg
Q2hhc2thciwgS2VtcGYgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIGldDQoMDQpJTlRFUk5F
VC1EUkFGVCAgQ2FuZGlkYXRlIEFjY2VzcyBSb3V0ZXIgRGlzY292ZXJ5IElzc3VlcyAgIEp1bHks
IDIwMDENCg0KDQoNCg0KDQogIFRBQkxFIE9GIENPTlRFTlRTDQoNCiAgICAxLiBJTlRST0RVQ1RJ
T04gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMQ0KDQogICAgMi4g
VEVSTUlOT0xPR1kgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEN
Cg0KICAgIDMuIENBTkRJREFURSBBQ0NFU1MgUk9VVEVSIERJU0NPVkVSWSBQUk9CTEVNICAgICAg
ICAgICAgICAyDQoNCiAgICAgICAzLjEgQW50aWNpcGF0ZWQgQ0FSIERpc2NvdmVyeSAgICAgICAg
ICAgICAgICAgICAgICAgICAgMg0KICAgICAgIDMuMiBEeW5hbWljIENBUiBEaXNjb3ZlcnkgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAzDQogICAgICAgMy4zIEh5YnJpZCBDQVIgRGlzY292
ZXJ5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDMNCg0KICAgIDQuIFNQRUNJRklDIElT
U1VFUyBJTiBDQVIgRElTQ09WRVJZICAgICAgICAgICAgICAgICAgICAgICAzDQoNCiAgICAgICA0
LjEgSWRlbnRpZnlpbmcgUEFBUnMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMw0K
ICAgICAgIDQuMiBJZGVudGlmeWluZyBjYXBhYmlsaXRpZXMgb2YgUEFBUnMgICAgICAgICAgICAg
ICAgICA0DQogICAgICAgNC4zIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIDUNCg0KICAgIDUuIFJFRkVSRU5DRVMgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICA1DQoNCiAgICA2LiBBVVRIT1JTJyBBRERSRVNTICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNg0KDQoNCg0KICBBQ0tOT1dMRURHTUVO
VFMNCiAgDQogICAgU3BlY2lhbCB0aGFua3MgYXJlIGR1ZSB0byBKb2huIExvdWdobmV5IChOb2tp
YSkgZm9yIGhpcyBpbnB1dA0KICAgIGR1cmluZyB0aGUgcHJlcGFyYXRpb24gb2YgdGhpcyBkb2N1
bWVudC4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClRyb3NzZW4s
IEtyaXNobmFtdXJ0aGksIENoYXNrYXIsIEtlbXBmICAgICAgICAgICAgICAgICAgICAgIFtQYWdl
IGlpXQ0KDA0KSU5URVJORVQtRFJBRlQgIENhbmRpZGF0ZSBBY2Nlc3MgUm91dGVyIERpc2NvdmVy
eSBJc3N1ZXMgICBKdWx5LCAyMDAxDQoNCg0KMS4gSU5UUk9EVUNUSU9ODQoNCklQIG1vYmlsaXR5
IHByb3RvY29scyBlbmFibGUgbW9iaWxlIG5vZGVzIChNTnMpIHRvIGNoYW5nZSB0aGUgYWNjZXNz
DQpyb3V0ZXJzIChBUnMpIGJ5IHdoaWNoIHRoZXkgYWNjZXNzIHRoZSBJbnRlcm5ldC4gQW4gQVIg
cHJvdmlkaW5nDQpJbnRlcm5ldCBjb25uZWN0aXZpdHkgdG8gdGhlIE1OIGNoYW5nZXMgd2hlbiBt
b3ZlbWVudCBvZiB0aGUgTU4NCmNhdXNlcyBhIGNoYW5nZSBpbiB0aGUgcmFkaW8gYWNjZXNzIHBv
aW50IHRocm91Z2ggd2hpY2ggdGhlIE1ODQpjb21tdW5pY2F0ZXMgd2l0aCB0aGUgd2lyZWQgbmV0
d29yaywgc3VjaCB0aGF0IHRoZSBuZXcgcmFkaW8gYWNjZXNzDQpwb2ludCBpcyBpbiBhIG5ldyBz
dWJuZXQuIFRoZXJlIGFyZSBleGlzdGluZyBzb2x1dGlvbnMgWzEsIDJdIHRoYXQNCmVuYWJsZSBN
TnMgdG8gZXhlY3V0ZSBoYW5kb2ZmcyBiZXR3ZWVuIHRoZSBBUnMuIEFkZGl0aW9uYWxseSwgd29y
ayBpcw0KdW5kZXJ3YXkgWzMsIDQsIDUsIDYsIDddLCB0byBkZWZpbmUgcHJvdG9jb2xzIHRoYXQg
d291bGQgYWxsb3cNCnNlYW1sZXNzLCBtZWFuaW5nIGxvdyBsYXRlbmN5IGFuZCBsb3cgcGFja2V0
IGxvc3MsIGhhbmRvZmZzIG9mIE1Ocw0KYmV0d2VlbiB0aGUgQVJzLiBUaGVzZSBoYW5kb2ZmIHNv
bHV0aW9ucyBhc3N1bWUgdGhhdCB0aGUgaWRlbnRpdHkgb2YNCnRoZSBuZXcgQVIgaXMga25vd24g
dG8gdGhlIG9sZCBBUi4gVGhleSBkbyBub3QgcHJvdmlkZSBhIHNvbHV0aW9uIHRvDQp0aGUgcHJv
YmxlbSBvZiBkaXNjb3ZlcmluZyB0aGUgdGFyZ2V0IEFSIGZvciB0aGUgTU4ncyBoYW5kb2ZmLiBX
aGF0DQppcyByZXF1aXJlZCBpcyBhIHByb3RvY29sIHRoYXQgd291bGQgYWxsb3cgYW4gQVIgb3Ig
YW4gTU4gdG8gZGlzY292ZXINCnRoZSBuZWlnaGJvcmluZyBBUnMgZm9yIGhhbmRvZmYsIGFsb25n
IHdpdGggdGhlaXIgY2FwYWJpbGl0aWVzLiBUaGlzDQppbmZvcm1hdGlvbiBjYW4gYmUgdXNlZCBm
b3Igc2VsZWN0aW5nIHRoZSBhY3R1YWwgdGFyZ2V0IEFSIGZvciB0aGUNCk1OJ3MgaGFuZG9mZi4g
VGhpcyBkcmFmdCBkaXNjdXNzZXMgdGhlIGlzc3VlcyBpbnZvbHZlZCBpbiB0aGUgcHJvYmxlbQ0K
b2YgY2FuZGlkYXRlIEFSIGRpc2NvdmVyeS4gVGhlIGRyYWZ0IGRvZXMgbm90IGRpc2N1c3MgdGhl
IHByb2JsZW0gb2YNCmFjdHVhbGx5IHNlbGVjdGluZyB0aGUgdGFyZ2V0IEFSIHRvIHdoaWNoIGhh
bmRvZmYgaXMgcGVyZm9ybWVkLCBub3INCnRoZSBhY3R1YWwgaGFuZG9mZiBwcm9jZXNzIGl0c2Vs
Zi4NCg0KMi4gVEVSTUlOT0xPR1kNCg0KQWNjZXNzIFBvaW50IChBUCkNCg0KICBBIHJhZGlvIHRy
YW5zY2VpdmVyIGJ5IHdoaWNoIGFuIE1OIG9idGFpbnMgTGF5ZXIgMiBjb25uZWN0aXZpdHkNCiAg
d2l0aCB0aGUgd2lyZWQgbmV0d29yay4NCg0KQWNjZXNzIFJvdXRlciAoQVIpDQoNCiAgQW4gSVAg
cm91dGVyIHJlc2lkaW5nIGluIGFuIGFjY2VzcyBuZXR3b3JrIGFuZCBjb25uZWN0ZWQgdG8gb25l
DQogIG9yIG1vcmUgQVBzLiBBbiBBUiBvZmZlcnMgSVAgY29ubmVjdGl2aXR5IHRvIE1OLg0KDQpQ
aHlzaWNhbGx5IEFkamFjZW50IEFSIChQQUFSKQ0KDQogIEFuIEFSIHdob3NlIGNvdmVyYWdlIGFy
ZWEgaXMgc3VjaCB0aGF0IGFuIE1OIG1heSBtb3ZlIGZyb20gdGhlDQogIGNvdmVyYWdlIGFyZWEg
b2YgdGhlIEFSIGN1cnJlbnRseSBzZXJ2aW5nIHRoZSBNTiBpbnRvIHRoZSBjb3ZlcmFnZQ0KICBh
cmVhIG9mIHRoaXMgQVIuDQoNCkNhbmRpZGF0ZSBBUiAoQ0FSKQ0KDQogIFRoaXMgaXMgYW4gQVIg
dGhhdCBpcyBhIGNhbmRpZGF0ZSBmb3IgTU4ncyBoYW5kb2ZmLiBDQVIgaXMNCiAgbmVjZXNzYXJp
bHkgYSBQQUFSIG9mIHRoZSBBUiBjdXJyZW50bHkgc2VydmluZyB0aGUgTU4sIGFuZCBhbHNvIGhh
cw0KICB0aGUgY2FwYWJpbGl0eSBzZXQgcmVxdWlyZWQgdG8gc2VydmUgdGhlIE1OLg0KDQpUYXJn
ZXQgQVIgKFRBUikNCg0KICBUaGlzIGlzIGFuIEFSIHdpdGggd2hpY2ggdGhlIHByb2NlZHVyZXMg
Zm9yIE1OJ3MgaGFuZG9mZg0KICBhcmUgaW5pdGlhdGVkLg0KDQoNClRyb3NzZW4sIEtyaXNobmFt
dXJ0aGksIENoYXNrYXIsIEtlbXBmICAgICAgICAgICAgICAgICAgICAgICBbUGFnZSAxXQ0KDA0K
SU5URVJORVQtRFJBRlQgIENhbmRpZGF0ZSBBY2Nlc3MgUm91dGVyIERpc2NvdmVyeSBJc3N1ZXMg
ICBKdWx5LCAyMDAxDQoNClRBUiBTZWxlY3Rpb24gQWxnb3JpdGhtDQoNCiAgVGhlIGFsZ29yaXRo
bSB0aGF0IGRldGVybWluZXMgYSB1bmlxdWUgVEFSIGZvciBNTidzIGhhbmRvZmYgZnJvbQ0KICB0
aGUgc2V0IG9mIENBUnMuIFRoZSBleGFjdCBuYXR1cmUgYW5kIGRlZmluaXRpb24gb2YgdGhpcyBh
bGdvcml0aG0NCiAgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4NCg0KMy4g
Q0FORElEQVRFIEFDQ0VTUyBST1VURVIgRElTQ09WRVJZIFBST0JMRU0NCg0KVGhlcmUgYXJlIHR3
byBiYXNpYyBhcHByb2FjaGVzIHRvIENBUiBkaXNjb3ZlcnksIG5hbWVseSwgQW50aWNpcGF0ZWQN
CkNBUiBEaXNjb3ZlcnkgYW5kIER5bmFtaWMgQ0FSIERpc2NvdmVyeS4NCg0KMy4xIEFudGljaXBh
dGVkIENBUiBEaXNjb3ZlcnkNCg0KSW4gdGhpcyBhcHByb2FjaCwgYW4gQVIgY3VycmVudGx5IHNl
cnZpbmcgdGhlIE1OIGlkZW50aWZpZXMgYWxsIENBUnMNCmZvciB0aGUgTU4ncyBoYW5kb2ZmLCBh
dCBzb21lIHBvaW50IHByaW9yIHRvIGhhbmRvZmYuIFRoaXMNCmluZm9ybWF0aW9uIGlzIHRoZW4g
aW1tZWRpYXRlbHkgYXZhaWxhYmxlIGF0IHRoZSB0aW1lIG9mIGhhbmRvZmYgYXMNCmlucHV0IHRv
IHRoZSBUQVIgU2VsZWN0aW9uIEFsZ29yaXRobS4gQW5vdGhlciBpbnB1dCBpbnRvIHRoZSBUQVIN
ClNlbGVjdGlvbiBBbGdvcml0aG0gbWF5IGJlIHRoZSBwcmVmZXJlbmNlcyBleHByZXNzZWQgYnkg
dGhlIE1OIHByaW9yDQp0byB0aGUgaGFuZG9mZiwgb3IgcHJlZmVyZW5jZXMgZW5mb3JjZWQgYnkg
dGhlIGFkbWluaXN0cmF0aXZlDQpjb250cm9sLiBBdCB0aGUgdGltZSBvZiBoYW5kb2ZmLCBpdCBt
YXkgb25seSBiZSByZXF1aXJlZCB0byBwcm92aWRlDQppbnB1dCB0byBUQVIgU2VsZWN0aW9uIEFs
Z29yaXRobSBhYm91dCB0aGUgcmVhY2hhYmlsaXR5IG9mDQpuZWlnaGJvcmluZyBBUnMgZnJvbSB0
aGUgTU4uIFRoZSBhZHZhbnRhZ2Ugb2YgdGhpcyBhcHByb2FjaCBpcyB0aGF0DQp0aGUgaGFuZG9m
ZiBjYW4gYmUgZXhlY3V0ZWQgcXVpY2tseSBiZWNhdXNlIHRoZSBBUiBoYXMgYWxyZWFkeQ0KY29s
bGVjdGVkIG11Y2ggb2YgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCBieSB0aGUgVEFSIFNlbGVjdGlv
bg0KQWxnb3JpdGhtLiBBbHNvLCB0aGlzIGFwcHJvYWNoIGRvZXMgbm90IGdlbmVyYXRlIG11Y2gg
cmFkaW8gdHJhZmZpYw0KZm9yIHBlcmZvcm1pbmcgQ0FSIGRpc2NvdmVyeS4NCg0KVGhlIEFudGlj
aXBhdGVkIENBUiBEaXNjb3ZlcnkgcHJvYmxlbSBlbmNvbXBhc3NlcyB0aGUgYXJlYXMgb3V0bGlu
ZWQNCmluIHRoZSBib3ggaW4gRmlndXJlIDEuDQoNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogIHwgICAgICAgICAg
ICAgICAgICAgICBBbGwgcm91dGVycyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN
CiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfA0KICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgUGh5c2ljYWwg
YWRqYWNlbmN5IGRpc2NvdmVyeSAgICAgICB8DQogIHwgICAgICAgICAgICAgICAgICAgICAgICAg
IHYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgfCAgICAgICAgICAg
TG9jYWwgbWFwIG9mIFBBQVJzIGF0IGN1cnJlbnQgQVIgICAgICAgICAgICAgICAgICAgICAgfA0K
ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB8DQogIHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICBDYXBhYmlsaXR5
IGlkZW50aWZpY2F0aW9uICAgICAgICAgIHwNCiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAg
diAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICB8ICAgICAgQ0FScyBm
b3IgTU4ncyBoYW5kb2ZmIGlkZW50aWZpZWQgYXQgY3VycmVudCBBUiAgICAgICAgICAgICB8DQog
IHwgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwNCiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfC0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIFByZWRlZmluZWQgcHJlZmVyZW5jZXMg
b2YgdGhlIE1ODQogICAgICAgIEFSIFJlYWNoYWJpbGl0eSAgICAgIHwgICBuZWdvdGlhdGVkIGF0
IGFkbWlzc2lvbiB0aW1lIG9yDQogICAgICAgICAgZm9yIHRoZSBNTiAgICAgICAgIHwgICBhZG1p
bmlzdHJhdGl2ZSBwcmVmZXJlbmNlcw0KICAgICAgICAgICAgICAgfCAgICAgICAgICAgICB8ICAg
ICAgICAgICAgIHwNCiAgICAgICAgICAgICAgIHYgICAgICAgICAgICAgdiAgICAgICAgICAgICB2
DQogICAgICAgICBUQVIgU2VsZWN0aW9uIEFsZ29yaXRobSBleGVjdXRlZCBhdCB0aGUgdGltZSBv
ZiANCiAgICAgICAgIGhhbmRvZmYgdG8gZGV0ZXJtaW5lIHVuaXF1ZSBUQVIgZm9yIE1OJ3MgaGFu
ZG9mZg0KDQogICAgICAgICAgICAgRmlndXJlIDE6IFRoZSBBbnRpY2lwYXRlZCBDQVIgRGlzY292
ZXJ5IFByb2JsZW0NCg0KVHJvc3NlbiwgS3Jpc2huYW11cnRoaSwgQ2hhc2thciwgS2VtcGYgICAg
ICAgICAgICAgICAgICAgICAgIFtQYWdlIDJdDQoMDQpJTlRFUk5FVC1EUkFGVCAgQ2FuZGlkYXRl
IEFjY2VzcyBSb3V0ZXIgRGlzY292ZXJ5IElzc3VlcyAgIEp1bHksIDIwMDENCg0KMy4yIER5bmFt
aWMgQ0FSIERpc2NvdmVyeQ0KDQpJbiB0aGlzIGFwcHJvYWNoLCBhbiBNTiBkeW5hbWljYWxseSBv
YnRhaW5zIGluZm9ybWF0aW9uIGFib3V0DQp0aGUgYXZhaWxhYmxlIEFScyBmb3IgaGFuZG9mZiwg
YWxvbmcgd2l0aCB0aGVpciBjYXBhYmlsaXRpZXMuIFdoZW4NCnRoZSBNTiBkZXRlY3RzIGFuIEFS
IHRoYXQgaGFzIGNhcGFiaWxpdGllcyB3aGljaCBtYXRjaCBpdHMNCnByZWZlcmVuY2VzLCB0aGUg
TU4gbWF5IG5vdGlmeSB0aGUgY3VycmVudGx5IHNlcnZpbmcgQVIgdG8gcGVyZm9ybSBhDQpoYW5k
b2ZmIHRvIHRoaXMgQVIgdXNpbmcgb25lIG9yIG1vcmUgb2YgdGhlIHNlYW1sZXNzIGhhbmRvZmYN
CnByb3RvY29scy4gVGhlIGFkdmFudGFnZSBvZiB0aGlzIHRlY2huaXF1ZSBpcyB0aGF0IHRoZSBN
TiBoYXMNCmZpbmUtZ3JhaW5lZCBjb250cm9sIG92ZXIgdGhlIFRBUiBzZWxlY3Rpb24uIEhvd2V2
ZXIsIHRoaXMgYXBwcm9hY2gNCmdlbmVyYXRlcyBtb3JlIHJhZGlvIHRyYWZmaWMgZHVyaW5nIHRo
ZSBDQVIgZGlzY292ZXJ5IHN0ZXAuIEFsc28sIGl0DQppcyByZXF1aXJlZCB0aGF0IHRoZSBNTiBj
YW4gbGlzdGVuIHRvIG9yLCBpbiBzb21lIGNhc2VzLCBldmVuIHRhbGsgdG8NCnRoZSBQQUFScyBm
b3IgY29sbGVjdGluZyBjYXBhYmlsaXR5IGluZm9ybWF0aW9uIGFuZCBuZWdvdGlhdGluZw0KcHJl
ZmVyZW5jZXMsIHdoaWxlIHN0aWxsIGJlaW5nIGNvbm5lY3RlZCB0byB0aGUgY3VycmVudCBBUi4N
Cg0KVGhlIER5bmFtaWMgQ0FSIERpc2NvdmVyeSBwcm9ibGVtIGVuY29tcGFzc2VzIHRoZSBhcmVh
cyBvdXRsaW5lZA0KaW4gdGhlIGJveCBpbiBGaWd1cmUgMi4NCg0KICAgLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgfCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
fA0KICB8ICAgICAgICAgICAgICAgICBQQUFScyBpZGVudGlmaWVkIGJ5IE1OICAgICAgICAgICAg
ICAgICAgICAgICB8DQogIHwgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
Q2FwYWJpbGl0eSBpZGVudGlmaWNhdGlvbiBieSBNTiAgfA0KICB8ICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogIHwgICAgICAg
ICAgICAgICAgICAgICAgICAgICB2ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwN
CiAgfCAgICAgICAgICBDQVJzIGZvciBNTidzIGhhbmRvZmYgaWRlbnRpZmllZCBhdCBNTiAgICAg
ICAgICAgICAgfA0KICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8DQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18LS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCBUQVIgc2VsZWN0aW9uIGJ5
IE1OIGF0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICB0aW1lIG9mIGhh
bmRvZmYNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHYNCiAgICAgICAgICAgICAgICBV
bmlxdWUgVEFSIGlkZW50aXR5IHNlbnQgdG8gY3VycmVudCBBUg0KDQogICAgICAgICAgICAgIEZp
Z3VyZSAyOiBEeW5hbWljIENBUiBEaXNjb3ZlcnkgUHJvYmxlbQ0KDQozLjMgSHlicmlkIENBUiBE
aXNjb3ZlcnkNCg0KSW4gcHJhY3RpY2UsIGEgaHlicmlkIG9mIHRoZSBhYm92ZSB0ZWNobmlxdWVz
IGZvciBDQVIgZGlzY292ZXJ5IG1heQ0KYmUgdXNlZC4gSW4gdGhlIGh5YnJpZCBhcHByb2FjaCwg
dGhlIHBhcnRpdGlvbmluZyBvZiBjYXBhYmlsaXR5DQppbmZvcm1hdGlvbiBiZXR3ZWVuIHRoZSB0
d28gdGVjaG5pcXVlcyBhcyB3ZWxsIGFzIHRoZSBwYXJ0aXRpb25pbmcgb2YNClRBUiBzZWxlY3Rp
b24gcHJvY2VzcyBiZXR3ZWVuIHRoZSBNTiBhbmQgdGhlIGN1cnJlbnQgQVIgaXMgcG9zc2libGUu
DQoNCjQuIFNQRUNJRklDIElTU1VFUyBJTiBDQVIgRElTQ09WRVJZDQoNClRoZSBmb2xsb3dpbmcg
c2VjdGlvbnMgZGVzY3JpYmUgdGhlIHNwZWNpZmljIGlzc3VlcyBpbiB0aGUgQ0FSDQpkaXNjb3Zl
cnksIG1heSBpdCBiZSBkb25lIGluIGFudGljaXBhdGVkLCBkeW5hbWljIG9yIGh5YnJpZCB3YXku
DQoNCjQuMSBJZGVudGlmeWluZyBQQUFScw0KDQpBIGJhc2ljIHJlcXVpcmVtZW50IGZvciBhIG5l
dyBBUiB0byBiZSBjb25zaWRlcmVkIGFzIGEgQ0FSIGZvciBNTidzDQpoYW5kb2ZmIGlzIHRoYXQg
dGhlIGNvdmVyYWdlIGFyZWEgb2YgdGhlIG5ldyBBUiBiZSAicGh5c2ljYWxseQ0KYWRqYWNlbnQi
IHRvIHRoYXQgb2YgdGhlIEFSIGN1cnJlbnRseSBzZXJ2aW5nIHRoZSBNTi4gSW4gb3RoZXIgd29y
ZHMsDQoNClRyb3NzZW4sIEtyaXNobmFtdXJ0aGksIENoYXNrYXIsIEtlbXBmICAgICAgICAgICAg
ICAgICAgICAgICBbUGFnZSAzXQ0KDA0KSU5URVJORVQtRFJBRlQgIENhbmRpZGF0ZSBBY2Nlc3Mg
Um91dGVyIERpc2NvdmVyeSBJc3N1ZXMgICBKdWx5LCAyMDAxDQoNCmEgbmV3IEFSIG11c3QgYmUg
YSBQQUFSLiBOb3RlLCB0aGUgcGh5c2ljYWwgYWRqYWNlbmN5IG9mIHRoZSBjb3ZlcmFnZQ0KYXJl
YXMgb2YgdHdvIEFScyBpcyBub3QgbmVjZXNzYXJpbHkgaW1wbGllZCBieSB0aGVpciAibG9naWNh
bCINCmFkamFjZW5jeS4gTG9naWNhbCBhZGphY2VuY3kgb2YgdHdvIEFScyBtZWFucyB0aGF0IHRo
ZXJlIGlzIGp1c3Qgb25lDQpJUCBob3AgYmV0d2VlbiB0aGUgdHdvIEFScywgd2hpbGUgcGh5c2lj
YWwgYWRqYWNlbmN5IG9mIHR3byBBUnMNCmltcGxpZXMgdGhhdCB0aGUgTU4gY2FuIGFjdHVhbGx5
IG1vdmUgZnJvbSB0aGUgY292ZXJhZ2UgYXJlYSBvZiBvbmUNCkFSIHRvIGFub3RoZXIuIENvbnZl
cnNlbHksIFBBQVJzIG5lZWQgbm90IGJlIGxvZ2ljYWxseSBhZGphY2VudCwgYW5kDQptYXkgZXZl
biBoYXZlIElQIGFkZHJlc3NlcyBpbiBkaWZmZXJlbnQgYWRtaW5pc3RyYXRpdmUgZG9tYWlucy4N
Cg0KT25lIGFwcHJvYWNoIGlzIHRvIG1hbnVhbGx5IGNvbmZpZ3VyZSB0aGlzIHBoeXNpY2FsIG5l
aWdoYm9yaG9vZCBhdA0KZWFjaCBBUi4gSG93ZXZlciwgc3VjaCBhbiBhcHByb2FjaCBoYXMgZGlz
YWR2YW50YWdlcyBhbmQgaW4gbWFueQ0KY2FzZXMsIG1heSBub3QgYmUgZmVhc2libGUuIEZvciBp
bnN0YW5jZSwgdHdvIEFScyB0aGF0IGFyZSBwaHlzaWNhbGx5DQphZGphY2VudCBtYXkgYmUgdW5k
ZXIgZGlmZmVyZW50IGFkbWluaXN0cmF0aXZlIGNvbnRyb2wsIGFuZCB0aHVzLCBhcmUNCm5vdCBp
bmZvcm1lZCBhYm91dCBlYWNoIG90aGVyJ3MgcHJlc2VuY2UuIEV2ZW4gd2l0aGluIHRoZSBzYW1l
DQphZG1pbmlzdHJhdGl2ZSBkb21haW4sIHRoZSBtYW51YWwgY29uZmlndXJhdGlvbiBhcHByb2Fj
aCBkZW1hbmRzIG11Y2gNCm5ldHdvcmsgcGxhbm5pbmcgaW4gdGVybXMgb2YgdGhlIGNvdmVyYWdl
IGFyZWFzIG9mIGRpZmZlcmVudCBBUnMuDQpGaW5hbGx5LCB0aGUgbWFudWFsIGNvbmZpZ3VyYXRp
b24gYXBwcm9hY2ggaXMgbm90IHN1aXRhYmxlIGlmIHRoZQ0Kcm91dGVycyBjYW4gYmUgcGh5c2lj
YWxseSByZWxvY2F0ZWQgb3IgdGhlaXIgY292ZXJhZ2UgYXJlYSBjaGFuZ2VkLA0KdGh1cyBhbHRl
cmluZyB0aGUgcGh5c2ljYWwgYWRqYWNlbmN5IG9mIHRoZWlyIGNvdmVyYWdlIGFyZWFzLiBTdWNo
IGENCnNjZW5hcmlvIGlzIHZlcnkgY29tbW9uIHdoZW4gQVJzIGFyZSB0ZW1wb3JhcmlseSBpbnRy
b2R1Y2VkIGluIA0KaG90IHNwb3RzLiBDbGVhcmx5LCBhIG1vcmUgYXV0b21hdGljIGFuZCBkeW5h
bWljIG1lY2hhbmlzbSBpcyBuZWVkZWQNCnRoYXQgd291bGQgYWxsb3cgYW4gQVIgdG8gZGlzY292
ZXIgcGh5c2ljYWxseSBhZGphY2VudCBBUnMgYXJvdW5kDQppdHNlbGYgd2l0aG91dCBtdWNoIGFk
bWluaXN0cmF0aXZlIGludGVydmVudGlvbi4NCg0KRm9yIHRoZSBBbnRpY2lwYXRlZCBDQVIgRGlz
Y292ZXJ5LCB0aGUgcHJvY2VzcyBvZiBpZGVudGlmeWluZyBQQUFScw0KcmVxdWlyZXMgYSBwcm90
b2NvbCB0aGF0IGFsbG93cyBBUnMgdG8gZXhjaGFuZ2UgcGh5c2ljYWwgYWRqYWNlbmN5DQppbmZv
cm1hdGlvbiBpbiBhZHZhbmNlIG9mIGhhbmRvZmYuIEluIER5bmFtaWMgQ0FSIERpc2NvdmVyeSwg
dGhlIE1ODQphdXRvbWF0aWNhbGx5IHNlcnZlcyBhcyB0aGUganVkZ2Ugb2Ygd2hldGhlciBhbiBB
UiBpcyBhIFBBQVIuIEluIHRoZQ0KbGF0dGVyIGNhc2UsIGlmIHRoZSBNTiBjYW4gaGVhciBhIFJv
dXRlciBBZHZlcnRpc2VtZW50IG9mIHRoZSBuZXcgQVIsDQp0aGVuIHRoZSBuZXcgQVIgaXMgUEFB
Ui4NCg0KNC4yIElkZW50aWZ5aW5nIGNhcGFiaWxpdGllcyBvZiBQQUFSczoNCg0KQWx0aG91Z2gg
bm90IGNvbW1vbiBub3csIHRoZSBmdXR1cmUgZ2VuZXJhdGlvbiBtb2JpbGUgbmV0d29ya3MgbWF5
DQpjb25zaXN0IG9mIEFScyB0aGF0IGFyZSBwaHlzaWNhbGx5IGFkamFjZW50LCBidXQgYXJlIGhl
dGVyb2dlbmVvdXMgaW4NCmFkbWluaXN0cmF0aXZlIGNvbnRyb2wsIGZ1bmN0aW9uLCBjYXBhYmls
aXR5LCBsaW5rIGxheWVyIHRlY2hub2xvZ3kNCmFuZCByZXNvdXJjZXMuIEFuIE1OIHRoYXQgaXMg
YXR0YWNoZWQgdG8gYSBnaXZlbiBBUiBtYXkgaGF2ZSBzcGVjaWZpYw0KcmVxdWlyZW1lbnRzIGFz
IHJlZ2FyZHMgdGhlc2UgcGFyYW1ldGVycy4gRm9yIGV4YW1wbGUsIHRoZSBNTiBtYXkNCm5lZWQg
c29tZSBoYXJkd2FyZSBvciBzb2Z0d2FyZSBzdXBwb3J0IGZyb20gdGhlIGFjY2VzcyByb3V0ZXIg
dG8gcnVuDQpjZXJ0YWluIElQLWJhc2VkIGFwcGxpY2F0aW9ucy4gU3VwcG9ydCBmb3IgUW9TLCBz
ZWN1cml0eSwgbXVsdGljYXN0LA0KaGVhZGVyIGNvbXByZXNzaW9uIGV0Yy4gYXJlIHNvbWUgb3Ro
ZXIgYXNwZWN0cyB0aGF0IG5lZWQgdG8gYmUNCmNvbnNpZGVyZWQgd2hlbiBjaG9vc2luZyB0aGUg
Q0FSIGZvciBNTidzIGhhbmRvZmYuIEl0IG1heSBhbHNvIGJlDQpyZXF1aXJlZCB0byBhc3N1cmUg
c29tZSBzZWN1cml0eSBhc3NvY2lhdGlvbiBvciBwb2xpY3kgYWdyZWVtZW50DQpiZXR3ZWVuIHRo
ZSBjdXJyZW50IEFSIGFuZCBpdHMgcGh5c2ljYWwgbmVpZ2hib3IgaW4gb3JkZXIgdG8gYWxsb3cN
Ck1OJ3MgaGFuZG9mZiBiZXR3ZWVuIHRoZW0uIFRoZSB2YXJpb3VzIGNhcGFiaWxpdGllcyB0aGF0
IG5lZWQgdG8gYmUNCmlkZW50aWZpZWQgaW4gUEFBUiBmb3Igc21vb3RoIGhhbmRvZmYgYXJlIG91
dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMNCmRyYWZ0LiBIb3dldmVyLCBhcyBhbiBpbGx1c3RyYXRp
b24sIHRoZSBjYXBhYmlsaXRpZXMgdG8gYmUgaWRlbnRpZmllZA0KbWF5IGluY2x1ZGUgYWRtaW5p
c3RyYXRpdmUgcGFyYW1ldGVycyBzdWNoIGFzIElTUCwgb3JnYW5pemF0aW9uIGFuZA0KcG9saWN5
IGluZm9ybWF0aW9uOyBjb3N0IG9mIGFjY2VzcyBwYXJhbWV0ZXJzOyBpbmZvcm1hdGlvbiBhYm91
dA0KcmFkaW8gaW50ZXJmYWNlczsgaW5mb3JtYXRpb24gYWJvdXQgYXZhaWxhYmlsaXR5IG9mIGFu
eSBhcHBsaWNhdGlvbg0KbG9naWMgc3VjaCBhcyBtdWx0aWNhc3Qgc3VwcG9ydCwgaGVhZGVyIGNv
bXByZXNzaW9uIGNhcGFiaWxpdHksDQpwbGF5b3V0IGJ1ZmZlciBob3N0aW5nIGZvciBzdHJlYW1p
bmcgYXBwbGljYXRpb25zLCBUQ1AgUEVQcyBhbmQgbWVkaWENCnRyYW5zY29kaW5nIGZ1bmN0aW9u
YWxpdHk7IEludGVybmV0IGNvbm5lY3Rpdml0eSBwYXJhbWV0ZXJzIHN1Y2ggYXMNCg0KVHJvc3Nl
biwgS3Jpc2huYW11cnRoaSwgQ2hhc2thciwgS2VtcGYgICAgICAgICAgICAgICAgICAgICAgIFtQ
YWdlIDRdDQoMDQpJTlRFUk5FVC1EUkFGVCAgQ2FuZGlkYXRlIEFjY2VzcyBSb3V0ZXIgRGlzY292
ZXJ5IElzc3VlcyAgIEp1bHksIDIwMDENCg0KDQpuZWVkIGZvciBOQVQgdHJhdmVyc2FsOyByZXNv
dXJjZSBwYXJhbWV0ZXJzIHN1Y2ggYXMgbG9hZCBhbmQgc28gb24uDQoNCkluIHRoZSBBbnRpY2lw
YXRlZCBDQVIgRGlzY292ZXJ5LCBjYXBhYmlsaXR5IGV4Y2hhbmdlIGJldHdlZW4gQVJzDQpvY2N1
cnMgb3ZlciB0aGUgSW50ZXJuZXQuIFRodXMsIGEgcHJvdG9jb2wgaXMgbmVlZGVkIHRoYXQgd291
bGQgYWxsb3cNCkFScyB0byBleGNoYW5nZSBjYXBhYmlsaXR5IGluZm9ybWF0aW9uLg0KDQpJbiB0
aGUgRHluYW1pYyBDQVIgRGlzY292ZXJ5IGFwcHJvYWNoLCB0aGUgTU4gaXMgc29saWNpdGluZyBv
cg0KcmVjZWl2aW5nIHRoZSBjYXBhYmlsaXRpZXMgb2YgUEFBUnMgZGlyZWN0bHkuIFNvbWUgcHJv
dG9jb2wgaXMNCnJlcXVpcmVkIHRvIGFsbG93IHRoZSBNTiB0byBzb2xpY2l0LCBvciB0aGUgQVJz
IHRvIGFkdmVydGlzZSB0aGVpcg0KY2FwYWJpbGl0aWVzLg0KDQo0LjMgU2VjdXJpdHkgY29uc2lk
ZXJhdGlvbnMNCg0KQVIgZGlzY292ZXJ5IG1heSBhbGxvdyBvdGhlciBub2RlcyB0byBsZWFybiB0
aGUgZm9sbG93aW5nIHBpZWNlcyBvZg0KaW5mb3JtYXRpb24gYWJvdXQgYW4gQVI6DQoNCi0gUGh5
c2ljYWwgbG9jYXRpb24NCi0gQ2FwYWJpbGl0aWVzDQotIFN0YXRlIG9mIGNhcGFiaWxpdGllcy4N
Cg0KTWFsaWNpb3VzIG5vZGVzIG1heSB1c2UgdGhpcyBraW5kIG9mIGluZm9ybWF0aW9uIHRvIGxh
dW5jaCBhdHRhY2tzIG9mDQp0aGUgRG9TLXN0eWxlIGFuZC9vciBzZXJ2aWNlIGhpamFja2luZy4g
VGhlcmVmb3JlLCB0aGUgZm9sbG93aW5nDQp0b3BpY3Mgc2hvdWxkIGJlIGNvdmVyZWQgaW4gYW55
IHByb3RvY29sIGRldmVsb3BlZCBmb3IgQVIgZGlzY292ZXJ5Og0KDQotIEF1dGhlbnRpY2F0aW9u
IG9mIG5vZGVzDQotIFNlY3VyaXR5IGFzc29jaWF0aW9ucyBiZXR3ZWVuIG5vZGVzDQotIE1lc3Nh
Z2UvcGF5bG9hZCBlbmNyeXB0aW9uLg0KDQoNCjUuIFJFRkVSRU5DRVMNCg0KWzFdIElQIE1vYmls
aXR5IFN1cHBvcnQsIEMuIFBlcmtpbnMgKEVkaXRvciksIFJGQyAyMDAyLCBPY3RvYmVyIDE5OTYu
DQoNClsyXSBNb2JpbGl0eSBTdXBwb3J0IGluIElQdjYsIEQuIEpvaG5zb24gYW5kIEMuIFBlcmtp
bnMsDQogICAgZHJhZnQtaWV0Zi1tb2JpbGVpcC1pcHY2LTEzLnR4dCwNCiAgICB3b3JrIGluIHBy
b2dyZXNzLCBOb3ZlbWJlciAyMDAwLg0KDQpbM10gTG93IExhdGVuY3kgSGFuZG9mZnMgaW4gTW9i
aWxlIElQdjQsIE1JUHY0IEhhbmRvZmZzIERlc2lnbiBUZWFtLA0KICAgIGRyYWZ0LWlldGYtbW9i
aWxlaXAtbG93bGF0ZW5jeS1oYW5kb2Zmcy12NC0wMC50eHQsDQogICAgd29yayBpbiBwcm9ncmVz
cywgRmVicnVhcnkgMjAwMS4NCg0KWzRdIEZhc3QgaGFuZG9mZnMgZm9yIE1vYmlsZSBJUHY2LCBN
SVB2NiBoYW5kb2ZmIERlc2lnbiBUZWFtLA0KICAgIGRyYWZ0LWlldGYtbW9iaWxlaXAtZmFzdC1t
aXB2Ni0wMS50eHQsDQogICAgd29yayBpbiBwcm9ncmVzcywgQXByaWwgMjAwMS4NCg0KWzVdIFBy
b2JsZW0gRGVzY3JpcHRpb246IFJlYXNvbnMgRm9yIFBlcmZvcm1pbmcgQ29udGV4dCBUcmFuc2Zl
cnMNCiAgICBCZXR3ZWVuIE5vZGVzIGluIGFuIElQIEFjY2VzcyBOZXR3b3JrLCBPLiBILiBMZXZr
b3dldHogZXQuIGFsLiwNCiAgICBkcmFmdC1pZXRmLXNlYW1vYnktY29udGV4dC10cmFuc2Zlci1w
cm9ibGVtLXN0YXQtMDEuZG9jLA0KICAgIHdvcmsgaW4gcHJvZ3Jlc3MsIE1heSAyMDAxLg0KDQoN
Cg0KVHJvc3NlbiwgS3Jpc2huYW11cnRoaSwgQ2hhc2thciwgS2VtcGYgICAgICAgICAgICAgICAg
ICAgICAgIFtQYWdlIDVdDQoMDQpJTlRFUk5FVC1EUkFGVCAgQ2FuZGlkYXRlIEFjY2VzcyBSb3V0
ZXIgRGlzY292ZXJ5IElzc3VlcyAgIEp1bHksIDIwMDENCg0KDQpbNl0gR2VuZXJhbCByZXF1aXJl
bWVudHMgZm9yIGEgY29udGV4dCB0cmFuc2ZlciBmcmFtZXdvcmssIEguIFNheWVkDQogICAgZXQu
IGFsLiwgZHJhZnQtaWV0Zi1zZWFtb2J5LWN0LXJlcXMtMDAudHh0LCANCiAgICB3b3JrIGluIHBy
b2dyZXNzLCBNYXkgMjAwMS4NCg0KWzddIEJ1ZmZlciBNYW5hZ2VtZW50IGZvciBTbW9vdGggaGFu
ZG9mZnMgaW4gTW9iaWxlIElQdjYsDQogICAgRy4gS3Jpc2huYW11cnRoaSwgUi4gQ2hhbG1lcnMs
IGFuZCBDLiBQZXJraW5zLA0KICAgIGRyYWZ0LWtyaXNobmFtdXJ0aGktbW9iaWxlaXAtYnVmZmVy
Ni0wMS50eHQsDQogICAgd29yayBpbiBwcm9ncmVzcywgTWFyY2ggMjAwMS4NCg0KDQo2LiBBVVRI
T1JTJyBBRERSRVNTDQoNCkRpcmsgVHJvc3Nlbg0KQ29tbXVuaWNhdGlvbiBTeXN0ZW1zIExhYm9y
YXRvcnksIE5va2lhIFJlc2VhcmNoIENlbnRlcg0KNSBXYXlzaWRlIFJvYWQNCkJ1cmxpbmd0b24s
IE1BIDAxODAzLCBVU0ENCg0KUGhvbmU6ICArMSA3ODEgOTkzIDM2MDUNCkZheDogICsxIDc4MSA5
OTMgMTkwNw0KRS1tYWlsOiAgZGlyay50cm9zc2VuQG5va2lhLmNvbQ0KDQoNCkdvdmluZCBLcmlz
aG5hbXVydGhpDQpDb21tdW5pY2F0aW9uIFN5c3RlbXMgTGFib3JhdG9yeSwgTm9raWEgUmVzZWFy
Y2ggQ2VudGVyDQo1IFdheXNpZGUgUm9hZA0KQnVybGluZ3RvbiwgTUEgMDE4MDMsIFVTQQ0KDQpQ
aG9uZTogICsxIDc4MSA5OTMgMzYyNw0KRmF4OiAgKzEgNzgxIDk5MyAxOTA3DQpFLW1haWw6ICBn
b3ZpbmQua3Jpc2huYW11cnRoaUBub2tpYS5jb20NCg0KDQpIZW1hbnQgQ2hhc2thcg0KQ29tbXVu
aWNhdGlvbiBTeXN0ZW1zIExhYm9yYXRvcnksIE5va2lhIFJlc2VhcmNoIENlbnRlcg0KNSBXYXlz
aWRlIFJvYWQNCkJ1cmxpbmd0b24sIE1BIDAxODAzLCBVU0ENCg0KUGhvbmU6ICArMSA3ODEgOTkz
IDM3ODUNCkZheDogICsxIDc4MSA5OTMgMTkwNw0KRS1tYWlsOiAgaGVtYW50LmNoYXNrYXJAbm9r
aWEuY29tDQoNCg0KSmFtZXMgS2VtcGYNCk5ldHdvcmsgYW5kIFNlY3VyaXR5IFJlc2VhcmNoIENl
bnRlciwgU3VuIExhYnMNClN1biBNaWNyb3N5c3RlbXMsIEluYy4NCjE1IE5ldHdvcmsgQ2lyY2xl
DQpNZW5sbyBQYXJrLCBDQSA5NDAyNSwgVVNBDQoNClBob25lOiAgKzEgNjUwIDc4NiA1ODkwDQpG
YXg6ICArMSA2NTAgNzg2IDY0NDUNCkUtbWFpbDogIGphbWVzLmtlbXBmQGVuZy5zdW4uY29tDQoN
ClRyb3NzZW4sIEtyaXNobmFtdXJ0aGksIENoYXNrYXIsIEtlbXBmICAgICAgICAgICAgICAgICAg
ICAgICBbUGFnZSA2XQ0KDA==

------_=_NextPart_001_01C10BAA.D216A5D0--


From owner-seamoby@diameter.org  Fri Jul 13 11:08:54 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20320
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 11:08:49 -0400 (EDT)
Received: (qmail 25336 invoked by alias); 13 Jul 2001 14:39:20 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 25329 invoked by uid 200); 13 Jul 2001 14:39:19 -0000
Received: (qmail 25320 invoked from network); 13 Jul 2001 14:39:15 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 14:39:15 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6DEnHb07288
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 10:49:17 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Fri, 13 Jul 2001 10:49:17 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ25LWS>; Fri, 13 Jul 2001 10:49:18 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E42@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: seamoby <seamoby@cdma-2000.org>
Cc: "john.loughney" <john.loughney@nokia.com>
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
         Phase CT
Date: Fri, 13 Jul 2001 10:48:23 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10BAA.DDB929D0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10BAA.DDB929D0
Content-Type: text/plain;
	charset="iso-8859-1"

I'm not sure that this is relevant, but there is a difference between
the requirement for multi-phasic ct, and proactive/reactive. The latter
are modes of operation - really just attempts at trying to characterize
when ct happens relative to ho (without being technology specific).

Multiphasic ct says you perform the ct over a number of transfers, and
use some method of prioritization to determine the order of context 
transfer.

There seems to be controversy around both, but they are separate issues.

Appologies if this was already obvious to everyone.

Gary

-----Original Message-----
From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
Sent: Thursday, July 12, 2001 3:39 PM
To: seamoby
Cc: john.loughney
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for
Mu lti- Phase CT


Ooh, well put, John.

	Best, Henrik

John Loughney wrote:
> 
> Hi Pat,
> 
> > I think that two phases are needed, regardless of the MTU size. I
> > believe that in order to achieve a seamless handoff, it is necessary
> > to transfer time sensitive context blobs as soon as possible (e.g.
> > header compression, L2 keying info, L3 SAs). These are necessary
> > in order to exchange packets with the mobile, but there may be other
> > time sensitive blobs that I haven't thought of as well. 
> > Non-time sensitive blobs (e.g. accounting session id) are not needed 
> > to send/receive packets and therefore do not need to be sent right away.
> 
> I think that discussing of phases is leading us to a dead end.  What
> we need is the following behavior:
> 
> 1) Ability to send time-critical context
> 2) Ability to discard stale context
> 3) Ability to synchronize the context transfer with an additional
>    procedure (like a handover)
> 4) Ability to use different triggers to start the transfer of some 
>    contexts.
> 5) Ability to acknowledge the transfer of some contexts.
> 6) Ability to group or send seperately contexts.
> 
> My feeling is that when we group the behaviors, we may get the different
> phases - but I think that there may be more than just 2 phases of 
> CT.  Actually, the above behaviors may depend upon the type context
> being transfered.  As we have not identified all the possible types
> of context to be transfered and all of the situations, I don't
> believe that discussing the phases (or modes) of context transfer
> is a good idea currently.
> 
> I'm writing up an issue on this right now.  I'm happy to contribute
> text.
> 
> Comments?
> John
> 
> 

------_=_NextPart_001_01C10BAA.DDB929D0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti-  Phase CT</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>I'm not sure that this is relevant, but there is a difference between</FONT>
<BR><FONT SIZE=2>the requirement for multi-phasic ct, and proactive/reactive. The latter</FONT>
<BR><FONT SIZE=2>are modes of operation - really just attempts at trying to characterize</FONT>
<BR><FONT SIZE=2>when ct happens relative to ho (without being technology specific).</FONT>
</P>

<P><FONT SIZE=2>Multiphasic ct says you perform the ct over a number of transfers, and</FONT>
<BR><FONT SIZE=2>use some method of prioritization to determine the order of context </FONT>
<BR><FONT SIZE=2>transfer.</FONT>
</P>

<P><FONT SIZE=2>There seems to be controversy around both, but they are separate issues.</FONT>
</P>

<P><FONT SIZE=2>Appologies if this was already obvious to everyone.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Henrik Levkowetz [<A HREF="mailto:henrik@levkowetz.com">mailto:henrik@levkowetz.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: Thursday, July 12, 2001 3:39 PM</FONT>
<BR><FONT SIZE=2>To: seamoby</FONT>
<BR><FONT SIZE=2>Cc: john.loughney</FONT>
<BR><FONT SIZE=2>Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for</FONT>
<BR><FONT SIZE=2>Mu lti- Phase CT</FONT>
</P>
<BR>

<P><FONT SIZE=2>Ooh, well put, John.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Best, Henrik</FONT>
</P>

<P><FONT SIZE=2>John Loughney wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hi Pat,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; I think that two phases are needed, regardless of the MTU size. I</FONT>
<BR><FONT SIZE=2>&gt; &gt; believe that in order to achieve a seamless handoff, it is necessary</FONT>
<BR><FONT SIZE=2>&gt; &gt; to transfer time sensitive context blobs as soon as possible (e.g.</FONT>
<BR><FONT SIZE=2>&gt; &gt; header compression, L2 keying info, L3 SAs). These are necessary</FONT>
<BR><FONT SIZE=2>&gt; &gt; in order to exchange packets with the mobile, but there may be other</FONT>
<BR><FONT SIZE=2>&gt; &gt; time sensitive blobs that I haven't thought of as well. </FONT>
<BR><FONT SIZE=2>&gt; &gt; Non-time sensitive blobs (e.g. accounting session id) are not needed </FONT>
<BR><FONT SIZE=2>&gt; &gt; to send/receive packets and therefore do not need to be sent right away.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I think that discussing of phases is leading us to a dead end.&nbsp; What</FONT>
<BR><FONT SIZE=2>&gt; we need is the following behavior:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 1) Ability to send time-critical context</FONT>
<BR><FONT SIZE=2>&gt; 2) Ability to discard stale context</FONT>
<BR><FONT SIZE=2>&gt; 3) Ability to synchronize the context transfer with an additional</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; procedure (like a handover)</FONT>
<BR><FONT SIZE=2>&gt; 4) Ability to use different triggers to start the transfer of some </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; contexts.</FONT>
<BR><FONT SIZE=2>&gt; 5) Ability to acknowledge the transfer of some contexts.</FONT>
<BR><FONT SIZE=2>&gt; 6) Ability to group or send seperately contexts.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; My feeling is that when we group the behaviors, we may get the different</FONT>
<BR><FONT SIZE=2>&gt; phases - but I think that there may be more than just 2 phases of </FONT>
<BR><FONT SIZE=2>&gt; CT.&nbsp; Actually, the above behaviors may depend upon the type context</FONT>
<BR><FONT SIZE=2>&gt; being transfered.&nbsp; As we have not identified all the possible types</FONT>
<BR><FONT SIZE=2>&gt; of context to be transfered and all of the situations, I don't</FONT>
<BR><FONT SIZE=2>&gt; believe that discussing the phases (or modes) of context transfer</FONT>
<BR><FONT SIZE=2>&gt; is a good idea currently.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I'm writing up an issue on this right now.&nbsp; I'm happy to contribute</FONT>
<BR><FONT SIZE=2>&gt; text.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Comments?</FONT>
<BR><FONT SIZE=2>&gt; John</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10BAA.DDB929D0--


From owner-seamoby@diameter.org  Fri Jul 13 11:37:55 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA24518
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 11:37:54 -0400 (EDT)
Received: (qmail 26528 invoked by alias); 13 Jul 2001 15:26:37 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26522 invoked by uid 200); 13 Jul 2001 15:26:37 -0000
Received: (qmail 26517 invoked from network); 13 Jul 2001 15:26:35 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 15:26:35 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1KPH8>; Fri, 13 Jul 2001 11:36:50 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484455A1@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Govind.Krishnamurthi@nokia.com'" <Govind.Krishnamurthi@nokia.com>,
        mobile-ip@sunroof.eng.sun.com
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router 
	Discovery
Date: Fri, 13 Jul 2001 11:36:46 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Amazing.  I am stunned.  Great start!  More useful comments
later...  One comment right now is that I have a candidate
algorithm in mind (:-)), also I am again finding it difficult
to see how this will work with macro-diversity since you may
want to have legs across ARs in different ADs but more on that
later.  

This draft moves MIP from blind faith to "enlightenment"
a mobility renaissance is under way in the MIP WG!!!

> -----Original Message-----
> From: Govind.Krishnamurthi@nokia.com
> [mailto:Govind.Krishnamurthi@nokia.com]
> 
> Abstract:
> Handoff in IP mobility protocols involves moving a mobile node's
> Layer 3 routing reachability information from one access router to
> another, before or after the mobile node has established a Layer 2
> connection with the radio access point that is covered by the new
> access router. In addition, other context information about the
> mobile node's packet session may be transferred from the old access
> router to the new one, in order to minimize the service disruption
> during the handoff process. While the exact details of how this is
> accomplished vary depending on the IP mobility and seamless handoff
> protocols, one common thread required for seamless handoffs is
> identifying the candidate access routers for the mobile node's
> handoff. When a collection of candidates has been identified, an
> algorithm is run to determine the target access router, and this
> router becomes the target of handoff at Layer 3. This document
> presents a problem statement describing issues involved in designing
> a candidate access router discovery protocol. The document does not
> discuss the algorithm by which the actual target router is
> identified, nor how the handoff to the target is achieved.

> 


From owner-seamoby@diameter.org  Fri Jul 13 11:58:01 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27572
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 11:57:58 -0400 (EDT)
Received: (qmail 27083 invoked by alias); 13 Jul 2001 15:46:31 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27077 invoked by uid 200); 13 Jul 2001 15:46:30 -0000
Received: (qmail 27072 invoked from network); 13 Jul 2001 15:46:29 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 15:46:29 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA09244;
	Fri, 13 Jul 2001 08:57:18 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA11055;
	Fri, 13 Jul 2001 08:56:47 -0700 (PDT)
Message-Id: <200107131556.IAA11055@heliopolis.eng.sun.com>
Date: Fri, 13 Jul 2001 08:56:46 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [seamoby] CT trigger/completion
To: Madjid.Nakhjiri@motorola.com, gyj@isl.stanford.edu
Cc: seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: QicJycWhipXsCXshyCvrUw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Youngjune,

I think it should be possible to tunnel packets to nAR w.o. context
transfer. Context transfer is an optimization, so that, when
the packets get to nAR, they can be delivered faster to the
MN.

		jak
		
>Delivered-To: seamoby-list@charizard.diameter.org
>Date: Thu, 12 Jul 2001 17:28:43 -0700 (PDT)
>From: Youngjune Lee Gwon <gyj@dcl.docomo-usa.com>
>X-Sender: gyj@fridge.docomo-usa.com
>To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
>cc: seamoby@cdma-2000.org
>Subject: [seamoby] CT trigger/completion
>
>Hi,
>
>This is a quick question regarding CT trigger/completion debate.
>
>Consider if a MN is receiving IP packets from nAR, and the packets are
>forwarded (tunneled, e.g. BETH) from the oAR. Are forwarded packets
>(CN->oAR->nAR->MN) OK without CT between oAR and nAR? Or, do they still
>require that CT should be completed at nAR by the time MN is receiving
>them from nAR?
>
>My understanding is that CT does not have to be completed at nAR if
>packets are tunneled from oAR. And, oAR can support MN's IP
>micro-flow because context info is still there at oAR. Correct?
>
>Youngjune
>
>
>On Thu, 12 Jul 2001, Nakhjiri Madjid-MNAKHJI1 wrote:
>
>> 
>> 
>> -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
>> 
>> Madjid>> James, the timer makes sense, however, the time to live
>> for each context depends on the feature that the context belongs 
>> too, maybe such a time to live can be added to the context packets.
>> Having a universal time to live for all types of context is not
>> very precise.
>> 
>> Madjid
>> 
>



From owner-seamoby@diameter.org  Fri Jul 13 12:35:12 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03143
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 12:35:10 -0400 (EDT)
Received: (qmail 27695 invoked by alias); 13 Jul 2001 16:23:44 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27690 invoked by uid 200); 13 Jul 2001 16:23:44 -0000
Received: (qmail 27685 invoked from network); 13 Jul 2001 16:23:42 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 16:23:42 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA26906;
	Fri, 13 Jul 2001 09:34:34 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA12932;
	Fri, 13 Jul 2001 09:34:34 -0700 (PDT)
Message-Id: <200107131634.JAA12932@heliopolis.eng.sun.com>
Date: Fri, 13 Jul 2001 09:34:34 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router  Discovery
To: Govind.Krishnamurthi@nokia.com, mobile-ip@sunroof.eng.sun.com,
        PNeumiller@MeshNetworks.com
Cc: seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: DgI4Au/+4HvwInDp1XKmDQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Phil,

Thanx for the positive comments.

Regarding macrodiversity, I tend to look at it as an L2 issue. I know
that in the past you've expressed a view that it can be upleveled
to IP, but I'm not exactly clear what benefit that might have, especially
since packet sizes in IP are large and variable.

If you look at it that way, it falls more into the purview of the
pwe3 working group. I've been wanting to tune in there and see whether
it might not be possible to get some work going for cellular RANs, 
but have simply not had the time.

Looking forward to seeing your protocol for CAR discovery.

		jak

>Delivered-To: seamoby-list@charizard.diameter.org
>From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
>To: "'Govind.Krishnamurthi@nokia.com'" <Govind.Krishnamurthi@nokia.com>, 
mobile-ip@sunroof.eng.sun.com
>Cc: seamoby@cdma-2000.org
>Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router  
Discovery
>Date: Fri, 13 Jul 2001 11:36:46 -0400
>
>Amazing.  I am stunned.  Great start!  More useful comments
>later...  One comment right now is that I have a candidate
>algorithm in mind (:-)), also I am again finding it difficult
>to see how this will work with macro-diversity since you may
>want to have legs across ARs in different ADs but more on that
>later.  
>
>This draft moves MIP from blind faith to "enlightenment"
>a mobility renaissance is under way in the MIP WG!!!
>
>> -----Original Message-----
>> From: Govind.Krishnamurthi@nokia.com
>> [mailto:Govind.Krishnamurthi@nokia.com]
>> 
>> Abstract:
>> Handoff in IP mobility protocols involves moving a mobile node's
>> Layer 3 routing reachability information from one access router to
>> another, before or after the mobile node has established a Layer 2
>> connection with the radio access point that is covered by the new
>> access router. In addition, other context information about the
>> mobile node's packet session may be transferred from the old access
>> router to the new one, in order to minimize the service disruption
>> during the handoff process. While the exact details of how this is
>> accomplished vary depending on the IP mobility and seamless handoff
>> protocols, one common thread required for seamless handoffs is
>> identifying the candidate access routers for the mobile node's
>> handoff. When a collection of candidates has been identified, an
>> algorithm is run to determine the target access router, and this
>> router becomes the target of handoff at Layer 3. This document
>> presents a problem statement describing issues involved in designing
>> a candidate access router discovery protocol. The document does not
>> discuss the algorithm by which the actual target router is
>> identified, nor how the handoff to the target is achieved.
>
>> 



From owner-seamoby@diameter.org  Fri Jul 13 12:51:59 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05661
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 12:51:57 -0400 (EDT)
Received: (qmail 28245 invoked by alias); 13 Jul 2001 16:40:22 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28239 invoked by uid 200); 13 Jul 2001 16:40:22 -0000
Received: (qmail 28234 invoked from network); 13 Jul 2001 16:40:20 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 16:40:20 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA21034;
	Fri, 13 Jul 2001 09:50:42 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6DGog107738;
	Fri, 13 Jul 2001 09:50:42 -0700
X-mProtect:  Fri, 13 Jul 2001 09:50:42 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdutsQol; Fri, 13 Jul 2001 09:50:41 PDT
Message-ID: <3B4F26E1.3B052FD2@iprg.nokia.com>
Date: Fri, 13 Jul 2001 09:50:41 -0700
From: Theo Pagtzis <tpagtzis@IPRG.nokia.com>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: john.loughney@nokia.com
CC: seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
 Phase CT
References: <0C1353ABB1DEB74DB067ADFF749C4EEF094050@esebe004.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi John,

   Appreciated! If you go to

http://www.cs.ucl.ac.uk/staff/t.pagtzis/docs/docs.html

you should be able to also find the postscript version which gives all the
schematics to facilitate clearer understanding..

As for the association ID you are right. It is imperative that when you
exchange context information you want to avoid sending back and forth
addresses that are that long. It is best to associate the context with the
best possible factoring design with a unique identifier. This way you would
save so much more bandwidth but admittedly the AR would need to work a little
harder. That is the price of a trade of. We cannot have it all unless you try
to compress signaling (hifi).

This is why I associated the roaming context signaling with what I call in the
draft an SCoA identifier that avoids the sending back and forth of addresses
(next draft version will  optimize on that also)

Cheers

Theo



john.loughney@nokia.com wrote:

> Hi Theo,
>
> >   Your example is very similar to what we are proposing in
> > the proactive mobility draft
> >
> > draft-pagtzis-mobileip-proactivev6-00.txt/.ps
>
> I've printed this out - but it'll take some time
> to digest all of this.
>
> >     I have a slight reservation about the term used here
> > though. It sounds to me that it is not syncronisation that
> > is effected, since for that MN the new AR will received the
> > context superset once and that is it. There is no
> > continuous streaming of context (even 'multiplexed' ) where
> > the MN needs to syncronize in the strict sense of syncronisation.
> >
> > It simply enables connectivity with the proactive forwarding of the
> > context; isn't that the case you refer to ?
>
> Exactly - all I meant by the term was that context would be connected
> or associated with a handoff.  Let's call it association id.
>
> I think in the protocol design phase, we can work out the specific details.
>
> In solution space, I would use a 32-bit integer that could be used in
> both CTP and the MIP handoff signaling messages.  The new AR can use
> a hash of the association id and the IP address who sent it to save
> the context, so that when a HO is completed, the new AR can easily
> retrieve the context.
>
> br,
> John



From owner-seamoby@diameter.org  Fri Jul 13 13:05:54 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07525
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 13:05:52 -0400 (EDT)
Received: (qmail 28772 invoked by alias); 13 Jul 2001 16:53:34 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28766 invoked by uid 200); 13 Jul 2001 16:53:34 -0000
Received: (qmail 28761 invoked from network); 13 Jul 2001 16:53:31 -0000
Received: from netmail2.alcatel.com (128.251.168.51)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 16:53:31 -0000
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id MAA02497;
	Fri, 13 Jul 2001 12:04:23 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6DH4N006516;
	Fri, 13 Jul 2001 12:04:23 -0500 (CDT)
Message-ID: <3B4F2A46.44626A68@usa.alcatel.com>
Date: Fri, 13 Jul 2001 12:05:10 -0500
From: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: mobile-ip@sunroof.eng.sun.com
CC: Govind.Krishnamurthi@nokia.com, PNeumiller@MeshNetworks.com,
        seamoby@cdma-2000.org
Subject: Re: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidate 
 Access Router  Discovery
References: <200107131634.JAA12932@heliopolis.eng.sun.com>
Content-Type: multipart/alternative;
 boundary="------------2EF20710B1BF3CBE7F983F22"
Sender: owner-seamoby@diameter.org
Precedence: bulk


--------------2EF20710B1BF3CBE7F983F22
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Jim,
  Has this work been triggered by an email from Micheal Tanis?
Since router discovery is of routing area, does your draft fall in seamoby 's
charter?

Just asking.

James Kempf wrote:

> Phil,
>
> Thanx for the positive comments.
>
> Regarding macrodiversity, I tend to look at it as an L2 issue. I know
> that in the past you've expressed a view that it can be upleveled
> to IP, but I'm not exactly clear what benefit that might have, especially
> since packet sizes in IP are large and variable.
>
> If you look at it that way, it falls more into the purview of the
> pwe3 working group. I've been wanting to tune in there and see whether
> it might not be possible to get some work going for cellular RANs,
> but have simply not had the time.
>
> Looking forward to seeing your protocol for CAR discovery.
>
>                 jak
>
> >Delivered-To: seamoby-list@charizard.diameter.org
> >From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
> >To: "'Govind.Krishnamurthi@nokia.com'" <Govind.Krishnamurthi@nokia.com>,
> mobile-ip@sunroof.eng.sun.com
> >Cc: seamoby@cdma-2000.org
> >Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router
> Discovery
> >Date: Fri, 13 Jul 2001 11:36:46 -0400
> >
> >Amazing.  I am stunned.  Great start!  More useful comments
> >later...  One comment right now is that I have a candidate
> >algorithm in mind (:-)), also I am again finding it difficult
> >to see how this will work with macro-diversity since you may
> >want to have legs across ARs in different ADs but more on that
> >later.
> >
> >This draft moves MIP from blind faith to "enlightenment"
> >a mobility renaissance is under way in the MIP WG!!!
> >
> >> -----Original Message-----
> >> From: Govind.Krishnamurthi@nokia.com
> >> [mailto:Govind.Krishnamurthi@nokia.com]
> >>
> >> Abstract:
> >> Handoff in IP mobility protocols involves moving a mobile node's
> >> Layer 3 routing reachability information from one access router to
> >> another, before or after the mobile node has established a Layer 2
> >> connection with the radio access point that is covered by the new
> >> access router. In addition, other context information about the
> >> mobile node's packet session may be transferred from the old access
> >> router to the new one, in order to minimize the service disruption
> >> during the handoff process. While the exact details of how this is
> >> accomplished vary depending on the IP mobility and seamless handoff
> >> protocols, one common thread required for seamless handoffs is
> >> identifying the candidate access routers for the mobile node's
> >> handoff. When a collection of candidates has been identified, an
> >> algorithm is run to determine the target access router, and this
> >> router becomes the target of handoff at Layer 3. This document
> >> presents a problem statement describing issues involved in designing
> >> a candidate access router discovery protocol. The document does not
> >> discuss the algorithm by which the actual target router is
> >> identified, nor how the handoff to the target is achieved.
> >
> >>

--
Behcet

--------------2EF20710B1BF3CBE7F983F22
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi Jim,
<br>&nbsp; Has this work been triggered by an email from Micheal Tanis?
<br>Since <font size=+3>router </font>discovery is of routing area, does
your draft fall in seamoby 's charter?
<p>Just asking.
<p>James Kempf wrote:
<blockquote TYPE=CITE>Phil,
<p>Thanx for the positive comments.
<p>Regarding macrodiversity, I tend to look at it as an L2 issue. I know
<br>that in the past you've expressed a view that it can be upleveled
<br>to IP, but I'm not exactly clear what benefit that might have, especially
<br>since packet sizes in IP are large and variable.
<p>If you look at it that way, it falls more into the purview of the
<br>pwe3 working group. I've been wanting to tune in there and see whether
<br>it might not be possible to get some work going for cellular RANs,
<br>but have simply not had the time.
<p>Looking forward to seeing your protocol for CAR discovery.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
jak
<p>>Delivered-To: seamoby-list@charizard.diameter.org
<br>>From: Phillip Neumiller &lt;PNeumiller@MeshNetworks.com>
<br>>To: "'Govind.Krishnamurthi@nokia.com'" &lt;Govind.Krishnamurthi@nokia.com>,
<br>mobile-ip@sunroof.eng.sun.com
<br>>Cc: seamoby@cdma-2000.org
<br>>Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access
Router
<br>Discovery
<br>>Date: Fri, 13 Jul 2001 11:36:46 -0400
<br>>
<br>>Amazing.&nbsp; I am stunned.&nbsp; Great start!&nbsp; More useful
comments
<br>>later...&nbsp; One comment right now is that I have a candidate
<br>>algorithm in mind (:-)), also I am again finding it difficult
<br>>to see how this will work with macro-diversity since you may
<br>>want to have legs across ARs in different ADs but more on that
<br>>later.
<br>>
<br>>This draft moves MIP from blind faith to "enlightenment"
<br>>a mobility renaissance is under way in the MIP WG!!!
<br>>
<br>>> -----Original Message-----
<br>>> From: Govind.Krishnamurthi@nokia.com
<br>>> [<a href="mailto:Govind.Krishnamurthi@nokia.com">mailto:Govind.Krishnamurthi@nokia.com</a>]
<br>>>
<br>>> Abstract:
<br>>> Handoff in IP mobility protocols involves moving a mobile node's
<br>>> Layer 3 routing reachability information from one access router
to
<br>>> another, before or after the mobile node has established a Layer
2
<br>>> connection with the radio access point that is covered by the new
<br>>> access router. In addition, other context information about the
<br>>> mobile node's packet session may be transferred from the old access
<br>>> router to the new one, in order to minimize the service disruption
<br>>> during the handoff process. While the exact details of how this
is
<br>>> accomplished vary depending on the IP mobility and seamless handoff
<br>>> protocols, one common thread required for seamless handoffs is
<br>>> identifying the candidate access routers for the mobile node's
<br>>> handoff. When a collection of candidates has been identified, an
<br>>> algorithm is run to determine the target access router, and this
<br>>> router becomes the target of handoff at Layer 3. This document
<br>>> presents a problem statement describing issues involved in designing
<br>>> a candidate access router discovery protocol. The document does
not
<br>>> discuss the algorithm by which the actual target router is
<br>>> identified, nor how the handoff to the target is achieved.
<br>>
<br>>></blockquote>

<p>--
<br>Behcet</html>

--------------2EF20710B1BF3CBE7F983F22--



From owner-seamoby@diameter.org  Fri Jul 13 13:10:26 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08269
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 13:10:24 -0400 (EDT)
Received: (qmail 29249 invoked by alias); 13 Jul 2001 16:58:07 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 29235 invoked by uid 200); 13 Jul 2001 16:58:06 -0000
Received: (qmail 29222 invoked from network); 13 Jul 2001 16:58:01 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 16:58:01 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA22128;
	Fri, 13 Jul 2001 10:08:22 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6DH8Lx03508;
	Fri, 13 Jul 2001 10:08:21 -0700
X-mProtect:  Fri, 13 Jul 2001 10:08:21 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdY1nROf; Fri, 13 Jul 2001 10:08:19 PDT
Message-ID: <3B4F2B04.157F3F97@iprg.nokia.com>
Date: Fri, 13 Jul 2001 10:08:20 -0700
From: Theo Pagtzis <tpagtzis@IPRG.nokia.com>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: "Govind.Krishnamurthi" <Govind.Krishnamurthi@nokia.com>
CC: mobile-ip <mobile-ip@sunroof.eng.sun.com>, seamoby <seamoby@cdma-2000.org>,
        seamoby-context <seamoby-context@cdma-2000.org>
Subject: [seamoby] Re: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router 
 Discovery
References: <B9CFA6CE8FFDD211A1FB0008C7894E460440DE01@bseis01nok>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Govind,

    I have already provided a detailed protocol on pessimistic and optimistic proactivity in
terms of router neighbour determination and candidacy. Please see
draft-pagtzis-mobileip-proactivev6-00.txt/.ps

I have also gone a long way in specifying the notions of mobility and routing neighbourhood as well as
provide an algorithm for their determination.

My proactive mobility scheme contains as part of it, exactly what you are describing as very briefly as
physical neighbourhood and its mapping to a routing neighbourhood. There are however much more issues that
are not elaborated in the targer AR determination. These are also covered in the draft on proactive mobility.

Also what is the date of your submission? Here your draft says it is July 2001. But what day?


Theo

UCL/ Mobile Systems


"Govind.Krishnamurthi" wrote:

> I'm resending the draft to the mailing list as I did not see it appear
> in the  archives. Sorry if you receive multiple copies.
> BRs,
> Govind.
>
> Abstract:
> Handoff in IP mobility protocols involves moving a mobile node's
> Layer 3 routing reachability information from one access router to
> another, before or after the mobile node has established a Layer 2
> connection with the radio access point that is covered by the new
> access router. In addition, other context information about the
> mobile node's packet session may be transferred from the old access
> router to the new one, in order to minimize the service disruption
> during the handoff process. While the exact details of how this is
> accomplished vary depending on the IP mobility and seamless handoff
> protocols, one common thread required for seamless handoffs is
> identifying the candidate access routers for the mobile node's
> handoff. When a collection of candidates has been identified, an
> algorithm is run to determine the target access router, and this
> router becomes the target of handoff at Layer 3. This document
> presents a problem statement describing issues involved in designing
> a candidate access router discovery protocol. The document does not
> discuss the algorithm by which the actual target router is
> identified, nor how the handoff to the target is achieved.
>
> Comments are welcome.
>
> Best Regards,
> Govind.
>
>  <<draft-ietf-seamoby-CARdiscovery-issues-00.txt>>
>
>   ------------------------------------------------------------------------
>                                                        Name: draft-ietf-seamoby-CARdiscovery-issues-00.txt
>    draft-ietf-seamoby-CARdiscovery-issues-00.txt       Type: Plain Text (text/plain)
>                                                    Encoding: base64
>                                                 Description: draft-ietf-seamoby-CARdiscovery-issues-00.txt



From owner-seamoby@diameter.org  Fri Jul 13 13:14:27 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08863
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 13:14:25 -0400 (EDT)
Received: (qmail 29685 invoked by alias); 13 Jul 2001 17:01:16 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 29673 invoked by uid 200); 13 Jul 2001 17:01:11 -0000
Received: (qmail 29653 invoked from network); 13 Jul 2001 17:01:05 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 17:01:05 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA00160;
	Fri, 13 Jul 2001 11:11:53 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA14813;
	Fri, 13 Jul 2001 10:11:53 -0700 (PDT)
Message-Id: <200107131711.KAA14813@heliopolis.eng.sun.com>
Date: Fri, 13 Jul 2001 10:11:53 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidate  Access Router  Discovery
To: mobile-ip@sunroof.eng.sun.com
Cc: Govind.Krishnamurthi@nokia.com, PNeumiller@MeshNetworks.com,
        seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 9jjQPyLgI5PY/8Aajab+Ig==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Behcet,

Please see the Seamoby charter at 
http://www.ietf.org/html.charters/seamoby-charter.html.
Handoff candidate discovery is part of the charter.

		jak
		
>Date: Fri, 13 Jul 2001 12:05:10 -0500
>From: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
>To: mobile-ip@sunroof.eng.sun.com
>CC: Govind.Krishnamurthi@nokia.com, PNeumiller@MeshNetworks.com, 
seamoby@cdma-2000.org
>Subject: Re: [mobile-ip] RE: [seamoby] Resend:New Draft:Issues in Candidate  
Access Router  Discovery
>
>Hi Jim,
>  Has this work been triggered by an email from Micheal Tanis?
>Since router discovery is of routing area, does your draft fall in seamoby 's
>charter?
>
>Just asking.
>
>James Kempf wrote:
>
>> Phil,
>>
>> Thanx for the positive comments.
>>
>> Regarding macrodiversity, I tend to look at it as an L2 issue. I know
>> that in the past you've expressed a view that it can be upleveled
>> to IP, but I'm not exactly clear what benefit that might have, especially
>> since packet sizes in IP are large and variable.
>>
>> If you look at it that way, it falls more into the purview of the
>> pwe3 working group. I've been wanting to tune in there and see whether
>> it might not be possible to get some work going for cellular RANs,
>> but have simply not had the time.
>>
>> Looking forward to seeing your protocol for CAR discovery.
>>
>>                 jak
>>
>> >Delivered-To: seamoby-list@charizard.diameter.org
>> >From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
>> >To: "'Govind.Krishnamurthi@nokia.com'" <Govind.Krishnamurthi@nokia.com>,
>> mobile-ip@sunroof.eng.sun.com
>> >Cc: seamoby@cdma-2000.org
>> >Subject: RE: [seamoby] Resend:New Draft:Issues in Candidate Access Router
>> Discovery
>> >Date: Fri, 13 Jul 2001 11:36:46 -0400
>> >
>> >Amazing.  I am stunned.  Great start!  More useful comments
>> >later...  One comment right now is that I have a candidate
>> >algorithm in mind (:-)), also I am again finding it difficult
>> >to see how this will work with macro-diversity since you may
>> >want to have legs across ARs in different ADs but more on that
>> >later.
>> >
>> >This draft moves MIP from blind faith to "enlightenment"
>> >a mobility renaissance is under way in the MIP WG!!!
>> >
>> >> -----Original Message-----
>> >> From: Govind.Krishnamurthi@nokia.com
>> >> [mailto:Govind.Krishnamurthi@nokia.com]
>> >>
>> >> Abstract:
>> >> Handoff in IP mobility protocols involves moving a mobile node's
>> >> Layer 3 routing reachability information from one access router to
>> >> another, before or after the mobile node has established a Layer 2
>> >> connection with the radio access point that is covered by the new
>> >> access router. In addition, other context information about the
>> >> mobile node's packet session may be transferred from the old access
>> >> router to the new one, in order to minimize the service disruption
>> >> during the handoff process. While the exact details of how this is
>> >> accomplished vary depending on the IP mobility and seamless handoff
>> >> protocols, one common thread required for seamless handoffs is
>> >> identifying the candidate access routers for the mobile node's
>> >> handoff. When a collection of candidates has been identified, an
>> >> algorithm is run to determine the target access router, and this
>> >> router becomes the target of handoff at Layer 3. This document
>> >> presents a problem statement describing issues involved in designing
>> >> a candidate access router discovery protocol. The document does not
>> >> discuss the algorithm by which the actual target router is
>> >> identified, nor how the handoff to the target is achieved.
>> >
>> >>
>
>--
>Behcet



From owner-seamoby@diameter.org  Fri Jul 13 13:20:18 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09794
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 13:20:17 -0400 (EDT)
Received: (qmail 30468 invoked by alias); 13 Jul 2001 17:08:35 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30451 invoked by uid 200); 13 Jul 2001 17:08:34 -0000
Received: (qmail 30438 invoked from network); 13 Jul 2001 17:08:29 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 17:08:29 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06509;
	Fri, 13 Jul 2001 11:19:20 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id KAA15138;
	Fri, 13 Jul 2001 10:19:21 -0700 (PDT)
Message-Id: <200107131719.KAA15138@heliopolis.eng.sun.com>
Date: Fri, 13 Jul 2001 10:19:21 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [seamoby] Re: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router  Discovery
To: Govind.Krishnamurthi@nokia.com, mobile-ip@sunroof.eng.sun.com
Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org,
        seamoby-context@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: cTwaRwSufd3liw7gxohsGw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Theo,

While it looks like your proactive draft has lots of good stuff in it,
since I've stopped doing international flights regularly, I don't
have large blocks of time for sitting still. So it may be hard
to go through the whole thing quickly, and I suspect that might be
true for others as well.

What I would like to suggest you may want to think about is to
carve out a few nuggets, like, for example, the CAR discovery protocol,
and put them into separate drafts, perhaps after IETF 51. 
Also, if you think you've got some good stuff on requirements for CAR discovery 
(what the draft that Govind et. al. wrote) is all about, then maybe we can get
together at IETF and talk about folding them into the CAR discovery
draft if they haven't already been covered, or even though the
mailing list. The CAR discovery draft is just at 00 now, and that must go 
through WG last call and IESG last call before the requirements are agreed to, 
so there is plenty of time.

		jak

>X-mProtect: Fri, 13 Jul 2001 10:08:21 -0700 Nokia Silicon Valley Messaging 
Protection
>Date: Fri, 13 Jul 2001 10:08:20 -0700
>From: Theo Pagtzis <tpagtzis@iprg.nokia.com>
>To: "Govind.Krishnamurthi" <Govind.Krishnamurthi@nokia.com>
>CC: mobile-ip <mobile-ip@sunroof.eng.sun.com>, seamoby <seamoby@cdma-2000.org>, 
seamoby-context <seamoby-context@cdma-2000.org>
>Subject: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in Candidate 
Access Router  Discovery
>
>Govind,
>
>    I have already provided a detailed protocol on pessimistic and optimistic 
proactivity in
>terms of router neighbour determination and candidacy. Please see
>draft-pagtzis-mobileip-proactivev6-00.txt/.ps
>
>I have also gone a long way in specifying the notions of mobility and routing 
neighbourhood as well as
>provide an algorithm for their determination.
>
>My proactive mobility scheme contains as part of it, exactly what you are 
describing as very briefly as
>physical neighbourhood and its mapping to a routing neighbourhood. There are 
however much more issues that
>are not elaborated in the targer AR determination. These are also covered in 
the draft on proactive mobility.
>
>Also what is the date of your submission? Here your draft says it is July 2001. 
But what day?
>
>
>Theo
>
>UCL/ Mobile Systems
>
>
>"Govind.Krishnamurthi" wrote:
>
>> I'm resending the draft to the mailing list as I did not see it appear
>> in the  archives. Sorry if you receive multiple copies.
>> BRs,
>> Govind.
>>
>> Abstract:
>> Handoff in IP mobility protocols involves moving a mobile node's
>> Layer 3 routing reachability information from one access router to
>> another, before or after the mobile node has established a Layer 2
>> connection with the radio access point that is covered by the new
>> access router. In addition, other context information about the
>> mobile node's packet session may be transferred from the old access
>> router to the new one, in order to minimize the service disruption
>> during the handoff process. While the exact details of how this is
>> accomplished vary depending on the IP mobility and seamless handoff
>> protocols, one common thread required for seamless handoffs is
>> identifying the candidate access routers for the mobile node's
>> handoff. When a collection of candidates has been identified, an
>> algorithm is run to determine the target access router, and this
>> router becomes the target of handoff at Layer 3. This document
>> presents a problem statement describing issues involved in designing
>> a candidate access router discovery protocol. The document does not
>> discuss the algorithm by which the actual target router is
>> identified, nor how the handoff to the target is achieved.
>>
>> Comments are welcome.
>>
>> Best Regards,
>> Govind.
>>
>>  <<draft-ietf-seamoby-CARdiscovery-issues-00.txt>>
>>
>>   ------------------------------------------------------------------------
>>                                                        Name: 
draft-ietf-seamoby-CARdiscovery-issues-00.txt
>>    draft-ietf-seamoby-CARdiscovery-issues-00.txt       Type: Plain Text 
(text/plain)
>>                                                    Encoding: base64
>>                                                 Description: 
draft-ietf-seamoby-CARdiscovery-issues-00.txt
>



From owner-seamoby@diameter.org  Fri Jul 13 13:25:03 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10408
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 13:25:00 -0400 (EDT)
Received: (qmail 31042 invoked by alias); 13 Jul 2001 17:13:20 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 31036 invoked by uid 200); 13 Jul 2001 17:13:19 -0000
Received: (qmail 31031 invoked from network); 13 Jul 2001 17:13:17 -0000
Received: from mgw-dax2.ext.nokia.com (63.78.179.217)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 17:13:17 -0000
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6DHOlI20482
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 12:24:47 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b8a469a3ac12f254079@davir01nok.americas.nokia.com>;
 Fri, 13 Jul 2001 12:23:55 -0500
content-class: urn:content-classes:message
Subject: [seamoby] FW: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router  Discovery
Date: Fri, 13 Jul 2001 12:23:14 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E460440DE05@bseis01nok>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router  Discovery
Thread-Index: AcELvoU4WTnumXewEdWrwwAIx6S5QwAACymg
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
From: <Govind.Krishnamurthi@nokia.com>
To: <Dirk.Trossen@nokia.com>, <Hemant.Chaskar@nokia.com>
Cc: <james.kempf@sun.com>, <tpagtzis@iprg.nokia.com>, <pcalhoun@diameter.org>,
        <seamoby@cdma-2000.org>
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA10408

Theo,
Theo,
I haven't read your draft yet. I will comment on your mail once I read
it.
Regarding a solution, we have one too but I think a solution is due only
after the problem
statement is described and the requirements are agreed upon. This is
atleast how the IETF
works as far as I know. Regarding our draft containing information from
your draft, it is
accidental. We have presented our draft as a first problem statement. If
you feel that we haven't addressed some of the issues (well this is the
00 version afterall!)
that you feel is necessary, go ahead and post it to the mailing list and
we can go from
there. 

Govind.

-----Original Message-----
From: Theo Pagtzis [mailto:tpagtzis@IPRG.nokia.com]
Sent: July 13, 2001 01:08 PM
To: Govind.Krishnamurthi
Cc: mobile-ip; seamoby; seamoby-context
Subject: Re: [seamoby-context] Resend:New Draft:Issues in Candidate
Access Router Discovery


Govind,

    I have already provided a detailed protocol on pessimistic and
optimistic proactivity in
terms of router neighbour determination and candidacy. Please see
draft-pagtzis-mobileip-proactivev6-00.txt/.ps

I have also gone a long way in specifying the notions of mobility and
routing neighbourhood as well as
provide an algorithm for their determination.

My proactive mobility scheme contains as part of it, exactly what you
are describing as very briefly as
physical neighbourhood and its mapping to a routing neighbourhood. There
are however much more issues that
are not elaborated in the targer AR determination. These are also
covered in the draft on proactive mobility.

Also what is the date of your submission? Here your draft says it is
July 2001. But what day?


Theo

UCL/ Mobile Systems


"Govind.Krishnamurthi" wrote:

> I'm resending the draft to the mailing list as I did not see it appear
> in the  archives. Sorry if you receive multiple copies.
> BRs,
> Govind.
>
> Abstract:
> Handoff in IP mobility protocols involves moving a mobile node's
> Layer 3 routing reachability information from one access router to
> another, before or after the mobile node has established a Layer 2
> connection with the radio access point that is covered by the new
> access router. In addition, other context information about the
> mobile node's packet session may be transferred from the old access
> router to the new one, in order to minimize the service disruption
> during the handoff process. While the exact details of how this is
> accomplished vary depending on the IP mobility and seamless handoff
> protocols, one common thread required for seamless handoffs is
> identifying the candidate access routers for the mobile node's
> handoff. When a collection of candidates has been identified, an
> algorithm is run to determine the target access router, and this
> router becomes the target of handoff at Layer 3. This document
> presents a problem statement describing issues involved in designing
> a candidate access router discovery protocol. The document does not
> discuss the algorithm by which the actual target router is
> identified, nor how the handoff to the target is achieved.
>
> Comments are welcome.
>
> Best Regards,
> Govind.
>
>  <<draft-ietf-seamoby-CARdiscovery-issues-00.txt>>
>
>
------------------------------------------------------------------------
>                                                        Name:
draft-ietf-seamoby-CARdiscovery-issues-00.txt
>    draft-ietf-seamoby-CARdiscovery-issues-00.txt       Type: Plain
Text (text/plain)
>                                                    Encoding: base64
>                                                 Description:
draft-ietf-seamoby-CARdiscovery-issues-00.txt


From owner-seamoby@diameter.org  Fri Jul 13 13:36:25 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12045
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 13:36:22 -0400 (EDT)
Received: (qmail 31648 invoked by alias); 13 Jul 2001 17:24:45 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 31642 invoked by uid 200); 13 Jul 2001 17:24:45 -0000
Received: (qmail 31632 invoked by uid 500); 13 Jul 2001 17:24:41 -0000
Date: Fri, 13 Jul 2001 10:24:41 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: [seamoby] Re: Yet another Security RANT was  L2 API (WAS: Ext. for FMIPv6 - com ments) (SHOULD be ,          RE: Issue #4)
Message-ID: <20010713102441.W5588@charizard.diameter.org>
Mail-Followup-To: Phillip Neumiller <PNeumiller@MeshNetworks.com>,
	'Nakhjiri Madjid-MNAKHJI1' <Madjid.Nakhjiri@motorola.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>, seamoby@cdma-2000.org
References: <0DF9FBC42474A24CA50F7A27FB08E04844559E@meshpdc.meshnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E04844559E@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Fri, Jul 13, 2001 at 09:22:52AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

What you describe below is how things should work in the idea world.
However, given that we aren't there, we have to live with existing
processes.

The way the process works, generally, is that a WG defines its
security requirements, and attempts to solve the problem. The
WG is highly encouraged to get folks that understand security
involved, and this can be done by asking the Security ADs for
some assitance. I've worked in some WGs where we requested
security review early on, and received great input.

The main reason why it works this way is that another WG typically
doesn't understand our problem space, and could propose a solution
that isn't feasible, but secure.

As far as disagreeing with IESG, there is no crime in that. In fact,
disagreeing, and raising issues, can sometimes lead to better results.

PatC

On Fri, Jul 13, 2001 at 09:22:52AM -0400, Phillip Neumiller wrote:
> Hi Madjid,
> 
> I disdain coupling security issues with non-security transport 
> design and requirements formulation.  I believe security issues
> should be left up to the security WG where the appropriate domain
> experts can create general purpose solutions.  IP and the major
> transport protocols such as UDP, TCP, and SCTP should be made
> secure (perhaps with IPsec).  Users of these off-the-shelf 
> protocols could then "feel" safe about doing what they want and
> not waste time getting all balled up in security issues.  It
> seems like a BAD idea to me to make every single IETF WG jump
> through security hoops since:
> 
> A).  It dilutes the real "work" the WG is trying to do
> B).  It allows for wasted effort on different security solutions
>      all over the IETF since they are uncoordinated
> C).  The members of many non-security WGs do not have the 
>      appropriate domain expertise to solve security problems.
> 
> So clearly I disagree with our ADs on this issue.  Is that a 
> crime?  This is not the first time (or the first WG) I have
> stated this (in).
> 
> CASE IN POINT: Handovers.
> 
> Handovers can be done with MIP.  They can be done with "local-mobility"
> protocols, or perhaps in other ways.  Security of the mobile host is
> likely to be done differently by different network operators.  To explicitly
> tie some mandated security to the our handover work weakens its 
> general applicability.  However, I am all in favor of an
> API/signaling/trigger
> mechanism/hooks for security/AAA.  My two cents!
> 
> Thanks,
> 
> Phil
> 
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> > Sent: Thursday, July 12, 2001 7:01 PM
> > To: 'Phillip Neumiller'; 'Pat Calhoun'
> > Cc: 'James Kempf'; gkenward@nortelnetworks.com; Nakhjiri
> > Madjid-MNAKHJI1; john.loughney@nokia.com; seamoby@cdma-2000.org
> > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> > comments) (SHOULD
> > be , RE: Issue #4)
> > 
> > 
> > <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 owner-seamoby@diameter.org  Fri Jul 13 14:22:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18437
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 14:22:37 -0400 (EDT)
Received: (qmail 32549 invoked by alias); 13 Jul 2001 18:10:42 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 32542 invoked by uid 200); 13 Jul 2001 18:10:41 -0000
Received: (qmail 32533 invoked from network); 13 Jul 2001 18:10:38 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 18:10:38 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id LAA28359;
	Fri, 13 Jul 2001 11:20:55 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6DIKtj19421;
	Fri, 13 Jul 2001 11:20:55 -0700
X-mProtect:  Fri, 13 Jul 2001 11:20:55 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdtk66c2; Fri, 13 Jul 2001 11:20:53 PDT
Message-ID: <3B4F3C05.A30C0140@iprg.nokia.com>
Date: Fri, 13 Jul 2001 11:20:53 -0700
From: Theo Pagtzis <tpagtzis@IPRG.nokia.com>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: James Kempf <James.Kempf@Sun.COM>, Govind.Krishnamurthi@nokia.com
CC: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org,
        seamoby-context@cdma-2000.org
Subject: [seamoby] Re: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in 
 Candidate Access Router Discovery
References: <200107131719.KAA15138@heliopolis.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

HI James,

   My draft spec document has also got a contents section for faster scanning of
relevant sections. But nevermind.

I would be glad to discuss with you guys about the issues on CAR discovery at the
IETF in London.

I would like to propose then whether it would be possible to contribute to your
draft my sections on the particular aspect and participate in a joint design
process of that aspect on CAR discovery as a co-author. What do you think?

Theo

UCL/ Mobile Systems


James Kempf wrote:

> Theo,
>
> While it looks like your proactive draft has lots of good stuff in it,
> since I've stopped doing international flights regularly, I don't
> have large blocks of time for sitting still. So it may be hard
> to go through the whole thing quickly, and I suspect that might be
> true for others as well.
>
> What I would like to suggest you may want to think about is to
> carve out a few nuggets, like, for example, the CAR discovery protocol,
> and put them into separate drafts, perhaps after IETF 51.
> Also, if you think you've got some good stuff on requirements for CAR discovery
> (what the draft that Govind et. al. wrote) is all about, then maybe we can get
> together at IETF and talk about folding them into the CAR discovery
> draft if they haven't already been covered, or even though the
> mailing list. The CAR discovery draft is just at 00 now, and that must go
> through WG last call and IESG last call before the requirements are agreed to,
> so there is plenty of time.
>
>                 jak
>
> >X-mProtect: Fri, 13 Jul 2001 10:08:21 -0700 Nokia Silicon Valley Messaging
> Protection
> >Date: Fri, 13 Jul 2001 10:08:20 -0700
> >From: Theo Pagtzis <tpagtzis@iprg.nokia.com>
> >To: "Govind.Krishnamurthi" <Govind.Krishnamurthi@nokia.com>
> >CC: mobile-ip <mobile-ip@sunroof.eng.sun.com>, seamoby <seamoby@cdma-2000.org>,
> seamoby-context <seamoby-context@cdma-2000.org>
> >Subject: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in Candidate
> Access Router  Discovery
> >
> >Govind,
> >
> >    I have already provided a detailed protocol on pessimistic and optimistic
> proactivity in
> >terms of router neighbour determination and candidacy. Please see
> >draft-pagtzis-mobileip-proactivev6-00.txt/.ps
> >
> >I have also gone a long way in specifying the notions of mobility and routing
> neighbourhood as well as
> >provide an algorithm for their determination.
> >
> >My proactive mobility scheme contains as part of it, exactly what you are
> describing as very briefly as
> >physical neighbourhood and its mapping to a routing neighbourhood. There are
> however much more issues that
> >are not elaborated in the targer AR determination. These are also covered in
> the draft on proactive mobility.
> >
> >Also what is the date of your submission? Here your draft says it is July 2001.
> But what day?
> >
> >
> >Theo
> >
> >UCL/ Mobile Systems
> >
> >
> >"Govind.Krishnamurthi" wrote:
> >
> >> I'm resending the draft to the mailing list as I did not see it appear
> >> in the  archives. Sorry if you receive multiple copies.
> >> BRs,
> >> Govind.
> >>
> >> Abstract:
> >> Handoff in IP mobility protocols involves moving a mobile node's
> >> Layer 3 routing reachability information from one access router to
> >> another, before or after the mobile node has established a Layer 2
> >> connection with the radio access point that is covered by the new
> >> access router. In addition, other context information about the
> >> mobile node's packet session may be transferred from the old access
> >> router to the new one, in order to minimize the service disruption
> >> during the handoff process. While the exact details of how this is
> >> accomplished vary depending on the IP mobility and seamless handoff
> >> protocols, one common thread required for seamless handoffs is
> >> identifying the candidate access routers for the mobile node's
> >> handoff. When a collection of candidates has been identified, an
> >> algorithm is run to determine the target access router, and this
> >> router becomes the target of handoff at Layer 3. This document
> >> presents a problem statement describing issues involved in designing
> >> a candidate access router discovery protocol. The document does not
> >> discuss the algorithm by which the actual target router is
> >> identified, nor how the handoff to the target is achieved.
> >>
> >> Comments are welcome.
> >>
> >> Best Regards,
> >> Govind.
> >>
> >>  <<draft-ietf-seamoby-CARdiscovery-issues-00.txt>>
> >>
> >>   ------------------------------------------------------------------------
> >>                                                        Name:
> draft-ietf-seamoby-CARdiscovery-issues-00.txt
> >>    draft-ietf-seamoby-CARdiscovery-issues-00.txt       Type: Plain Text
> (text/plain)
> >>                                                    Encoding: base64
> >>                                                 Description:
> draft-ietf-seamoby-CARdiscovery-issues-00.txt
> >



From owner-seamoby@diameter.org  Fri Jul 13 14:34:06 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19933
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 14:33:46 -0400 (EDT)
Received: (qmail 401 invoked by alias); 13 Jul 2001 18:13:11 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 395 invoked by uid 200); 13 Jul 2001 18:13:10 -0000
Received: (qmail 379 invoked from network); 13 Jul 2001 18:13:04 -0000
Received: from thumper.research.telcordia.com (128.96.41.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 18:13:04 -0000
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f6DINNm02176
	for <seamoby@diameter.org>; Fri, 13 Jul 2001 14:23:23 -0400 (EDT)
Received: from tuna.research.telcordia.com (ohba@tari-dhcp7.research.telcordia.com [207.3.232.121])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id OAA18381
	for <seamoby@diameter.org>; Fri, 13 Jul 2001 14:25:27 -0400 (EDT)
Date: Fri, 13 Jul 2001 15:22:57 -0400
Message-ID: <877kxc8wha.wl@tuna.research.telcordia.com>
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
To: seamoby@diameter.org
Subject: [seamoby] Forward: [seamoby-paging] Last Hop DMHA protocol
References: <87ae288xgj.wl@tuna.research.telcordia.com>
User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: multipart/mixed;
 boundary="Multipart_Fri_Jul_13_15:22:57_2001-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

--Multipart_Fri_Jul_13_15:22:57_2001-1
Content-Type: text/plain; charset=US-ASCII

Sorry if you got multiple copies of the attached I-D.

Comments are very much appreciated.

Yoshihiro Ohba


--Multipart_Fri_Jul_13_15:22:57_2001-1
Content-Type: message/rfc822

Delivered-To: seamoby-paging-list@charizard.diameter.org
Date: Fri, 13 Jul 2001 15:01:48 -0400
Message-ID: <87ae288xgj.wl@tuna.research.telcordia.com>
From: Yoshihiro Ohba <yohba@tai.toshiba.com>
To: seamoby-paging@diameter.org
Subject: [seamoby-paging] Last Hop DMHA protocol
User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Sender: owner-seamoby-paging@diameter.org
Precedence: bulk
Content-Type: multipart/mixed;
 boundary="Multipart_Fri_Jul_13_15:01:48_2001-1"
Status: U

--Multipart_Fri_Jul_13_15:01:48_2001-1
Content-Type: text/plain; charset=US-ASCII

Dear all,

Today I've submitted an I-D on Last Hop DMHA protocol.
As it may take some time until it appears in the I-D directory, 
I attaches the file.

I hope this would be a good starting point to discuss actual Seamoby
DMHA protocol.

Comments are very much appreciated.

Regards,
Yoshihiro Ohba


--Multipart_Fri_Jul_13_15:01:48_2001-1
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: attachment; filename="draft-ohba-seamoby-last-hop-dmha-00.txt"
Content-Transfer-Encoding: quoted-printable







Internet-Draft                                            Yoshihiro Ohba
Expires: January, 2002                                 Nobuyasu Nakajima
                                          Toshiba America Research, Inc.

                                                               Tao Zhang
                                                  Telcordia Technologies

                                                           July 13, 2001



          Last Hop DMHA (Dormant Mode Host Alerting) Protocol
               <draft-ohba-seamoby-last-hop-dmha-00.txt>


Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents, valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Key Words

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.


Abstract

   This document specifies a protocol used in the "last hop" networks to
   support alerting of dormant mode hosts.  The proposed protocol
   conforms with the DMHA (Dormant Mode Host Alerting) protocol
   requirements discussed in the IETF Seamoby WG, in that it is
   independent of any mobility management protocol.  This protocol
   supports mobile hosts as well as stationary hosts, provided that a
   dormant host is able to detect a change in L2, e.g., a change in L2
   paging area or a change in L2 attachment point.






                          Expires January 2002                  [Page 1]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


1.  Terminology

   The following terminology is defined in this document.


   Host


     A standard IP host in the sense of STD0003, with an additional
     capability to enter dormant mode.


   Paging Server


     An entity that locates in the same subnet that the Host is
     connecting to, and has functionalities of both DMA (Dormant
     Monitoring Agent) and PA (Paging Agent) [1].


   Last Hop Subnet


     The edge subnet to which a Host is connected.  We use the word
     "Last Hop Subnet" instead of "Edge Subnet", because the main
     purpose of paging is alerting a dormant Host when there is an
     incoming packet to the Host.


   Last Hop


     The final hop for a packet to reach a Host on the Last Hop Subnet.


2.  Protocol Overview

   The Last Hop Dormant Mode Host Alerting (LH-DMHA) is a client-server
   type protocol in which a Host acts as a client and a Paging Server
   acts as a server.  A Paging Server can either be co-located with a
   last hop router or be a separate box.  In the latter case, legacy
   routers can be used as it is.

   When a Host which is in active mode decides to enter a dormant mode,
   it performs paging registration to a Paging Server by sending a
   Registration message to the Paging Server, specifying at least the
   hardware address of the interface that is going to be dormant and the
   lifetime of the registration.

   The Paging Server then registers the information specified in the
   received Registration message and returns a Registration ACK message
   to the Host.

   The Paging Server also monitors the packets on the subnet, and when
   it captures a packet that is worth awaking the registered dormant
   Host, it performs paging.  The paging is performed either by
   triggering L2 paging if the L2 supports it, or by forwarding the



                          Expires January 2002                  [Page 2]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


   packet to the Host in a way that is receivable by the Host.  Anyway,
   paging is performed without using an explicit L3 signaling message.

   When the host exits a dormant mode either spontaneously due to e.g.,
   originating a SIP call or starting web-browsing or passively as a
   result of the paging operation, it performs paging deregistration.
   Paging deregistration is performed in the same way as paging
   registration except that the lifetime is set to be zero.

   The protocol conforms with [1] in that it is independent of any
   mobility management protocol.  (On the other hand, the protocol could
   also be used as a last hop part of a paging protocol (such as [2])
   that is dependent on a specific mobility management protocol, though
   we do not recommend such a usage.)

   This protocol supports mobile Hosts as well as stationary Hosts,
   provided that a dormant Host is able to detect a change in L2, e.g.,
   a change in L2 paging area or a change in L2 attachment point.  See
   section 3.9 for details.

   This version of the document does not yet specify a method to
   authenticate the message exchange.  Next version will come with
   security support.


3.  Protocol Description


3.1.  Transport

   The LH-DMHA uses UDP as its transport for paging server advertisement
   and paging registration.  The UDP port number is TBD.


3.2.  Paging Server Advertisement

   A Paging Server periodically multicasts a Advertisement message on
   the subnet by using multicast.  The scope of the multicast is limited
   within the advertising subnet.

   The multicast address for IPv4 is TBD.

   The multicast address for IPv6 is TBD.

   A Host joins the multicast group to listen to the Advertisement
   messages from the Paging Server.  When a Host receives an
   Advertisement while it is in active mode, it registers the source IP
   address of the Advertisement as the Paging Server address.

   Alternatively, a Host can manually configure the Paging Server
   address if it is previously known.


3.3.  Paging Registration

   Before a Host enters a dormant mode, it sends a Registration message
   to the Paging Server and waits for an Registration ACK message.  A



                          Expires January 2002                  [Page 3]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


   Registration message contains the hardware address of the interface
   of the Host that is going to be dormant and the lifetime of the
   registration.  The lifetime used for paging registration MUST be
   greater than zero.

   The Paging Server then registers the specified information in the
   received Registration message and returns a Registration ACK message
   to the Host.  The Registration ACK message contains a status
   indicating whether the registration is successful or not, the
   hardware address of the Host that sent the Registration message and
   the lifetime.  The lifetime contained in the Registration ACK message
   can be different from that is specified by the Host if the specified
   value is out of the range that the Paging Server is supporting.

   When the Host that is waiting for an ACK receives the Registration
   ACK from the Paging Server with a status indicating successful
   registration , it is able to enter a dormant mode.

   To refresh the paging registration state, the registered Host sends a
   Registration message to the Paging Server before the next lifetime
   expires.

   The Host SHOULD retransmit the Registering message until Registration
   ACK or Notification message is received from the Paging Server.

   If ARP is used in the last hop subnet, the following consideration is
   needed.



   o The Paging Server MUST NOT delete its ARP cache entry for the
     dormant Host while the Host is registered.


   o If a Host is not able to receive broadcast frames in dormant mode,
     it SHOULD delete all the ARP cache entries while it is in dormant
     mode, as those entries will not be updated and thus will become
     obsolete.


3.4.  Paging Deregistration

   At the time a Host exits a dormant mode, it sends a Registration
   message to the Paging Server with specifying the lifetime of zero.

   The Paging Server then removes the entry for the Host from its
   database and returns a Registration ACK message to the Host with
   specifying the lifetime of zero.

   Note that the Host can enter the active mode before it receives a
   Registration ACK message for paging deregistration, or even before it
   sends a Registration message.


3.5. Monitoring Paging Trigger Packets

   A Paging Server monitors the subnet to which the Hosts are connected



                          Expires January 2002                  [Page 4]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


   in order to capture paging trigger packets.  Currently the following
   set of paging trigger packets is defined by default:



   o Any unicast IP packet in which the destination IP address matches
     the IP address of a registered dormant Host.


   o Broadcast ARP REQUEST message in which the target network layer
     address matches the IP address of a registered dormant Host.


   o In IPv6 case, Neighbor Solicitation message to the target dormant
     Host. The destination address of this message is either the
     solicited-node multicast address which corresponds to the target
     dormant Host, or the IPv6 address of the target dormant Host.


   When the Host specifies a set of trigger packets in the Register
   message, it overrides the default set of trigger packets.  For
   example, a Host MAY specify a set of trigger packets so that it is
   awaken only when a SIP INVITE message destined for the Host is
   received at the last hop router, provided that the Paging Server is
   co-located with the last hop router.

3.6.  Paging

   When a Paging Host captures a paging trigger packet, it takes one of
   the following actions:


   o If the underlying L2 technology supports L2 paging, the Paging
     Server triggers the L2 paging for the registered hardware address.
     If the control channel used for L2 paging channel supports carrying
     data packets, the trigger packet is forwarded on the control
     channel.  Otherwise, the captured trigger packets is buffered until
     the L2 paging completes, and then forwarded on the traffic channel
     after the completion of L2 paging.


   o If the underlying L2 technology does not support L2 paging, the
     Paging Server MUST forward the packet on the traffic channel in a
     way that is receivable by the dormant host.


   When the dormant Host eventually receives the trigger packet, it
   performs paging deregistration.


3.7.  Supporting Multiple IP Addresses Per Hardware Address

   In the case of IPv6, it is possible to assign multiple IP addresses
   for an interface of a Host.  Or if the Host supports both IPv4 and
   IPv6 it is possible to assign one IPv4 address and one or more IPv6
   addresses for the interface.  In such cases, the Host MAY perform
   paging registration for different IP addresses with specifying the



                          Expires January 2002                  [Page 5]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


   same hardware address.  To support this, the Paging Server MUST be
   able to handle multiple IP addresses per hardware address.  Last Hop
   Paging support for this case will be described in detail in the next
   version.

3.8.  Supporting Multiple Hardware Addresses

   A Host MAY be equipped with multiple radio interfaces (e.g., both
   Bluetooth and IEEE 802.11 interfaces).  Each radio interface may be
   identified by a separate MAC address.  The host MAY use a separate IP
   address for each of its radio interface.  In this case, different
   radio interfaces on the same Host can be treated by the Paging Server
   as different IP hosts, each identified by a separate IP address.
   That is, the Host can perform paging registration for each radio
   interface separately with the Paging Server. The Paging Server can
   then maintain Paging Registration states for each interface in the
   same way it handles a single-interface Host.

   On the other hand, a single IP address MAY be used for multiple or
   all of the radio interfaces of a multi-interface Host.  In this case,
   the Paging Server MUST be able to handle multiple hardware addresses
   per IP address.  Last Hop Paging support for this case will be
   described in detail in the next version.


3.9.  Supporting Mobility

   If a Host is a mobile node, it is able to move around while it is in
   a dormant mode, with changing L2 attachment points or L3 subnets but
   without changing its IP address.  Dormant host alerting for mobile
   Hosts is supported in the following way.


   o In order for a mobility management protocol to enjoy the benefit of
     DMHA in terms of both power saving and reduced signaling message
     exchange, the mobility management protocol should have a capability
     to reduce the frequency of mobility binding update.  In addition,
     if a Host is running a mobility management protocol that has such a
     capability, the Host should perform an action to reduce the
     frequency of mobility binding update before it enters a dormant
     mode.


   o If underlying L2 does not support paging, a dormant Host should
     check whether the subnet has changed, when one of the following
     cases occurs.


      a) The L2 is a wireless link and there is a change in Base Station
        or Access Point.


      b) The L2 is wired link and the wire is detached and then
        connected again.


      If the Host detects a change in subnet, it performs paging



                          Expires January 2002                  [Page 6]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


      registration to the Paging Server on the new subnet.  In addition,
      if the Host is running a mobility management protocol, it also
      performs mobility binding update.


   o If underlying L2 supports paging, a dormant Host is assumed to have
     a capability to detect a change in L2 paging area and inform the L2
     location registrar of the change.  If the Host detects a change in
     L2 paging area, it checks whether the subnet has also changed, and
     if a subnet change is detected, it performs paging registration to
     the Paging Server on the new subnet.  In addition, if the Host is
     running a mobility management protocol, it also performs mobility
     binding update.


   o Whenever a Host that has been registering to a Paging Server
     detects a subnet change, it also performs paging deregistration to
     the Paging Server in the "old" subnet.


   Based on the discussion in [4] that a dormant Host can perform
   mobility binding update when it detects a change in L2, Tracking
   Agent [1] is not required for this protocol.


4.  Message Format

   All messages defined in the LH-DMHA have the following structure.
   All fields are transmitted in network byte order.

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Version    |    Type       |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Payload ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The first 4 octets are the protocol header.

     Version
        The version of the protocol.  The current version is zero.

     Type
        Message type.

     Length
        Length of the Payload part in octets.


   The currently defined message types are shown in Table 1.









                          Expires January 2002                  [Page 7]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


                     Type         Message Name
                     -----------------------------
                     0x01         Advertisement
                     0x02         Registration
                     0x03         Registration ACK
                     -----------------------------

                        Table 1: Message Types


4.1.  Payload

   The Payload part is composed of one or more TLVs (Type-Length-Value
   objects), where each TLV has the following format:


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Length    |      Value ...
   +---------------+---------------+-------------------------------+

     Type
        The type of this TLV.

     Length
        The length of the Value field in octets.

     Value
        The value of this TLV.  This field is null if the value of the
        Length field is zero.


   Table 2 summarizes the defined TLVs.  They can appear in any order in
   the Payload.

               TLV Name                  Type    Length
               ------------------------------------------
               Hardware Address          0x01    Variable
               IP Address                0x02    Variable
               Lifetime                  0x03     0x04
               Lifetime Range            0x04     0x08
               Status                    0x05     0x04
               Paging Trigger Packets    0x06    Variable
               ------------------------------------------

                            Table 2: TLVs


4.2.1.  Hardware Address

   This TLV contains the hardware address of an interface of the host
   that is performing paging registration.  The Value field of has the
   following format.






                          Expires January 2002                  [Page 8]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Adders Family          |Address Length |  Address ...
   +-------------------------------+---------------+---------------+


     Address Family

        Two octet quantity containing a value from ADDRESS FAMILY
        NUMBERS in RFC1700 that encodes the address family of the
        hardware address.


     Address Length
        The length of the Address field in octets.

     Address
        The hardware address.


4.2.2.  IP Address

   This TLV contains an IP address of an interface of the host that is
   performing paging registration.  The Value field of has the following
   format.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Adders Family          |Address Length |  Address ...
   +-------------------------------+---------------+---------------+


     Address Family

        Two octet quantity containing a value from ADDRESS FAMILY
        NUMBERS in RFC1700 that encodes the address family of the IP
        address.  It MUST be either 1 (for IPv4 address) or 2 (for IPv6
        address).


     Address Length
        The length of the Address field in octets.  It MUST be either 4
        (for IPv4 address) or 16 (for IPv6 address).

     Address
        The IP address.


4.2.3.  Lifetime

   This TLV contains a lifetime of the paging registration, specified in
   seconds.  The value of zero indicates paging deregistration.






                          Expires January 2002                  [Page 9]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


4.2.4.  Lifetime Range

   This TLV contains two lifetimes, the first one is the minimum
   lifetime and the second one is the maximum lifetime.  Each lifetime
   contains 2-octet integer value specified in seconds.


4.2.5.  Status

   This TLV contains the result of the paging (de)registration.  The
   Value field contains a 4-octet integer.  A value of zero indiciates
   successful registration.  Non-zero values indicates failure.  More
   specific values for failure are to be defined.


4.2.6.  Paging Trigger Packets

   This TLV contains a set of paging trigger packets.  The format is to
   be defined.


4.3.  LH-DMHA Messages


4.3.1.  Advertisement Message

   An Advertisement message contains the following TLV.

   o  Lifetime Range TLV


4.3.2.  Registration Message

   A Registration message contains the following TLVs.

   o  Hardware Address TLV
   o  IP Address TLV
   o  Lifetime TLV
   o  Paging Trigger Packets [optional]


4.3.3.  Registration ACK Message

   A Registration ACK message contains the following TLVs.

   o  Hardware Address TLV
   o  IP Address TLV
   o  Lifetime TLV
   o  Paging Trigger Packets [optional]
   o  Status TLV


5.  Security Consideration

   This version of the document does not yet have a method to
   authenticate the message exchange which is required for standard
   Seamoby IP Paging protocol [1].  Next version will come with security



                          Expires January 2002                 [Page 10]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


   support.


References

   [1] J. Kempf, et al., "Requirements and Functional Architecture for an
       IP Host Alerting Protocol",
       draft-ietf-seamoby-paging-requirements-01.txt, Work in Progress, May
       2001.

   [2] M. Liebsch, et al., "Paging Concept for IP based Networks",
       draft-renker-paging-ipv6-00.txt, Work in Progress, June 2001.

   [3] "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
       specifications", IEEE Std 802.11, June 1997.

   [4] J. Kempf, "Dormant Mode Host Alerting ("IP Paging") Problem
       Statement", RFC 3132, June 2001.


Authors' Information

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   P.O. Box 136
   Convent Station, NJ
   07961-0136
   USA

   Phone: +1 973 829 5174
   Fax:   +1 973 829 5601
   Email: yohba@tari.toshiba.com


   Nobuyasu Nakajima
   Toshiba America Research, Inc.
   P.O. Box 136
   Convent Station, NJ
   07961-0136
   USA

   Phone: +1 973 829 4752
   Email: nnakajima@tari.toshiba.com


   Tao Zhang
   Telcordia Technologies, Inc.
   445 South Street, Room 1J-214B
   Morristown, NJ 07960
   USA

   Phone: +1 973 829 4539
   Fax:   +1 973 829 5889
   Email: tao@research.telcordia.com






                          Expires January 2002                 [Page 11]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


Appendix A:  An LH-DMHA implementation over 802.11


A.1.  802.11 Power Management

   The power management capability of IEEE 802.11 [3] for an
   infrastructure network can be summarized as follows.  A station
   changing Power Management mode informs the Access Point (AP) of this
   fact using the Power Management bits in the Frame Control field of the
   transmitted MAC frames.  An AP periodically broadcasts beacon signals
   to provide time synchronization information and inform stations in
   Power Save mode of arriving frames.  A station uses the time
   synchronization information received from the AP to determine when it
   should wake up periodically from Power Save mode.  The AP buffers the
   MAC frames destined to the station in Power Save mode and transmit
   them at designated times.

   Unicast frames destined to a host in Power Save mode are transmitted
   by the AP and received by the station in different ways from
   broadcast/multicast frames.  With every beacon transmission, the AP
   informs each station in Power Save mode of the unicast frames buffered
   by the AP for the station and whether these frames are to be sent to
   the station during a content-free or a contention time period.  If a
   unicast frame is to be sent in a contention period, the station will
   poll the AP to receive the unicast frame.  If a frame is to be sent
   during a contention-free period, the station will not poll the AP but
   will instead remain active until the frame is received or the
   contention-free period ends.

   The AP notifies the stations of the existence of broadcast/multicast
   frames only via selected beacons periodically and the
   broadcast/multicast frames are sent immediately after these beacons.


A.2.  Dormant mode support with 802.11 Power Management

   By utilizing the timing differences for multicast/broadcast frames and
   unicast frames, three different dormant modes can be realized in the
   single Power Save mode.


   o All Mode:  Both unicast and multicast/broadcast frames are received.


   o Unicast Only Mode: Only unicast frames are received.


   o Multicast Only Mode: Only multicast/broadcast frames are received.


   The dormancy levels of Unicast Only Mode and Multicast Only Mode are
   higher than that of All Mode.  Unicast Only Mode is effective in terms
   of battery saving especially for a Host connecting to the network
   where broadcast/multicast traffic is high and most of the
   broadcast/multicast traffic is not important to the dormant station.
   On the other hand, there are also important broadcast/multicast frames
   that need to be received by the dormant Host in order to to receive



                          Expires January 2002                 [Page 12]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


   incoming SIP calls.  One example is ARP REQUEST packets which are
   broadcast by a node in the last hop subnet in order to obtain the MAC
   address for an IP address of the Host.

   Section A.3 describes an implementation of the Last Hop IP Paging
   Protocol that allows a Host to stay in the Unicast Only Mode while in
   power saving mode and will still be able to receive both unicast and
   selected types of broadcast traffic.


A.3.  LH-DMHA over 802.11: Host Implementation

   The LH-DMHA over 802.11 for IPv4 is implemented in a Host in
   the following way.


   1) The Host monitors its own IP activity.


   2) The Host stays in active mode while IP packets are sent or received.


   3) If no IP packet is sent or received during a certain period, it
      performs paging registration as defined in section 2.3.


   4) If paging registration is successful, the Host enters the Unicast
      Only Mode, otherwise, enters the All Mode.


   5) If the Host receives a paging trigger packet as a result paging, it
      performs paging deregistration as defined in section 3.6.


A.4.  LH-DMHA over 802.11: Paging Server Implementation

   In this section, it is assumed that a Paging Server is connected
   to the last hop subnet through wired Ethernet.

   The Last Hop Paging over 802.11 is implemented in a Paging Server
   in the following way.


   1) The Paging Server monitors packets on the last hop subnet.


   2) If it captures a paging trigger packet for a registered Host, it
      forwards the packet to the Host to registered hardware address, with
      specifying the hardware address of the registered Host as the
      destination MAC address and the Paging Server's hardware address on
      the monitoring interface as the source MAC address.

      For example, if the paging trigger packet is a broadcast ARP REQUEST
      message, the destination MAC address of the forwarded packet is
      changed from ff:ff:ff:ff:ff:ff to the hardware address of the
      registered Host, and the source MAC address is changed from the
      original sender's hardware address to the the Paging Server's hardware



                          Expires January 2002                 [Page 13]





Internet-Draft           Last Hop DMHA Protocol            July 13, 2001


      address on the monitoring interface.  The body of the ARP REQUEST is
      not modified.  Since the Host in operating in Unicast Only Mode, it
      can receive the unicast ARP REQUEST.  Then, it returns an ARP REPLY to
      the original sender, not to the Paging Server.

      In addition, if the Paging Server is co-located with the last hop
      router, there is also a case in which it receives a unicast IP packet
      that is destined for the dormant Host and needs to be forwarded from
      other interface to the last hop interface.  In this case it can use
      the ARP cache entry as usual to forward the packet to the dormant
      Host, since the ARP cache entry is not deleted during the lifetime of
      the paging registration (see section 3.3).
















































                          Expires January 2002                 [Page 14]



--Multipart_Fri_Jul_13_15:01:48_2001-1--


--Multipart_Fri_Jul_13_15:22:57_2001-1--


From owner-seamoby@diameter.org  Fri Jul 13 14:45:46 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21822
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 14:45:46 -0400 (EDT)
Received: (qmail 866 invoked by alias); 13 Jul 2001 18:20:16 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 859 invoked by uid 200); 13 Jul 2001 18:20:16 -0000
Received: (qmail 852 invoked from network); 13 Jul 2001 18:20:12 -0000
Received: from netmail.alcatel.com (128.251.168.50)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 18:20:12 -0000
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA16878
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 13:30:52 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6DIUo020194
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 13:30:50 -0500 (CDT)
Message-ID: <3B4F3E88.A7993F36@usa.alcatel.com>
Date: Fri, 13 Jul 2001 13:31:36 -0500
From: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby <seamoby@cdma-2000.org>
Subject: [seamoby] I-D draft-sarikaya-seamoby-hmip6hp-00.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,
  We submitted an I-D to IETF. It is also available at:
http://www.geocities.com/bsarikaya/draft-sarikaya-seamoby-hmip6hp-00.txt

Abstract

   This document specifies Hierarchical Mobile IPv6 Hierarchical Paging
   (HMIPv6HP), an IP host alerting protocol which is a link-layer
   independent extension to Hierarchical Mobile IPv6. The extension
   allows a mobile node to enter a power saving dormant mode during
   which its location is known with coarse accuracy defined by a paging
   area. In the visited domain only the paging mobility anchor point
   (PMAP) is responsible for keeping the binding cache entries for
   dormant mobile nodes and, it re-establishes the downlink routes on
   demand by means of paging. Paging is initiated by the paging agent
   (PA) and the access routers in paging areas and does not involve
   periodic layer 3 messages to be sent except for time-slot based
   paging which is optional and is to be used on links with no support
   for layer 2 paging.


Comments welcome.
  Kind regards,
--
Behcet



From owner-seamoby@diameter.org  Fri Jul 13 14:50:33 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22409
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 14:50:32 -0400 (EDT)
Received: (qmail 1687 invoked by alias); 13 Jul 2001 18:36:54 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 1671 invoked by uid 200); 13 Jul 2001 18:36:48 -0000
Received: (qmail 1646 invoked from network); 13 Jul 2001 18:36:42 -0000
Received: from netmail.alcatel.com (128.251.168.50)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 18:36:42 -0000
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA21938;
	Fri, 13 Jul 2001 13:47:34 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6DIlX023995;
	Fri, 13 Jul 2001 13:47:33 -0500 (CDT)
Message-ID: <3B4F5DA0.412B61B9@usa.alcatel.com>
Date: Fri, 13 Jul 2001 13:44:16 -0700
From: Xiaofeng Xu <xiaofeng.xu@usa.alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby-paging@diameter.org, seamoby <seamoby@cdma-2000.org>
Subject: [seamoby] I-D draft-sarikaya-seamoby-hmip6hp-00.txt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hello,
  We submitted an I-D to IETF. It is also available at:
http://www.geocities.com/bsarikaya/draft-sarikaya-seamoby-hmip6hp-00.txt

Abstract

   This document specifies Hierarchical Mobile IPv6 Hierarchical Paging
   (HMIPv6HP), an IP host alerting protocol which is a link-layer
   independent extension to Hierarchical Mobile IPv6. The extension
   allows a mobile node to enter a power saving dormant mode during
   which its location is known with coarse accuracy defined by a paging
   area. In the visited domain only the paging mobility anchor point
   (PMAP) is responsible for keeping the binding cache entries for
   dormant mobile nodes and, it re-establishes the downlink routes on
   demand by means of paging. Paging is initiated by the paging agent
   (PA) and the access routers in paging areas and does not involve
   periodic layer 3 messages to be sent except for time-slot based
   paging which is optional and is to be used on links with no support
   for layer 2 paging.


Comments welcome.
  Kind regards,
--
Xiaofeng Xu



From owner-seamoby@diameter.org  Fri Jul 13 15:44:13 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29476
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 15:44:12 -0400 (EDT)
Received: (qmail 2735 invoked by alias); 13 Jul 2001 19:32:44 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2729 invoked by uid 200); 13 Jul 2001 19:32:43 -0000
Received: (qmail 2722 invoked by uid 500); 13 Jul 2001 19:32:40 -0000
Date: Fri, 13 Jul 2001 12:32:40 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Rajeev Koodli <rajeev@IPRG.nokia.com>
Cc: James Kempf <James.Kempf@Sun.COM>, seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- Phase CT
Message-ID: <20010713123240.B32517@charizard.diameter.org>
Mail-Followup-To: Rajeev Koodli <rajeev@IPRG.nokia.com>,
	James Kempf <James.Kempf@Sun.COM>, seamoby@cdma-2000.org
References: <200107111547.IAA22595@heliopolis.eng.sun.com> <3B4C97D3.7F876F9@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B4C97D3.7F876F9@iprg.nokia.com>; from rajeev@IPRG.nokia.com on Wed, Jul 11, 2001 at 11:15:47AM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Wed, Jul 11, 2001 at 11:15:47AM -0700, Rajeev Koodli wrote:
> 
> Hello,
> 
> I agree that there is much to gain from doing CT _with_ handover signaling. In
> fact, I have raised this issue of potential state inconsistency (what James calls
> synchronization problem below) a *few times* already in the mailing list. However,
> the value of CT should not be tied to MIP handovers alone. So, the way to make use
> of CT for MIP handovers is to separate the feature contexts from the actual
> signaling messages. This is outlined in draft-koodli-seamoby-ctv6-00.txt.

ok, finally got around to reading it. This is interesting because it
doesn't require CT to be tied to MIP, but allows it to be carried in
the same packet. I wonder, though, what the IESG would think about
the use of ICMP for CT. I know that they *really* frown upon UDP for
CT, so I wonder what their thoughts would be.

PatC


From owner-seamoby@diameter.org  Fri Jul 13 15:53:34 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00714
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 15:53:33 -0400 (EDT)
Received: (qmail 3288 invoked by alias); 13 Jul 2001 19:42:00 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 3282 invoked by uid 200); 13 Jul 2001 19:42:00 -0000
Received: (qmail 3273 invoked from network); 13 Jul 2001 19:41:57 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 19:41:57 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1KPSV>; Fri, 13 Jul 2001 15:52:19 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484455A4@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Rajeev Koodli <rajeev@IPRG.nokia.com>
Cc: James Kempf <James.Kempf@Sun.COM>, seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
	 lti- Phase CT
Date: Fri, 13 Jul 2001 15:52:15 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

So if we read between the lines (or eliminate the impossible
as Sherlock Holmes would) we are left with SCTP.  We just can't
say that SCTP is our only logical choice for CT yet can we????

:-)

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Friday, July 13, 2001 3:33 PM
> To: Rajeev Koodli
> Cc: James Kempf; seamoby@cdma-2000.org
> Subject: Re: CT reliability model was RE: [seamoby] [Issue] 
> Support for
> Mu lti- Phase CT
> 
> 
> On Wed, Jul 11, 2001 at 11:15:47AM -0700, Rajeev Koodli wrote:
> > 
> > Hello,
> > 
> > I agree that there is much to gain from doing CT _with_ 
> handover signaling. In
> > fact, I have raised this issue of potential state 
> inconsistency (what James calls
> > synchronization problem below) a *few times* already in the 
> mailing list. However,
> > the value of CT should not be tied to MIP handovers alone. 
> So, the way to make use
> > of CT for MIP handovers is to separate the feature contexts 
> from the actual
> > signaling messages. This is outlined in 
> draft-koodli-seamoby-ctv6-00.txt.
> 
> ok, finally got around to reading it. This is interesting because it
> doesn't require CT to be tied to MIP, but allows it to be carried in
> the same packet. I wonder, though, what the IESG would think about
> the use of ICMP for CT. I know that they *really* frown upon UDP for
> CT, so I wonder what their thoughts would be.
> 
> PatC
> 


From owner-seamoby@diameter.org  Fri Jul 13 15:57:11 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01310
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 15:57:10 -0400 (EDT)
Received: (qmail 3450 invoked by alias); 13 Jul 2001 19:42:53 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 3436 invoked by uid 200); 13 Jul 2001 19:42:48 -0000
Received: (qmail 3413 invoked by uid 500); 13 Jul 2001 19:42:35 -0000
Date: Fri, 13 Jul 2001 12:42:35 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)
Message-ID: <20010713124235.C32517@charizard.diameter.org>
Mail-Followup-To: Gary Kenward <gkenward@nortelnetworks.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>, seamoby@cdma-2000.org
References: <9FBD322B7824D511B36900508BF93C9C9F5E37@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E37@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Thu, Jul 12, 2001 at 01:33:37PM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Thu, Jul 12, 2001 at 01:33:37PM -0400, Gary Kenward wrote:
> So, if we do not put some sort of deading goal into the requirements, and
> describe
> how the protocol is expected to behave to reach that goal, and how it should
> behave
> if the goal is missed, then what is the point? I could transfer context
> using
> ftp and a dial up link (don't flame me, I like ftp).

But there isn't really anything you can do in a protocol to meet timing
requirements. This is all an implementation detail. I agree, btw, with
your observations, and don't have a particular issue with having a 
requirement to state this, but we must all agree that it isn't really
a "protocol" issue, but more how one invokes the protocol.

PatC


From owner-seamoby@diameter.org  Fri Jul 13 16:01:01 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01858
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 16:01:00 -0400 (EDT)
Received: (qmail 4233 invoked by alias); 13 Jul 2001 19:48:23 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 4220 invoked by uid 200); 13 Jul 2001 19:48:17 -0000
Received: (qmail 4201 invoked by uid 500); 13 Jul 2001 19:48:12 -0000
Date: Fri, 13 Jul 2001 12:48:12 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>, pcalhoun@diameter.org,
        seamoby@cdma-2000.org
Subject: [seamoby] Getting ready for London and other stuff
Message-ID: <20010713124812.D32517@charizard.diameter.org>
Mail-Followup-To: Gary Kenward <gkenward@nortelnetworks.com>,
	'Phillip Neumiller' <PNeumiller@MeshNetworks.com>,
	pcalhoun@diameter.org, seamoby@cdma-2000.org
References: <9FBD322B7824D511B36900508BF93C9C9F5E3F@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E3F@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Thu, Jul 12, 2001 at 03:02:08PM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Thu, Jul 12, 2001 at 03:02:08PM -0400, Gary Kenward wrote:
> I'm not saying the issues are unimportant; I am just concerned
> that the requirements will never be done, or more importantly,
> that the design will never start. 

I share your concerns, but I'd argue that it would be difficult to
design a protocol around requirements that are moving targets. The
whole point behind the IETF meeting is to make sure that we get past
this point.

I am collecting a list of what I perceive are issues. I believe that
we have a couple:
1. Should CT be tied to a mobility management protocol
2. To what point does the requirements spec need to define
   the modes of operation (e.g. proactive, reactive).

Any others that I may have missed?

PatC



From owner-seamoby@diameter.org  Fri Jul 13 16:05:01 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02336
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 16:05:00 -0400 (EDT)
Received: (qmail 4501 invoked by alias); 13 Jul 2001 19:50:11 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 4490 invoked by uid 200); 13 Jul 2001 19:50:06 -0000
Received: (qmail 4465 invoked by uid 500); 13 Jul 2001 19:49:57 -0000
Date: Fri, 13 Jul 2001 12:49:57 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Gary Kenward <gkenward@nortelnetworks.com>,
        "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)
Message-ID: <20010713124957.E32517@charizard.diameter.org>
Mail-Followup-To: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>,
	Gary Kenward <gkenward@nortelnetworks.com>,
	"'john.loughney@nokia.com'" <john.loughney@nokia.com>,
	seamoby@cdma-2000.org
References: <35DBB8B7AC89D4118E98009027B1009B017A9E99@IL27EXM10.cig.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <35DBB8B7AC89D4118E98009027B1009B017A9E99@IL27EXM10.cig.mot.com>; from Madjid.Nakhjiri@motorola.com on Thu, Jul 12, 2001 at 05:02:10PM -0500
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Thu, Jul 12, 2001 at 05:02:10PM -0500, Nakhjiri Madjid-MNAKHJI1 wrote:
> MN>> ok, this is a good point, are we envisioning different CTP
> functionality between proactive and reactive case? If yes, then it 
> is definitely a problem!!
> 

The sense I read at the moment is that these are modes of
operation more than protocol issues. I believe that these modes
should be described in the protocol spec, to guide implementors
of CT and link layers, but that's as far as it needs to go (IMHO).

PatC


From owner-seamoby@diameter.org  Fri Jul 13 16:08:45 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02862
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 16:08:45 -0400 (EDT)
Received: (qmail 4800 invoked by alias); 13 Jul 2001 19:52:24 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 4790 invoked by uid 200); 13 Jul 2001 19:52:18 -0000
Received: (qmail 4771 invoked by uid 500); 13 Jul 2001 19:52:13 -0000
Date: Fri, 13 Jul 2001 12:52:13 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: James Kempf <James.Kempf@sun.com>
Cc: pcalhoun@diameter.org, gkenward@nortelnetworks.com, seamoby@cdma-2000.org
Subject: Re: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
Message-ID: <20010713125212.F32517@charizard.diameter.org>
Mail-Followup-To: James Kempf <James.Kempf@sun.com>, pcalhoun@diameter.org,
	gkenward@nortelnetworks.com, seamoby@cdma-2000.org
References: <200107121733.KAA24139@heliopolis.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200107121733.KAA24139@heliopolis.eng.sun.com>; from James.Kempf@sun.com on Thu, Jul 12, 2001 at 10:33:02AM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Thu, Jul 12, 2001 at 10:33:02AM -0700, James Kempf wrote:
> I understand that MIP is only one of many, but I'm particularly concerned
> about MIP. View MIP as a customer. I would like the CT requirements, and,
> ultimately, the framework or protocol to support MIP.

Bingo!

PatC


From owner-seamoby@diameter.org  Fri Jul 13 16:14:21 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03677
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 16:14:19 -0400 (EDT)
Received: (qmail 6040 invoked by alias); 13 Jul 2001 20:02:29 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6034 invoked by uid 200); 13 Jul 2001 20:02:28 -0000
Received: (qmail 6029 invoked by uid 500); 13 Jul 2001 20:02:25 -0000
Date: Fri, 13 Jul 2001 13:02:25 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: James Kempf <James.Kempf@Sun.COM>
Cc: rajeev.koodli@nokia.com, seamoby@diameter.org
Subject: Re: [seamoby] Comments on draft-koodli-seamoby-ctv6-00.txt
Message-ID: <20010713130225.G32517@charizard.diameter.org>
Mail-Followup-To: James Kempf <James.Kempf@Sun.COM>,
	rajeev.koodli@nokia.com, seamoby@diameter.org
References: <200107122047.NAA04838@heliopolis.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200107122047.NAA04838@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Thu, Jul 12, 2001 at 01:47:52PM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

Actually, I have another comment. Figure 2, and the surrounding text,
implies that each blob is targetted for a particular flow. However,
what about state info that isn't flow specific? An example is some AAA
information, which is "session based". Is that what the top "context"
box implies? You may want to consider this in your next revision.

PatC
On Thu, Jul 12, 2001 at 01:47:52PM -0700, James Kempf wrote:
> Hi Rajeev,
> 
> I looked over your draft and I have some comments.
> 
> 1) pg. 5 I like your charaterization of GTP (not the other one) but the
> idea that it consists of a type identifier and *state* variables
> brings up a fundamental question w.r.t. context transfer. Protocols
> usually define the interface between two different network elements.
> State variables have to do with implementation. Isn't context
> transfer basically asking for implementations to be exposed?
> 
> For example, suppose I am SuperWhizzy QoS Router manufacturer and
> I have a router that supports the Diffserv  protocols just fine,
> so it interoperates, but inside I have my proprietary algorithms
> that make my router live up to its name. In order to provide state
> transfer, would I need to expose the internals of my algorithms
> so I could interoperate?
> 
> I'm not sure how to solve this problem, but I think you need to
> clarify that these state variables aren't internals of the implementation,
> but rather protocol-specified state variables that are part of the
> interface.
> 
> 2) pg. 5 What is the filter and handle alluded to in the last paragraph?
> There is not alot of detail as to what these are supposed to do.
> 
> 3) pg. 7 and the whole discussion of SHIN/SHAK header options. When
> I first read this, I thought these were being defined for the purpose
> of having the MN do context transfer to the router, which didn't make
> any sense to me. After I got to Section 5, however, it became clear
> that what you really mean is that the MN signals to the router that
> it wants particular context to be transfered. I think you need to
> rewrite it to make this clear (but see below for some comments on
> the utility of the SHIN/SHAK in the first place).
> 
> 4) Section 4.3-4.5 I like the idea of the context transfer being an
> extension to the HO messaging. Reduces the number of timers required
> in the router. And it is possible in IPv6. The only issue here is
> there has been some opinion expressed on the list that a reliable
> transport might be a better idea for context transfer, which would
> not be possible with ICMP extensions.
> 
> 5) pg. 12 - What happens if a router or MN asks for some context to
> be transfered and it is not available?
> 
> 6) pg 12 - What is an unsolicited SHREP? Up until this point, I don't
> think it has been described. You may want to describe it in the
> terminology section, or somehow earlier in the paper.
> 
> 7) pg. 13 Section 5.1 Actually, I think this scenario is pretty
> unlikely for slow speed links, or, if it occurs at all, it will probably occur 
> when there is almost no traffic between the MN and the network. I think
> that any scenario where the MN has to trigger the context transfer
> is not likely to occur when there is active traffic because it will involve
> messaging over the wireless link, which is the slowest. 
> 
> I think it more likely that context transfer occurs as part of the HI/HACK
> as described in Section 5.2. I don't think the MN needs to signal over
> the air to get the CT to happen (P-SHIN), I think that CT could be 
> triggered by the need for a handover. The L2 triggers draft, which
> should be out shortly, spells out requirements for L2 triggers to
> support CT.
> 
> With faster wireless protocols, the over-the-air signaling won't have
> as much cost (but it will always have a higher cost than over the wire),
> so the option should probably be kept in, but I think for standard
> 3G scenarios, triggering the context transfer as part of the need
> for a handover without any over-the-air signalling is likely to be
> much faster.
> 
> 		jak
> 
> 


From owner-seamoby@diameter.org  Fri Jul 13 16:28:50 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05795
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 16:28:49 -0400 (EDT)
Received: (qmail 6676 invoked by alias); 13 Jul 2001 20:16:35 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6663 invoked by uid 200); 13 Jul 2001 20:16:34 -0000
Received: (qmail 6652 invoked by uid 500); 13 Jul 2001 20:16:30 -0000
Date: Fri, 13 Jul 2001 13:16:30 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Govind.Krishnamurthi@nokia.com
Cc: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org,
        seamoby-context@cdma-2000.org
Subject: Re: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery
Message-ID: <20010713131630.J32517@charizard.diameter.org>
Mail-Followup-To: Govind.Krishnamurthi@nokia.com,
	mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org,
	seamoby-context@cdma-2000.org
References: <B9CFA6CE8FFDD211A1FB0008C7894E460440DE01@bseis01nok>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <B9CFA6CE8FFDD211A1FB0008C7894E460440DE01@bseis01nok>; from Govind.Krishnamurthi@nokia.com on Fri, Jul 13, 2001 at 09:48:04AM -0500
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Fri, Jul 13, 2001 at 09:48:04AM -0500, Govind.Krishnamurthi@nokia.com wrote:
> I'm resending the draft to the mailing list as I did not see it appear
> in the  archives. Sorry if you receive multiple copies.

Just for future reference, it is better to make a URL available for
folks that care, as opposed to the whole draft.

However, I'd like to note to the WG that this draft is the first
attempt at a Problem Statement. I would *highly* encourage folks to
comment on this draft so that we can get it completed on time.

Thanks,

PatC


From owner-seamoby@diameter.org  Fri Jul 13 16:32:54 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06453
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 16:32:53 -0400 (EDT)
Received: (qmail 6874 invoked by alias); 13 Jul 2001 20:17:50 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6865 invoked by uid 200); 13 Jul 2001 20:17:49 -0000
Received: (qmail 6846 invoked by uid 500); 13 Jul 2001 20:17:45 -0000
Date: Fri, 13 Jul 2001 13:17:45 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: "'Govind.Krishnamurthi@nokia.com'" <Govind.Krishnamurthi@nokia.com>,
        mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
Subject: Re: [seamoby] Resend:New Draft:Issues in Candidate Access Router Discovery
Message-ID: <20010713131745.K32517@charizard.diameter.org>
Mail-Followup-To: Phillip Neumiller <PNeumiller@MeshNetworks.com>,
	"'Govind.Krishnamurthi@nokia.com'" <Govind.Krishnamurthi@nokia.com>,
	mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
References: <0DF9FBC42474A24CA50F7A27FB08E0484455A1@meshpdc.meshnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E0484455A1@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Fri, Jul 13, 2001 at 11:36:46AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Fri, Jul 13, 2001 at 11:36:46AM -0400, Phillip Neumiller wrote:
> Amazing.  I am stunned.  Great start!  More useful comments
> later...  One comment right now is that I have a candidate
> algorithm in mind (:-)), also I am again finding it difficult
> to see how this will work with macro-diversity since you may
> want to have legs across ARs in different ADs but more on that
> later.  
> 
> This draft moves MIP from blind faith to "enlightenment"
> a mobility renaissance is under way in the MIP WG!!!

You enthusiasm is very encouraging.

Thanks Phil,

PatC


From owner-seamoby@diameter.org  Fri Jul 13 16:38:20 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07314
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 16:38:19 -0400 (EDT)
Received: (qmail 7481 invoked by alias); 13 Jul 2001 20:22:10 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 7461 invoked by uid 200); 13 Jul 2001 20:22:05 -0000
Received: (qmail 7443 invoked by uid 500); 13 Jul 2001 20:21:58 -0000
Date: Fri, 13 Jul 2001 13:21:57 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Theo Pagtzis <tpagtzis@IPRG.nokia.com>
Cc: James Kempf <James.Kempf@Sun.COM>, Govind.Krishnamurthi@nokia.com,
        mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org,
        seamoby-context@cdma-2000.org
Subject: Re: [seamoby] Re: [mobile-ip] Re: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router Discovery
Message-ID: <20010713132157.L32517@charizard.diameter.org>
Mail-Followup-To: Theo Pagtzis <tpagtzis@IPRG.nokia.com>,
	James Kempf <James.Kempf@Sun.COM>, Govind.Krishnamurthi@nokia.com,
	mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org,
	seamoby-context@cdma-2000.org
References: <200107131719.KAA15138@heliopolis.eng.sun.com> <3B4F3C05.A30C0140@iprg.nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B4F3C05.A30C0140@iprg.nokia.com>; from tpagtzis@IPRG.nokia.com on Fri, Jul 13, 2001 at 11:20:53AM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Fri, Jul 13, 2001 at 11:20:53AM -0700, Theo Pagtzis wrote:
> I would be glad to discuss with you guys about the issues on CAR discovery at the
> IETF in London.
> 
> I would like to propose then whether it would be possible to contribute to your
> draft my sections on the particular aspect and participate in a joint design
> process of that aspect on CAR discovery as a co-author. What do you think?

I certainly encourage it

PatC


From owner-seamoby@diameter.org  Fri Jul 13 16:46:39 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08513
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 16:46:36 -0400 (EDT)
Received: (qmail 8544 invoked by alias); 13 Jul 2001 20:34:42 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 8538 invoked by uid 200); 13 Jul 2001 20:34:42 -0000
Received: (qmail 8525 invoked by uid 500); 13 Jul 2001 20:34:38 -0000
Date: Fri, 13 Jul 2001 13:34:38 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Govind.Krishnamurthi@nokia.com
Cc: Dirk.Trossen@nokia.com, Hemant.Chaskar@nokia.com, james.kempf@sun.com,
        tpagtzis@iprg.nokia.com, pcalhoun@diameter.org, seamoby@cdma-2000.org
Subject: [seamoby] Re: FW: [seamoby-context] Resend:New Draft:Issues in Candidate Access Router  Discovery
Message-ID: <20010713133438.M32517@charizard.diameter.org>
Mail-Followup-To: Govind.Krishnamurthi@nokia.com, Dirk.Trossen@nokia.com,
	Hemant.Chaskar@nokia.com, james.kempf@sun.com,
	tpagtzis@iprg.nokia.com, pcalhoun@diameter.org,
	seamoby@cdma-2000.org
References: <B9CFA6CE8FFDD211A1FB0008C7894E460440DE05@bseis01nok>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <B9CFA6CE8FFDD211A1FB0008C7894E460440DE05@bseis01nok>; from Govind.Krishnamurthi@nokia.com on Fri, Jul 13, 2001 at 12:23:14PM -0500
Sender: owner-seamoby@diameter.org
Precedence: bulk

Govind,

If Theo has specific issues in his draft that do belong in the
problem statement, then we should consider those. However, being guilty
of not having the chance to read his I-D, if it is solution-space, then
it is premature.

That said, if Theo, or anyone else, has comments, or even better, proposed
text for the problem statement, and the WG agrees, then it needs to be
added.

PatC
On Fri, Jul 13, 2001 at 12:23:14PM -0500, Govind.Krishnamurthi@nokia.com wrote:
> Theo,
> Theo,
> I haven't read your draft yet. I will comment on your mail once I read
> it.
> Regarding a solution, we have one too but I think a solution is due only
> after the problem
> statement is described and the requirements are agreed upon. This is
> atleast how the IETF
> works as far as I know. Regarding our draft containing information from
> your draft, it is
> accidental. We have presented our draft as a first problem statement. If
> you feel that we haven't addressed some of the issues (well this is the
> 00 version afterall!)
> that you feel is necessary, go ahead and post it to the mailing list and
> we can go from
> there. 
> 
> Govind.
> 
> -----Original Message-----
> From: Theo Pagtzis [mailto:tpagtzis@IPRG.nokia.com]
> Sent: July 13, 2001 01:08 PM
> To: Govind.Krishnamurthi
> Cc: mobile-ip; seamoby; seamoby-context
> Subject: Re: [seamoby-context] Resend:New Draft:Issues in Candidate
> Access Router Discovery
> 
> 
> Govind,
> 
>     I have already provided a detailed protocol on pessimistic and
> optimistic proactivity in
> terms of router neighbour determination and candidacy. Please see
> draft-pagtzis-mobileip-proactivev6-00.txt/.ps
> 
> I have also gone a long way in specifying the notions of mobility and
> routing neighbourhood as well as
> provide an algorithm for their determination.
> 
> My proactive mobility scheme contains as part of it, exactly what you
> are describing as very briefly as
> physical neighbourhood and its mapping to a routing neighbourhood. There
> are however much more issues that
> are not elaborated in the targer AR determination. These are also
> covered in the draft on proactive mobility.
> 
> Also what is the date of your submission? Here your draft says it is
> July 2001. But what day?
> 
> 
> Theo
> 
> UCL/ Mobile Systems
> 
> 
> "Govind.Krishnamurthi" wrote:
> 
> > I'm resending the draft to the mailing list as I did not see it appear
> > in the  archives. Sorry if you receive multiple copies.
> > BRs,
> > Govind.
> >
> > Abstract:
> > Handoff in IP mobility protocols involves moving a mobile node's
> > Layer 3 routing reachability information from one access router to
> > another, before or after the mobile node has established a Layer 2
> > connection with the radio access point that is covered by the new
> > access router. In addition, other context information about the
> > mobile node's packet session may be transferred from the old access
> > router to the new one, in order to minimize the service disruption
> > during the handoff process. While the exact details of how this is
> > accomplished vary depending on the IP mobility and seamless handoff
> > protocols, one common thread required for seamless handoffs is
> > identifying the candidate access routers for the mobile node's
> > handoff. When a collection of candidates has been identified, an
> > algorithm is run to determine the target access router, and this
> > router becomes the target of handoff at Layer 3. This document
> > presents a problem statement describing issues involved in designing
> > a candidate access router discovery protocol. The document does not
> > discuss the algorithm by which the actual target router is
> > identified, nor how the handoff to the target is achieved.
> >
> > Comments are welcome.
> >
> > Best Regards,
> > Govind.
> >
> >  <<draft-ietf-seamoby-CARdiscovery-issues-00.txt>>
> >
> >
> ------------------------------------------------------------------------
> >                                                        Name:
> draft-ietf-seamoby-CARdiscovery-issues-00.txt
> >    draft-ietf-seamoby-CARdiscovery-issues-00.txt       Type: Plain
> Text (text/plain)
> >                                                    Encoding: base64
> >                                                 Description:
> draft-ietf-seamoby-CARdiscovery-issues-00.txt


From owner-seamoby@diameter.org  Fri Jul 13 16:50:29 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09087
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 16:50:28 -0400 (EDT)
Received: (qmail 8722 invoked by alias); 13 Jul 2001 20:35:50 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 8715 invoked by uid 200); 13 Jul 2001 20:35:49 -0000
Received: (qmail 8693 invoked from network); 13 Jul 2001 20:35:44 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 20:35:44 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15186;
	Fri, 13 Jul 2001 13:46:35 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA25073;
	Fri, 13 Jul 2001 13:46:35 -0700 (PDT)
Message-Id: <200107132046.NAA25073@heliopolis.eng.sun.com>
Date: Fri, 13 Jul 2001 13:46:34 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [seamoby] Getting ready for London and other stuff
To: gkenward@nortelnetworks.com, pcalhoun@diameter.org
Cc: PNeumiller@MeshNetworks.com, pcalhoun@diameter.org, seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: qDL/0nkb3h7NncHEoCdMnw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk


>I am collecting a list of what I perceive are issues. I believe that
>we have a couple:
>1. Should CT be tied to a mobility management protocol

I would rephrase this as:

  Should CT be designed as a framework that can be tied to a mobility
  protocol in addition to being a separate protocol or should it
  be just a standalone protocol.
  
That's a little verbose, but I think maybe you get the drift.

	jak
	
>2. To what point does the requirements spec need to define
>   the modes of operation (e.g. proactive, reactive).
>
>Any others that I may have missed?
>
>PatC
>



From owner-seamoby@diameter.org  Fri Jul 13 16:54:34 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09630
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 16:54:33 -0400 (EDT)
Received: (qmail 8930 invoked by alias); 13 Jul 2001 20:37:28 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 8924 invoked by uid 200); 13 Jul 2001 20:37:27 -0000
Received: (qmail 8908 invoked by uid 500); 13 Jul 2001 20:37:22 -0000
Date: Fri, 13 Jul 2001 13:37:22 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
Cc: seamoby <seamoby@cdma-2000.org>
Subject: Re: [seamoby] I-D draft-sarikaya-seamoby-hmip6hp-00.txt
Message-ID: <20010713133721.N32517@charizard.diameter.org>
Mail-Followup-To: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>,
	seamoby <seamoby@cdma-2000.org>
References: <3B4F3E88.A7993F36@usa.alcatel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B4F3E88.A7993F36@usa.alcatel.com>; from behcet.sarikaya@usa.alcatel.com on Fri, Jul 13, 2001 at 01:31:36PM -0500
Sender: owner-seamoby@diameter.org
Precedence: bulk

I take it that this is a candidate protocol for our domant host alerting
work (AKA paging), right? If so, then the WG is still waiting for the
IESG to accept the requirements spec, after which we will begin the
protocol work.

Thanks for the submission,

PatC

On Fri, Jul 13, 2001 at 01:31:36PM -0500, Behcet Sarikaya wrote:
> Hello,
>   We submitted an I-D to IETF. It is also available at:
> http://www.geocities.com/bsarikaya/draft-sarikaya-seamoby-hmip6hp-00.txt
> 
> Abstract
> 
>    This document specifies Hierarchical Mobile IPv6 Hierarchical Paging
>    (HMIPv6HP), an IP host alerting protocol which is a link-layer
>    independent extension to Hierarchical Mobile IPv6. The extension
>    allows a mobile node to enter a power saving dormant mode during
>    which its location is known with coarse accuracy defined by a paging
>    area. In the visited domain only the paging mobility anchor point
>    (PMAP) is responsible for keeping the binding cache entries for
>    dormant mobile nodes and, it re-establishes the downlink routes on
>    demand by means of paging. Paging is initiated by the paging agent
>    (PA) and the access routers in paging areas and does not involve
>    periodic layer 3 messages to be sent except for time-slot based
>    paging which is optional and is to be used on links with no support
>    for layer 2 paging.
> 
> 
> Comments welcome.
>   Kind regards,
> --
> Behcet
> 


From owner-seamoby@diameter.org  Fri Jul 13 17:00:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10457
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 17:00:31 -0400 (EDT)
Received: (qmail 9753 invoked by alias); 13 Jul 2001 20:43:30 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 9731 invoked by uid 200); 13 Jul 2001 20:43:24 -0000
Received: (qmail 9701 invoked from network); 13 Jul 2001 20:43:16 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 20:43:16 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA09637;
	Fri, 13 Jul 2001 13:53:38 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6DKrcb21128;
	Fri, 13 Jul 2001 13:53:38 -0700
X-mProtect:  Fri, 13 Jul 2001 13:53:38 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdHtrwZ1; Fri, 13 Jul 2001 13:53:36 PDT
Message-ID: <3B4F5FD0.93EF9B73@iprg.nokia.com>
Date: Fri, 13 Jul 2001 13:53:36 -0700
From: Theo Pagtzis <tpagtzis@IPRG.nokia.com>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>
CC: James Kempf <James.Kempf@Sun.COM>, Govind.Krishnamurthi@nokia.com,
        mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org,
        seamoby-context@cdma-2000.org
Subject: Re: [seamoby] Re: [mobile-ip] Re: [seamoby-context] Resend:New 
 Draft:Issues in Candidate Access Router Discovery
References: <200107131719.KAA15138@heliopolis.eng.sun.com> <3B4F3C05.A30C0140@iprg.nokia.com> <20010713132157.L32517@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Thanks Pat !

   This is definetely refreshing and more inspiring


Theo

UCL/ Mobile Systems


Pat Calhoun wrote:

> On Fri, Jul 13, 2001 at 11:20:53AM -0700, Theo Pagtzis wrote:
> > I would be glad to discuss with you guys about the issues on CAR discovery at the
> > IETF in London.
> >
> > I would like to propose then whether it would be possible to contribute to your
> > draft my sections on the particular aspect and participate in a joint design
> > process of that aspect on CAR discovery as a co-author. What do you think?
>
> I certainly encourage it
>
> PatC



From owner-seamoby@diameter.org  Fri Jul 13 17:08:18 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11484
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 17:08:17 -0400 (EDT)
Received: (qmail 10206 invoked by alias); 13 Jul 2001 20:47:10 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 10200 invoked by uid 200); 13 Jul 2001 20:47:09 -0000
Received: (qmail 10192 invoked by uid 500); 13 Jul 2001 20:47:07 -0000
Date: Fri, 13 Jul 2001 13:47:07 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Rajeev Koodli <rajeev@IPRG.nokia.com>,
        James Kempf <James.Kempf@Sun.COM>, seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- Phase CT
Message-ID: <20010713134707.Q32517@charizard.diameter.org>
Mail-Followup-To: Phillip Neumiller <PNeumiller@MeshNetworks.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>,
	Rajeev Koodli <rajeev@IPRG.nokia.com>,
	James Kempf <James.Kempf@Sun.COM>, seamoby@cdma-2000.org
References: <0DF9FBC42474A24CA50F7A27FB08E0484455A4@meshpdc.meshnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E0484455A4@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Fri, Jul 13, 2001 at 03:52:15PM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Fri, Jul 13, 2001 at 03:52:15PM -0400, Phillip Neumiller wrote:
> So if we read between the lines (or eliminate the impossible
> as Sherlock Holmes would) we are left with SCTP.  We just can't
> say that SCTP is our only logical choice for CT yet can we????

I hear you :)

As I've mentioned time and time again, if folks believe that another 
transport is better suited, please plead your case to the transport 
ADs. Perhaps given the necessary justification they could be swayed.

PatC


From owner-seamoby@diameter.org  Fri Jul 13 17:43:24 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15940
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 17:41:52 -0400 (EDT)
Received: (qmail 11654 invoked by alias); 13 Jul 2001 21:12:59 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 11648 invoked by uid 200); 13 Jul 2001 21:12:58 -0000
Received: (qmail 11643 invoked from network); 13 Jul 2001 21:12:55 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 21:12:55 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id OAA11837
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 14:23:18 -0700 (PDT)
X-Delivered-For: <seamoby@cdma-2000.org>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6DLNHm22399
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 14:23:17 -0700
X-mProtect:  Fri, 13 Jul 2001 14:23:17 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd1LDOUS; Fri, 13 Jul 2001 14:23:14 PDT
Message-ID: <3B4F66C3.C52E82F6@iprg.nokia.com>
Date: Fri, 13 Jul 2001 14:23:15 -0700
From: Rajeev Koodli <rajeev@IPRG.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@cdma-2000.org
Subject: [seamoby] Idle-mode CT, QoS CT draft submissions
Content-Type: multipart/mixed;
 boundary="------------AF1D37A98747CD1260DF9277"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------AF1D37A98747CD1260DF9277
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hello folks,

we have submitted the following drafts to the ID registrar. I am
attaching(sorry) them here for consideration by the group.

1. draft-westphal-seamoby-qos-relocate-00.txt.

2. draft-koodli-seamoby-idle-mode-ct-00.txt

Comments are welcome and will be appreciated.

Best Regards,

-Rajeev



--------------AF1D37A98747CD1260DF9277
Content-Type: text/plain; charset=us-ascii;
 name="draft-westphal-seamoby-qos-relocate-00.txt"
Content-Disposition: inline;
 filename="draft-westphal-seamoby-qos-relocate-00.txt"
Content-Transfer-Encoding: 7bit


Seamoby Working Group                                    Cedric Westphal
INTERNET DRAFT                                             Rajeev Koodli
13 July 2001                                          Charles E. Perkins
                                        Communication Systems Laboratory
                                                   Nokia Research Center

          Context Relocation of QoS Parameters in IP Networks
               draft-westphal-seamoby-qos-relocate-00.txt


Status of This Memo

   This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet- Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at:
        http://www.ietf.org/shadow.html.

   This document is an individual submission for the seamoby Working
Group of the Internet Engineering Task Force (IETF).  Comments should be
submitted to the SEAMOBY@DIAMETER:ORG  mailing list.

   Distribution of this memo is unlimited.


Abstract

   Seamless offering of Quality of Service (QoS) to a Mobile Node during
handovers is considered crucial for enabling a variety of application
services in the Mobile Internet.  In this document, we define the QoS
contexts and show how they could be transferred to enable seamless QoS
operation during handovers.  We introduce the notion of QoS Profile
Types and the associated QoS Profiles, which together constitute QoS
contexts, that facilitate QoS inter-operability among the pariticipating
access routers.  We also illustrate how these contexts can be used with
fast handover signaling.








Westphal, Koodli, Perkins        Expires 12 January 2002        [Page i]

Internet Draft            QoS Context Relocation            13 July 2001




                                Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       2

 2. Terminology                                                        3

 3. QoS Profile and QoS Profile Types                                  4
     3.1. QoS Profile Type  . . . . . . . . . . . . . . . . . . . .    5
     3.2. Examples of QoS Profile Data Structures . . . . . . . . .    6
           3.2.1. Best Effort QoS Profile Type  . . . . . . . . . .    6
           3.2.2. ``Default'' Intserv QoS Profile Type  . . . . . .    6
           3.2.3. DiffServ trTCM QoS Profile Type . . . . . . . . .    8
           3.2.4. Generic QoS Profile Type  . . . . . . . . . . . .    9

 4. QoS Context Transfer with Handover signaling                      10

 5. Message Formats                                                   12
     5.1. QoS Context Transfer Request ICMP Option  . . . . . . . .   12

 6. QoS Context Transfer Reply ICMP Option                            13
     6.1. QoS Context Transfer Request SHIN Suboption . . . . . . .   14
     6.2. QoS Context Transfer SHAK Suboption . . . . . . . . . . .   14

 7. Configurable Parameters                                           14

 8. Security Considerations                                           15

 9. IANA Considerations                                               15

 A. QoS Acknowledgment Response Codes                                 17
           A.0.1. QoS Profile Unavailable Acknowledgment Code Format  17
     A.1. QoS Context Transfer Error SHAK Suboption . . . . . . . .   17
           A.1.1. Resource Unavailable Error Data Format  . . . . .   18
           A.1.2. Bad Format Error Data Format  . . . . . . . . . .   18
           A.1.3. Context Unavailable Error Data Format . . . . . .   19

Addresses                                                             20








Westphal, Koodli, Perkins        Expires 12 January 2002        [Page 1]

Internet Draft            QoS Context Relocation            13 July 2001


1. Introduction

   Over the past few years, Quality of Service (QoS) has emerged as a
crucial technology for IP networks.  Considerable work has taken place
in IETF and in research circles to advance this technology leading to
a better understanding of its feasibility in a network the size of the
Internet.  However, very little work has taken place considering QoS
with device mobility.  Specifically, how to maintain and support QoS
for a mobile node's packet streams when it changes its access routers
is a problem of considerable interest, especially for those interested
in designing mobility protocols that offer seamless ``services'' across
handovers.

   The QoS mechanism offered in a network could be based either on
Differentiated Services architecture (DiffServ)[9], or an Integrated
Services architecture (IntServ)[8], or a combination of Intserv in
the access network and DiffServ in the core network (Intserv over
DiffServ)[10].  It is also possible that QoS is simply a default
Best-Effort service as it is in today's Internet.  In any case, prior
to handover, a Mobile Node (MN) attached to its Previous Router (Prtr)
receives certain amount of QoS from the network.  When the handover
takes place, for seamless operation, the New Router (Nrtr) must receive
the appropriate QoS state.  The failure to possess this state could
result in having to re-establish the QoS, potentially end-to-end, which
could delay the establishment of the proper connections throughout the
network.

   We take the position that context transfer is one of the components
of seamless handovers.  In any network, discovery of neighboring access
router capabilities is an important, independent process that provides
necessary information to effect seamless handovers.  Once the target
access router capability is known, context transfer could transmit only
the required state information.  When detailed capability information
regarding the target router is not available however, context transfer
has to be more generic, transferring the existing state assuming that it
would be useful at the receiver.  In any case, this transfer of feature
contexts has to be synchronized with the actual handover of the mobile
node from one access router to another.  It is important to bear in mind
that any feature context state is tightly related to packet forwarding.
This state could quickly get inconsistent if it does not intrinsically
follow the handover protocol which establishes basic packet forwarding.
While it is important to be able to effect context transfers with
handovers, it is also important that context transfers are not dependent
upon any particular handover mechanism.

   Driven by the postulation in the preceding paragraph, we focus in
this document to define feature contexts for QoS which can be used
along-with handover signaling.  We assume that a separate target
router selection process guides the context transfer protocol about



Westphal, Koodli, Perkins        Expires 12 January 2002        [Page 2]

Internet Draft            QoS Context Relocation            13 July 2001


the destination of context transfer.  We demonstrate how the context
definitions can be used with Fast Handover signaling for Mobile IPv6.
For this purpose, we make use of the new seamless handover options
defined in [3] and specific options for QoS defined in this document.
Using the introduction in [3], we define QoS Profile Types, which
capture the specific QoS state parameters present at an access router.
We define certain major profile types expected to be generally useful.
These definitions are provided in Section 3.

   The mechanism described in section 4 closely follows the structure
in [7] for the transfer of Header Compression context.

   In the rest of this document, we use Figure 1 as the reference for
discussion.



             v            +------------+
           +-+            |  Previous  |        <
           | | ---------- |   Router   | ------ > ----\
           +-+            |   (Prtr)   |        <      \
               MN         |            |                \
            |             +------------+            +---------------+
            |                   ^            IP     | Correspondent |
            |                   |         Network   |  Node         |
            V                   |                   +---------------+
                                v                        /
             v            +------------+                /
           +-+            |    New     |        <      /
           | | ---------- |   Router   | ------ > ----/
           +-+            |   (Nrtr)   |        <
              MN          |            |
                          +------------+



                      Figure 1: Reference Diagram




2. Terminology

   We define the following terms for use in this document.

      HAck Message
               The ICMP Handover Acknowledgment message, sent from the
               New Router to the Previous Router, and defined in [6].




Westphal, Koodli, Perkins        Expires 12 January 2002        [Page 3]

Internet Draft            QoS Context Relocation            13 July 2001


      HI Message
               The ICMP Handover Initiate message, sent from the
               Previous Router to the New Router, and defined in [6].

      New Router (Nrtr)
               The router to which the MN attaches after handover

      Previous Router (Prtr)
               The MN's default router prior to handover

      New access address (Naddr) The access IP address of the Mobile
               Node (MN) when attached to the link served by the New
               Router

      Previous access address (Paddr)
               The access IP Address of the Mobile Node (MN) when
               attached to the link served by the Previous Router

      Context Identifier (CID)
               A 16-bit unsigned integer that identifies a particular
               QoS context.

      Compression Profile Type (CPT)
               A 16-bit unsigned integer that indicates the type of QoS
               (see section 3).

      SHAK Message
               Any IPv6 message received by the mobile node containing
               the SHAK Destination Option defined in [3].

      SHIN Message
               Any IPv6 message sent by the mobile node containing the
               SHIN Destination Option defined in [3].

      SHREP Message
               The ICMP Smooth Handover Reply message, sent between
               access routers, and defined in [3].

      SHREQ Message
               The ICMP Smooth Handover Request message, sent between
               access routers, and defined in [3].


3. QoS Profile and QoS Profile Types

   A QoS Profile specifies the structure of the state variables which
are used for QoS. The QoS Profile Type (QPT), on the other hand,
provides a way to indicate which kind of QoS is provided to a particular
packet stream.  A QoS context thus includes QPT and the corresponding



Westphal, Koodli, Perkins        Expires 12 January 2002        [Page 4]

Internet Draft            QoS Context Relocation            13 July 2001


QoS Profile.  For seamless QoS establishment, the routers located at
separate network nodes must agree on the structure of these QoS state
parameters.  When the New Router receives the QoS context, it will
instantiate a QoS state machine for the packet stream in question.  That
new state machine will be created with the values of the state variables
taken from the QoS Profile contained in the appropriate message, and
interpreted according to the data structure and format defined by the
QPT.


3.1. QoS Profile Type

   The following QPTs are currently defined.

   10: reserved

   11: Best Effort

   12: IntServ Controlled-Load Service

   13: IntServ Guaranteed Service

   14: DiffServ default

   15: DiffServ srTCM

   16: DiffServ trTCM

   17: Generic

   Each QPT value is allocated an IANA type number.  The size of each
QPT is well-defined and is fixed.  A value of zero has special meaning
in suboption processing as outlined in Section 4.  This list in not
exhaustive.  For instance, there are different possible meters in a
DiffServ router architecture that would maintain different QoS states
and request different QPT.

   Some discussion regarding flow monitoring and metering is in order.
The monitoring and metering of the microflow behavior is usually done
using token buckets or some averaging process.  When token bucket
schemes are used, the only dynamic parameter is the token count.  Thus,
this parameter should be provided to the relevant token bucket at the
New Router.  If this parameter arrives after the service has started at
the New Router, then the new bucket count SHOULD be updated by taking
into account the value of the previous token count.  For instance, for
a buffer of depth B with a bucket count b1 at Previous Router, and a
buffer of depth B with a bucket count b2 not taking into account the
history of the flow, then, upon arrival of the QoS context, the new
buffer count should be adjusted to b3 = max( b2 + (b1-B),0).



Westphal, Koodli, Perkins        Expires 12 January 2002        [Page 5]

Internet Draft            QoS Context Relocation            13 July 2001


   In the case of a moving average, the new rate at the New Router
SHOULD be initialized to the corresponding value in the QoS Profile.
If the value and the early computation of the moving average starts
before the arrival of the QoS context, then, upon arrival of the QoS
context, the value of the moving average SHOULD be updated by taking
into account the value of the previous rate.  For instance, for a rate
r1 at the Previous Router, and a rate r2 at the New Router, then, upon
arrival of the QoS context, the new rate should be adjusted to r3 = p*r2
+ (1-p)*r1, with p = (time spent at New Router)/(total time length of
the connection).

   In the case of an average rate, the dynamic state is this rate.  The
rate at New Router has to be initialized to this value, with a weight
corresponding to the length of the connection.  The Previous Router MUST
provide a QoS Profile that the New Router can use.  This means that the
Previous Router must chose the format corresponding to the New Router
and attempt to fill it with its own data.  If it does not understand the
format corresponding to the New Router, then it MUST provide a generic
QoS Profile.


3.2. Examples of QoS Profile Data Structures

   We define a few example QoS Profile object formats.  We expect other
QoS Profiles to be similar to these examples.  Once again, the following
list is not exhaustive.  However, we do not expect a large number of
such data structures either.


3.2.1. Best Effort QoS Profile Type

   The QPT-BE is the context maintained by a router that does not
distinguish between the packet streams.  It does not maintain any
information besides the fact that the router does not keep microflow
states.

   It is the default QPT if no other one is provided.  The QPT code for
BE is 11 (cf.  Section 3.1).


3.2.2. ``Default'' Intserv QoS Profile Type

   We present here the default IntServ QoS Profile.  The QPT code for
this profile type is 12.  It is to be used when the IntServ type is
Controlled-Load service or when it is not known.







Westphal, Koodli, Perkins        Expires 12 January 2002        [Page 6]

Internet Draft            QoS Context Relocation            13 July 2001



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1  |  Type (TBD)   |   Length      |          QPT-BE               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




                Figure 2: Best-Effort QoS Profile Option



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1  |  Type (TBD)   |   Length      |  QPT-Default-Intserv          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2  |QoS Requirement(16-bit integer)|        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3  |     Average Data Rate (32-bit IEEE floating point number)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4  |Burstiness:Token Bucket Size(32-bit IEEE floating point number)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5  |     Peak Data Rate  (32-bit IEEE floating point number)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6  |        Minimum Policed Unit  (32-bit integer)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7  |        Maximum Packet Size  (32-bit integer)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8  |      Measured Rate  (32-bit IEEE floating point number)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9  |      Initial Token Count at New Router (32 bit IEEE fl. pt)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 |         Connection Length (timestamp)                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 |               Flags (future use)                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




        Figure 3: Composition of QoS Profile for default IntServ


   The QoS Context for a Controlled-load IntServ connection uses
the single token bucket specified in [13].  There is only one state
variable, the current token count, that becomes the initial token count



Westphal, Koodli, Perkins        Expires 12 January 2002        [Page 7]

Internet Draft            QoS Context Relocation            13 July 2001


at the New Router once context is established.  If the Previous Router
is not an IntServ Router, then it is unable to fill this specific field.
It sets the field either to a infinite value, meaning that the New
Router would set it to the bucket size, or to the bucket size requested
by the Burstiness parameter, if this parameter is available.

   The connection length field keeps track of the time the flow is in
use.


3.2.3. DiffServ trTCM QoS Profile Type

   We present here the DiffServ two rates Three Color Marker QoS Profile
Type.  It is one of the metering/marking devices introduced in the
DiffServ MIB (presented for instance in [11]).  The QoS Context state
that has to be transferred is composed of the configuration state and
the monitoring state.  Thus the state would be different for different
meters.  The trTCM is defined in [12].


































Westphal, Koodli, Perkins        Expires 12 January 2002        [Page 8]

Internet Draft            QoS Context Relocation            13 July 2001



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1  |  Type (TBD)   |   Length      |  QPT-Diffserv-trTCM           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2  |QoS Requirement(16-bit integer)|        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3  | Committed Information Rate (32-bit IEEE floating point number)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4  | Burstiness:Committed Bucket Size(32-bit IEEE floating point)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5  |     Peak Information Rate  (32-bit IEEE floating point number)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6  |     Peak Burst Size (32-bit IEEE floating point number)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6  |        Minimum Policed Unit  (32-bit integer)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7  |        Maximum Packet Size  (32-bit integer)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8  |    New Router  initial Committed Token Count                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9  |    New Router  initial Peak Token Count                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 |            Connection length   (time stamp)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 |            Flags (future use)                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



        Figure 4: Composition of QoS Profile for Diffserv trTCM



3.2.4. Generic QoS Profile Type

   The Previous Router uses this profile when it does not know the
capability of the New Router or when it does not understand the New
Router's capability.












Westphal, Koodli, Perkins        Expires 12 January 2002        [Page 9]

Internet Draft            QoS Context Relocation            13 July 2001



    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1  |  Type (TBD)   |   Length      |        QPT-Generic            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2  |QoS Requirement(16-bit integer)|        Reserved               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3  |         Data Rate (32-bit IEEE floating point number)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4  |    Burstiness:Token Bucket Size(32-bit IEEE floating point)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5  |     Peak Rate  (32-bit IEEE floating point number)            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6  |     Peak Burst Size (32-bit IEEE floating point number)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
6  |        Minimum Policed Unit  (32-bit integer)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7  |        Maximum Packet Size  (32-bit integer)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8  | Average Measured Data Rate (32-bit IEEE floating point number)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9  |    New Router  initial Burst Token Count                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
10 |    New Router  initial Peak Token Count                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
11 |            Connection length   (time stamp)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12 |            Flags (future use)                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



              Figure 5: Composition of Generic QoS Profile



4. QoS Context Transfer with Handover signaling

   In this section, we provide an illustration of how the QoS Profiles
and QPTs defined in the previous section can be transferred along-with
handover signaling.  Note that these QoS Contexts (i.e., QPT plus QoS
Profile) can be carried in other forms of messages as well, e.g.,
they could be carried in a Paging Message [14].  We use fast handover
signaling for Mobile IPv6 for our illustration here.

   The Previous Router, in response to either the network-initiated
handover or the mobile-initiated handover, sends a HI message to
the New Router.  In this HI message, it includes the Unsolicited



Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 10]

Internet Draft            QoS Context Relocation            13 July 2001


Seamless Handover Reply (U-SHREP) option defined in [3], which carries
the appropriate QoS contexts.  The actual QPT and the QoS Profiles
carried may depend on the knowledge the Previous Router has regarding
the New Router's QoS capabilities.  The Unsolicited SHREP option
carries an authentication token for the New Router to verify prior to
authorizing the feature contexts.  This token uses the session key that
gets established when the MN first connects to the Previous Router.
Alternative to carrying the token, the Unsolicited SHREP message could
instead carry the session key itself as one of the sub options.  In any
case, the network policy may require the New Router to authenticate the
MN prior to granting network access as well as feature contexts.  In
such a case, the MN has to respond to an appropriate challenege from
the New Router providing its own token that must match the one that the
New Router possesses.  The details of this mechanism described in [14]
for IP paging are applicable for our purposes here.  Once authorized
(whenever enforced), the New Router makes QoS contexts available to the
MN. The New Router SHOULD include a SHREP-Ack option in the HAck message
to the Previous Router.

   When fast handover signaling is either not available or fails, the
New Router fetches context subsequent to the MN's attachment to it.
The MN sends a SHIN message containing its Previous IP address and
Previous Router address to the New Router.  This SHIN can be embedded
as an option in the network access authentication message [15].  In
response to the SHIN message, recognizing that the required state is not
available, the New Router transmits a Seamless Handover Request (SHREQ)
message with QoS sub options.  And, the Previous Router responds back
with a Seamless Handover Reply (SHREP) message containing the actual
QoS context information.  See [3] for the details.  In this case, the
QoS context that is provided to the New Router is only the relevant
QoS context.  For instance, the two routers providing IntServ QoS can
exchange a context that has an IntServ granularity.

   Observe that even optimal handover procedures sometimes fail due
to the real-world dynamics including unpredictable physical terrains,
spotty coverage areas etc.  For instance, due to unfavorable terrain
conditions, the MN may lose link connectivity with its current AR and
establish a new link with a new AR. In such a case, the New Router
does not necessarily know the MN's Previous Router and its Previous IP
address.  However, the MN can supply this information, and it does this
by including it in the SHIN message.  Since there is no established
means for a MN to be certain that the New Router has knowledge of its
Previous Router and its Previous IP address (which is necessary to
identify the contexts), we propose including the SHIN option in all the
handover scenarios.  When context is already present at the New Router,
SHIN facilitates explicit authorization of feature contexts.  When the
context is not present, it triggers reactive context transfer.





Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 11]

Internet Draft            QoS Context Relocation            13 July 2001


5. Message Formats

   QoS options and suboptions are defined for use in several different
protocol message types:

    -  as an option or a sub option to a HI, HAck, SHREQ, or SHREP
       ICMPv6 messages.

    -  as a suboption of an IPv6 destination option.

    -  as an extension to a Mobile IPv4 registration request to be
       processed by a Foreign Agent.

    -  as an extension to some other seamless handover message to be
       defined in the future for mobile nodes using IPv4.

   The general format for the options is the same in all cases, as shown
in Figure 6.




   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   QOSOpt Type |   QOSOpt Len  |   QOSOpt Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




         Figure 6: QoS Options, Suboptions and Extension Format



5.1. QoS Context Transfer Request ICMP Option

   The QOSReq suboption is sent by Nrtr to Previous Router in the SHREQ
message to obtain QoS context on behalf of the mobile node.

   The New Router MAY request all of the relevant QoS context associated
with the mobile node, by sending QOSReq with suboption length equal to
zero.

   Suboption Type:  QOSReq-ICMP

   Suboption Length:  Variable

   The processing of this ICMP option at the Previous Router depends on
the availability of required QoS state, and is done in accordance with
requirements outlined in Section 3.2.  The New Router MUST respond with



Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 12]

Internet Draft            QoS Context Relocation            13 July 2001


the SHAK suboption defined in section 4.4.  The New Router, possibly
using the information sent by the Previous Router, MAY include suboption
QOSErr (defined below) in the SHAK message.


6. QoS Context Transfer Reply ICMP Option

   The QoS Context Transfer Reply suboption (QOSRep) suboption is
defined for Prtr to transfer state to Nrtr in the HI or SHREP ICMP
messages.  The QOSRep suboption includes the necessary state for Nrtr to
seamlessly carry-over QoS.




   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              CID              |              QPT              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      QoS State Variables ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                    Figure 7: QoS Reply Data Element


   The Option Type and Option Length fields of the QOSRep ICMP option
are followed by blocks consisting of [CID, QPT, QoS State variables]
tuple(s).  Each block has the format illustrated in Figure 7.

      CID     Context Identifier

      QPT     QoS Profile Type

      QoS State Variables
              Values for QoS state variables, in the format defined by
              the QPT

   The CID and QPT are 16-bit fields.  For a particular QPT, the size of
QoS state variables field is fixed; this allows inclusion of multiple
tuples without requiring a length indicator.

   If the suboption length is zero, it indicates that Prtr cannot supply
the required QoS level to Nrtr.  In case of errors, Prtr SHOULD include
the QOSErr suboption defined in section 4.5 in the SHREP message.

   When the value of QPT is zero in a tuple, it indicates that the
Previous Router cannot supply state information for the associated
context identified by the CID. In this case also, Prtr SHOULD



Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 13]

Internet Draft            QoS Context Relocation            13 July 2001


include suboption QOSErr (e.g., to indicate that suboption QOSReq was
incorrectly formatted) in the packet.


6.1. QoS Context Transfer Request SHIN Suboption

   When the mobile node wishes to continue receiving the same level
of QoS at Nrtr, it sends the QoS Context Transfer Request (QOSReq)
suboption in a message addressed to Nrtr containing a SHIN Destination
Option.

   Suboption Type:  QOSReq-SHIN

   Suboption Length:  Variable

   When the QOSReq is present in a SHIN message and the suboption length
is zero (the default value), this suboption indicates the MN's desire to
continue with the same QoS features as prior to handover.


6.2. QoS Context Transfer SHAK Suboption

   The QoS Context Transfer Acknowledge suboption (QOSAck) is defined
for inclusion in the SHAK IPv6 Destination Option, and is used by Nrtr
to respond to the mobile node.  Note that SHAK is an optional message.
The MN SHOULD be prepared to accept packets treated with feature
contexts even when it does not receive a SHAK message.

   Suboption Type:  QOSAck-SHAK

   Suboption Length:  Variable

   When the suboption length is zero (the default value), this suboption
indicates that MN's request to continue with the QoS level was accepted
at Nrtr without any modifications to the context parameters.

   When the suboption length is non-zero, the QOSAck data has the format
shown in Figure 8.

   Each acknowledgment code specifies the format of the QOSAck data
field, which contains the data associated with the acknowledgment.  The
currently defined acknowledgment codes are described in the appendix.


7. Configurable Parameters

   The nodes supporting mobility defined in this document SHOULD be able
to configure the parameters outlined below as well those in [4].  Each
table entry contains the name of the parameter and the default value.



Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 14]

Internet Draft            QoS Context Relocation            13 July 2001




   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   QOSAck Code |   QOSAck Len  |       QOSAck Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




     Figure 8: QoS Context Transfer SHAK Suboptions (QOSAck) format




      Parameter Name            Default Value
      -------------------------------------------------
      QOS\_CONTEXT\_SAVE\_TIME      2 * SHREQ\_REXMIT\_TIME
      QOS\_CONTEXT\_PURGE\_TIME     5 * SHREQ\_REXMIT\_TIME
      SHIN\_WAIT\_TIME            1000 milliseconds



8. Security Considerations

   All context transfer for QoS MUST be secured by use of the
Authentication suboption [4], or the IPv6 Authentication Header [2].
Thus, no additional vulnerability has been introduced.


9. IANA Considerations

   The QoS Profile Type (QPT) defined in this document requires IANA
Type numbers.


References

    [1] J. Bound and C. Perkins. Dynamic Host Configuration Protocol
        for IPv6 (DHCPv6) (work in progress). Internet Draft, Internet
        Engineering Task Force, May 2000.

    [2] S. Kent and R. Atkinson. IP Authentication Header. Request for
        Comments (Proposed Standard) 2402, Internet Engineering Task
        Force, November 1998.

    [3] R. Koodli and C. Perkins. A Context Transfer Framework for
        Seamless Mobility (work in progress). Internet Draft, Internet
        Engineering Task Force. draft-koodli-seamoby-ctv6-00.txt,
        February 2001.



Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 15]

Internet Draft            QoS Context Relocation            13 July 2001


    [4] R. Koodli and C. Perkins. A Framework for Smooth Handovers
        with Mobile IPv6 (work in progress). Internet Draft, Internet
        Engineering Task Force. draft-koodli-mobileip-smoothv6-01.txt,
        November 2000.

    [5] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
        IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461,
        Internet Engineering Task Force, December 1998.

    [6] G. Tsirtsis and et al. Fast Handovers for Mobile IPv6(work in
        progress). Internet Draft, Internet Engineering Task Force.
        draft-designteam-fast-mipv6-01.txt, February 2001.

    [7] R. Koodli, M. Tiwari, C. Perkins. Context Relocation
        for Seamless Header Compression in IP Networks (work in
        progress). Internet Draft, Internet Engineering Task Force.
        draft-koodli-seamoby-hc-relocate-00.txt

    [8] J. Wroclawski. The Use of RSVP with IETF Integrated Services.
        RFC 2210, Internet Engineering Task Force.

    [9] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss.
        An Architecture for Differentiated Service. December 1998. RFC
        2475, Internet Engineering Task Force.

   [10] Y. Bernet et al., A Framework for Integrated Services Operation
        over Diffserv Networks. RFC 2998, Internet Engineering Task
        Force.

   [11] Bernet et al., DiffServ Informal Management Model,
        draft-ietf-diffserv-model-06.txt (work in progress)

   [12] J. Heinanen, A two rate Three Color Marker, RFC 2698

   [13] S. Shenker, J. Wroclawski, General Characterization Parameters
        for Service Network Elements, RFC 2215.

   [14] R. Koodli and J. T. Malinen. Idle-mode Context
        Transfers in IPv6 Networks (work in progress).
        Internet Draft, Internet Engineering Task Force.
        draft-koodli-seamoby-idle-mode-ctv6-00.txt, July 2001

   [15] N. Asokan, Patrik Flykt, C. Perkins and Thomas Eklund. AAA for
        IPv6 Network Access (work in progress). Internet Draft, Internet
        Engineering Task Force.







Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 16]

Internet Draft            QoS Context Relocation            13 July 2001


A. QoS Acknowledgment Response Codes

   In this section, we define the various error codes sent back to the
MN in response to its request for QoS context transfer.


A.0.1. QoS Profile Unavailable Acknowledgment Code Format

   The QoS Acknowledgment Code block for QPT_UNAVAILABLE is as shown in
Figure 9




    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | QOSAck Code=2 |   Length      |  [CID,New-CID] pairs...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



         Figure 9: QPT UNAVAILABLE acknowledgement Data format


      Code:   02 (QPT_UNAVAILABLE)

      Length: Variable

   The data for the QPT_UNAVAILABLE acknowledgment code consists
of [CID, New-QPT] tuple(s), one for each requested QPT that was
unavailable.  When the value of QPT is zero in a tuple, it indicates
that the associated context identified by the CID was not activated.  In
this case, Nrtr MAY include suboption QOSErr with an appropriate error
code indicating the reason for failure to activate the context.


A.1. QoS Context Transfer Error SHAK Suboption

   The QoS Context Transfer SHAK Error Suboption (QOSErr) allows the
access routers to supply error codes when activation fails for one or
more QoS level requests.  The QOSErr data format is shown in Figure 10.

   Suboption Type:  QOSErr-SHAK

   Suboption Length:  Variable

   Each error code specifies the format of the QOSErr data field, which
contains the data associated with the error condition.  The currently
defined error codes are specified in the following sections.




Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 17]

Internet Draft            QoS Context Relocation            13 July 2001




    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  QOSErr Code  | QOSErr Length |   QOSErr Error Code Blocks...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



              Figure 10: QoS Context Transfer Error Format



A.1.1. Resource Unavailable Error Data Format

   The QoS Error Code block for RESOURCE_UNAVAILABLE is as shown in
Figure 11.



    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | QOSErr Code=1 |   Length = 0  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




              Figure 11: RESOURCE UNAVAILABLE error format


      Code:   01 (RESOURCE_UNAVAILABLE)

      Length: 0

   The RESOURCE_UNAVAILABLE error has no associated error data.  This
error is returned when no resources are available.  This code indicates
that Nrtr does not have the resources required to set up QoS context(s)
for this MN. The MN MUST deactivate the previous QoS state.  It MAY
either start sending packets expecting only Best Effort service in this
case, or it may re-negotiate with Nrtr to activate a new QoS level and a
QoS profile.


A.1.2. Bad Format Error Data Format

   The QoS Error Code block for BAD_FORMAT is as shown in Figure 12.

      Code:   02 (BAD_FORMAT)

      Length: Variable



Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 18]

Internet Draft            QoS Context Relocation            13 July 2001




    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | QOSErr Code=2 |   Length      |  Offending Suboption ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                   Figure 12: BAD FORMAT error format



   This error indicates that the context transfer request was poorly
formatted.  If a router does not understand the format of a particular
suboption, it sends QOSErr with this code; and the data part contains
the

   details of the suboption which caused this error.  The Previous
Router SHOULD send this suboption to Nrtr whenever appropriate, and Nrtr
MAY send this suboption to the MN.


A.1.3. Context Unavailable Error Data Format

   The QOS Error Code block for CONTEXT_UNAVAILABLE is as shown in
Figure 13.

      Code:   03 (CONTEXT_UNAVAILABLE)

      Length: Variable

   The QOSErr data for this code contains the CIDs representing contexts
which are not available for transfer.  This might happen because


    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    | QOSErr Code=3 |   Length      |  Unavailable CIDs ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





              Figure 13: CONTEXT UNAVAILABLE error format


   the context has already been removed at both the routers in the
fast handover case.  Note that Nrtr MAY remove the state supplied




Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 19]

Internet Draft            QoS Context Relocation            13 July 2001


by Prtr if Nrtr does not receive a SHIN message from the MN within
QOS_CONTEXT_SAVE_TIME.


Addresses

   Questions about this memo can also be directed to the authors:


      Cedric Westphal                    Rajeev Koodli
      Communications Systems Lab         Communications Systems Lab
      Nokia Research Center              Nokia Research Center
      313 Fairchild Drive                313 Fairchild Drive
      Mountain View, California 94043    Mountain View, California 94043
      USA                                USA
      Phone:  +1-650 625-2247            Phone:  +1-650 625-2359
      EMail:  cedric@iprg.nokia.com      EMail:  rajeev.koodli@nokia.com
      Fax:  +1 650 625-2502              Fax:  +1 650 625-2502


      Charles Perkins
      Communications Systems Lab
      Nokia Research Center
      313 Fairchild Drive
      Mountain View, California 94043
      USA
      Phone:  +1-650 625-2986
      EMail:  charliep@iprg.nokia.com
      Fax:  +1 650 625-2502























Westphal, Koodli, Perkins       Expires 12 January 2002        [Page 20]

--------------AF1D37A98747CD1260DF9277
Content-Type: text/plain; charset=us-ascii;
 name="draft-koodli-seamoby-idle-mode-ct-00.txt"
Content-Disposition: inline;
 filename="draft-koodli-seamoby-idle-mode-ct-00.txt"
Content-Transfer-Encoding: 7bit


Seamoby Working Group                                      Rajeev Koodli
INTERNET DRAFT                                           Jari T. Malinen
13 July 2001                            Communication Systems Laboratory

              Idle Mode Handover Support in IPv6 Networks
                   draft-koodli-idle-mode-ctv6-00.txt


Status of This Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet- Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at:
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at:
        http://www.ietf.org/shadow.html.

This document is an individual submission for the mobile-ip Working
Group of the Internet Engineering Task Force (IETF).  Comments should be
submitted to the seamoby@diameter:org  mailing list.

Distribution of this memo is unlimited.


Abstract

This document considers the problem of expediting authenticated network
access as well as enabling authorized context transfer during idle-mode
handovers.  In essence, this document addresses idle-mode context
transfers, so that an idle-mode Mobile Node (MN) can resume its sessions
in a seamless fashion.  We propose supplying the session key in the
paging message to the Access Router (AR) that locates the idle Mobile
Node.  Subsequently, the AR issues a local challenge in the router
advertisement, and the MN replies with a hash of session key, its
previous IP address and the local challenge.  The new AR grants network
access once its own hash matches that supplied by the MN. We demonstrate
how this simple procedure can be used for any generic context transfers.








Koodli, Malinen            Expires 13 January  2002             [Page i]

Internet Draft          Idle Mode Handover Support          13 July 2001




                                Contents


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       2

 2. Terminology                                                        3

 3. Idle Handover Considerations                                       4

 4. Protocol Messages                                                  6
     4.1. Key Distribution Extension to the Paging Message  . . . .    6
     4.2. Context Transfer Extension to the Paging Message  . . . .    7
     4.3. Router Advertisement with AAAv6 Local Challenge . . . . .    8
     4.4. AAAv6 Request for Idle Mode Handover Support  . . . . . .   10
     4.5. AAAv6 Reply for Idle Mode Handover Support  . . . . . . .   12

 5. Protocol Constants                                                14

 6. Security Considerations                                           14

Addresses                                                             15

























Koodli, Malinen            Expires 13 January  2002             [Page 1]

Internet Draft          Idle Mode Handover Support          13 July 2001


1. Introduction

When a MN powers up in a visited domain and obtains link connectivity
with the network, a network policy may require that MN performs network
layer authentication prior to obtaining IP connectivity.  This is
critical in order to provide a mechanism for the network provider to
ensure unabused network access.  The specification in [1] outlines a
mechanism based on ICMP protocol that could be used in conjunction with
other protocols, such as IPv6 address auto-configuration and Mobile
IPv6, in order to provide this kind of network layer authentication.
Provided the MN is authorized to access the network, this protocol then
enables a security association between a MN and its default Access
Router (AR) and supplies both the entities the necessary security
keys.  The MN then uses the supplied key in securing its communication,
whenever necessary, with its AR.




             v                     +------------+
           +-+                     |  Previous  |
           ! ! -----------------   |  Access    |
           +-+                     | Router(PAR)|
               MN                  |            |
            |                      +------------+
            |                            |
            |                            | IP Paging Message
            |                            |
            |                            V
            |                ...........................
            |               .                           .
            |              .   Paging area multicast     .
            V             .           group               .
                         .                                 .
             v        +------------+  +------------+  +------------+
           +-+        |    New     |  |    New     |  |    New     |
           | | -------|  Access    |  |  Access    |  |  Access    |
           +-+        | Router(NAR)|  | Router(NAR)|  | Router(NAR)|
              MN      |            |  |            |  |            |
                      +------------+  +------------+  +------------+




          Figure 1: Reference Scenario for Idle-Mode Handover


Once authorized to use the network prefix advertised by the AR, the MN
may proceed to send IP packets.  For instance, the MN may send a Binding



Koodli, Malinen            Expires 13 January  2002             [Page 2]

Internet Draft          Idle Mode Handover Support          13 July 2001


Update to its Home Agent to inform about its new location.  Note that
for performance reasons, it is possible to combine the Binding Update
with network authentication messages, as proposed in [1].  Here, we
assume a logical separation between the two protocols.  Nevertheless,
the MN may then engage in active packet transmission and reception, or
it may remain idle.  Observe that the MN may establish feature contexts
for its packet streams and then enter idle-mode.  For example, the MN
may establish QoS context for its `www' traffic, engage in active data
communication, and then transition to idle state.  Furthermore, the MN
may enter idle mode even while engaged in active communication due to
the bursty nature of packet data communication.  Subsequently, the MN
undergoes a handover while remaining in idle-mode.  See Figure 1

The purpose of this document is to address the problem of expeditiously
authenticating network access (for the MN) as well as authorizing feature
contexts (to the MN) during idle-mode handovers.  In essence, this
document addresses idle-mode context transfers, so that an idle-mode
Mobile Node (MN) can resume its sessions in a seamless fashion.  We
propose a solution using simple extensions to paging messages that would
allow us to meet our objectives without the need for a dedicated paging
server or additional entries in the routing tables.


2. Terminology

      Mobile Node       A host that attaches to a network, untethered or
                        otherwise, and changes its point of attachment
                        due to host mobility.

      Idle mode         A state internal to a Mobile Node in which the
                        MN is not in active packet transmission or
                        reception.  This definition assumes that it is
                        possible for a MN to enter idle mode, e.g., due
                        to silence intervals, when it has an active
                        traffic channel.

      Paging            A mechanism by which a network locates a MN
                        in idle mode, in order to, e.g., deliver an
                        incoming packet [3].

      (Access) Authentication The process by which an Access Router
                        (AR) verifies the MN's credentials and grants
                        (authorizes) network access [1].

      Context Transfer  The process by which state information
                        pertaining to a MN is transferred from one AR
                        to another, perhaps to facilitate seamless
                        operation of applications running on the MN [6].




Koodli, Malinen            Expires 13 January  2002             [Page 3]

Internet Draft          Idle Mode Handover Support          13 July 2001


3. Idle Handover Considerations

We begin with a set of assumptions.  First, we assume that each paging
area is uniquely identified by an IP multicast group called ``all access
router's multicast group'', whose members are the ARs that constitute
the paging area.  Second, a Mobile Node does not perform paging area
registrations when inside the same paging area.  The mechanisms by which
a MN determines that it is within the boundary of the same paging area
are beyond the scope of this document.  It may make use of any known
mechanism; for example, it may make use of the paging area identifier
typically advertised on the broadcast channel to determine its location
with respect to the paging area.  Third, an AR originates an IP paging
message when it determines that it cannot deliver an IP packet to its
MN. The mechanism by which an AR determines that a MN that was attached
to it is no longer visible is not specified in this document.  An
AR may be able to realize this by, for example, explicit idle mode
registrations or (implicitly) via timer expirations.  Note that because
of this assumption, we see no reason for a specialized paging server in
our discourse.  Note also that there is no need for additional routing
table entries in this model.  Finally, we assume that all the members of
the all access routers multicast group share security association with
each other.

We consider the two idle mode scenarios outlined earlier.  We start
with the case where the MN moves without having initiated active data
communication.

Recall that the MN first establishes network connectivity.  This means,
at the very least, the state corresponding to security association
should be present at both the MN and its default AR. Now, let us assume
that the MN moves to a subnet controlled by a different AR, yet within
the same paging area.  As mentioned earlier, we assume that the MN does
not send a paging area registration message if operating within the
same paging area.  This assumption is necessary since a paging area
registration may entitle the MN to IP connectivity, in which case, the
routing of IP packets follows normal Mobile IP procedures.  Now, if a
packet arrives at the previous AR for the MN, the previous AR has to
locate the MN in order to deliver the packet.  We assume that an IP
paging message would be available for this purpose.  Whereas the exact
form and nature of such a message is not standardized yet, we will
assume the message outlined in [9], and identify extensions needed.

In [9], the PAR uses a well-known multicast address, the ``all access
routers multicast group'', to send the paging request, which we call
the ``IP paging message''.  All the ARs within the paging area are
members of this multicast group, and thus receive the paging request
packet.  Each AR then sends an unsolicited router advertisement that
contains the MN's IP address established while connected to PAR. This
message may trigger Layer 2 (L2) paging, when present, on each AR in



Koodli, Malinen            Expires 13 January  2002             [Page 4]

Internet Draft          Idle Mode Handover Support          13 July 2001


order to wake up the sleeping MN. The MN, once paged, has to determine
that it has changed its AR by verifying the source address in the router
advertisement, begin to formulate a new IP address, and then respond to
the IP paging request.

When the MN wakes up and realizes that it has changed its AR, it may be
required to perform network access authentication described earlier.
This procedure is time-consuming given the delays in accessing the MN's
home network AAA and the Home Agent.  In order to minimize this delay,
we propose to transfer the key from PAR to all the potential access
routers which are members of the ``all access routers multicast group''
in the IP paging message.  We assume that the MN first established
authenticated network access with PAR.

In the unsolicited router advertisement message that follows the IP
paging message, each AR sends and caches a random number in a local
challenge requiring the MN to return a token that is a hash of network
prefix advertised, the random number in the local challenge and the key
that the MN possesses.  Each AR uses the key supplied in the IP paging
message to compute its own hash and allows network access if the token
supplied by the MN matches its computation.  The MN uses the Embedded
Data Option in the AAAv6 Request message in [1] to include this token
as well as other information, such as the Binding Update message.  When
the AR receives the AAAv6 Request, it determines that the AAAv6 Request
message corresponds to the unsolicited router advertisement (sent in
response to the paging message) by inspecting the Embedded Data Option
containing the above-mentioned hash.

The above key transfer concept can indeed be applied to handle generic
feature contexts.  The MN's contexts at PAR are transferred gratuitously
to all the ARs in the paging area multicast group.  When the network
policy requires explicit authorization of these contexts, each AR
mandates that the MN presents a separate access authentication token
such that the AR can verify authenticity of the feature context request.
This token is generated according to HMAC-MD5-96 [7] using the random
number advertised in the Local Challenge as an input parameter.  The
details of this token computation are specified in the description of
Seamless Handover Initiate (SHIN) option [5].

We propose using the SHIN option as an embedded data in the AAAv6
request for explicit authorization of the feature context requests.
The new AR verifies that the token present in the SHIN matches its
own computation and makes the contexts available to the MN. It then
generates a SHREQ message to the PAR that originated the IP paging
message in order to set up a forwarding path for packets arriving at
PAR. The PAR SHOULD generate a SHREP message indicating the response
for the SHREQ message.  The new AR MAY send a SHAK message indicating
authorization of contexts to the MN. The MN SHOULD be prepared to handle
packets treated with feature contexts without expecting a SHAK message.



Koodli, Malinen            Expires 13 January  2002             [Page 5]

Internet Draft          Idle Mode Handover Support          13 July 2001


Note that context transfer could happen reactively following paging.
That is, the AR that locates the MN would initiate the transfer of
contexts from the PAR in response to successfully authenticating the MN
and (optionally) processing the SHIN option.  In such a scenario, only
the session key is transferred from the PAR to the members of the paging
area.  The net effect is that fewer bytes are sent in the access network
since context transfer only happens between the AR that locates the MN
and the PAR.


4. Protocol Messages

In this section, we describe new protocol messages or options used
in the protocol extensions described earlier.  When paging occurs, a
session key is passed along with the paging message.  A paging message
triggers a router advertisement which is required to contain a Local
Challenge (LC) as in AAAv6.  The router advertisement invokes the mobile
node to perform a localized AAAv6 request and reply exchange with the
AR.


4.1. Key Distribution Extension to the Paging Message

We assume that a paging entity sends a paging message containing the
IP address of the MN to a multicast group specific for the paging
area.  A paging message can be, e.g., a Paging Request Message as
specified in [9].  Since the exact form of a Paging Message has not been
standardized yet, we define a generic session key option which is shown
in Figure 2.  This option can be carried (with suitable padding whenever
necessary) in an appropriate paging message.  The receiving AR extracts
the session key from this option, where the key is encrypted using
pre-existing shared key between the originator of the paging message and
the receiving access router.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    |      Alg      |   Key Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              SPI                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              Key...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                      Figure 2: Session Key Option





Koodli, Malinen            Expires 13 January  2002             [Page 6]

Internet Draft          Idle Mode Handover Support          13 July 2001


      Type       TBD (skippable), one for key request, one for key reply

      Length     8-bit unsigned integer.  The length of the option
                 (including the type and length fields) in units of 8
                 octets.

      Alg        8-bit algorithm indication as specified for the
                 Authentication Header [4].

      Key Length

                  8-bit unsigned integer.  The length of the key in
                 units of 4 octets.

      SPI        32-bit Security Parameter Index value.

      Key        Encrypted key.


4.2. Context Transfer Extension to the Paging Message

A paging entity may use this option to gratuitously supply the contexts
established at PAR to all the members of the paging area.  Such an
action could provide performance benefits, since data communication
typically follows paging.  The option is shown in Figure 3.


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |     Length    |          Reserved             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +             One or more feature contexts                      +
   |                                                               |
   ~                                                               ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                   Figure 3: Context Transfer Option










Koodli, Malinen            Expires 13 January  2002             [Page 7]

Internet Draft          Idle Mode Handover Support          13 July 2001


      Type       (skippable) Gratuitous Context Transfer.

      Length     8-bit unsigned integer.  The length of the option
                 (including the type and length fields) in units of 8
                 octets.

As with the Session Key option, this option is also carried in an
appropriate paging message.  The AR that locates the MN then authorizes
the use of received contexts after successfully processing the SHIN
option from the MN.


4.3. Router Advertisement with AAAv6 Local Challenge

The paging message is received by access routers in the paging area.  A
subsequent router advertisement message, described in this section, is
sent out by each Access Router.  The router advertisement as specified
by Neighbor Discovery [8] is modified to include the local challenge as
specified in [1].  The AR uses the value in local challenge in computing
the access authentication token.

The extension appears as a Router Advertisement option shown in 4.






























Koodli, Malinen            Expires 13 January  2002             [Page 8]

Internet Draft          Idle Mode Handover Support          13 July 2001


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{1}|   Router Advertisement Options                                |
   |    . . .                                                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}| Type          |    Length     |  Sequence no  | Rsvd          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Challenge                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


       Figure 4: Router Advertisement with AAAv6 local challenge


{1} Router Advertisement Options

A paging option contains the IP address of the paged MN. It is possible
to send a page to a group of dormant mobiles by associating a multicast
address with that group.  In such a case, this option includes the IP
addresses of all the paged mobiles.  May also include target Link-layer
address, Prefix Information Options, etc.

{2} AAAv6 Challenge Option in the router advertisement

      Type

         9 = ICMPv6 Router Advertisement Local Challenge Option

      Length

         1 = Length in 8 octets including the type and length fields

      Sequence Number

         a monotonically increasing integer that associates the IP
         address, Challenge and the Key tuple.  The MN supplies this
         value in addition to the hash it generates to aid the AR in
         verifying the checksum computation.

      Reserved

         0 = Ignored on reception

      Challenge

         This is a 32-bit random number generated by the access router
         and used to prevent replay attacks.




Koodli, Malinen            Expires 13 January  2002             [Page 9]

Internet Draft          Idle Mode Handover Support          13 July 2001


4.4. AAAv6 Request for Idle Mode Handover Support

This section describes the message the mobile node sends in response to
the paging router advertisement which contains an AAAv6 local challenge.
This response includes a token to facilitate expedited network access
authentication and also request for context transfer authorization.

The message the MN sends is an ICMPv6 message of AAAv6 request
type.  This AAAv6 message contains one or more Embedded Data Options.
Each Embedded Data Option (EDO) may contain sub types for various
purposes.  The two new sub types used by this extension are the access
authentication token and Seamless Handover Initiate (SHIN). The SHIN
subtype is optional if the network policy allows context authorization
based only on network access authentication.

The access authentication token contains a hash over mobile node's
previous IP address and the challenge sent in the router advertisement.
Since the paging message from the paging router to the access routers
distributes the key known to the MN and the paging router, this key is
now known by the new router which can verify whether the hash received
is valid.  If not, the packet is dropped and a diagnostics AAAv6 reply
with status AAAV6_INVALID_CREDENTIALS in the Code field is returned.






























Koodli, Malinen            Expires 13 January  2002            [Page 10]

Internet Draft          Idle Mode Handover Support          13 July 2001


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{1}|                                                               |
   |                         IPv6 Header...                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}|Type=AAAv6req  |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   (AAAv6 Request Options) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{3}| Type=EDO      |Subtype=AAToken|      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |             Network Access Authentication Hash                |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{4}| Type=EDO      |Subtype=SHIN   |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        SHIN (optional)                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




         Figure 5: AAAv6 request for Idle Mode Handover Support


{1} IPv6 Header

SRC = MN's new IP address; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6)

{2} ICMPv6 Header [2]

      Type

         151 (97h) [TBD] = AAAv6 Request

      Code

         0 - For AAA request, not defined

      Checksum

         Calculated as defined in [2].




Koodli, Malinen            Expires 13 January  2002            [Page 11]

Internet Draft          Idle Mode Handover Support          13 July 2001


{3} AAAv6 Embedded Data Option [1] for access authentication

      Type

         8 (unskippable) = Embedded Data Option

      Subtype

         5 = AAToken

      Length

         4 = Length of Network Access Authentication Hash in octets.

      Network Access Authentication Hash



          A 16-byte result of a pseudo-random function, such as
         HMAC-MD5-96, computed over the identity-providing old CoA,
         freshness-providing random number (LC), and the session key.

{4} AAAv6 Embedded Data Option [1] for SHIN

      Type

         8 (unskippable) = Embedded Data Option

      Subtype

         6 = SHIN

      Length

         4 = Length of SHIN in octets.

      SHIN

         Seamless Handover Initiate message.


4.5. AAAv6 Reply for Idle Mode Handover Support

In this section, we provide the extended AAAv6 reply to the AAAv6
request for idle mode context transfer support.  Note that the request
for context transfer was embedded to an EDO containing the SHIN message.
Here a similar new and optional EDO contains the optional SHAK.

{1} IPv6 Header



Koodli, Malinen            Expires 13 January  2002            [Page 12]

Internet Draft          Idle Mode Handover Support          13 July 2001


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{1}|                                                               |
   |                         IPv6 Header...                        |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}|Type=AAAv6req  |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   (AAAv6 Reply Options) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{3}| Type=EDO      |Subtype=SHAK   |      Length                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        SHAK (optional)                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+





          Figure 6: AAAv6 reply for Idle Mode Handover Support



SRC = AAAv6 Attendant; DEST = mobile node; NxtHDR = 58 (ICMPv6)

{2} ICMPv6 Header [2]

      Type

         [TBD] = AAAv6 Reply

      Code

         The success code for AAAv6 Reply.

      Checksum

         Calculated as defined in [2].

{3} AAAv6 Embedded Data Option [1] for SHAK

      Type

         8 (unskippable) = Embedded Data Option





Koodli, Malinen            Expires 13 January  2002            [Page 13]

Internet Draft          Idle Mode Handover Support          13 July 2001


      Subtype

         7 = SHAK

      Length

         Length of SHAK in octets.

      SHAK

         Seamless Handover Acknowledgment.


5. Protocol Constants

Three new sub-types for AAAv6 Embedded Data Option are needed, one
for access authentication token, and one for SHIN, and SHAK options,
respectively.


6. Security Considerations

This protocol assumes that when the mobile node arrives at a visited
domain, it performs a secure initial registration, after which there
is a mobile-visited domain session key in both the mobile node and the
first visited-domain router.  Also, there is a pre-existing common
security association between all nodes in a paging area multicast group.

Using the assumed associations, the paging causes the session key to
be provided to the new access router which can use it to verify both
authenticity of the received AAAv6 request as well as the authorization
token present in the SHIN message.  These mechanisms used together with
AAAv6 provide authorized idle mode context transfers.



















Koodli, Malinen            Expires 13 January  2002            [Page 14]

Internet Draft          Idle Mode Handover Support          13 July 2001


References

   [1] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund.  AAA for
       IPv6 Network Access (work in progress).  Internet Draft, Internet
       Engineering Task Force, March 2000.

   [2] A. Conta and S. Deering.  Internet Control Message Protocol
       (ICMPv6) for the Internet protocol version 6 (ipv6)
       specification.  Request for Comments (Draft Standard) 2463,
       Internet Engineering Task Force, December 1998.

   [3] J. Kempf.  Dormant mode host alerting (ip paging) problem
       statement.  Request for Comments (Informational) 3132, Internet
       Engineering Task Force, June 2001.

   [4] S. Kent and R. Atkinson.  IP Authentication Header.  Request for
       Comments (Proposed Standard) 2402, Internet Engineering Task
       Force, November 1998.

   [5] R. Koodli, , and C. Perkins.  A context transfer framework for
       seamless mobility (work in progress).  Internet Draft, Internet
       Engineering Task Force, July 2000.

   [6] et al. Levkowetz, O. H.  Problem description:  Reasons for
       performing context transfers between nodes in an ip access
       network (work in progress).  Internet Draft, Internet Engineering
       Task Force, June 2001.

   [7] C. Madson and R. Glenn.  The Use of HMAC-MD5-96 within ESP and
       AH.  Request for Comments (Proposed Standard) 2403, Internet
       Engineering Task Force, November 1998.

   [8] T. Narten, E. Nordmark, and W. Simpson.  Neighbor Discovery for
       IP Version 6 (ipv6).  Request for Comments (Draft Standard) 2461,
       Internet Engineering Task Force, December 1998.

   [9] B. Sarikaya, J. Haverinen, H.and Malinen, and V. Magret.  Mobile
       ipv6 regional paging (work in progress).  Internet Draft,
       Internet Engineering Task Force, November 2000.


Addresses

Questions about this memo can also be directed to the authors:








Koodli, Malinen            Expires 13 January  2002            [Page 15]

Internet Draft          Idle Mode Handover Support          13 July 2001


     Rajeev Koodli                   Jari T. Malinen
     Communications Systems Lab      Communications Systems Lab
     Nokia Research Center           Nokia Research Center
     313 Fairchild Drive             313 Fairchild Drive
     Mountain View, California 94043 Mountain View, California 94043
     USA                             USA
     Phone:  +1-650 625-2359         Phone:  +1-650 625-2355
     EMail:  rajeev.koodli@nokia.com EMail:  jmalinen@iprg.nokia.com
     Fax:  +1 650 625-2502           Fax:  +1 650 625-2502











































Koodli, Malinen            Expires 13 January  2002            [Page 16]

--------------AF1D37A98747CD1260DF9277--



From owner-seamoby@diameter.org  Fri Jul 13 18:17:36 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20014
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 18:17:35 -0400 (EDT)
Received: (qmail 12439 invoked by alias); 13 Jul 2001 22:05:07 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 12433 invoked by uid 200); 13 Jul 2001 22:05:05 -0000
Received: (qmail 12428 invoked from network); 13 Jul 2001 22:05:03 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 22:05:03 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA15394;
	Fri, 13 Jul 2001 15:15:26 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6DMFPI10976;
	Fri, 13 Jul 2001 15:15:25 -0700
X-mProtect:  Fri, 13 Jul 2001 15:15:25 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd72Qw1c; Fri, 13 Jul 2001 15:15:23 PDT
Message-ID: <3B4F72FC.3565C6C1@iprg.nokia.com>
Date: Fri, 13 Jul 2001 15:15:24 -0700
From: Theo Pagtzis <tpagtzis@IPRG.nokia.com>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: James Kempf <James.Kempf@Sun.COM>
CC: gkenward@nortelnetworks.com, pcalhoun@diameter.org,
        PNeumiller@MeshNetworks.com, seamoby@cdma-2000.org
Subject: Re: [seamoby] Getting ready for London and other stuff
References: <200107132046.NAA25073@heliopolis.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

  Jame

  IMHO I think that the CT should be a stand alone protocol which must
encompass the
capability to be 'associated' with a mobility protocol, if CT is to
effect seamlessness guarantees for mobility. The association hooks in
terms of identification of the mobility protocol should be provided by
the mobility protocol itself.


Theo

UCL/ Mobile Systems


James Kempf wrote:

> >I am collecting a list of what I perceive are issues. I believe that
> >we have a couple:
> >1. Should CT be tied to a mobility management protocol
>
> I would rephrase this as:
>
>   Should CT be designed as a framework that can be tied to a mobility
>   protocol in addition to being a separate protocol or should it
>   be just a standalone protocol.
>
> That's a little verbose, but I think maybe you get the drift.
>
>         jak
>
> >2. To what point does the requirements spec need to define
> >   the modes of operation (e.g. proactive, reactive).
> >
> >Any others that I may have missed?
> >
> >PatC
> >



From owner-seamoby@diameter.org  Fri Jul 13 18:56:53 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24465
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 18:56:52 -0400 (EDT)
Received: (qmail 13114 invoked by alias); 13 Jul 2001 22:45:09 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 13108 invoked by uid 200); 13 Jul 2001 22:45:09 -0000
Received: (qmail 13103 invoked from network); 13 Jul 2001 22:45:07 -0000
Received: from netmail2.alcatel.com (128.251.168.51)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 22:45:07 -0000
Received: from auds951.usa.alcatel.com (auds951.usa.alcatel.com [143.209.238.80])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id RAA17203
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 17:56:00 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by auds951.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6DMtx006467
	for <seamoby@cdma-2000.org>; Fri, 13 Jul 2001 17:55:59 -0500 (CDT)
Message-ID: <3B4F6DAB.5D550FC5@usa.alcatel.com>
Date: Fri, 13 Jul 2001 17:52:43 -0400
From: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby <seamoby@cdma-2000.org>
Subject: Re: [seamoby] I-D draft-sarikaya-seamoby-hmip6hp-00.txt
References: <3B4F3E88.A7993F36@usa.alcatel.com> <20010713133721.N32517@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

We are going to ask for a slot in London to present the draft. Keep this in
mind when you schedule things for London meeting.

Pat Calhoun wrote:

> I take it that this is a candidate protocol for our domant host alerting
> work (AKA paging), right? If so, then the WG is still waiting for the
> IESG to accept the requirements spec, after which we will begin the
> protocol work.
>
> Thanks for the submission,
>
> PatC
>
> On Fri, Jul 13, 2001 at 01:31:36PM -0500, Behcet Sarikaya wrote:
> > Hello,
> >   We submitted an I-D to IETF. It is also available at:
> > http://www.geocities.com/bsarikaya/draft-sarikaya-seamoby-hmip6hp-00.txt
> >
> > Abstract
> >
> >    This document specifies Hierarchical Mobile IPv6 Hierarchical Paging
> >    (HMIPv6HP), an IP host alerting protocol which is a link-layer
> >    independent extension to Hierarchical Mobile IPv6. The extension
> >    allows a mobile node to enter a power saving dormant mode during
> >    which its location is known with coarse accuracy defined by a paging
> >    area. In the visited domain only the paging mobility anchor point
> >    (PMAP) is responsible for keeping the binding cache entries for
> >    dormant mobile nodes and, it re-establishes the downlink routes on
> >    demand by means of paging. Paging is initiated by the paging agent
> >    (PA) and the access routers in paging areas and does not involve
> >    periodic layer 3 messages to be sent except for time-slot based
> >    paging which is optional and is to be used on links with no support
> >    for layer 2 paging.
> >
> >
> > Comments welcome.

>

> Kind regards,

> Behcet



From owner-seamoby@diameter.org  Fri Jul 13 19:11:19 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26154
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 19:11:18 -0400 (EDT)
Received: (qmail 13695 invoked by alias); 13 Jul 2001 22:59:16 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 13689 invoked by uid 200); 13 Jul 2001 22:59:15 -0000
Received: (qmail 13683 invoked by uid 500); 13 Jul 2001 22:59:13 -0000
Date: Fri, 13 Jul 2001 15:59:13 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
Cc: seamoby <seamoby@cdma-2000.org>
Subject: Re: [seamoby] I-D draft-sarikaya-seamoby-hmip6hp-00.txt
Message-ID: <20010713155913.Y32517@charizard.diameter.org>
Mail-Followup-To: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>,
	seamoby <seamoby@cdma-2000.org>
References: <3B4F3E88.A7993F36@usa.alcatel.com> <20010713133721.N32517@charizard.diameter.org> <3B4F6DAB.5D550FC5@usa.alcatel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B4F6DAB.5D550FC5@usa.alcatel.com>; from behcet.sarikaya@usa.alcatel.com on Fri, Jul 13, 2001 at 05:52:43PM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

Let me try again. We have priority items at the moment, which is the CT
requirements and the Handoff discovery Problem Statement. Since the paging
requirements haven't been accepted by the IESG yet, it is premature to be
discussing protocols.

If we have time at the end of the meeting, folks with paging protocol
interest can use the room, but there is no guarantee. Another alternative
is to have a bar meeting of all paging protocol folks. 

I understand that this is important, but protocol discussions prior 
to acceptance of requirements is not acceptable. If you have issues 
with my decision, please take it up with the Area Directors.

Thanks,

PatC
On Fri, Jul 13, 2001 at 05:52:43PM -0400, Behcet Sarikaya wrote:
> We are going to ask for a slot in London to present the draft. Keep this in
> mind when you schedule things for London meeting.
> 
> Pat Calhoun wrote:
> 
> > I take it that this is a candidate protocol for our domant host alerting
> > work (AKA paging), right? If so, then the WG is still waiting for the
> > IESG to accept the requirements spec, after which we will begin the
> > protocol work.
> >
> > Thanks for the submission,
> >
> > PatC
> >
> > On Fri, Jul 13, 2001 at 01:31:36PM -0500, Behcet Sarikaya wrote:
> > > Hello,
> > >   We submitted an I-D to IETF. It is also available at:
> > > http://www.geocities.com/bsarikaya/draft-sarikaya-seamoby-hmip6hp-00.txt
> > >
> > > Abstract
> > >
> > >    This document specifies Hierarchical Mobile IPv6 Hierarchical Paging
> > >    (HMIPv6HP), an IP host alerting protocol which is a link-layer
> > >    independent extension to Hierarchical Mobile IPv6. The extension
> > >    allows a mobile node to enter a power saving dormant mode during
> > >    which its location is known with coarse accuracy defined by a paging
> > >    area. In the visited domain only the paging mobility anchor point
> > >    (PMAP) is responsible for keeping the binding cache entries for
> > >    dormant mobile nodes and, it re-establishes the downlink routes on
> > >    demand by means of paging. Paging is initiated by the paging agent
> > >    (PA) and the access routers in paging areas and does not involve
> > >    periodic layer 3 messages to be sent except for time-slot based
> > >    paging which is optional and is to be used on links with no support
> > >    for layer 2 paging.
> > >
> > >
> > > Comments welcome.
> 
> >
> 
> > Kind regards,
> 
> > Behcet
> 


From owner-seamoby@diameter.org  Fri Jul 13 19:15:05 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26598
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 19:15:04 -0400 (EDT)
Received: (qmail 13911 invoked by alias); 13 Jul 2001 23:00:48 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 13905 invoked by uid 200); 13 Jul 2001 23:00:48 -0000
Received: (qmail 13894 invoked from network); 13 Jul 2001 23:00:44 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 23:00:44 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA19115;
	Fri, 13 Jul 2001 16:11:07 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6DNB6p02781;
	Fri, 13 Jul 2001 16:11:06 -0700
X-mProtect:  Fri, 13 Jul 2001 16:11:06 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdx6mUyq; Fri, 13 Jul 2001 16:11:05 PDT
Message-ID: <3B4F8009.8D9306E6@iprg.nokia.com>
Date: Fri, 13 Jul 2001 16:11:05 -0700
From: Rajeev Koodli <rajeev@IPRG.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>
CC: James Kempf <James.Kempf@Sun.COM>, seamoby@cdma-2000.org,
        charliep@IPRG.nokia.com
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- 
 Phase CT
References: <200107111547.IAA22595@heliopolis.eng.sun.com> <3B4C97D3.7F876F9@iprg.nokia.com> <20010713123240.B32517@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello Pat,

Pat Calhoun wrote:

> On Wed, Jul 11, 2001 at 11:15:47AM -0700, Rajeev Koodli wrote:
> >
> > Hello,
> >
> > I agree that there is much to gain from doing CT _with_ handover signaling. In
> > fact, I have raised this issue of potential state inconsistency (what James calls
> > synchronization problem below) a *few times* already in the mailing list. However,
> > the value of CT should not be tied to MIP handovers alone. So, the way to make use
> > of CT for MIP handovers is to separate the feature contexts from the actual
> > signaling messages. This is outlined in draft-koodli-seamoby-ctv6-00.txt.
>
> ok, finally got around to reading it. This is interesting because it
> doesn't require CT to be tied to MIP, but allows it to be carried in
> the same packet. I wonder, though, what the IESG would think about
> the use of ICMP for CT. I know that they *really* frown upon UDP for
> CT, so I wonder what their thoughts would be.
>

Rajeev: We describe carrying contexts in ICMP because HI/HAck are ICMP messages. One of
the principles outlined in the draft is to separate a context defintion (and its
subsequent packet format) from the signal that carries it. We have shown how it can be
done for FMIPv6. We think that the context packets could be carried in other forms of
messages as well.

Thanks for the comments.

-Rajeev


>
> PatC



From owner-seamoby@diameter.org  Fri Jul 13 19:23:53 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27663
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 19:23:52 -0400 (EDT)
Received: (qmail 14786 invoked by alias); 13 Jul 2001 23:11:59 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 14780 invoked by uid 200); 13 Jul 2001 23:11:58 -0000
Received: (qmail 14772 invoked from network); 13 Jul 2001 23:11:55 -0000
Received: from mgw-dax1.ext.nokia.com (63.78.179.216)
  by c900656-a.plstn1.sfba.home.com with SMTP; 13 Jul 2001 23:11:55 -0000
Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6DNMmi26878;
	Fri, 13 Jul 2001 18:22:49 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir03nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54b9ecdf8bac12f256079@davir03nok.americas.nokia.com>;
 Fri, 13 Jul 2001 18:22:41 -0500
content-class: urn:content-classes:message
Subject: RE: [seamoby] Comments on draft-koodli-seamoby-ctv6-00.txt
Date: Fri, 13 Jul 2001 18:22:33 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A65B9F@bseis01nok>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: [seamoby] Comments on draft-koodli-seamoby-ctv6-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Thread-Index: AcEL2E3Xmy3i1nfGEdWxLgAIx6TWeAAGYbow
From: <rajeev.koodli@nokia.com>
To: <pcalhoun@diameter.org>, <James.Kempf@Sun.COM>
Cc: <rajeev.koodli@nokia.com>, <seamoby@diameter.org>
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA27663


hello Pat,

> 
> Actually, I have another comment. Figure 2, and the surrounding text,
> implies that each blob is targetted for a particular flow. However,
> what about state info that isn't flow specific? An example is some AAA
> information, which is "session based". Is that what the top "context"
> box implies? You may want to consider this in your next revision.

Indeed not all context is only flow-based. And, the top box is meant to
include all the contexts including flow-based contexts. Will add
clarification. 

Thanks for the input.

-Rajeev


> 
> PatC
> On Thu, Jul 12, 2001 at 01:47:52PM -0700, James Kempf wrote:
> > Hi Rajeev,
> > 
> > I looked over your draft and I have some comments.
> > 
> > 1) pg. 5 I like your charaterization of GTP (not the other 
> one) but the
> > idea that it consists of a type identifier and *state* variables
> > brings up a fundamental question w.r.t. context transfer. Protocols
> > usually define the interface between two different network elements.
> > State variables have to do with implementation. Isn't context
> > transfer basically asking for implementations to be exposed?
> > 
> > For example, suppose I am SuperWhizzy QoS Router manufacturer and
> > I have a router that supports the Diffserv  protocols just fine,
> > so it interoperates, but inside I have my proprietary algorithms
> > that make my router live up to its name. In order to provide state
> > transfer, would I need to expose the internals of my algorithms
> > so I could interoperate?
> > 
> > I'm not sure how to solve this problem, but I think you need to
> > clarify that these state variables aren't internals of the 
> implementation,
> > but rather protocol-specified state variables that are part of the
> > interface.
> > 
> > 2) pg. 5 What is the filter and handle alluded to in the 
> last paragraph?
> > There is not alot of detail as to what these are supposed to do.
> > 
> > 3) pg. 7 and the whole discussion of SHIN/SHAK header options. When
> > I first read this, I thought these were being defined for 
> the purpose
> > of having the MN do context transfer to the router, which 
> didn't make
> > any sense to me. After I got to Section 5, however, it became clear
> > that what you really mean is that the MN signals to the router that
> > it wants particular context to be transfered. I think you need to
> > rewrite it to make this clear (but see below for some comments on
> > the utility of the SHIN/SHAK in the first place).
> > 
> > 4) Section 4.3-4.5 I like the idea of the context transfer being an
> > extension to the HO messaging. Reduces the number of timers required
> > in the router. And it is possible in IPv6. The only issue here is
> > there has been some opinion expressed on the list that a reliable
> > transport might be a better idea for context transfer, which would
> > not be possible with ICMP extensions.
> > 
> > 5) pg. 12 - What happens if a router or MN asks for some context to
> > be transfered and it is not available?
> > 
> > 6) pg 12 - What is an unsolicited SHREP? Up until this 
> point, I don't
> > think it has been described. You may want to describe it in the
> > terminology section, or somehow earlier in the paper.
> > 
> > 7) pg. 13 Section 5.1 Actually, I think this scenario is pretty
> > unlikely for slow speed links, or, if it occurs at all, it 
> will probably occur 
> > when there is almost no traffic between the MN and the 
> network. I think
> > that any scenario where the MN has to trigger the context transfer
> > is not likely to occur when there is active traffic because 
> it will involve
> > messaging over the wireless link, which is the slowest. 
> > 
> > I think it more likely that context transfer occurs as part 
> of the HI/HACK
> > as described in Section 5.2. I don't think the MN needs to 
> signal over
> > the air to get the CT to happen (P-SHIN), I think that CT could be 
> > triggered by the need for a handover. The L2 triggers draft, which
> > should be out shortly, spells out requirements for L2 triggers to
> > support CT.
> > 
> > With faster wireless protocols, the over-the-air signaling 
> won't have
> > as much cost (but it will always have a higher cost than 
> over the wire),
> > so the option should probably be kept in, but I think for standard
> > 3G scenarios, triggering the context transfer as part of the need
> > for a handover without any over-the-air signalling is likely to be
> > much faster.
> > 
> > 		jak
> > 
> > 
> 


From owner-seamoby@diameter.org  Fri Jul 13 20:14:12 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04128
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 20:14:10 -0400 (EDT)
Received: (qmail 15625 invoked by alias); 14 Jul 2001 00:02:18 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15619 invoked by uid 200); 14 Jul 2001 00:02:18 -0000
Received: (qmail 15613 invoked by uid 500); 14 Jul 2001 00:02:15 -0000
Date: Fri, 13 Jul 2001 17:02:15 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: john.loughney@nokia.com
Cc: seamoby@cdma-2000.org
Subject: Re: [seamoby] CT Requirements Issue 7
Message-ID: <20010713170215.D32517@charizard.diameter.org>
Mail-Followup-To: john.loughney@nokia.com, seamoby@cdma-2000.org
References: <0C1353ABB1DEB74DB067ADFF749C4EEF094045@esebe004.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF094045@esebe004.NOE.Nokia.com>; from john.loughney@nokia.com on Fri, Jul 13, 2001 at 09:04:28AM +0300
Sender: owner-seamoby@diameter.org
Precedence: bulk

I did see this yesterday, and added it to the issues list. Monday morning
I will update the list with the latest status.

PatC
On Fri, Jul 13, 2001 at 09:04:28AM +0300, john.loughney@nokia.com wrote:
> Hi all,
> 
> I sent this yesterday, but it didn't seem to make the list - let me try
> again.
> 
> ====
> 
> Description of issue 
> 
> Section 4.4 & 4.5 are potentially limiting.
> 
> Submitter name: John Loughney
> Submitter email address: john.loughney@nokia.com
> Date first submitted: July 12, 2001 
> Comment type: T
> 
> Priority: S
> 
> Section: Insert_Section_Number_Here 
> 
> Rationale/Explanation of issue: 
> 
> Currently 4.4 and 4.5 imply that there are two modes of operation.  It is
> not so cut & dry.  As seen by the discussion on the list, there are many
> differing requirements that may not be satisfied by discussion these modes.
> Length description of problem 
> 
> Currently, by defining proactive & reactive, the work group may start to
> think in terms of these 2 modes of operation.  I don't think that CT is so
> black & white.  
> 
> Requested change: 
> 
> Remove proactive & reactive from the document.  These could be used as
> examples in the document, if needed.
> 
> Disclaimer: I am not saying that proactive, reactive, active, etc. are not
> needed - what I am saying is that by defining requirements for more basic
> building blocks, we can then use those building blocks to create aggregate
> behavior that looks like proactive, reactive, etc.
> 
> Proposal 
> 
> Focus on the features & functions of reactive & proactive modes rather.  For
> example, everyone will agree that certain context may have a higher priority
> (may take precidence over, may be more time sensitive, etc.) than others.
> Some context may go stale.  Some context may need to be acknowledged.  
> 
> By stating the types of functionality that are needed, the requirements will
> allow a more rich protocol.
> 
> 
> =============================================
> 
> Example (solution space):  
> 
> We define these features - this is not the complete set:
> (priority, time-to-live, ack-needed, synchonized with ho)
> 
> So, I would define the transfer of header compression state
> as context transfer that has a high priority, a certain time-to-live, 
> ack-needed.
> 
> High priority would mean that the AR would send it ASAP.
> 
> TTL would indicate that the context would go stale.
> 
> Ack-needed would indicate to the mobile node that if the
> new AR does not yet have the header compression state, 
> then it shouldn't send compressed headers, but attempt to
> re-initialize the compressor at the new AR.


From owner-seamoby@diameter.org  Fri Jul 13 20:29:50 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05947
	for <seamoby-archive@odin.ietf.org>; Fri, 13 Jul 2001 20:29:47 -0400 (EDT)
Received: (qmail 16184 invoked by alias); 14 Jul 2001 00:17:16 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16178 invoked by uid 200); 14 Jul 2001 00:17:15 -0000
Received: (qmail 16173 invoked from network); 14 Jul 2001 00:17:12 -0000
Received: from mgw-dax1.ext.nokia.com (63.78.179.216)
  by c900656-a.plstn1.sfba.home.com with SMTP; 14 Jul 2001 00:17:12 -0000
Received: from davir02nok.americas.nokia.com (davir02nok.americas.nokia.com [172.18.242.85])
	by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6E0S5i29353
	for <seamoby@diameter.org>; Fri, 13 Jul 2001 19:28:05 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir02nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54ba288013ac12f255079@davir02nok.americas.nokia.com>;
 Fri, 13 Jul 2001 19:27:49 -0500
content-class: urn:content-classes:message
Subject: [seamoby] RE: Comments on draft-koodli-seamoby-ctv6-00.txt
Date: Fri, 13 Jul 2001 19:27:42 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A65BA0@bseis01nok>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: Comments on draft-koodli-seamoby-ctv6-00.txt
X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65
Thread-Index: AcELF2R9c2cZbHcFEdWBSQBQi2X+DwA22mTQ
From: <rajeev.koodli@nokia.com>
To: <James.Kempf@Sun.COM>, <rajeev.koodli@nokia.com>
Cc: <seamoby@diameter.org>, <Charles.Perkins@nokia.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id UAA05947


Hello James,

thanks for your input. Got finished with this week's deadline. Please
see my comments in-line. 

Regards,

-Rajeev


> -----Original Message-----
> From: ext James Kempf [mailto:James.Kempf@Sun.COM]
> Sent: Thursday, July 12, 2001 1:48 PM
> To: rajeev.koodli@nokia.com
> Cc: seamoby@diameter.org
> Subject: Comments on draft-koodli-seamoby-ctv6-00.txt
> 
> 
> Hi Rajeev,
> 
> I looked over your draft and I have some comments.
> 
> 1) pg. 5 I like your charaterization of GTP (not the other 
> one) but the

Actually it is GPT: Generic Profile Type

> idea that it consists of a type identifier and *state* variables
> brings up a fundamental question w.r.t. context transfer. Protocols
> usually define the interface between two different network elements.
> State variables have to do with implementation. Isn't context
> transfer basically asking for implementations to be exposed?

Well, by state variables we mean the parameters and their values that
constitute a context. For instance, header compression maintains the
Src, Dst addresses and port numbers which we refer to as state
variables.


> 
> For example, suppose I am SuperWhizzy QoS Router manufacturer and
> I have a router that supports the Diffserv  protocols just fine,
> so it interoperates, but inside I have my proprietary algorithms
> that make my router live up to its name. In order to provide state
> transfer, would I need to expose the internals of my algorithms
> so I could interoperate?

Obviously we do not require this. If you are willing to provide some
"additional information" we might accept it :-) (just kidding).
As I mentioned above, we only refer to those fields which are necessary
for inter-operability. In your example, the peak and committed
information rates for instance would qualify as context parameters. BTW,
we have QoS context relocation draft that we submitted to the seamoby
list that contains an enumeration of these "state variables".

> 
> I'm not sure how to solve this problem, but I think you need to
> clarify that these state variables aren't internals of the 
> implementation,
> but rather protocol-specified state variables that are part of the
> interface.
> 

Ok. 

> 2) pg. 5 What is the filter and handle alluded to in the last 
> paragraph?
> There is not alot of detail as to what these are supposed to do.
> 

The filter is the [addr, port] pair perhaps with SPI. The text says
"..filter that identifies the packet stream..". The handle is an id that
identifies the particular context. For instance, the CID in HC.


> 3) pg. 7 and the whole discussion of SHIN/SHAK header options. When
> I first read this, I thought these were being defined for the purpose
> of having the MN do context transfer to the router, which didn't make
> any sense to me. After I got to Section 5, however, it became clear
> that what you really mean is that the MN signals to the router that
> it wants particular context to be transfered. I think you need to
> rewrite it to make this clear (but see below for some comments on
> the utility of the SHIN/SHAK in the first place).
>

The current text mentions that these are for requesting context
transfers. If it is not clear, I will re-read it and try to revise. 

Note that SHAK is optional. The P-SHIN need not be sent at all. We think
that there is some value in including SHIN when there is a need for
explicit authorization of contexts. 
We have specified this in the idle-mode context transfer draft. We will
also revise the ctv6 draft and submit it next week.

  
> 4) Section 4.3-4.5 I like the idea of the context transfer being an
> extension to the HO messaging. Reduces the number of timers required
> in the router. And it is possible in IPv6. The only issue here is
> there has been some opinion expressed on the list that a reliable
> transport might be a better idea for context transfer, which would
> not be possible with ICMP extensions.
> 

The idea is to separate context definitions from the signals that carry
the contexts. We have defined context definitions and shown how they
could be used with FMIPv6 signals, which as you know uses ICMP for HI
and HAck. 

It is entirely possible that the context definitions that we have
provided are used in other forms of messages as well. Indeed, we are
proposing that the contexts be carried in the paging message in our
recent draft.


> 5) pg. 12 - What happens if a router or MN asks for some context to
> be transfered and it is not available?
> 

For each context type, there is Subopt-type and Subopt-len fields. One
of the Subopt-type fields encodes that context is not available. See
draft-koodli-seamoby-hc-relocate-00.txt for details on how we do this
for HC.

We make the error known to the MN through SHAK.


> 6) pg 12 - What is an unsolicited SHREP? Up until this point, I don't
> think it has been described. You may want to describe it in the
> terminology section, or somehow earlier in the paper.

Good point. Will do.

> 
> 7) pg. 13 Section 5.1 Actually, I think this scenario is pretty
> unlikely for slow speed links, or, if it occurs at all, it 
> will probably occur 
> when there is almost no traffic between the MN and the 
> network. I think
> that any scenario where the MN has to trigger the context transfer
> is not likely to occur when there is active traffic because 
> it will involve
> messaging over the wireless link, which is the slowest. 
> 

Well, I agree to the extent that we should conserve air interface
bandwidth. If a MN attaches to the New Router which has no information
about the MN's Previous Router as well as its Previous IP address, how
can the New Router fetch the contexts ? I hope you would agree that it
is ok to send the Binding Update. SHIN, in its default form, includes
two IP addresses, and perhaps a 32-bit authentication field when
necessary and goes out along-with the BU. 

Also, what would you consider a slow-speed link ?


> I think it more likely that context transfer occurs as part 
> of the HI/HACK
> as described in Section 5.2. I don't think the MN needs to signal over
> the air to get the CT to happen (P-SHIN), I think that CT could be 
> triggered by the need for a handover. The L2 triggers draft, which
> should be out shortly, spells out requirements for L2 triggers to
> support CT.
> 

We also think that P-SHIN is not required. We will revise the draft
appropriately. 
As per the CT trigger, any authentic indication to the Previous Router
should do. This indication could be network-generated. An MN-generated
indication is F-BU, and it will suffice to have a single bit in it to
trigger CT.
 

> With faster wireless protocols, the over-the-air signaling won't have
> as much cost (but it will always have a higher cost than over 
> the wire),
> so the option should probably be kept in, but I think for standard
> 3G scenarios, triggering the context transfer as part of the need
> for a handover without any over-the-air signalling is likely to be
> much faster.
> 

While designing IP protocols, it is good to define efficient IP messages
isn't it ? As I mentioned above, we allow for network-initiated CT which
does not require that the MN provide explicit trigger. However, if F-BU
were to be implemented, a single bit in it to trigger CT should not be
too expensive. 

Thanks for your input. We will use it in the next revision, which is due
next week!

> 		jak
> 
> 


From owner-seamoby@diameter.org  Mon Jul 16 02:46:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08273
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 02:46:31 -0400 (EDT)
Received: (qmail 5406 invoked by alias); 16 Jul 2001 06:35:43 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5399 invoked by uid 200); 16 Jul 2001 06:35:42 -0000
Received: (qmail 5390 invoked from network); 16 Jul 2001 06:35:40 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 06:35:40 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6G6ksI09431
	for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 09:46:54 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54c78736ceac158f2313e2@esvir03nok.nokia.com>;
 Mon, 16 Jul 2001 09:46:20 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS40K76>; Mon, 16 Jul 2001 09:46:20 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09405E@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: James.Kempf@Sun.COM, pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] Getting ready for London and other stuff
Date: Mon, 16 Jul 2001 09:46:16 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

James & Pat,

> >1. Should CT be tied to a mobility management protocol
> 
> I would rephrase this as:
> 
>   Should CT be designed as a framework that can be tied to a mobility
>   protocol in addition to being a separate protocol or should it
>   be just a standalone protocol.

I'd make it a multiple choice question:

 A) CT is a stand alone protocol
 B) CT is a used by another protocol
 C) CT is a framework which can work as a standalone protocol,
    or be used by another protocol.

best regards,
John


From owner-seamoby@diameter.org  Mon Jul 16 02:48:41 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08715
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 02:48:40 -0400 (EDT)
Received: (qmail 5826 invoked by alias); 16 Jul 2001 06:37:29 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5819 invoked by uid 200); 16 Jul 2001 06:37:29 -0000
Received: (qmail 5809 invoked from network); 16 Jul 2001 06:37:27 -0000
Received: from mgw-x2.nokia.com (131.228.20.22)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 06:37:27 -0000
Received: from esvir02nok.nokia.com (esvir02nokt.ntc.nokia.com [172.21.143.34])
	by mgw-x2.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6G6mR315850
	for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 09:48:27 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir02nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54c788d4f0ac158f22077@esvir02nok.nokia.com>;
 Mon, 16 Jul 2001 09:48:06 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS40K9M>; Mon, 16 Jul 2001 09:48:06 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09405F@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: CT reliability model was RE: [seamoby] [Issue] Support for Mu
	 lti- Phase CT
Date: Mon, 16 Jul 2001 09:48:02 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Pat,

> As I've mentioned time and time again, if folks believe that another 
> transport is better suited, please plead your case to the transport 
> ADs. Perhaps given the necessary justification they could be swayed.

As a matter of procedure, I thought that this would be discussed
when it is time to do protocol selection.  I don't think that this
is something that could or should be decided prior to that.

John


From owner-seamoby@diameter.org  Mon Jul 16 03:07:19 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12437
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 03:07:18 -0400 (EDT)
Received: (qmail 6478 invoked by alias); 16 Jul 2001 06:56:40 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6472 invoked by uid 200); 16 Jul 2001 06:56:39 -0000
Received: (qmail 6467 invoked from network); 16 Jul 2001 06:56:37 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 06:56:37 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6G77pI17705
	for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 10:07:51 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54c79a6cf5ac158f2313e2@esvir03nok.nokia.com>;
 Mon, 16 Jul 2001 10:07:19 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS40L4W>; Mon, 16 Jul 2001 10:07:19 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF094060@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: PNeumiller@MeshNetworks.com
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be
	 ,  RE: Issue #4)
Date: Mon, 16 Jul 2001 10:07:14 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Phil,

> 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.

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


From owner-seamoby@diameter.org  Mon Jul 16 03:10:11 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13014
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 03:10:11 -0400 (EDT)
Received: (qmail 6958 invoked by alias); 16 Jul 2001 06:59:25 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 6952 invoked by uid 200); 16 Jul 2001 06:59:25 -0000
Received: (qmail 6947 invoked from network); 16 Jul 2001 06:59:23 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 06:59:23 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6G7AbI18679
	for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 10:10:37 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54c79cd23dac158f2313e2@esvir03nok.nokia.com>;
 Mon, 16 Jul 2001 10:09:56 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MS40LYQ>; Mon, 16 Jul 2001 10:09:56 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09BAFD@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: pcalhoun@diameter.org, gkenward@nortelnetworks.com
Cc: PNeumiller@MeshNetworks.com, seamoby@cdma-2000.org
Subject: RE: [seamoby] Getting ready for London and other stuff
Date: Mon, 16 Jul 2001 10:09:52 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Pat,

> 2. To what point does the requirements spec need to define
>    the modes of operation (e.g. proactive, reactive).

Hopefully, this will be a no-brainer.  Modes of operation of
a yet to be designed protocol seems to putting the cariage
before the horse ...

I'd prefer that the requirements document discuss the features/
functionality needed to support proactive, reactive, multi-phasic,
etc. context transfer.

br,
John


From owner-seamoby@diameter.org  Mon Jul 16 03:13:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13616
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 03:13:09 -0400 (EDT)
Received: (qmail 7405 invoked by alias); 16 Jul 2001 07:01:17 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 7395 invoked by uid 200); 16 Jul 2001 07:01:16 -0000
Received: (qmail 7378 invoked from network); 16 Jul 2001 07:01:14 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 07:01:14 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA11050;
	Mon, 16 Jul 2001 00:11:28 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6G7BRT28604;
	Mon, 16 Jul 2001 00:11:27 -0700
X-mProtect:  Mon, 16 Jul 2001 00:11:27 -0700 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdbq9CGH; Mon, 16 Jul 2001 00:11:25 PDT
Message-ID: <3B529398.B6FF763A@iprg.nokia.com>
Date: Mon, 16 Jul 2001 00:11:20 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>
CC: Gary Kenward <gkenward@nortelnetworks.com>, seamoby@cdma-2000.org
Subject: [seamoby] New words for Req's 4.4reactive/4.5proactive
References: <9FBD322B7824D511B36900508BF93C9C9F5E37@zcard031.ca.nortel.com> <20010713124235.C32517@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hey,

Gary and myself have worked on a new proactive/reactive paragraph
to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
same terminology.
Here it is, please comment, thanks,

Cedric.
-------------------------------------------------------------------------


4.4 The context transfer framework MUST support proactive context transfer.

4.5 The context transfer framework MUST support reactive context transfer.

   It is useful to consider two complementary, non exclusive
modes of operation for context transfer:
proactive and reactive.

   The context transfer process is said to be proactive when the required
contexts are requested to be in place at the target AR  prior to the arrival of
MN's packet
at target AR.

   With proactive context transfer, the idea is to make the context available
to an AR before it is needed. This means that the context is
available at the AR before it is required to forward the first
packet arrival in the MN's traffic. Proactive context transfer is
coupled to mobile handover only by the requirement that the context
be in place before the handover of the MN's traffic is complete.

   The context transfer is said to be reactive when it is not proactive.

   The idea is that in a reactive context transfer, no guarantee is made as to
when the context will be in place at newAR. The context transfer process reacts
to the handover, but has no control over or knowledge of the handover to ensure
that it is in places before the arrival of MN's packet at the target AR.
Reactive context transfer is coupled to mobile handover only by the requirement
that some handover event is triggering the reaction. Reactive context transfer
completes as soon as possible, but its completion is independent of the handover
process.

   Depending upon the network configuration, the MN's velocity and the behavior
of the mobility solution, a reactive context transfer may or may not complete
quickly enough for the new forwarding AR to provide a consistent service to
the first packets of the re-directed traffic.

   In many situations there is no forewarning available of a handover
and context transfer must be initiated simply because the
re-direction of the MN's traffic is in progress and the AR needs the
forwarding context immediately. Because of the physical constraints,
these situations can  never be completely avoided. Thus, if context
transfer is to be  performed at all, the fundamental mode of operation
must be reactive.

   The proactive mode of context transfer is an attempt to further
reduce any disruption of the service provided to the MN's traffic by
making the context available to an AR prior to it being needed for
forwarding. This implies that some network event will occur at the IP
level to indicate the potential for a handover, prior to the handover
being initiated (c.f. requirements 4.1 and 4.2). This event would
trigger a proactive context transfer if there is confidence the context
transfer can complete before the arrival of MN's packet at the target AR.
There can be no guarantee that this event will occur or that this confidence
will be acquired, and thus, a reactive context transfer is
always required as a contingency.

   This also means that a context transfer that begins in proactive mode
may, as a result of the MN moving or other changes to the wireless
environment, be required to complete in reactive mode.  If the target
AR stays the same, then the same proactive context transfer attempt
should evolve into a reactive context transfer attempt.

   As the proactive mode of context transfer is an enhancement, there may be
situations where the reactive mode is considered a sufficient solution.
While it is required that the context transfer protocol support proactive
mode, its use is optional.




From owner-seamoby@diameter.org  Mon Jul 16 04:26:16 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23330
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 04:26:06 -0400 (EDT)
Received: (qmail 9600 invoked by alias); 16 Jul 2001 08:14:24 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 9594 invoked by uid 200); 16 Jul 2001 08:14:24 -0000
Received: (qmail 9589 invoked from network); 16 Jul 2001 08:14:22 -0000
Received: from maile.telia.com (194.22.190.16)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 08:14:22 -0000
Received: from parchment (h242n1fls33o801.telia.com [213.64.180.242])
	by maile.telia.com (8.11.2/8.11.0) with SMTP id f6G8P3c09776;
	Mon, 16 Jul 2001 10:25:03 +0200 (CEST)
From: "Henrik Levkowetz" <henrik@levkowetz.com>
To: <seamoby@cdma-2000.org>
Cc: "Gary Kenward" <gkenward@nortelnetworks.com>,
        "Cedric Westphal" <cedric@IPRG.nokia.com>
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Mon, 16 Jul 2001 10:25:03 +0200
Message-ID: <MFEILCGMDFHKIOINEEHEMEPCCHAA.henrik@levkowetz.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3B529398.B6FF763A@iprg.nokia.com>
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Cedric, Gary

	I find the background explanatory text very good but when you get
into describing the way the protocol will work, I see an assumption
sneaking in which I don't agree to, namely that the protocol will need
to have two _modes_ of operation.  Maybe it will, or maybe we will be
able to define / design the triggers and handling at the destination
in such a way that there really will be only one mode. But I think
it's premature to imply two modes, ... maybe you didn't really mean to?

	Anyway, I've suggested revised text inline, below.

	Best,
		Henrik

> 
> Hey,
> 
> Gary and myself have worked on a new proactive/reactive paragraph
> to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> same terminology.
> Here it is, please comment, thanks,
> 
> Cedric.
> -------------------------------------------------------------------------
> 
> 
> 4.4 The context transfer framework MUST support proactive context transfer.
> 
> 4.5 The context transfer framework MUST support reactive context transfer.
> 
>    It is useful to consider two complementary, non exclusive
> modes of operation for context transfer:
> proactive and reactive.
> 
>    The context transfer process is said to be proactive when the required
> contexts are requested to be in place at the target AR  prior to the arrival of
> MN's packet
> at target AR.
> 
>    With proactive context transfer, the idea is to make the context available
> to an AR before it is needed. This means that the context is
> available at the AR before it is required to forward the first
> packet arrival in the MN's traffic. Proactive context transfer is
> coupled to mobile handover only by the requirement that the context
> be in place before the handover of the MN's traffic is complete.
> 
>    The context transfer is said to be reactive when it is not proactive.
> 
>    The idea is that in a reactive context transfer, no guarantee is made as to
> when the context will be in place at newAR. The context transfer process reacts
> to the handover, but has no control over or knowledge of the handover to ensure
> that it is in places before the arrival of MN's packet at the target AR.
> Reactive context transfer is coupled to mobile handover only by the requirement
> that some handover event is triggering the reaction. Reactive context transfer
> completes as soon as possible, but its completion is independent of the handover
> process.
> 
>    Depending upon the network configuration, the MN's velocity and the behavior
> of the mobility solution, a reactive context transfer may or may not complete
> quickly enough for the new forwarding AR to provide a consistent service to
> the first packets of the re-directed traffic.
> 
>    In many situations there is no forewarning available of a handover
> and context transfer must be initiated simply because the
> re-direction of the MN's traffic is in progress and the AR needs the
> forwarding context immediately. Because of the physical constraints,
> these situations can  never be completely avoided. Thus, if context
> transfer is to be  performed at all, the fundamental mode of operation
> must be reactive.

.................................................. Thus, if context
transfer is to be performed at all, its fundamental function must be
reactive context transfer.

> 
>    The proactive mode of context transfer is an attempt to further

   The ability to transfer context proactively is an attempt to further
...

> reduce any disruption of the service provided to the MN's traffic by
> making the context available to an AR prior to it being needed for
> forwarding. This implies that some network event will occur at the IP
> level to indicate the potential for a handover, prior to the handover
> being initiated (c.f. requirements 4.1 and 4.2). This event would
> trigger a proactive context transfer if there is confidence the context
> transfer can complete before the arrival of MN's packet at the target AR.
> There can be no guarantee that this event will occur or that this confidence
> will be acquired, and thus, a reactive context transfer is
> always required as a contingency.
> 
>    This also means that a context transfer that begins in proactive mode
> may, as a result of the MN moving or other changes to the wireless
> environment, be required to complete in reactive mode.  If the target
> AR stays the same, then the same proactive context transfer attempt
> should evolve into a reactive context transfer attempt.

   This also means that a context transfer that begins as a proactive transfer
may, as a result of the MN moving or other changes to the wireless
environment, be required to complete as a reactive transfer.  If the target
AR stays the same, then the same proactive context transfer attempt
should evolve into a reactive context transfer attempt.

> 
>    As the proactive mode of context transfer is an enhancement, there may be
> situations where the reactive mode is considered a sufficient solution.
> While it is required that the context transfer protocol support proactive
> mode, its use is optional.

   As proactive context transfer is an enhancement, there may be
situations where reactive transfer is considered a sufficient solution.
While it is required that the context transfer protocol support proactive
context transfer, this ability may not always be implemented or used.
   <<<The last sentence limps a bit, I think. Maybe you'll find
      a better formulation that doesn't go into Modes. /Henrik>>>



From owner-seamoby@diameter.org  Mon Jul 16 06:59:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09907
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 06:59:09 -0400 (EDT)
Received: (qmail 10893 invoked by alias); 16 Jul 2001 10:48:10 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 10887 invoked by uid 200); 16 Jul 2001 10:48:09 -0000
Received: (qmail 10882 invoked from network); 16 Jul 2001 10:48:07 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 10:48:07 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09564;
	Mon, 16 Jul 2001 06:57:58 -0400 (EDT)
Message-Id: <200107161057.GAA09564@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: seamoby@cdma-2000.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [seamoby] I-D ACTION:draft-ietf-seamoby-cardiscovery-issues-00.txt
Date: Mon, 16 Jul 2001 06:57:57 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Context Transfer, Handoff Candidate Discovery and Dormant Mode Host Alerting Working Group of the IETF.

	Title		: Issues in candidate access router discovery for 
                          seamless IP handoffs
	Author(s)	: D. Trossen et al.
	Filename	: draft-ietf-seamoby-cardiscovery-issues-00.txt
	Pages		: 6
	Date		: 13-Jul-01
	
Handoff in IP mobility protocols involves moving a mobile node's
Layer 3 routing reachability information from one access router to
another, before or after the mobile node has established a Layer 2
connection with the radio access point that is covered by the new
access router.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-seamoby-cardiscovery-issues-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-seamoby-cardiscovery-issues-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-ietf-seamoby-cardiscovery-issues-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010713123741.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-ietf-seamoby-cardiscovery-issues-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-seamoby-cardiscovery-issues-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010713123741.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-seamoby@diameter.org  Mon Jul 16 07:01:43 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10800
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 07:01:42 -0400 (EDT)
Received: (qmail 11376 invoked by alias); 16 Jul 2001 10:50:44 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 11370 invoked by uid 200); 16 Jul 2001 10:50:44 -0000
Received: (qmail 11365 invoked from network); 16 Jul 2001 10:50:42 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 10:50:42 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10339;
	Mon, 16 Jul 2001 07:00:32 -0400 (EDT)
Message-Id: <200107161100.HAA10339@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [seamoby] I-D ACTION:draft-manyfolks-l2-mobilereq-00.txt
Date: Mon, 16 Jul 2001 07:00:32 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Requirements for Layer 2 Protocols to Support 
                          Optimized Handover for IP Mobility
	Author(s)	: J. Kempf et al.
	Filename	: draft-manyfolks-l2-mobilereq-00.txt
	Pages		: 
	Date		: 13-Jul-01
	
A critical factor in achieving good performance for IP mobility 
protocols is the design of L2 handover. Handover occurs when a 
Mobile Node moves from one radio Access Point to another. If the new 
radio Access Point is associated with a new subnet, a change in 
routing reachability may occur and require L3 protocol action on the 
part of the Mobile Node or Access Routers. If no change in subnet 
occurs, the Access Point may still need to take some action to 
inform the Access Router about a change in on-link reachability.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-manyfolks-l2-mobilereq-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-manyfolks-l2-mobilereq-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-manyfolks-l2-mobilereq-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010713124228.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-manyfolks-l2-mobilereq-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-manyfolks-l2-mobilereq-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010713124228.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-seamoby@diameter.org  Mon Jul 16 07:44:25 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16754
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 07:44:23 -0400 (EDT)
Received: (qmail 12157 invoked by alias); 16 Jul 2001 11:33:53 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 12151 invoked by uid 200); 16 Jul 2001 11:33:53 -0000
Received: (qmail 12142 invoked by uid 500); 16 Jul 2001 11:33:51 -0000
Date: Mon, 16 Jul 2001 04:33:51 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: john.loughney@nokia.com
Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org
Subject: Re: CT reliability model was RE: [seamoby] [Issue] Support for Mu lti- Phase CT
Message-ID: <20010716043351.C1139@charizard.diameter.org>
Mail-Followup-To: john.loughney@nokia.com, pcalhoun@diameter.org,
	seamoby@cdma-2000.org
References: <0C1353ABB1DEB74DB067ADFF749C4EEF09405F@esebe004.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF09405F@esebe004.NOE.Nokia.com>; from john.loughney@nokia.com on Mon, Jul 16, 2001 at 09:48:02AM +0300
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Mon, Jul 16, 2001 at 09:48:02AM +0300, john.loughney@nokia.com wrote:
> Hi Pat,
> 
> > As I've mentioned time and time again, if folks believe that another 
> > transport is better suited, please plead your case to the transport 
> > ADs. Perhaps given the necessary justification they could be swayed.
> 
> As a matter of procedure, I thought that this would be discussed
> when it is time to do protocol selection.  I don't think that this
> is something that could or should be decided prior to that.

Correct. The best we can do at this stage is to provide requirements
on how we need the protocol to function over the network. These can later
be extracted into transport discussions.

I was simply responding to a question.

PatC


From owner-seamoby@diameter.org  Mon Jul 16 08:46:06 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28460
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 08:46:05 -0400 (EDT)
Received: (qmail 13003 invoked by alias); 16 Jul 2001 12:34:58 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 12996 invoked by uid 200); 16 Jul 2001 12:34:57 -0000
Received: (qmail 12991 invoked from network); 16 Jul 2001 12:34:56 -0000
Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 12:34:56 -0000
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id <317T3Z60>; Mon, 16 Jul 2001 08:44:54 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE46054673@ftmail>
From: George Tsirtsis <G.Tsirtsis@flarion.com>
To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
Subject: [seamoby] Comments on:  I-D ACTION:draft-manyfolks-l2-mobilereq-00.txt
Date: Mon, 16 Jul 2001 08:43:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

First of all to say again that this is useful work...sorry for the large
number of comments but I hope you will find them constructive.


1. In section 3.1 you explain what an L2 Trigger is. 
"  An L2 trigger is an abstraction of a notification from L2 
   (potentially including parameter information) that a certain event 
   has happened or is about to happen. "
I would continue to clarify with something like that:
"...The L2 Trigger is delivered to the IP layer so that IP protocols aware
of this trigger can act accordingly. The purpose of this specification is to
standardize a set of triggers with their meaning and parameters they carry.
How the triggers are created is outside the scope of this document and
should be defined on a per L2 Protocols bases."

2. Why is Section 4 in this draft? Why do we examine triggers for L2
Handoffs...I think this is out of scope? Section 5 describes use of triggers
with L3 Handoffs which is in scope and all we need...

3. In the table in Section 5 I have a different view on the concept of
"Recipient" of the various Triggers described. I think the "Recipient" is
the *IP Layer* in either the AR or the MN. Whether the trigger comes via an
AP or not is not relevant IMO. The consideration of the AP, however, is
sometime useful in the spec (e.g.: some times you need the AP's L2 addr if
one is used). Still the AP itself is never the recipient of the
trigger...i.e.: the AP does not act on trigger reception, apart from
forwarding it to the AR as normal.

4. I suggest the table in section 5 to be expanded and each Trigger to be
described in a bit more detailed...the sort, table descriptions, are a bit
nebulous...BTW, what is the purpose of "L2 Handover Start" Trigger??

5. Section 6.1.:
"  Although this timing requirement is 
   loosely defined, it is desirable to initiate reactive CT sometime 
   before (or about the same time as) the L2 handoff initiation. "
Please define "L2 Handoff" in the spec...it keeps confusing me...to my mind
we are only talking about L2 Handoffs here...so, what do you mean above?
similar things appear throughout the doc...


6. Section 6.2 defines CT related triggers, why are these different from the
ones in Section 5?? Surely the Source/Dest Triggers defined in section 5 can
(optionally?) include the information required for the triggers defined in
6.2. Also why do you have CT triggers going to the MN? and why both reactive
and proactive triggers go to both old and new ARs? 

7. Section 7:
"  While the primary purpose of L2 triggers described in this draft is 
   to aid L2 mobility optimization, L2 triggers can also benefit 
   networks without Mobile IP or other IP mobility protocol support. "
...to aid L2 mobility optimization???? you mean L3 mobility optimization? or
the term confuses me again?


Thanks and again good work!
George


From owner-seamoby@diameter.org  Mon Jul 16 11:40:54 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04940
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 11:40:52 -0400 (EDT)
Received: (qmail 15411 invoked by alias); 16 Jul 2001 15:29:58 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15405 invoked by uid 200); 16 Jul 2001 15:29:58 -0000
Received: (qmail 15400 invoked from network); 16 Jul 2001 15:29:56 -0000
Received: from netmail.alcatel.com (128.251.168.50)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 15:29:56 -0000
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id KAA04860;
	Mon, 16 Jul 2001 10:40:32 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6GFeVx20604;
	Mon, 16 Jul 2001 10:40:31 -0500 (CDT)
Message-ID: <3B52FC17.AA681AA1@usa.alcatel.com>
Date: Mon, 16 Jul 2001 10:37:12 -0400
From: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby <seamoby@cdma-2000.org>
CC: Pat Calhoun <pcalhoun@diameter.org>, Allison Mankin <mankin@isi.edu>,
        James Kempf <James.Kempf@Sun.COM>
Subject: [seamoby] Re: 
References: <200107091647.JAA17164@heliopolis.eng.sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

If there is a rule that says that every I-D submitted within the preset
deadlines to the right WG (whose charter includes the subject matter) has a
right to be presented at the next IETF meeting,
then clearly and once more your decision is against this rule. I'd like the
AD Allison Mankin to pronounce her opinion on this.
  To my knowledge, Mobile IP WG always followed this rule.

Pat Calhoun wrote:
>Another alternative
>is to have a bar meeting of all paging protocol folks.
People can discuss whatever subject they like  at a bar.
Is this new Calhounism, or what?

BTW, our work was motivated by Jim's (paging DT editor)  following remarks
James Kempf wrote:

> For those of you who argued against having the core network involved in
> paging, I'm told that, in the absence of a well defined IP paging
> protocol, 3GPP has decided to adopt a hack involving SMS and WAP
> to do push services notification from the core network. I don't
> have many details, but I think the idea is that where there is no
> active PDP context, the core issues an SMS message including some
> WAP content that causes the UE to wake up and smell the coffee.
>
> Is there anyone out there who regularly attends 3GPP meetings that
> has more information on this? Unfortunatly, I am unable to attend
> any 3GPP meetings because Sun has a very strict travel ban in
> place, but I would be really interested in talking with someone
> who can go about the Seamoby IP paging work. We now have requirements
> and I would like to match them up against 3GPP's requirements to
> see whether we can get a better match than this hack they seem
> to have come up with. In addition, we have at least one
> candidate protocol (which, unfortunately, is currently tied to
> mobile IP), and the plan is to finalize a protocol by Dec.
>
>                 jak

Regards,

--
Behcet



From owner-seamoby@diameter.org  Mon Jul 16 11:45:33 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05717
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 11:45:32 -0400 (EDT)
Received: (qmail 15900 invoked by alias); 16 Jul 2001 15:34:42 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15894 invoked by uid 200); 16 Jul 2001 15:34:41 -0000
Received: (qmail 15885 invoked from network); 16 Jul 2001 15:34:40 -0000
Received: from hume.neobright.net (root@209.143.19.251)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 15:34:40 -0000
Received: from brightnetFW ([192.168.1.1])
	by hume.neobright.net (8.9.3/8.9.3 FNG) with SMTP id LAA12391
	for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 11:45:25 -0400
Received: from wrq-nc1 [10.1.1.1] by WRQ1-NorthCoast.bright.net [209.143.22.124] with SMTP (MDaemon.v2.7.SP3.R) for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 11:45:15 -0400
From: "Emil Sturniolo" <emils@netmotionwireless.com>
To: "Cedric Westphal" <cedric@IPRG.nokia.com>,
        "Pat Calhoun" <pcalhoun@diameter.org>
Cc: "Gary Kenward" <gkenward@nortelnetworks.com>, <seamoby@cdma-2000.org>
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Mon, 16 Jul 2001 11:45:14 -0400
Message-ID: <004701c10e0e$4e10f630$7c168fd1@wrq-nc1.wrq.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
In-Reply-To: <3B529398.B6FF763A@iprg.nokia.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-MDaemon-Deliver-To: seamoby@cdma-2000.org
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi folks,
	I just have one observation. From reading the new text:

"This means that the context is available at the AR before it is
required to forward the first
packet arrival in the MN's traffic. Proactive context transfer is
coupled to mobile handover only by the requirement that the context be
in place before the handover of the MN's traffic is complete."

My interpretation of this is that a "proactive context transfer" must
be totally completed prior to HO. If one considers a multi-phasic
transfer, and only enough context is transfer proactively to allow
packet forwarding, but other ancillary information is subsequently
communicated, I believe from the current definition that the
completion of this transfer is deemed a "reactive process". I am fine
with this distinction,  but I would like to see it be specifically
stated rather then just implied. Alternatively, we could change the
text slightly to account for this case and still allow it to be a
completed within the scope of a proactive transfer. Suggested text:

"This means that enough of the context is available at the AR before
it is required to process any of the MN's traffic. Proactive context
transfer is coupled to mobile handover only by the prerequisite that
elements of the context that enable packet forwarding be in place
before the handover of the MN's traffic is complete."


Comments?


Cordially,
Emil Sturniolo
EmilS@NetMotionWireless.Com
www.NetMotionWireless.com
330-723-9099
330-461-0326 - Mobile/Voice Mail
=====================




From owner-seamoby@diameter.org  Mon Jul 16 12:56:37 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21545
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 12:56:36 -0400 (EDT)
Received: (qmail 16523 invoked by alias); 16 Jul 2001 16:46:03 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16517 invoked by uid 200); 16 Jul 2001 16:46:03 -0000
Received: (qmail 16512 invoked from network); 16 Jul 2001 16:46:01 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 16:46:01 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA01321;
	Mon, 16 Jul 2001 10:56:35 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA23654;
	Mon, 16 Jul 2001 09:56:35 -0700 (PDT)
Message-Id: <200107161656.JAA23654@heliopolis.eng.sun.com>
Date: Mon, 16 Jul 2001 09:56:36 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [seamoby] Mobile Operators REquirements (MORE) BOF
To: seamoby@diameter.org, mobile-ip@sunroof.eng.sun.com,
        urp@research.telcordia.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: mRjSOzCDMAelux9uxHYtLw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Folks,

Apologies for the wide posting.

Recently, there was a draft posted 
(draft-reynolds-mobile-isp-requirements-00.txt) that discusses requirements
for wireless ISPs (WISPs) for IP protocols related to or impacted
by mobility. There has been some discussion on the mailing list
(more@psg.com, usual majordomo subscription procedure) about the
requirements. We are now in the process of planning for a BOF at IETF 51
in London. If anyone is interested in speaking at the BOF, please send
me email.

		jak 



From owner-seamoby@diameter.org  Mon Jul 16 13:19:15 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27417
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 13:19:13 -0400 (EDT)
Received: (qmail 17057 invoked by alias); 16 Jul 2001 17:08:13 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 17051 invoked by uid 200); 16 Jul 2001 17:08:13 -0000
Received: (qmail 17040 invoked by uid 500); 16 Jul 2001 17:08:11 -0000
Date: Mon, 16 Jul 2001 10:08:11 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
Cc: seamoby <seamoby@cdma-2000.org>, Pat Calhoun <pcalhoun@diameter.org>,
        Allison Mankin <mankin@isi.edu>, James Kempf <James.Kempf@Sun.COM>
Subject: Re: [seamoby] Process Violation (was: no subject)
Message-ID: <20010716100811.K1139@charizard.diameter.org>
Mail-Followup-To: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>,
	seamoby <seamoby@cdma-2000.org>,
	Pat Calhoun <pcalhoun@diameter.org>,
	Allison Mankin <mankin@isi.edu>, James Kempf <James.Kempf@Sun.COM>
References: <200107091647.JAA17164@heliopolis.eng.sun.com> <3B52FC17.AA681AA1@usa.alcatel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B52FC17.AA681AA1@usa.alcatel.com>; from behcet.sarikaya@usa.alcatel.com on Mon, Jul 16, 2001 at 10:37:12AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Mon, Jul 16, 2001 at 10:37:12AM -0400, Behcet Sarikaya wrote:
> If there is a rule that says that every I-D submitted within the preset
> deadlines to the right WG (whose charter includes the subject matter) has a
> right to be presented at the next IETF meeting,
> then clearly and once more your decision is against this rule. 

Well, no there is absolutely no such rule. In fact, the transport Area
Directors frown upon "presentations", since there is no way that folks
can evaluate the technical merits of a draft based on a 10 minute talk.
It is assumed that folks have read the specs, and the face to face meeting
is used for issues that require high-bandwidth. A good example of a
slot would be to discuss paging issues that have arised on the list
and need to be discussed face to face.

I'd be interested in why you accuse me of attempting to violate rules
"once more". Having worked in the IETF for a long time now, there is no
rule that I am aware of that I have violated. Perhaps you can enlighten
me?

> I'd like the
> AD Allison Mankin to pronounce her opinion on this.

Absolutely. Allison is the right person to talk to if you believe that
I am not performing the duties of chair properly. I would also
encourage you to read RFC2418, as background material prior to
chatting with Allison.

>   To my knowledge, Mobile IP WG always followed this rule.

Right, and each area is handled differently. I have stated before
that there are many items that are discussed in MIP meetings that
really belong on the list. The transport ADs are much more stringent.

Having said all that, I am curious as to why you believe it is
a important for us to listen to a protocol discussion when we have
yet to reach that stage. As I previously stated, the requirements
I-D are still being discussed by the IESG, and before we have concrete
requirements, I do not see how we can realistically discuss
protocols.

All I am asking for is a little patience on your part. Once we 
have completed the requirements stage, you will be entitled to
discuss issues that your draft solves. Meanwhile, I encourage you
to start a discussion on the list (which is the right way to do
things within the IETF).

PatC


From owner-seamoby@diameter.org  Mon Jul 16 13:47:39 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03403
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 13:47:36 -0400 (EDT)
Received: (qmail 17844 invoked by alias); 16 Jul 2001 17:36:17 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 17838 invoked by uid 200); 16 Jul 2001 17:36:17 -0000
Received: (qmail 17833 invoked from network); 16 Jul 2001 17:36:15 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 17:36:15 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA08184;
	Mon, 16 Jul 2001 10:46:29 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6GHkTF11673;
	Mon, 16 Jul 2001 10:46:29 -0700
X-mProtect:  Mon, 16 Jul 2001 10:46:29 -0700 Nokia Silicon Valley Messaging Protection
Received: from tpagtzis.iprg.nokia.com (205.226.2.115, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdXZij9p; Mon, 16 Jul 2001 10:46:27 PDT
Message-ID: <3B532873.FAB52CED@iprg.nokia.com>
Date: Mon, 16 Jul 2001 10:46:27 -0700
From: Theo Pagtzis <tpagtzis@IPRG.nokia.com>
Reply-To: tpagtzis@IPRG.nokia.com
Organization: UCL/NOKIA
X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.1-STABLE i386)
X-Accept-Language: el, en
MIME-Version: 1.0
To: Emil Sturniolo <emils@netmotionwireless.com>
CC: Cedric Westphal <cedric@IPRG.nokia.com>,
        Pat Calhoun <pcalhoun@diameter.org>,
        Gary Kenward <gkenward@nortelnetworks.com>,
        seamoby <seamoby@cdma-2000.org>
Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive
References: <004701c10e0e$4e10f630$7c168fd1@wrq-nc1.wrq.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Emil,

    While I would agree with the terminology over proactive context
transfer, I would have to disagree on the atomicity of tranfer with
respect to proactivity. Proactivity must not require that all context is
transfered to the new point of attachement. This is bound to be too
costly should the selection decision of the new CAR misses the correct
candidate; this is bound to be the case a lot until...something 'else' is
in place. More on that 'else' later.

The transfer of context must be bound by the context constituents that
are sufficient and necessary for the node to transit over a proactive
transition mode. This implies partial context existence in the new
candidate points of attachement. Partiality must not mean that something
critical for seamlessness is not in place in terms of context at the
CARs. Thus partial context transfer over proactive transition mode(s)
must imply a totality of context necessary to effect seamlessness.
Depending on what is considered as a seamlessness factor in each context
ontology, then the totality and partiality over transfer of a discrete
number of constituents in new CARs is defined accordingly.

I would like to expand the set of transition modes to the CT requirements
document by adding an extra transition mode. It can be found in
draft-pagtzis-mobileip-proactivev6-00.txt or ps file.

This is the transition mode of "forward reactive handoff". I personally
consider it as equally important since it provides the intermediate step
between a pure reactive and a pure proactive handoff.

I would appreciate the view of the constituency on this transition mode
for the purposes of context transfer.

Theo

UCL/ Mobile Systems


Emil Sturniolo wrote:

> Hi folks,
>         I just have one observation. From reading the new text:
>
> "This means that the context is available at the AR before it is
> required to forward the first
> packet arrival in the MN's traffic. Proactive context transfer is
> coupled to mobile handover only by the requirement that the context be
> in place before the handover of the MN's traffic is complete."
>
> My interpretation of this is that a "proactive context transfer" must
> be totally completed prior to HO. If one considers a multi-phasic
> transfer, and only enough context is transfer proactively to allow
> packet forwarding, but other ancillary information is subsequently
> communicated, I believe from the current definition that the
> completion of this transfer is deemed a "reactive process". I am fine
> with this distinction,  but I would like to see it be specifically
> stated rather then just implied. Alternatively, we could change the
> text slightly to account for this case and still allow it to be a
> completed within the scope of a proactive transfer. Suggested text:
>
> "This means that enough of the context is available at the AR before
> it is required to process any of the MN's traffic. Proactive context
> transfer is coupled to mobile handover only by the prerequisite that
> elements of the context that enable packet forwarding be in place
> before the handover of the MN's traffic is complete."
>
> Comments?
>
> Cordially,
> Emil Sturniolo
> EmilS@NetMotionWireless.Com
> www.NetMotionWireless.com
> 330-723-9099
> 330-461-0326 - Mobile/Voice Mail
> =====================



From owner-seamoby@diameter.org  Mon Jul 16 14:21:13 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10307
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 14:21:11 -0400 (EDT)
Received: (qmail 18785 invoked by alias); 16 Jul 2001 18:09:14 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18779 invoked by uid 200); 16 Jul 2001 18:09:14 -0000
Received: (qmail 18774 invoked from network); 16 Jul 2001 18:09:13 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 18:09:13 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA12965
	for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 12:19:55 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA27902;
	Mon, 16 Jul 2001 11:19:55 -0700 (PDT)
Message-Id: <200107161819.LAA27902@heliopolis.eng.sun.com>
Date: Mon, 16 Jul 2001 11:19:56 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [seamoby] Re: [mobile-ip] Comments on:  I-D ACTION:draft-manyfolks-l2-mobilereq-00.txt
To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: ahEMQ88TqPBxAFnLjGpqXg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

George,

Thanx for you comments. I'll fold them in on the next revision, which
will be after IETF 51. Specific responses below.

		jak

>1. In section 3.1 you explain what an L2 Trigger is. 
>"  An L2 trigger is an abstraction of a notification from L2 
>   (potentially including parameter information) that a certain event 
>   has happened or is about to happen. "
>I would continue to clarify with something like that:
>"...The L2 Trigger is delivered to the IP layer so that IP protocols aware
>of this trigger can act accordingly. The purpose of this specification is to
>standardize a set of triggers with their meaning and parameters they carry.
>How the triggers are created is outside the scope of this document and
>should be defined on a per L2 Protocols bases."
>

OK.

>2. Why is Section 4 in this draft? Why do we examine triggers for L2
>Handoffs...I think this is out of scope? Section 5 describes use of triggers
>with L3 Handoffs which is in scope and all we need...
>

If the AR is not informed that the MN has changed APs, the AR's 
mapping of L2 address to IP address may be out of date when the MN moves.
The AR must either perform proxy ARP (IPv4) or Neighbor Discovery (IPv6)
in order to refresh the mapping.

With an L2 trigger and an associated update protocol, the AP could
specfically tell the AR what the new mapping is. If all the APs
have a single radio technology, then one can  reasonably argue
that this is radio technology specific (even if the protocol
to update the AR's mapping is based on IP); however, in the future,
it is possible that subnets with mixed technology APs may become
more common. So, while the draft does not advocate a particular
approach to solving this problem, it does lay out the requirements
for allowing it to be solved, should some working group  decide
they wanted to take on the task.

>3. In the table in Section 5 I have a different view on the concept of
>"Recipient" of the various Triggers described. I think the "Recipient" is
>the *IP Layer* in either the AR or the MN. Whether the trigger comes via an
>AP or not is not relevant IMO. The consideration of the AP, however, is
>sometime useful in the spec (e.g.: some times you need the AP's L2 addr if
>one is used). Still the AP itself is never the recipient of the
>trigger...i.e.: the AP does not act on trigger reception, apart from
>forwarding it to the AR as normal.
>

I'm not entirely sure I understand your comment, but let me see.

Basically, the idea in the draft is that the AP is not a recipient
of the trigger, however, it may be the source. The recipient that
is identified in the draft is an IP entity (i.e. an IP host or
an IP router, the only entities that there are in IP networks).
APs are neither, since they are transparent by definition. 

So I think we are agreeing on that point.

The AP *may* have an IP address if it is engaged in, say, IAPP like
traffic to propogate L2 trigger information. At that point, it
is acting like an IP host.

I agree that, on a particular IP entity identified as a target,
the IP stack is the recepient of the trigger. 

Does this correspond to what you are saying?

>4. I suggest the table in section 5 to be expanded and each Trigger to be
>described in a bit more detailed...the sort, table descriptions, are a bit
>nebulous...

OK, I'll look into it. If you have any proposed wording, please send it
along.

>BTW, what is the purpose of "L2 Handover Start" Trigger??
>

See draft-kempf-beth-ipv6-01.txt. It is used to optimize handover
smoothing.

>5. Section 6.1.:
>"  Although this timing requirement is 
>   loosely defined, it is desirable to initiate reactive CT sometime 
>   before (or about the same time as) the L2 handoff initiation. "
>Please define "L2 Handoff" in the spec...it keeps confusing me...to my mind
>we are only talking about L2 Handoffs here...so, what do you mean above?
>similar things appear throughout the doc...
>

OK.

>
>6. Section 6.2 defines CT related triggers, why are these different from the
>ones in Section 5?? Surely the Source/Dest Triggers defined in section 5 can
>(optionally?) include the information required for the triggers defined in
>6.2. Also why do you have CT triggers going to the MN? and why both reactive
>and proactive triggers go to both old and new ARs? 
>

We had some discussion on this among the authors. It is true that
there is overlap, we wanted to lay out the requirements separately.
The reason is that there is a strong feeling among the CT design
team participants that CT should not be tied to a mobility protocol.
While I think it is probably worthwhile to lay out the requirements
separately, perhaps something should be said about overlap, and
maybe put a section in that describes how to satisfy them with
a single set of triggers. Does this sound like a good idea?

>7. Section 7:
>"  While the primary purpose of L2 triggers described in this draft is 
>   to aid L2 mobility optimization, L2 triggers can also benefit 
>   networks without Mobile IP or other IP mobility protocol support. "
>...to aid L2 mobility optimization???? you mean L3 mobility optimization? or
>the term confuses me again?
>

OK, we probably need to sharpen up the definitions, maybe add one
for L3 mobility.

The idea in this section was some L2 triggers (like those in Section 4,
for example) could be used in nonmobile networks or networks with
the nomadic model.
>
>Thanks and again good work!


Thank you for the comments! If you have any text you'd like to see in the 
document (particularly on the table in Section 5) please send it along.

		jak



From owner-seamoby@diameter.org  Mon Jul 16 14:28:59 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12098
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 14:28:52 -0400 (EDT)
Received: (qmail 19401 invoked by alias); 16 Jul 2001 18:15:03 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 19395 invoked by uid 200); 16 Jul 2001 18:15:03 -0000
Received: (qmail 19390 invoked from network); 16 Jul 2001 18:15:01 -0000
Received: from h157s242a129n47.user.nortelnetworks.com (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 18:15:01 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6GIOE918151
	for <seamoby@diameter.org>; Mon, 16 Jul 2001 14:24:14 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Mon, 16 Jul 2001 14:24:07 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <3HJ26H6F>; Mon, 16 Jul 2001 14:24:09 -0400
Message-ID: <E1A4B2CC91EBD1118A510000F80836F80376D2D3@zwdld002.ca.nortel.com>
From: "Muhammad Jaseemuddin" <jaseem@nortelnetworks.com>
To: mobile-ip@sunroof.eng.sun.com, seamoby@diameter.org
Subject: [seamoby] CFP: Next Generation Internet at ICC 2002
Date: Mon, 16 Jul 2001 14:24:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C10E24.7DC29440"
X-Orig: <jaseem@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C10E24.7DC29440
Content-Type: text/plain

                    CALL FOR PAPERS
           Next Generation Internet Symposium

IN CONJUNCTION WITH ICC 2002
April 28-May 2, 2002 New York, NY USA

As part of ICC 2002, a symposium on the Next Generation Internet
will be held. Participation in this symposium is open to all 
registrants of ICC 2002 (i.e. a separate registration is not 
required).

Papers submitted for consideration to the symposium should focus on 
topics related to the Next Generation Internet (i.e. addressing 
issues and areas that will not be deployed in the public Internet 
for at least 3-5 years). Examples of topics of interest include:
  * NGI Performance                    * NGI Architecture
  * QoS - Fact or Fiction              * Streaming Media
  * Home Networking-based Internet     * Voice over IP
    Services                           * Internet Service
                                         Management
  * Internet Appliances                * Next Generation Optical 
  * NGI Protocols                        Internet
  * NGI Operations & Management        * NGI Applications and
  * Monitoring and measurements          Services
    for next-generation networks       * NGI modeling and
  * Middleboxes (in-the-net services)    simulation tools
  * Network-friendly applications      * Interplanetary issues

Instructions: The paper submission schedule and process is the same 
as for the general ICC 2002 conference (see 
http://www.icc2002.com/InfoForAuthors.html). Be sure to indicate the
Next Generation Internet (NGI) symposium as the target for your
paper on the cover page and also list the relevant hot topic(s).
See the ICC 2002 Call for Papers for detailed submission
Instructions (i.e., schedule, paper-length, etc.).

Business Application Sessions (i.e. panel discussions) proposals are 
also welcome. For these, please submit session proposals to Stan
Moyer and include a brief description of the session, along with
bios of the session organizer/moderator and the proposed speakers.
                                                 
Further information can be obtained from:
  Stan Moyer                       Michael Devetsikiotis 
  General Co-Chair                 General Co-Chair 
  Telcordia Technologies           North Carolina State University
  stanm@research.telcordia.com     mdevets@eos.ncsu.edu 

Sponsored by the following IEEE Communications Society Technical 
Committees:
 * Communications Systems    * Computer Communications
   Integration & Modeling    * Communications Software
 * Personal Communications

Technical Program Committee:

     Symeon Papavassiliou, New Jersey Institute of Technology 
     Nelson Fonseca, State University of Campinas, Brazil 
     Pascal Lorenz, University of Haute-Alsace, France 
     Mohammad Ilyas, Florida Atlantic University 
     Algirdas Pakstas, University of North London 
     Ray Sundararaman, Lucent 
     Amitabh Mishra, Virginia Polytech 
     Joe Touch, USC Information Sciences Institute 
     Tim Moors, Polytechnic University 
     Bassam Hashem, Nortel Networks 
     Alagan Anpalagan, University of Toronto 
     S.-H. Gary Chan, Hong Kong University of Science and Technology 
     Sung Jun Lee, HP Labs 
     Elizabeth Royer, UC Santa Barbara 
     Muhammad Jaseemuddin, Nortel Networks 
     Ted Faber, USC Information Sciences Institute 
     Eric Nahum, IBM Watson Research 
     Vishal Misra, University of Massachusetts 
     Behcet Sarikaya, Alcatel USA 
     David Harle, University of Strathclyde, Scotland 
     Jogesh Muppala, Hong Kong University of Science & Technology 
                                    l
For more information, see:
http://www.comsoc.org/socstr/techcom/commsoft/confs/ngi_cfp.htm


------_=_NextPart_001_01C10E24.7DC29440
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>CFP: Next Generation Internet at ICC 2002</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CALL FOR PAPERS</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Next =
Generation Internet Symposium</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">IN CONJUNCTION WITH ICC =
2002</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">April 28-May 2, 2002 New York, =
NY USA</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">As part of ICC 2002, a symposium =
on the Next Generation Internet</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">will be held. Participation in =
this symposium is open to all </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">registrants of ICC 2002 (i.e. a =
separate registration is not </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">required).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Papers submitted for =
consideration to the symposium should focus on </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">topics related to the Next =
Generation Internet (i.e. addressing </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">issues and areas that will not =
be deployed in the public Internet </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">for at least 3-5 years). =
Examples of topics of interest include:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; * NGI =
Performance&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * NGI =
Architecture</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; * QoS - Fact or =
Fiction&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp; * Streaming Media</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; * Home Networking-based =
Internet&nbsp;&nbsp;&nbsp;&nbsp; * Voice over IP</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp; =
Services&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; * Internet Service</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Management</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; * Internet =
Appliances&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp; * Next Generation Optical </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; * NGI =
Protocols&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; Internet</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; * NGI Operations &amp; =
Management&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * NGI Applications =
and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; * Monitoring and =
measurements&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Services</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp; for =
next-generation networks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * NGI =
modeling and</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; * Middleboxes =
(in-the-net services)&nbsp;&nbsp;&nbsp; simulation tools</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; * Network-friendly =
applications&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; * Interplanetary =
issues</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Instructions: The paper =
submission schedule and process is the same </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">as for the general ICC 2002 =
conference (see </FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"http://www.icc2002.com/InfoForAuthors.html" =
TARGET=3D"_blank">http://www.icc2002.com/InfoForAuthors.html</A></FONT><=
/U><FONT SIZE=3D2 FACE=3D"Courier New">). Be sure to indicate =
the</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Next Generation Internet (NGI) =
symposium as the target for your</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">paper on the cover page and =
also list the relevant hot topic(s).</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">See the ICC 2002 Call for =
Papers for detailed submission</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Instructions (i.e., schedule, =
paper-length, etc.).</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Business Application Sessions =
(i.e. panel discussions) proposals are </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">also welcome. For these, please =
submit session proposals to Stan</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Moyer and include a brief =
description of the session, along with</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">bios of the session =
organizer/moderator and the proposed speakers.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp; </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Further information can be =
obtained from:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; Stan =
Moyer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Michael Devetsikiotis </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; General =
Co-Chair&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; General Co-Chair </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; Telcordia =
Technologies&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
 North Carolina State University</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp; =
stanm@research.telcordia.com&nbsp;&nbsp;&nbsp;&nbsp; =
mdevets@eos.ncsu.edu </FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Sponsored by the following IEEE =
Communications Society Technical </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">Committees:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;* Communications =
Systems&nbsp;&nbsp;&nbsp; * Computer Communications</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp; Integration &amp; =
Modeling&nbsp;&nbsp;&nbsp; * Communications Software</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;* Personal =
Communications</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">Technical Program =
Committee:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Symeon =
Papavassiliou, New Jersey Institute of Technology </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Nelson =
Fonseca, State University of Campinas, Brazil </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Pascal =
Lorenz, University of Haute-Alsace, France </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; =
Mohammad Ilyas, Florida Atlantic University </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; =
Algirdas Pakstas, University of North London </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Ray =
Sundararaman, Lucent </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; =
Amitabh Mishra, Virginia Polytech </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Joe =
Touch, USC Information Sciences Institute </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Tim =
Moors, Polytechnic University </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Bassam =
Hashem, Nortel Networks </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Alagan =
Anpalagan, University of Toronto </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; S.-H. =
Gary Chan, Hong Kong University of Science and Technology </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Sung =
Jun Lee, HP Labs </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; =
Elizabeth Royer, UC Santa Barbara </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; =
Muhammad Jaseemuddin, Nortel Networks </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Ted =
Faber, USC Information Sciences Institute </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Eric =
Nahum, IBM Watson Research </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Vishal =
Misra, University of Massachusetts </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Behcet =
Sarikaya, Alcatel USA </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; David =
Harle, University of Strathclyde, Scotland </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">&nbsp;&nbsp;&nbsp;&nbsp; Jogesh =
Muppala, Hong Kong University of Science &amp; Technology </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier =
New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
l</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Courier New">For more information, =
see:</FONT>
<BR><U><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier New"><A =
HREF=3D"http://www.comsoc.org/socstr/techcom/commsoft/confs/ngi_cfp.htm"=
 =
TARGET=3D"_blank">http://www.comsoc.org/socstr/techcom/commsoft/confs/ng=
i_cfp.htm</A></FONT></U>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C10E24.7DC29440--


From owner-seamoby@diameter.org  Mon Jul 16 15:31:40 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23546
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 15:31:39 -0400 (EDT)
Received: (qmail 20133 invoked by alias); 16 Jul 2001 19:21:01 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20127 invoked by uid 200); 16 Jul 2001 19:21:01 -0000
Received: (qmail 20117 invoked from network); 16 Jul 2001 19:20:59 -0000
Received: from netmail2.alcatel.com (128.251.168.51)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 19:20:59 -0000
Received: from auds953.usa.alcatel.com (auds953.usa.alcatel.com [143.209.238.6])
	by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id OAA16804;
	Mon, 16 Jul 2001 14:31:38 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by auds953.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6GJVbx04975;
	Mon, 16 Jul 2001 14:31:37 -0500 (CDT)
Message-ID: <3B533242.BB6E81E5@usa.alcatel.com>
Date: Mon, 16 Jul 2001 14:28:18 -0400
From: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
X-Mailer: Mozilla 4.76 [en]C-CCK-MCD BDPjm-Sony3  (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>
CC: seamoby <seamoby@cdma-2000.org>, Allison Mankin <mankin@isi.edu>,
        James Kempf <James.Kempf@Sun.COM>
Subject: Re: [seamoby] Process Violation (was: no subject)
References: <200107091647.JAA17164@heliopolis.eng.sun.com> <3B52FC17.AA681AA1@usa.alcatel.com> <20010716100811.K1139@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I do not think that one should try to give or create the impression that (s)he is
indispensible. There are so many respectful, highly qualified and experienced
experts on mobility who can perform the duties of a WG chair. In my humble
opinion these positions should be viewed as opportunities to volontarily serve
IETF and not vice versa.

Pat Calhoun wrote:

> > I'd like the
> > AD Allison Mankin to pronounce her opinion on this.
>
> Absolutely. Allison is the right person to talk to if you believe that
> I am not performing the duties of chair properly.

Kind regards,

--
Behcet



From owner-seamoby@diameter.org  Mon Jul 16 15:37:37 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24632
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 15:37:36 -0400 (EDT)
Received: (qmail 20616 invoked by alias); 16 Jul 2001 19:27:01 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20610 invoked by uid 200); 16 Jul 2001 19:27:00 -0000
Received: (qmail 20604 invoked from network); 16 Jul 2001 19:26:59 -0000
Received: from unknown (HELO megisto-sql1.megisto.com) (63.113.114.132)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 19:26:59 -0000
Received: by mail.megisto.com with Internet Mail Service (5.5.2650.21)
	id <M0D5GWBL>; Mon, 16 Jul 2001 15:36:03 -0400
Message-ID: <CD8355C7E19ED411BD5F00508BB0D19D39B004@mail.megisto.com>
From: Phil Roberts <PRoberts@MEGISTO.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
Cc: seamoby <seamoby@cdma-2000.org>, Allison Mankin <mankin@isi.edu>,
        James Kempf <James.Kempf@Sun.COM>
Subject: RE: [seamoby] Process Violation (was: no subject)
Date: Mon, 16 Jul 2001 15:36:03 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

> >   To my knowledge, Mobile IP WG always followed this rule.
> 
> Right, and each area is handled differently. I have stated before
> that there are many items that are discussed in MIP meetings that
> really belong on the list. The transport ADs are much more stringent.

MIP is going to be constraining things quite a bit more going forward.
There is a long history of allowing lots of presentations, but we tried
last time to restrict things quite a bit and will do so more.

> All I am asking for is a little patience on your part. Once we 
> have completed the requirements stage, you will be entitled to
> discuss issues that your draft solves. Meanwhile, I encourage you
> to start a discussion on the list (which is the right way to do
> things within the IETF).
> 
> PatC
> 


From owner-seamoby@diameter.org  Mon Jul 16 16:18:21 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02092
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 16:18:20 -0400 (EDT)
Received: (qmail 21151 invoked by alias); 16 Jul 2001 20:07:18 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 21145 invoked by uid 200); 16 Jul 2001 20:07:18 -0000
Received: (qmail 21140 invoked from network); 16 Jul 2001 20:07:17 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 20:07:17 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01600;
	Mon, 16 Jul 2001 16:15:36 -0400 (EDT)
Message-Id: <200107162015.QAA01600@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: seamoby@cdma-2000.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [seamoby] I-D ACTION:draft-levkowetz-seamoby-sample-00.txt
Date: Mon, 16 Jul 2001 16:15:35 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Wireless Micro-Mobility Handover Protocol (MM-HOP)
	Author(s)	: O. Levkowetz
	Filename	: draft-levkowetz-seamoby-sample-00.txt
	Pages		: 40
	Date		: 13-Jul-01
	
This Internet-Draft describes an experimental protocol, MM-HOP,
which was defined during the fall of 2000 and is currently being
implemented by ABNW. Using MM-HOP fast, state-preserving handovers
between pico-cell wireless base-stations carrying IP traffic may be
achieved.  This draft is NOT submitted to seamoby as candidate for
any standard protocol, only as a record of a limited implementation
of context transfer and micro-mobility support.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-levkowetz-seamoby-sample-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-levkowetz-seamoby-sample-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-levkowetz-seamoby-sample-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010713124542.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-levkowetz-seamoby-sample-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-levkowetz-seamoby-sample-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010713124542.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-seamoby@diameter.org  Mon Jul 16 17:12:51 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11162
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 17:12:50 -0400 (EDT)
Received: (qmail 21700 invoked by alias); 16 Jul 2001 21:01:35 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 21694 invoked by uid 200); 16 Jul 2001 21:01:35 -0000
Received: (qmail 21686 invoked from network); 16 Jul 2001 21:01:32 -0000
Received: from motgate2.mot.com (136.182.1.10)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 21:01:32 -0000
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA15338 for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 14:12:17 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id OAA06497 for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 14:12:16 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3XDBRX3G>; Mon, 16 Jul 2001 16:12:16 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9EB8@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: seamoby@cdma-2000.org
Subject: [seamoby] RE: Yet another Security RANT was  L2 API (WAS: Ext. for FMIPv6 -
	 comments) (SHOULD be ,          RE: Issue #4)
Date: Mon, 16 Jul 2001 16:12:14 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Phil,

You and I and possibly a lot of people might all have our 2 cents
worth (no offense, just borrowing from your own signature below)
of comments, when it comes to security, but

I heard Jeff Schiller during his security tutorial say:
"Don't come to us with unsecure protocols and say this is
my protocol, if you need security, use IPSec. You need to secure
your protocols yourself."
He also said, "the security folks in security area say, why should
we drop everything and go analyze other people's security problems"

As much as most of us feel we don't know as much as we would like
about security, we need to deal with it ourself. You can expect
your neighbor to shovel your driveway, just because he has a expensive
blower. 

So bottom line, as much as we might hate it, we have to deal with
our own security problems.

Madjid

-----Original Message-----
From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
Sent: Friday, July 13, 2001 8:23 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; Phillip Neumiller; 'Pat Calhoun'
Cc: seamoby@cdma-2000.org
Subject: Yet another Security RANT was L2 API (WAS: Ext. for FMIPv6 -
comments) (SHOULD be , RE: Issue #4)


Hi Madjid,

I disdain coupling security issues with non-security transport 
design and requirements formulation.  I believe security issues
should be left up to the security WG where the appropriate domain
experts can create general purpose solutions.  IP and the major
transport protocols such as UDP, TCP, and SCTP should be made
secure (perhaps with IPsec).  Users of these off-the-shelf 
protocols could then "feel" safe about doing what they want and
not waste time getting all balled up in security issues.  It
seems like a BAD idea to me to make every single IETF WG jump
through security hoops since:

A).  It dilutes the real "work" the WG is trying to do
B).  It allows for wasted effort on different security solutions
     all over the IETF since they are uncoordinated
C).  The members of many non-security WGs do not have the 
     appropriate domain expertise to solve security problems.

So clearly I disagree with our ADs on this issue.  Is that a 
crime?  This is not the first time (or the first WG) I have
stated this (in).

CASE IN POINT: Handovers.

Handovers can be done with MIP.  They can be done with "local-mobility"
protocols, or perhaps in other ways.  Security of the mobile host is
likely to be done differently by different network operators.  To explicitly
tie some mandated security to the our handover work weakens its 
general applicability.  However, I am all in favor of an
API/signaling/trigger
mechanism/hooks for security/AAA.  My two cents!

Thanks,

Phil

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Thursday, July 12, 2001 7:01 PM
> To: 'Phillip Neumiller'; 'Pat Calhoun'
> Cc: 'James Kempf'; gkenward@nortelnetworks.com; Nakhjiri
> Madjid-MNAKHJI1; john.loughney@nokia.com; seamoby@cdma-2000.org
> Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> comments) (SHOULD
> be , RE: Issue #4)
> 
> 
> <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 owner-seamoby@diameter.org  Mon Jul 16 17:36:26 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15821
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 17:36:23 -0400 (EDT)
Received: (qmail 22226 invoked by alias); 16 Jul 2001 21:25:00 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 22220 invoked by uid 200); 16 Jul 2001 21:25:00 -0000
Received: (qmail 22215 invoked from network); 16 Jul 2001 21:24:58 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 21:24:58 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1KQ7W>; Mon, 16 Jul 2001 17:35:12 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484455AF@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Nakhjiri Madjid-MNAKHJI1'" <Madjid.Nakhjiri@motorola.com>,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: seamoby@cdma-2000.org
Subject: [seamoby] RE: Yet another Security RANT was  L2 API (WAS: Ext. for FMIPv6 -
	 comments) (SHOULD be ,          RE: Issue #4)
Date: Mon, 16 Jul 2001 17:35:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Snow blowing my driveway is one thing.  They are asking us to plow
a path to the grocery store!  That I pay taxes for!  In the IETF
the equivalent is the existence of the Security WG and its 
contribution to the Internet as a whole.  So I guess I differ from
you here.  C u in London.  

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Monday, July 16, 2001 5:12 PM
> To: 'Phillip Neumiller'; Nakhjiri Madjid-MNAKHJI1; 'Pat Calhoun'
> Cc: seamoby@cdma-2000.org
> Subject: RE: Yet another Security RANT was L2 API (WAS: Ext. 
> for FMIPv6
> - comments) (SHOULD be , RE: Issue #4)
> 
> 
> Phil,
> 
> You and I and possibly a lot of people might all have our 2 cents
> worth (no offense, just borrowing from your own signature below)
> of comments, when it comes to security, but
> 
> I heard Jeff Schiller during his security tutorial say:
> "Don't come to us with unsecure protocols and say this is
> my protocol, if you need security, use IPSec. You need to secure
> your protocols yourself."
> He also said, "the security folks in security area say, why should
> we drop everything and go analyze other people's security problems"
> 
> As much as most of us feel we don't know as much as we would like
> about security, we need to deal with it ourself. You can expect
> your neighbor to shovel your driveway, just because he has a expensive
> blower. 
> 
> So bottom line, as much as we might hate it, we have to deal with
> our own security problems.
> 
> Madjid
> 
> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Friday, July 13, 2001 8:23 AM
> To: 'Nakhjiri Madjid-MNAKHJI1'; Phillip Neumiller; 'Pat Calhoun'
> Cc: seamoby@cdma-2000.org
> Subject: Yet another Security RANT was L2 API (WAS: Ext. for FMIPv6 -
> comments) (SHOULD be , RE: Issue #4)
> 
> 
> Hi Madjid,
> 
> I disdain coupling security issues with non-security transport 
> design and requirements formulation.  I believe security issues
> should be left up to the security WG where the appropriate domain
> experts can create general purpose solutions.  IP and the major
> transport protocols such as UDP, TCP, and SCTP should be made
> secure (perhaps with IPsec).  Users of these off-the-shelf 
> protocols could then "feel" safe about doing what they want and
> not waste time getting all balled up in security issues.  It
> seems like a BAD idea to me to make every single IETF WG jump
> through security hoops since:
> 
> A).  It dilutes the real "work" the WG is trying to do
> B).  It allows for wasted effort on different security solutions
>      all over the IETF since they are uncoordinated
> C).  The members of many non-security WGs do not have the 
>      appropriate domain expertise to solve security problems.
> 
> So clearly I disagree with our ADs on this issue.  Is that a 
> crime?  This is not the first time (or the first WG) I have
> stated this (in).
> 
> CASE IN POINT: Handovers.
> 
> Handovers can be done with MIP.  They can be done with 
> "local-mobility"
> protocols, or perhaps in other ways.  Security of the mobile host is
> likely to be done differently by different network operators. 
>  To explicitly
> tie some mandated security to the our handover work weakens its 
> general applicability.  However, I am all in favor of an
> API/signaling/trigger
> mechanism/hooks for security/AAA.  My two cents!
> 
> Thanks,
> 
> Phil
> 
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> > Sent: Thursday, July 12, 2001 7:01 PM
> > To: 'Phillip Neumiller'; 'Pat Calhoun'
> > Cc: 'James Kempf'; gkenward@nortelnetworks.com; Nakhjiri
> > Madjid-MNAKHJI1; john.loughney@nokia.com; seamoby@cdma-2000.org
> > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> > comments) (SHOULD
> > be , RE: Issue #4)
> > 
> > 
> > <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 owner-seamoby@diameter.org  Mon Jul 16 18:01:08 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19755
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 18:01:06 -0400 (EDT)
Received: (qmail 22752 invoked by alias); 16 Jul 2001 21:49:53 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 22746 invoked by uid 200); 16 Jul 2001 21:49:53 -0000
Received: (qmail 22741 invoked from network); 16 Jul 2001 21:49:51 -0000
Received: from motgate3.mot.com (144.189.100.103)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 21:49:51 -0000
Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate3.mot.com (motgate3 2.1) with ESMTP id OAA12936 for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 14:53:11 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id PAA02611 for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 15:00:20 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19)
	id <NKTA5Z4W>; Mon, 16 Jul 2001 17:00:20 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9EB9@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'john.loughney@nokia.com'" <john.loughney@nokia.com>,
        seamoby@cdma-2000.org
Subject: RE: [seamoby] CT Requirements Issue 7
Date: Mon, 16 Jul 2001 17:00:08 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk


John,

As I said earlier, I don't think removing the definitions is a good
idea. I was looking at the proactive and reactive definitions that cedric
and
Gary sent out. Although, the definition of reactive does not
require anything, the definition of proactive does set a limit
for CT timing. 

The proactive/ reactive definitions (or procedures as Pat is suggesting)
might not be complete yet, but removing them all together would
be just ignoring all the work that has been done so far. At least
now we have something that reminds us, we need to be careful about
delays and losses.

Regards,
madjid


-----Original Message-----
From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
Sent: Friday, July 13, 2001 1:04 AM
To: seamoby@cdma-2000.org
Subject: [seamoby] CT Requirements Issue 7
Importance: High


Hi all,

I sent this yesterday, but it didn't seem to make the list - let me try
again.

====

Description of issue 

Section 4.4 & 4.5 are potentially limiting.

Submitter name: John Loughney
Submitter email address: john.loughney@nokia.com
Date first submitted: July 12, 2001 
Comment type: T

Priority: S

Section: Insert_Section_Number_Here 

Rationale/Explanation of issue: 

Currently 4.4 and 4.5 imply that there are two modes of operation.  It is
not so cut & dry.  As seen by the discussion on the list, there are many
differing requirements that may not be satisfied by discussion these modes.
Length description of problem 

Currently, by defining proactive & reactive, the work group may start to
think in terms of these 2 modes of operation.  I don't think that CT is so
black & white.  

Requested change: 

Remove proactive & reactive from the document.  These could be used as
examples in the document, if needed.

Disclaimer: I am not saying that proactive, reactive, active, etc. are not
needed - what I am saying is that by defining requirements for more basic
building blocks, we can then use those building blocks to create aggregate
behavior that looks like proactive, reactive, etc.

Proposal 

Focus on the features & functions of reactive & proactive modes rather.  For
example, everyone will agree that certain context may have a higher priority
(may take precidence over, may be more time sensitive, etc.) than others.
Some context may go stale.  Some context may need to be acknowledged.  

By stating the types of functionality that are needed, the requirements will
allow a more rich protocol.


=============================================

Example (solution space):  

We define these features - this is not the complete set:
(priority, time-to-live, ack-needed, synchonized with ho)

So, I would define the transfer of header compression state
as context transfer that has a high priority, a certain time-to-live, 
ack-needed.

High priority would mean that the AR would send it ASAP.

TTL would indicate that the context would go stale.

Ack-needed would indicate to the mobile node that if the
new AR does not yet have the header compression state, 
then it shouldn't send compressed headers, but attempt to
re-initialize the compressor at the new AR.


From owner-seamoby@diameter.org  Mon Jul 16 18:04:47 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20269
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 18:04:43 -0400 (EDT)
Received: (qmail 23122 invoked by alias); 16 Jul 2001 21:52:05 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 23116 invoked by uid 200); 16 Jul 2001 21:52:04 -0000
Received: (qmail 23104 invoked from network); 16 Jul 2001 21:52:02 -0000
Received: from ftpbox.mot.com (129.188.136.101)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 21:52:02 -0000
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id PAA13963 for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 15:02:45 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA29872 for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 15:02:44 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3XDBRZ1C>; Mon, 16 Jul 2001 17:02:44 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9EBA@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Henrik Levkowetz'" <henrik@levkowetz.com>, seamoby@cdma-2000.org
Cc: Gary Kenward <gkenward@nortelnetworks.com>,
        Cedric Westphal <cedric@IPRG.nokia.com>
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Mon, 16 Jul 2001 17:02:42 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

I agree with Henrik, I think it is premature to mention proactive
and reactive as modes of operations, unless we describe the procedures
that are making those two different.

I will sent my comments about the text later :)

Madjid

-----Original Message-----
From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
Sent: Monday, July 16, 2001 3:25 AM
To: seamoby@cdma-2000.org
Cc: Gary Kenward; Cedric Westphal
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive


Cedric, Gary

	I find the background explanatory text very good but when you get
into describing the way the protocol will work, I see an assumption
sneaking in which I don't agree to, namely that the protocol will need
to have two _modes_ of operation.  Maybe it will, or maybe we will be
able to define / design the triggers and handling at the destination
in such a way that there really will be only one mode. But I think
it's premature to imply two modes, ... maybe you didn't really mean to?

	Anyway, I've suggested revised text inline, below.

	Best,
		Henrik

> 
> Hey,
> 
> Gary and myself have worked on a new proactive/reactive paragraph
> to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> same terminology.
> Here it is, please comment, thanks,
> 
> Cedric.
> -------------------------------------------------------------------------
> 
> 
> 4.4 The context transfer framework MUST support proactive context transfer.
> 
> 4.5 The context transfer framework MUST support reactive context transfer.
> 
>    It is useful to consider two complementary, non exclusive
> modes of operation for context transfer:
> proactive and reactive.
> 
>    The context transfer process is said to be proactive when the required
> contexts are requested to be in place at the target AR  prior to the arrival of
> MN's packet
> at target AR.
> 
>    With proactive context transfer, the idea is to make the context available
> to an AR before it is needed. This means that the context is
> available at the AR before it is required to forward the first
> packet arrival in the MN's traffic. Proactive context transfer is
> coupled to mobile handover only by the requirement that the context
> be in place before the handover of the MN's traffic is complete.
> 
>    The context transfer is said to be reactive when it is not proactive.
> 
>    The idea is that in a reactive context transfer, no guarantee is made as to
> when the context will be in place at newAR. The context transfer process reacts
> to the handover, but has no control over or knowledge of the handover to ensure
> that it is in places before the arrival of MN's packet at the target AR.
> Reactive context transfer is coupled to mobile handover only by the requirement
> that some handover event is triggering the reaction. Reactive context transfer
> completes as soon as possible, but its completion is independent of the handover
> process.
> 
>    Depending upon the network configuration, the MN's velocity and the behavior
> of the mobility solution, a reactive context transfer may or may not complete
> quickly enough for the new forwarding AR to provide a consistent service to
> the first packets of the re-directed traffic.
> 
>    In many situations there is no forewarning available of a handover
> and context transfer must be initiated simply because the
> re-direction of the MN's traffic is in progress and the AR needs the
> forwarding context immediately. Because of the physical constraints,
> these situations can  never be completely avoided. Thus, if context
> transfer is to be  performed at all, the fundamental mode of operation
> must be reactive.

.................................................. Thus, if context
transfer is to be performed at all, its fundamental function must be
reactive context transfer.

> 
>    The proactive mode of context transfer is an attempt to further

   The ability to transfer context proactively is an attempt to further
...

> reduce any disruption of the service provided to the MN's traffic by
> making the context available to an AR prior to it being needed for
> forwarding. This implies that some network event will occur at the IP
> level to indicate the potential for a handover, prior to the handover
> being initiated (c.f. requirements 4.1 and 4.2). This event would
> trigger a proactive context transfer if there is confidence the context
> transfer can complete before the arrival of MN's packet at the target AR.
> There can be no guarantee that this event will occur or that this confidence
> will be acquired, and thus, a reactive context transfer is
> always required as a contingency.
> 
>    This also means that a context transfer that begins in proactive mode
> may, as a result of the MN moving or other changes to the wireless
> environment, be required to complete in reactive mode.  If the target
> AR stays the same, then the same proactive context transfer attempt
> should evolve into a reactive context transfer attempt.

   This also means that a context transfer that begins as a proactive transfer
may, as a result of the MN moving or other changes to the wireless
environment, be required to complete as a reactive transfer.  If the target
AR stays the same, then the same proactive context transfer attempt
should evolve into a reactive context transfer attempt.

> 
>    As the proactive mode of context transfer is an enhancement, there may be
> situations where the reactive mode is considered a sufficient solution.
> While it is required that the context transfer protocol support proactive
> mode, its use is optional.

   As proactive context transfer is an enhancement, there may be
situations where reactive transfer is considered a sufficient solution.
While it is required that the context transfer protocol support proactive
context transfer, this ability may not always be implemented or used.
   <<<The last sentence limps a bit, I think. Maybe you'll find
      a better formulation that doesn't go into Modes. /Henrik>>>


From owner-seamoby@diameter.org  Mon Jul 16 18:12:25 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21245
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 18:12:18 -0400 (EDT)
Received: (qmail 23741 invoked by alias); 16 Jul 2001 22:00:45 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 23735 invoked by uid 200); 16 Jul 2001 22:00:45 -0000
Received: (qmail 23725 invoked from network); 16 Jul 2001 22:00:43 -0000
Received: from motgate4.mot.com (144.189.100.102)
  by c900656-a.plstn1.sfba.home.com with SMTP; 16 Jul 2001 22:00:43 -0000
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id PAA04893 for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 15:11:29 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA13311 for <seamoby@cdma-2000.org>; Mon, 16 Jul 2001 15:11:28 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3XDBRZMZ>; Mon, 16 Jul 2001 17:11:28 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9EBB@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: seamoby@cdma-2000.org
Subject: [seamoby] RE: Yet another Security RANT was  L2 API (WAS: Ext. for FMIPv6 -
	 comments) (SHOULD be ,          RE: Issue #4)
Date: Mon, 16 Jul 2001 17:11:28 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Ok, Phil, I guess I haven't been with IETF long enough :)
you need to explain the grocery store part for me in London.

Madjid

-----Original Message-----
From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
Sent: Monday, July 16, 2001 4:35 PM
To: 'Nakhjiri Madjid-MNAKHJI1'; Phillip Neumiller; 'Pat Calhoun'
Cc: seamoby@cdma-2000.org
Subject: RE: Yet another Security RANT was L2 API (WAS: Ext. for FMIPv6
- comments) (SHOULD be , RE: Issue #4)


Snow blowing my driveway is one thing.  They are asking us to plow
a path to the grocery store!  That I pay taxes for!  In the IETF
the equivalent is the existence of the Security WG and its 
contribution to the Internet as a whole.  So I guess I differ from
you here.  C u in London.  

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> Sent: Monday, July 16, 2001 5:12 PM
> To: 'Phillip Neumiller'; Nakhjiri Madjid-MNAKHJI1; 'Pat Calhoun'
> Cc: seamoby@cdma-2000.org
> Subject: RE: Yet another Security RANT was L2 API (WAS: Ext. 
> for FMIPv6
> - comments) (SHOULD be , RE: Issue #4)
> 
> 
> Phil,
> 
> You and I and possibly a lot of people might all have our 2 cents
> worth (no offense, just borrowing from your own signature below)
> of comments, when it comes to security, but
> 
> I heard Jeff Schiller during his security tutorial say:
> "Don't come to us with unsecure protocols and say this is
> my protocol, if you need security, use IPSec. You need to secure
> your protocols yourself."
> He also said, "the security folks in security area say, why should
> we drop everything and go analyze other people's security problems"
> 
> As much as most of us feel we don't know as much as we would like
> about security, we need to deal with it ourself. You can expect
> your neighbor to shovel your driveway, just because he has a expensive
> blower. 
> 
> So bottom line, as much as we might hate it, we have to deal with
> our own security problems.
> 
> Madjid
> 
> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: Friday, July 13, 2001 8:23 AM
> To: 'Nakhjiri Madjid-MNAKHJI1'; Phillip Neumiller; 'Pat Calhoun'
> Cc: seamoby@cdma-2000.org
> Subject: Yet another Security RANT was L2 API (WAS: Ext. for FMIPv6 -
> comments) (SHOULD be , RE: Issue #4)
> 
> 
> Hi Madjid,
> 
> I disdain coupling security issues with non-security transport 
> design and requirements formulation.  I believe security issues
> should be left up to the security WG where the appropriate domain
> experts can create general purpose solutions.  IP and the major
> transport protocols such as UDP, TCP, and SCTP should be made
> secure (perhaps with IPsec).  Users of these off-the-shelf 
> protocols could then "feel" safe about doing what they want and
> not waste time getting all balled up in security issues.  It
> seems like a BAD idea to me to make every single IETF WG jump
> through security hoops since:
> 
> A).  It dilutes the real "work" the WG is trying to do
> B).  It allows for wasted effort on different security solutions
>      all over the IETF since they are uncoordinated
> C).  The members of many non-security WGs do not have the 
>      appropriate domain expertise to solve security problems.
> 
> So clearly I disagree with our ADs on this issue.  Is that a 
> crime?  This is not the first time (or the first WG) I have
> stated this (in).
> 
> CASE IN POINT: Handovers.
> 
> Handovers can be done with MIP.  They can be done with 
> "local-mobility"
> protocols, or perhaps in other ways.  Security of the mobile host is
> likely to be done differently by different network operators. 
>  To explicitly
> tie some mandated security to the our handover work weakens its 
> general applicability.  However, I am all in favor of an
> API/signaling/trigger
> mechanism/hooks for security/AAA.  My two cents!
> 
> Thanks,
> 
> Phil
> 
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:Madjid.Nakhjiri@motorola.com]
> > Sent: Thursday, July 12, 2001 7:01 PM
> > To: 'Phillip Neumiller'; 'Pat Calhoun'
> > Cc: 'James Kempf'; gkenward@nortelnetworks.com; Nakhjiri
> > Madjid-MNAKHJI1; john.loughney@nokia.com; seamoby@cdma-2000.org
> > Subject: RE: [seamoby] L2 API (WAS: Ext. for FMIPv6 - 
> > comments) (SHOULD
> > be , RE: Issue #4)
> > 
> > 
> > <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 owner-seamoby@diameter.org  Mon Jul 16 20:22:25 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15225
	for <seamoby-archive@odin.ietf.org>; Mon, 16 Jul 2001 20:22:24 -0400 (EDT)
Received: (qmail 24602 invoked by alias); 17 Jul 2001 00:11:22 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 24596 invoked by uid 200); 17 Jul 2001 00:11:22 -0000
Received: (qmail 24585 invoked by uid 500); 17 Jul 2001 00:11:20 -0000
Date: Mon, 16 Jul 2001 17:11:20 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
Cc: Pat Calhoun <pcalhoun@diameter.org>, seamoby <seamoby@cdma-2000.org>,
        Allison Mankin <mankin@isi.edu>, James Kempf <James.Kempf@Sun.COM>
Subject: Re: [seamoby] Process Violation (was: no subject)
Message-ID: <20010716171120.A1139@charizard.diameter.org>
Mail-Followup-To: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>,
	Pat Calhoun <pcalhoun@diameter.org>,
	seamoby <seamoby@cdma-2000.org>, Allison Mankin <mankin@isi.edu>,
	James Kempf <James.Kempf@Sun.COM>
References: <200107091647.JAA17164@heliopolis.eng.sun.com> <3B52FC17.AA681AA1@usa.alcatel.com> <20010716100811.K1139@charizard.diameter.org> <3B533242.BB6E81E5@usa.alcatel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B533242.BB6E81E5@usa.alcatel.com>; from behcet.sarikaya@usa.alcatel.com on Mon, Jul 16, 2001 at 02:28:18PM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

Behcet,

I've tried to be polite, but apparently that isn't going to work :(

I believe that the e-mail below demonstrates your lack of knowledge on
how the IETF works. In no way am I stating that Allison is indispensible (sp),
but rather that she is our Area Director, and is the one that help 
enforce process. My point to you was that if you don't like the way I
am running the WG, take it up with her. I hope this more direct statement
is easier for you to understand.

btw, it doesn't take someone knowledgeable in mobility to run a WG. It
just takes someone that is willing to volunteer way too much of their
time. The folks with mobility expertise don't chair, they contribute.

Now could we perhaps get off this complete waste of time, and get
back to work?

BTW, I heard today that the requirements were accepted by the IESG. However,
we still do not allow "presentations" in the IETF. The face to face meetings
are reserved to discuss issues. If you have such issues to discuss, let
me know.

PatC

On Mon, Jul 16, 2001 at 02:28:18PM -0400, Behcet Sarikaya wrote:
> I do not think that one should try to give or create the impression that (s)he is
> indispensible. There are so many respectful, highly qualified and experienced
> experts on mobility who can perform the duties of a WG chair. In my humble
> opinion these positions should be viewed as opportunities to volontarily serve
> IETF and not vice versa.
> 
> Pat Calhoun wrote:
> 
> > > I'd like the
> > > AD Allison Mankin to pronounce her opinion on this.
> >
> > Absolutely. Allison is the right person to talk to if you believe that
> > I am not performing the duties of chair properly.
> 
> Kind regards,
> 
> --
> Behcet
> 


From owner-seamoby@diameter.org  Tue Jul 17 03:07:13 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA10059
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 03:07:12 -0400 (EDT)
Received: (qmail 26446 invoked by alias); 17 Jul 2001 06:56:07 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26440 invoked by uid 200); 17 Jul 2001 06:56:07 -0000
Received: (qmail 26435 invoked from network); 17 Jul 2001 06:56:06 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 06:56:06 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id AAA26406;
	Tue, 17 Jul 2001 00:06:23 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6H76M403298;
	Tue, 17 Jul 2001 00:06:22 -0700
X-mProtect:  Tue, 17 Jul 2001 00:06:22 -0700 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdnZXHWT; Tue, 17 Jul 2001 00:06:20 PDT
Message-ID: <3B53E3EA.A7025529@iprg.nokia.com>
Date: Tue, 17 Jul 2001 00:06:19 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Emil Sturniolo <emils@netmotionwireless.com>, seamoby@diameter.org
Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive
References: <004701c10e0e$4e10f630$7c168fd1@wrq-nc1.wrq.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Emil,



Emil Sturniolo wrote:

> Hi folks,
>         I just have one observation. From reading the new text:

the quote below is not new text. It already is in the current req. draft.
On the other hand, the multiple phase req. is not at this time. So, I
share
your concern, and I hope that the definition of the support of multiple
phases will
addresss your point.
Regards,

Cedric.

>
>
> "This means that the context is available at the AR before it is
> required to forward the first
> packet arrival in the MN's traffic. Proactive context transfer is
> coupled to mobile handover only by the requirement that the context be
> in place before the handover of the MN's traffic is complete."
>
> My interpretation of this is that a "proactive context transfer" must
> be totally completed prior to HO. If one considers a multi-phasic
> transfer, and only enough context is transfer proactively to allow
> packet forwarding, but other ancillary information is subsequently
> communicated, I believe from the current definition that the
> completion of this transfer is deemed a "reactive process". I am fine
> with this distinction,  but I would like to see it be specifically
> stated rather then just implied. Alternatively, we could change the
> text slightly to account for this case and still allow it to be a
> completed within the scope of a proactive transfer. Suggested text:
>
> "This means that enough of the context is available at the AR before
> it is required to process any of the MN's traffic. Proactive context
> transfer is coupled to mobile handover only by the prerequisite that
> elements of the context that enable packet forwarding be in place
> before the handover of the MN's traffic is complete."
>
> Comments?
>
> Cordially,
> Emil Sturniolo
> EmilS@NetMotionWireless.Com
> www.NetMotionWireless.com
> 330-723-9099
> 330-461-0326 - Mobile/Voice Mail
> =====================



From owner-seamoby@diameter.org  Tue Jul 17 04:14:24 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA22212
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 04:14:18 -0400 (EDT)
Received: (qmail 27034 invoked by alias); 17 Jul 2001 08:01:55 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27027 invoked by uid 200); 17 Jul 2001 08:01:54 -0000
Received: (qmail 27022 invoked from network); 17 Jul 2001 08:01:49 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 08:01:49 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id BAA28922;
	Tue, 17 Jul 2001 01:11:56 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6H8Bq031214;
	Tue, 17 Jul 2001 01:11:52 -0700
X-mProtect:  Tue, 17 Jul 2001 01:11:52 -0700 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdvlGOSu; Tue, 17 Jul 2001 01:11:49 PDT
Message-ID: <3B53F342.20FE683E@iprg.nokia.com>
Date: Tue, 17 Jul 2001 01:11:46 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henrik Levkowetz <henrik@levkowetz.com>
CC: seamoby@cdma-2000.org, Gary Kenward <gkenward@nortelnetworks.com>
Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive
References: <MFEILCGMDFHKIOINEEHEMEPCCHAA.henrik@levkowetz.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Henrik,

thanks for the comment. One general reply, before more specific ones in line.
You are concerned about something that was present in earlier versions of the
requirement draft, and that did not raise any issues back then. The introduction
sentence in section 4.5 of draft-ietf-seamoby-ct-reqs-00.txt is:
'it is useful to consider two modes of operation'. Nobody objected to that. People
discussed at length what those modes were, but never the term _mode_.

So why discuss something that had been accepted? If I hear where you come from,
I'd say there is the new multi-phase req that induces changes (so now there is the
added 'non exclusive', to underline that both modes can work cooperatively in the
same ct if need be). Other cautionary words should be in that multi-phase req.

Going through your suggestions, you try to replace 'mode' by 'ability'. I disagree
with this. A mode is a way of doing things (how do you attempt ct?), an ability is
the capacity of doing things (can you achieve this ct?), these are different notions.

A little bit more in-line.

Henrik Levkowetz wrote:

> Cedric, Gary
>
>         I find the background explanatory text very good but when you get
> into describing the way the protocol will work, I see an assumption
> sneaking in which I don't agree to, namely that the protocol will need
> to have two _modes_ of operation.

For sure, we agree, and I personnaly did not
see or intend the implication that you see. I think the very first sentence
('two complementray, non exclusive modes of operation') is clear enough
to dispell any doubt about getting locked into one _mode_. There's also
a paragraph talking on how proactive evolves into reactive if need be.

> Maybe it will, or maybe we will be
> able to define / design the triggers and handling at the destination
> in such a way that there really will be only one mode. But I think
> it's premature to imply two modes, ... maybe you didn't really mean to?

To tell you the truth, maybe we don't understand mode the same way. Let me
give a picturesque, snow-plowing the driveway kinda example:
a car transmission might have a sporty mode and a comfort
mode. Marketing guys in Detroit did the requirement: we must support sporty,
we must support comfort. Do engineers build two different cars? No, it's just
a switch on the dashboard: up, sporty, down, comfort.
My point is, a _mode_ is not a _protocol_.

>       Anyway, I've suggested revised text inline, below.
>
>         Best,
>                 Henrik
>
> >
> > Hey,
> >
> > Gary and myself have worked on a new proactive/reactive paragraph
> > to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> > same terminology.
> > Here it is, please comment, thanks,
> >
> > Cedric.
> > -------------------------------------------------------------------------
> >
> >
> > 4.4 The context transfer framework MUST support proactive context transfer.
> >
> > 4.5 The context transfer framework MUST support reactive context transfer.
> >
> >    It is useful to consider two complementary, non exclusive
> > modes of operation for context transfer:
> > proactive and reactive.
> >
> >    The context transfer process is said to be proactive when the required
> > contexts are requested to be in place at the target AR  prior to the arrival of
> > MN's packet
> > at target AR.
> >
> >    With proactive context transfer, the idea is to make the context available
> > to an AR before it is needed. This means that the context is
> > available at the AR before it is required to forward the first
> > packet arrival in the MN's traffic. Proactive context transfer is
> > coupled to mobile handover only by the requirement that the context
> > be in place before the handover of the MN's traffic is complete.
> >
> >    The context transfer is said to be reactive when it is not proactive.
> >
> >    The idea is that in a reactive context transfer, no guarantee is made as to
> > when the context will be in place at newAR. The context transfer process reacts
> > to the handover, but has no control over or knowledge of the handover to ensure
> > that it is in places before the arrival of MN's packet at the target AR.
> > Reactive context transfer is coupled to mobile handover only by the requirement
> > that some handover event is triggering the reaction. Reactive context transfer
> > completes as soon as possible, but its completion is independent of the handover
> > process.
> >
> >    Depending upon the network configuration, the MN's velocity and the behavior
> > of the mobility solution, a reactive context transfer may or may not complete
> > quickly enough for the new forwarding AR to provide a consistent service to
> > the first packets of the re-directed traffic.
> >
> >    In many situations there is no forewarning available of a handover
> > and context transfer must be initiated simply because the
> > re-direction of the MN's traffic is in progress and the AR needs the
> > forwarding context immediately. Because of the physical constraints,
> > these situations can  never be completely avoided. Thus, if context
> > transfer is to be  performed at all, the fundamental mode of operation
> > must be reactive.
>
> .................................................. Thus, if context
> transfer is to be performed at all, its fundamental function must be
> reactive context transfer.
>

I understand what you are trying to do, but saying 'the fundamental function of
ct' replies to the question 'what is ct' (the fundamental function of ct is to
transfer
context), and this addresses the question 'how'.

>
> >
> >    The proactive mode of context transfer is an attempt to further
>
>    The ability to transfer context proactively is an attempt to further
> ...

an ability is not an attempt.

Henrik, I hope that this helped alleviate your concerns,
best regards,

Cedric.

>
>
> > reduce any disruption of the service provided to the MN's traffic by
> > making the context available to an AR prior to it being needed for
> > forwarding. This implies that some network event will occur at the IP
> > level to indicate the potential for a handover, prior to the handover
> > being initiated (c.f. requirements 4.1 and 4.2). This event would
> > trigger a proactive context transfer if there is confidence the context
> > transfer can complete before the arrival of MN's packet at the target AR.
> > There can be no guarantee that this event will occur or that this confidence
> > will be acquired, and thus, a reactive context transfer is
> > always required as a contingency.
> >
> >    This also means that a context transfer that begins in proactive mode
> > may, as a result of the MN moving or other changes to the wireless
> > environment, be required to complete in reactive mode.  If the target
> > AR stays the same, then the same proactive context transfer attempt
> > should evolve into a reactive context transfer attempt.
>
>    This also means that a context transfer that begins as a proactive transfer
> may, as a result of the MN moving or other changes to the wireless
> environment, be required to complete as a reactive transfer.  If the target
> AR stays the same, then the same proactive context transfer attempt
> should evolve into a reactive context transfer attempt.

>
> >
> >    As the proactive mode of context transfer is an enhancement, there may be
> > situations where the reactive mode is considered a sufficient solution.
> > While it is required that the context transfer protocol support proactive
> > mode, its use is optional.
>
>    As proactive context transfer is an enhancement, there may be
> situations where reactive transfer is considered a sufficient solution.
> While it is required that the context transfer protocol support proactive
> context transfer, this ability may not always be implemented or used.
>    <<<The last sentence limps a bit, I think. Maybe you'll find
>       a better formulation that doesn't go into Modes. /Henrik>>>



From owner-seamoby@diameter.org  Tue Jul 17 04:50:58 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA26146
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 04:50:56 -0400 (EDT)
Received: (qmail 27562 invoked by alias); 17 Jul 2001 08:38:52 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27556 invoked by uid 200); 17 Jul 2001 08:38:51 -0000
Received: (qmail 27551 invoked from network); 17 Jul 2001 08:38:50 -0000
Received: from femail2.rdc1.on.home.com (24.2.9.89)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 08:38:50 -0000
Received: from cr851003a ([24.157.232.166]) by femail2.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010717084931.YIPD21397.femail2.rdc1.on.home.com@cr851003a>;
          Tue, 17 Jul 2001 01:49:31 -0700
Message-ID: <001d01c10e9d$754b2d80$a6e89d18@slnt1.on.wave.home.com>
Reply-To: "Kulwinder Atwal" <katwal2200@home.com>
From: "Kulwinder Atwal" <katwal2200@home.com>
To: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>,
        "'Henrik Levkowetz'" <henrik@levkowetz.com>, <seamoby@cdma-2000.org>
Cc: "Gary Kenward" <gkenward@nortelnetworks.com>,
        "Cedric Westphal" <cedric@IPRG.nokia.com>
References: <35DBB8B7AC89D4118E98009027B1009B017A9EBA@IL27EXM10.cig.mot.com>
Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Tue, 17 Jul 2001 04:49:57 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

It seems to me that proactive and reactive are not two modes, but opposite
ends of a spectrum of possible start points for initiating context transfer,
particularily when multiphasic context transfer and AR discovery is
considered.

- Kulwinder.

----- Original Message -----
From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
To: "'Henrik Levkowetz'" <henrik@levkowetz.com>; <seamoby@cdma-2000.org>
Cc: "Gary Kenward" <gkenward@nortelnetworks.com>; "Cedric Westphal"
<cedric@IPRG.nokia.com>
Sent: Monday, July 16, 2001 6:02 PM
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive


> I agree with Henrik, I think it is premature to mention proactive
> and reactive as modes of operations, unless we describe the procedures
> that are making those two different.
>
> I will sent my comments about the text later :)
>
> Madjid
>
> -----Original Message-----
> From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> Sent: Monday, July 16, 2001 3:25 AM
> To: seamoby@cdma-2000.org
> Cc: Gary Kenward; Cedric Westphal
> Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
>
>
> Cedric, Gary
>
> I find the background explanatory text very good but when you get
> into describing the way the protocol will work, I see an assumption
> sneaking in which I don't agree to, namely that the protocol will need
> to have two _modes_ of operation.  Maybe it will, or maybe we will be
> able to define / design the triggers and handling at the destination
> in such a way that there really will be only one mode. But I think
> it's premature to imply two modes, ... maybe you didn't really mean to?
>
> Anyway, I've suggested revised text inline, below.
>
> Best,
> Henrik
>
> >
> > Hey,
> >
> > Gary and myself have worked on a new proactive/reactive paragraph
> > to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> > same terminology.
> > Here it is, please comment, thanks,
> >
> > Cedric.
>
> -------------------------------------------------------------------------
> >
> >
> > 4.4 The context transfer framework MUST support proactive context
transfer.
> >
> > 4.5 The context transfer framework MUST support reactive context
transfer.
> >
> >    It is useful to consider two complementary, non exclusive
> > modes of operation for context transfer:
> > proactive and reactive.
> >
> >    The context transfer process is said to be proactive when the
required
> > contexts are requested to be in place at the target AR  prior to the
arrival of
> > MN's packet
> > at target AR.
> >
> >    With proactive context transfer, the idea is to make the context
available
> > to an AR before it is needed. This means that the context is
> > available at the AR before it is required to forward the first
> > packet arrival in the MN's traffic. Proactive context transfer is
> > coupled to mobile handover only by the requirement that the context
> > be in place before the handover of the MN's traffic is complete.
> >
> >    The context transfer is said to be reactive when it is not proactive.
> >
> >    The idea is that in a reactive context transfer, no guarantee is made
as to
> > when the context will be in place at newAR. The context transfer process
reacts
> > to the handover, but has no control over or knowledge of the handover to
ensure
> > that it is in places before the arrival of MN's packet at the target AR.
> > Reactive context transfer is coupled to mobile handover only by the
requirement
> > that some handover event is triggering the reaction. Reactive context
transfer
> > completes as soon as possible, but its completion is independent of the
handover
> > process.
> >
> >    Depending upon the network configuration, the MN's velocity and the
behavior
> > of the mobility solution, a reactive context transfer may or may not
complete
> > quickly enough for the new forwarding AR to provide a consistent service
to
> > the first packets of the re-directed traffic.
> >
> >    In many situations there is no forewarning available of a handover
> > and context transfer must be initiated simply because the
> > re-direction of the MN's traffic is in progress and the AR needs the
> > forwarding context immediately. Because of the physical constraints,
> > these situations can  never be completely avoided. Thus, if context
> > transfer is to be  performed at all, the fundamental mode of operation
> > must be reactive.
>
> .................................................. Thus, if context
> transfer is to be performed at all, its fundamental function must be
> reactive context transfer.
>
> >
> >    The proactive mode of context transfer is an attempt to further
>
>    The ability to transfer context proactively is an attempt to further
> ...
>
> > reduce any disruption of the service provided to the MN's traffic by
> > making the context available to an AR prior to it being needed for
> > forwarding. This implies that some network event will occur at the IP
> > level to indicate the potential for a handover, prior to the handover
> > being initiated (c.f. requirements 4.1 and 4.2). This event would
> > trigger a proactive context transfer if there is confidence the context
> > transfer can complete before the arrival of MN's packet at the target
AR.
> > There can be no guarantee that this event will occur or that this
confidence
> > will be acquired, and thus, a reactive context transfer is
> > always required as a contingency.
> >
> >    This also means that a context transfer that begins in proactive mode
> > may, as a result of the MN moving or other changes to the wireless
> > environment, be required to complete in reactive mode.  If the target
> > AR stays the same, then the same proactive context transfer attempt
> > should evolve into a reactive context transfer attempt.
>
>    This also means that a context transfer that begins as a proactive
transfer
> may, as a result of the MN moving or other changes to the wireless
> environment, be required to complete as a reactive transfer.  If the
target
> AR stays the same, then the same proactive context transfer attempt
> should evolve into a reactive context transfer attempt.
>
> >
> >    As the proactive mode of context transfer is an enhancement, there
may be
> > situations where the reactive mode is considered a sufficient solution.
> > While it is required that the context transfer protocol support
proactive
> > mode, its use is optional.
>
>    As proactive context transfer is an enhancement, there may be
> situations where reactive transfer is considered a sufficient solution.
> While it is required that the context transfer protocol support proactive
> context transfer, this ability may not always be implemented or used.
>    <<<The last sentence limps a bit, I think. Maybe you'll find
>       a better formulation that doesn't go into Modes. /Henrik>>>



From owner-seamoby@diameter.org  Tue Jul 17 05:37:45 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01256
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 05:37:40 -0400 (EDT)
Received: (qmail 28139 invoked by alias); 17 Jul 2001 09:25:44 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28133 invoked by uid 200); 17 Jul 2001 09:25:44 -0000
Received: (qmail 28128 invoked from network); 17 Jul 2001 09:25:42 -0000
Received: from unknown (HELO RRMAIL01.RADIOROUTER?NT) (63.103.94.23)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 09:25:42 -0000
Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2653.19)
	id <317T36GB>; Tue, 17 Jul 2001 05:35:59 -0400
Message-ID: <8C92E23A3E87FB479988285F9E22BE4605467D@ftmail>
From: George Tsirtsis <G.Tsirtsis@flarion.com>
To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
Subject: RE: [seamoby] Re: [mobile-ip] Comments on:  I-D ACTION:draft-many
	folks-l2-mobilereq-00.txt
Date: Tue, 17 Jul 2001 05:34:26 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk



-----Original Message-----
From: James Kempf [mailto:James.Kempf@Sun.COM]
Sent: Monday, July 16, 2001 7:20 PM
To: mobile-ip@sunroof.eng.sun.com; seamoby@cdma-2000.org
Subject: [seamoby] Re: [mobile-ip] Comments on: I-D
ACTION:draft-manyfolks-l2-mobilereq-00.txt


George,

Thanx for you comments. I'll fold them in on the next revision, which
will be after IETF 51. Specific responses below.


...
>2. Why is Section 4 in this draft? Why do we examine triggers for L2
>Handoffs...I think this is out of scope? Section 5 describes use of
triggers
>with L3 Handoffs which is in scope and all we need...
>

If the AR is not informed that the MN has changed APs, the AR's 
mapping of L2 address to IP address may be out of date when the MN moves.
The AR must either perform proxy ARP (IPv4) or Neighbor Discovery (IPv6)
in order to refresh the mapping.

With an L2 trigger and an associated update protocol, the AP could
specfically tell the AR what the new mapping is. If all the APs
have a single radio technology, then one can  reasonably argue
that this is radio technology specific (even if the protocol
to update the AR's mapping is based on IP); however, in the future,
it is possible that subnets with mixed technology APs may become
more common. So, while the draft does not advocate a particular
approach to solving this problem, it does lay out the requirements
for allowing it to be solved, should some working group  decide
they wanted to take on the task.

GT> OK, I see...It would be nice to state that somewhere though....i.e.: the
AP to AR protocol for this update is likely to be proprietary to the AP's
technology...and yes I know that some APs (as well as wavelan hubs) also
speak IP in which case this could be an IP protocol...oh well...the world is
not simple anymore :-)

>3. In the table in Section 5 I have a different view on the concept of
>"Recipient" of the various Triggers described. I think the "Recipient" is
>the *IP Layer* in either the AR or the MN. Whether the trigger comes via an
>AP or not is not relevant IMO. The consideration of the AP, however, is
>sometime useful in the spec (e.g.: some times you need the AP's L2 addr if
>one is used). Still the AP itself is never the recipient of the
>trigger...i.e.: the AP does not act on trigger reception, apart from
>forwarding it to the AR as normal.
>

I'm not entirely sure I understand your comment, but let me see.

Basically, the idea in the draft is that the AP is not a recipient
of the trigger, however, it may be the source. The recipient that
is identified in the draft is an IP entity (i.e. an IP host or
an IP router, the only entities that there are in IP networks).
APs are neither, since they are transparent by definition. 

So I think we are agreeing on that point.

GT> We do indeed, I just said that because in Table 2 you have AP/AR as
Recipient of Link UP/DOWN triggers

The AP *may* have an IP address if it is engaged in, say, IAPP like
traffic to propogate L2 trigger information. At that point, it
is acting like an IP host.

I agree that, on a particular IP entity identified as a target,
the IP stack is the recepient of the trigger. 

Does this correspond to what you are saying?

GT> Hmmm...you see that is what I do not like about this...I would much
better prefer not to refer to APs in this way...The L2 triggers always go to
an IP router or a host as you said...if one wants to implement an IP host in
an AP then as far as this mechanism goes this is an IP host (not an AP!).
The reason I am fussy about this is that any IETF mechanism/protocol should
be designed for the clear architectural case so it is correct...then it can
be implemented in whatever way fits the specific scenario. The other way
never works quit so well...So, lets just define the API and let people
implement it the way they need...you can even give the AP case as an
example...

>4. I suggest the table in section 5 to be expanded and each Trigger to be
>described in a bit more detailed...the sort, table descriptions, are a bit
>nebulous...

OK, I'll look into it. If you have any proposed wording, please send it
along.

GT> OK, will think about it and we can discuss in London.


>
>6. Section 6.2 defines CT related triggers, why are these different from
the
>ones in Section 5?? Surely the Source/Dest Triggers defined in section 5
can
>(optionally?) include the information required for the triggers defined in
>6.2. Also why do you have CT triggers going to the MN? and why both
reactive
>and proactive triggers go to both old and new ARs? 
>

We had some discussion on this among the authors. It is true that
there is overlap, we wanted to lay out the requirements separately.
The reason is that there is a strong feeling among the CT design
team participants that CT should not be tied to a mobility protocol.
While I think it is probably worthwhile to lay out the requirements
separately, perhaps something should be said about overlap, and
maybe put a section in that describes how to satisfy them with
a single set of triggers. Does this sound like a good idea?

GT> I fully agree that CT should not be tight to one single mobility
protocol but I also think the API described in this spec should not be
either...these are *generic* triggers "I am coming from there"...or "I am
going there"...some of them not even mobility specific i.e.: "link up",
"link down"....These have nothing to do with any particular mobility
protocol and some of them can be used by non mobility protocols...So, I
think we should start the opposite way...assume they are the same triggers
until you find a strong reason why CT needs its own specific triggers.
Otherwise protocol X will also come later on and demand its own specific
triggers => no good....

...
>
>Thanks and again good work!


Thank you for the comments! If you have any text you'd like to see in the 
document (particularly on the table in Section 5) please send it along.


GT> OK, we can discuss in London...

Thanks
George

P.S.: BTW, I am a bit confused with the seamoby list...you use the
seamoby@cdma-2000.org address...but when I go to though this is
seamoby@diameter.org...is this an alias of the same list?


From owner-seamoby@diameter.org  Tue Jul 17 06:01:59 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03884
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 06:01:59 -0400 (EDT)
Received: (qmail 28695 invoked by alias); 17 Jul 2001 09:51:15 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28689 invoked by uid 200); 17 Jul 2001 09:51:15 -0000
Received: (qmail 28684 invoked from network); 17 Jul 2001 09:51:13 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 09:51:13 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6HA2UI25062
	for <seamoby@cdma-2000.org>; Tue, 17 Jul 2001 13:02:30 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54cd6095fdac158f2313e2@esvir03nok.nokia.com>;
 Tue, 17 Jul 2001 13:01:51 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MSVAL6F>; Tue, 17 Jul 2001 13:01:52 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF09406F@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: Madjid.Nakhjiri@motorola.com, PNeumiller@MeshNetworks.com,
        pcalhoun@diameter.org
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] RE: Yet another Security RANT was  L2 API (WAS: Ext
	. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
Date: Tue, 17 Jul 2001 13:01:44 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Madjid,

> I heard Jeff Schiller during his security tutorial say:
> "Don't come to us with unsecure protocols and say this is
> my protocol, if you need security, use IPSec. You need to secure
> your protocols yourself."
> He also said, "the security folks in security area say, why should
> we drop everything and go analyze other people's security problems"
> 
> As much as most of us feel we don't know as much as we would like
> about security, we need to deal with it ourself. You can expect
> your neighbor to shovel your driveway, just because he has a expensive
> blower. 

Exactly - that was a good summary.  

For Phil - I think the idea is that if you leave your front door
wide open, don't blame the police when you find that all of your
stuff has been stolen.

John


From owner-seamoby@diameter.org  Tue Jul 17 06:12:55 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05052
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 06:12:45 -0400 (EDT)
Received: (qmail 29194 invoked by alias); 17 Jul 2001 10:00:27 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 29188 invoked by uid 200); 17 Jul 2001 10:00:27 -0000
Received: (qmail 29183 invoked from network); 17 Jul 2001 10:00:25 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 10:00:25 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id DAA03678;
	Tue, 17 Jul 2001 03:10:43 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6HAAge01569;
	Tue, 17 Jul 2001 03:10:42 -0700
X-mProtect:  Tue, 17 Jul 2001 03:10:42 -0700 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdj5RQ0R; Tue, 17 Jul 2001 03:10:40 PDT
Message-ID: <3B540F1C.DC944428@iprg.nokia.com>
Date: Tue, 17 Jul 2001 03:10:36 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Kulwinder Atwal <katwal2200@home.com>, seamoby@diameter.org
Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive
References: <35DBB8B7AC89D4118E98009027B1009B017A9EBA@IL27EXM10.cig.mot.com> <001d01c10e9d$754b2d80$a6e89d18@slnt1.on.wave.home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Kulwinder,

I don't want to get into a debate about modes, since this word is re-used from
version -00 of the requirements.
It does seem to me that the question about this word comes from the
multi-phase support req. 4.9. Proposed solutions:
a clarification in section 4.9 along the lines:
"4.9 Context information MAY be transferred in phases, .....
Different phases could use different context transfer modes...."
Regards,

Cedric.

Kulwinder Atwal wrote:

> It seems to me that proactive and reactive are not two modes, but opposite
> ends of a spectrum of possible start points for initiating context transfer,
> particularily when multiphasic context transfer and AR discovery is
> considered.
>
> - Kulwinder.
>
> ----- Original Message -----
> From: "Nakhjiri Madjid-MNAKHJI1" <Madjid.Nakhjiri@motorola.com>
> To: "'Henrik Levkowetz'" <henrik@levkowetz.com>; <seamoby@cdma-2000.org>
> Cc: "Gary Kenward" <gkenward@nortelnetworks.com>; "Cedric Westphal"
> <cedric@IPRG.nokia.com>
> Sent: Monday, July 16, 2001 6:02 PM
> Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
>
> > I agree with Henrik, I think it is premature to mention proactive
> > and reactive as modes of operations, unless we describe the procedures
> > that are making those two different.
> >
> > I will sent my comments about the text later :)
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
> > Sent: Monday, July 16, 2001 3:25 AM
> > To: seamoby@cdma-2000.org
> > Cc: Gary Kenward; Cedric Westphal
> > Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
> >
> >
> > Cedric, Gary
> >
> > I find the background explanatory text very good but when you get
> > into describing the way the protocol will work, I see an assumption
> > sneaking in which I don't agree to, namely that the protocol will need
> > to have two _modes_ of operation.  Maybe it will, or maybe we will be
> > able to define / design the triggers and handling at the destination
> > in such a way that there really will be only one mode. But I think
> > it's premature to imply two modes, ... maybe you didn't really mean to?
> >
> > Anyway, I've suggested revised text inline, below.
> >
> > Best,
> > Henrik
> >
> > >
> > > Hey,
> > >
> > > Gary and myself have worked on a new proactive/reactive paragraph
> > > to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> > > same terminology.
> > > Here it is, please comment, thanks,
> > >
> > > Cedric.
> >
> > -------------------------------------------------------------------------
> > >
> > >
> > > 4.4 The context transfer framework MUST support proactive context
> transfer.
> > >
> > > 4.5 The context transfer framework MUST support reactive context
> transfer.
> > >
> > >    It is useful to consider two complementary, non exclusive
> > > modes of operation for context transfer:
> > > proactive and reactive.
> > >
> > >    The context transfer process is said to be proactive when the
> required
> > > contexts are requested to be in place at the target AR  prior to the
> arrival of
> > > MN's packet
> > > at target AR.
> > >
> > >    With proactive context transfer, the idea is to make the context
> available
> > > to an AR before it is needed. This means that the context is
> > > available at the AR before it is required to forward the first
> > > packet arrival in the MN's traffic. Proactive context transfer is
> > > coupled to mobile handover only by the requirement that the context
> > > be in place before the handover of the MN's traffic is complete.
> > >
> > >    The context transfer is said to be reactive when it is not proactive.
> > >
> > >    The idea is that in a reactive context transfer, no guarantee is made
> as to
> > > when the context will be in place at newAR. The context transfer process
> reacts
> > > to the handover, but has no control over or knowledge of the handover to
> ensure
> > > that it is in places before the arrival of MN's packet at the target AR.
> > > Reactive context transfer is coupled to mobile handover only by the
> requirement
> > > that some handover event is triggering the reaction. Reactive context
> transfer
> > > completes as soon as possible, but its completion is independent of the
> handover
> > > process.
> > >
> > >    Depending upon the network configuration, the MN's velocity and the
> behavior
> > > of the mobility solution, a reactive context transfer may or may not
> complete
> > > quickly enough for the new forwarding AR to provide a consistent service
> to
> > > the first packets of the re-directed traffic.
> > >
> > >    In many situations there is no forewarning available of a handover
> > > and context transfer must be initiated simply because the
> > > re-direction of the MN's traffic is in progress and the AR needs the
> > > forwarding context immediately. Because of the physical constraints,
> > > these situations can  never be completely avoided. Thus, if context
> > > transfer is to be  performed at all, the fundamental mode of operation
> > > must be reactive.
> >
> > .................................................. Thus, if context
> > transfer is to be performed at all, its fundamental function must be
> > reactive context transfer.
> >
> > >
> > >    The proactive mode of context transfer is an attempt to further
> >
> >    The ability to transfer context proactively is an attempt to further
> > ...
> >
> > > reduce any disruption of the service provided to the MN's traffic by
> > > making the context available to an AR prior to it being needed for
> > > forwarding. This implies that some network event will occur at the IP
> > > level to indicate the potential for a handover, prior to the handover
> > > being initiated (c.f. requirements 4.1 and 4.2). This event would
> > > trigger a proactive context transfer if there is confidence the context
> > > transfer can complete before the arrival of MN's packet at the target
> AR.
> > > There can be no guarantee that this event will occur or that this
> confidence
> > > will be acquired, and thus, a reactive context transfer is
> > > always required as a contingency.
> > >
> > >    This also means that a context transfer that begins in proactive mode
> > > may, as a result of the MN moving or other changes to the wireless
> > > environment, be required to complete in reactive mode.  If the target
> > > AR stays the same, then the same proactive context transfer attempt
> > > should evolve into a reactive context transfer attempt.
> >
> >    This also means that a context transfer that begins as a proactive
> transfer
> > may, as a result of the MN moving or other changes to the wireless
> > environment, be required to complete as a reactive transfer.  If the
> target
> > AR stays the same, then the same proactive context transfer attempt
> > should evolve into a reactive context transfer attempt.
> >
> > >
> > >    As the proactive mode of context transfer is an enhancement, there
> may be
> > > situations where the reactive mode is considered a sufficient solution.
> > > While it is required that the context transfer protocol support
> proactive
> > > mode, its use is optional.
> >
> >    As proactive context transfer is an enhancement, there may be
> > situations where reactive transfer is considered a sufficient solution.
> > While it is required that the context transfer protocol support proactive
> > context transfer, this ability may not always be implemented or used.
> >    <<<The last sentence limps a bit, I think. Maybe you'll find
> >       a better formulation that doesn't go into Modes. /Henrik>>>



From owner-seamoby@diameter.org  Tue Jul 17 06:48:13 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08951
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 06:48:13 -0400 (EDT)
Received: (qmail 29776 invoked by alias); 17 Jul 2001 10:37:23 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 29770 invoked by uid 200); 17 Jul 2001 10:37:23 -0000
Received: (qmail 29765 invoked from network); 17 Jul 2001 10:37:22 -0000
Received: from hume.neobright.net (root@209.143.19.251)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 10:37:22 -0000
Received: from brightnetFW ([192.168.1.1])
	by hume.neobright.net (8.9.3/8.9.3 FNG) with SMTP id GAA24675
	for <seamoby@diameter.org>; Tue, 17 Jul 2001 06:48:09 -0400
Received: from wrq-nc1 [10.1.1.1] by WRQ1-NorthCoast.bright.net [209.143.22.124] with SMTP (MDaemon.v2.7.SP3.R) for <seamoby@diameter.org>; Tue, 17 Jul 2001 06:43:59 -0400
From: "Emil Sturniolo" <emils@netmotionwireless.com>
To: "Cedric Westphal" <cedric@iprg.nokia.com>, <seamoby@diameter.org>
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Tue, 17 Jul 2001 06:43:58 -0400
Message-ID: <002501c10ead$629ad590$7c168fd1@wrq-nc1.wrq.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <3B53E3EA.A7025529@iprg.nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-MDaemon-Deliver-To: seamoby@diameter.org
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Cedric,
	Shame on me!. I read the draft some time ago and I didn't compare the
text. I was just going by the note you had posted.  Furthermore, I
didn't want to restart the debate about proactive versus reactive. As
for the multi-phasic issues, ultimately I was just trying to suggest
some text that might allow for the better description of this
functionality with respect to the definition. On the other hand,  if
the original text is deemed more appropriate by the WG, I wanted  to
insure that the distinction I pointed out was clearly identified and
not left up to interpretation. Looking forward to meeting you in
London.


Cordially,
Emil Sturniolo
EmilS@NetMotionWireless.Com
www.NetMotionWireless.com
330-723-9099
330-461-0326 - Mobile/Voice Mail
=====================


-----Original Message-----
From:	Cedric Westphal [mailto:cedric@iprg.nokia.com]
Sent:	Tuesday, July 17, 2001 3:06 AM
To:	Emil Sturniolo; seamoby@diameter.org
Subject:	Re: [seamoby] New words for Req's 4.4reactive/4.5proactive

Emil,



Emil Sturniolo wrote:

> Hi folks,
>         I just have one observation. From reading the new text:

the quote below is not new text. It already is in the current req.
draft.
On the other hand, the multiple phase req. is not at this time. So, I
share
your concern, and I hope that the definition of the support of
multiple
phases will
addresss your point.
Regards,

Cedric.




From owner-seamoby@diameter.org  Tue Jul 17 07:33:28 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15288
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 07:33:25 -0400 (EDT)
Received: (qmail 30527 invoked by alias); 17 Jul 2001 11:21:50 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30521 invoked by uid 200); 17 Jul 2001 11:21:49 -0000
Received: (qmail 30516 invoked from network); 17 Jul 2001 11:21:47 -0000
Received: from hume.neobright.net (root@209.143.19.251)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 11:21:47 -0000
Received: from brightnetFW ([192.168.1.1])
	by hume.neobright.net (8.9.3/8.9.3 FNG) with SMTP id HAA29944
	for <seamoby@cdma-2000.org>; Tue, 17 Jul 2001 07:32:35 -0400
Received: from wrq-nc1 [10.1.1.1] by WRQ1-NorthCoast.bright.net [209.143.22.124] with SMTP (MDaemon.v2.7.SP3.R) for <seamoby@cdma-2000.org>; Tue, 17 Jul 2001 07:32:28 -0400
From: "Emil Sturniolo" <emils@netmotionwireless.com>
To: <tpagtzis@IPRG.nokia.com>
Cc: "seamoby" <seamoby@cdma-2000.org>
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Tue, 17 Jul 2001 07:32:28 -0400
Message-ID: <002a01c10eb4$288f32e0$7c168fd1@wrq-nc1.wrq.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0
Importance: Normal
In-Reply-To: <3B532873.FAB52CED@iprg.nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-MDaemon-Deliver-To: seamoby@cdma-2000.org
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Theo,
	Maybe I am missing something here, but I think we are somewhat in
agreement. I too believe that the "proactiveness"  by which CT was
initiated does not (can not?)  directly correlate to its completion,
although I might have stated that in a circuitous fashion.  What is
important to me is that somehow we describe in the document that
enough elements of the context (your totality of context necessary to
effect seamlessness )  be communicated to the nAR to facilitate
seamless HO prior to having it process/propagate any of the MN's
traffic. However we go about describing this functionality, using 2,3
or n modes as you suggest, makes little difference to me. On the other
hand, if the WG at large deems that this behavior falls into one of
the already defined categories, I would like to insure that the
definition clearly points this out so it is not left to interpretation
(such as mine). Thanks for the response.



Cordially,
Emil Sturniolo
EmilS@NetMotionWireless.Com
www.NetMotionWireless.com
330-723-9099
330-461-0326 - Mobile/Voice Mail
=====================


-----Original Message-----
From:	owner-seamoby@diameter.org [mailto:owner-seamoby@diameter.org]
On Behalf Of Theo Pagtzis
Sent:	Monday, July 16, 2001 1:46 PM
To:	Emil Sturniolo
Cc:	Cedric Westphal; Pat Calhoun; Gary Kenward; seamoby
Subject:	Re: [seamoby] New words for Req's 4.4reactive/4.5proactive

Hi Emil,

    While I would agree with the terminology over proactive context
transfer, I would have to disagree on the atomicity of tranfer with
respect to proactivity. Proactivity must not require that all context
is
transfered to the new point of attachement. This is bound to be too
costly should the selection decision of the new CAR misses the correct
candidate; this is bound to be the case a lot until...something 'else'
is
in place. More on that 'else' later.

The transfer of context must be bound by the context constituents that
are sufficient and necessary for the node to transit over a proactive
transition mode. This implies partial context existence in the new
candidate points of attachement. Partiality must not mean that
something
critical for seamlessness is not in place in terms of context at the
CARs. Thus partial context transfer over proactive transition mode(s)
must imply a totality of context necessary to effect seamlessness.
Depending on what is considered as a seamlessness factor in each
context
ontology, then the totality and partiality over transfer of a discrete
number of constituents in new CARs is defined accordingly.

I would like to expand the set of transition modes to the CT
requirements
document by adding an extra transition mode. It can be found in
draft-pagtzis-mobileip-proactivev6-00.txt or ps file.

This is the transition mode of "forward reactive handoff". I
personally
consider it as equally important since it provides the intermediate
step
between a pure reactive and a pure proactive handoff.

I would appreciate the view of the constituency on this transition
mode
for the purposes of context transfer.

Theo

UCL/ Mobile Systems


Emil Sturniolo wrote:

> Hi folks,
>         I just have one observation. From reading the new text:
>
> "This means that the context is available at the AR before it is
> required to forward the first
> packet arrival in the MN's traffic. Proactive context transfer is
> coupled to mobile handover only by the requirement that the context
be
> in place before the handover of the MN's traffic is complete."
>
> My interpretation of this is that a "proactive context transfer"
must
> be totally completed prior to HO. If one considers a multi-phasic
> transfer, and only enough context is transfer proactively to allow
> packet forwarding, but other ancillary information is subsequently
> communicated, I believe from the current definition that the
> completion of this transfer is deemed a "reactive process". I am
fine
> with this distinction,  but I would like to see it be specifically
> stated rather then just implied. Alternatively, we could change the
> text slightly to account for this case and still allow it to be a
> completed within the scope of a proactive transfer. Suggested text:
>
> "This means that enough of the context is available at the AR before
> it is required to process any of the MN's traffic. Proactive context
> transfer is coupled to mobile handover only by the prerequisite that
> elements of the context that enable packet forwarding be in place
> before the handover of the MN's traffic is complete."
>
> Comments?
>
> Cordially,
> Emil Sturniolo
> EmilS@NetMotionWireless.Com
> www.NetMotionWireless.com
> 330-723-9099
> 330-461-0326 - Mobile/Voice Mail
> =====================




From owner-seamoby@diameter.org  Tue Jul 17 08:01:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19156
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 08:01:23 -0400 (EDT)
Received: (qmail 31059 invoked by alias); 17 Jul 2001 11:48:44 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 31053 invoked by uid 200); 17 Jul 2001 11:48:44 -0000
Received: (qmail 31048 invoked from network); 17 Jul 2001 11:48:40 -0000
Received: from 217.134.88.213.host.tele1europe.se (HELO mailgw.ipunplugged.com) (@213.88.134.217)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 11:48:40 -0000
Received: from Gioconda (c2.local.ipunplugged.com [192.168.4.201])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id OAA14796
	for <seamoby@diameter.org>; Tue, 17 Jul 2001 14:01:06 +0200
From: "Henrik Levkowetz" <henrik@levkowetz.com>
To: <seamoby@diameter.org>
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Tue, 17 Jul 2001 13:59:12 +0200
Message-ID: <GMEEKDGLAJJFGAFEMMPIEEENCEAA.henrik@levkowetz.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3B53F342.20FE683E@iprg.nokia.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Cedric,

	Your are quite right in that mode may be used more generally, as it was in the
introduction sentence. This is not what I object to.  It is the much more specific
usage and examples at the end of the text which I object to, as they actually seem
to require two separate, different, modes of operation. 

	I'm not in any way particular about the specific wording I proposed, any wording
that does not enforce two modes would be Ok; I simply submitted text as the decent
thing to do when proposing a change. If you don't like it, different words could
be just as fine.

	However, if you don't mean to require that the protocol has two separate, 
different modes, I believe that the text will have to change somewhat. I understand
the way you wish to use mode, but the current text does not clearly read in that 
manner -- quite the contrary, actually, which is why I commented in the first place.

	Regards,
		Henrik


Cedric wrote:
> 
> Henrik,
> 
> thanks for the comment. One general reply, before more specific ones in line.
> You are concerned about something that was present in earlier versions of the
> requirement draft, and that did not raise any issues back then. The introduction
> sentence in section 4.5 of draft-ietf-seamoby-ct-reqs-00.txt is:
> 'it is useful to consider two modes of operation'. Nobody objected to that. People
> discussed at length what those modes were, but never the term _mode_.
> 
> So why discuss something that had been accepted? If I hear where you come from,
> I'd say there is the new multi-phase req that induces changes (so now there is the
> added 'non exclusive', to underline that both modes can work cooperatively in the
> same ct if need be). Other cautionary words should be in that multi-phase req.
> 
> Going through your suggestions, you try to replace 'mode' by 'ability'. I disagree
> with this. A mode is a way of doing things (how do you attempt ct?), an ability is
> the capacity of doing things (can you achieve this ct?), these are different notions.
> 
> A little bit more in-line.
> 
> Henrik Levkowetz wrote:
> 
> > Cedric, Gary
> >
> >         I find the background explanatory text very good but when you get
> > into describing the way the protocol will work, I see an assumption
> > sneaking in which I don't agree to, namely that the protocol will need
> > to have two _modes_ of operation.
> 
> For sure, we agree, and I personnaly did not
> see or intend the implication that you see. I think the very first sentence
> ('two complementray, non exclusive modes of operation') is clear enough
> to dispell any doubt about getting locked into one _mode_. There's also
> a paragraph talking on how proactive evolves into reactive if need be.
> 
> > Maybe it will, or maybe we will be
> > able to define / design the triggers and handling at the destination
> > in such a way that there really will be only one mode. But I think
> > it's premature to imply two modes, ... maybe you didn't really mean to?
> 
> To tell you the truth, maybe we don't understand mode the same way. Let me
> give a picturesque, snow-plowing the driveway kinda example:
> a car transmission might have a sporty mode and a comfort
> mode. Marketing guys in Detroit did the requirement: we must support sporty,
> we must support comfort. Do engineers build two different cars? No, it's just
> a switch on the dashboard: up, sporty, down, comfort.
> My point is, a _mode_ is not a _protocol_.
> 
> >       Anyway, I've suggested revised text inline, below.
> >
> >         Best,
> >                 Henrik
> >
> > >
> > > Hey,
> > >
> > > Gary and myself have worked on a new proactive/reactive paragraph
> > > to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> > > same terminology.
> > > Here it is, please comment, thanks,
> > >
> > > Cedric.
> > > -------------------------------------------------------------------------
> > >
> > >
> > > 4.4 The context transfer framework MUST support proactive context transfer.
> > >
> > > 4.5 The context transfer framework MUST support reactive context transfer.
> > >
> > >    It is useful to consider two complementary, non exclusive
> > > modes of operation for context transfer:
> > > proactive and reactive.
> > >
> > >    The context transfer process is said to be proactive when the required
> > > contexts are requested to be in place at the target AR  prior to the arrival of
> > > MN's packet
> > > at target AR.
> > >
> > >    With proactive context transfer, the idea is to make the context available
> > > to an AR before it is needed. This means that the context is
> > > available at the AR before it is required to forward the first
> > > packet arrival in the MN's traffic. Proactive context transfer is
> > > coupled to mobile handover only by the requirement that the context
> > > be in place before the handover of the MN's traffic is complete.
> > >
> > >    The context transfer is said to be reactive when it is not proactive.
> > >
> > >    The idea is that in a reactive context transfer, no guarantee is made as to
> > > when the context will be in place at newAR. The context transfer process reacts
> > > to the handover, but has no control over or knowledge of the handover to ensure
> > > that it is in places before the arrival of MN's packet at the target AR.
> > > Reactive context transfer is coupled to mobile handover only by the requirement
> > > that some handover event is triggering the reaction. Reactive context transfer
> > > completes as soon as possible, but its completion is independent of the handover
> > > process.
> > >
> > >    Depending upon the network configuration, the MN's velocity and the behavior
> > > of the mobility solution, a reactive context transfer may or may not complete
> > > quickly enough for the new forwarding AR to provide a consistent service to
> > > the first packets of the re-directed traffic.
> > >
> > >    In many situations there is no forewarning available of a handover
> > > and context transfer must be initiated simply because the
> > > re-direction of the MN's traffic is in progress and the AR needs the
> > > forwarding context immediately. Because of the physical constraints,
> > > these situations can  never be completely avoided. Thus, if context
> > > transfer is to be  performed at all, the fundamental mode of operation
> > > must be reactive.
> >
> > .................................................. Thus, if context
> > transfer is to be performed at all, its fundamental function must be
> > reactive context transfer.
> >
> 
> I understand what you are trying to do, but saying 'the fundamental function of
> ct' replies to the question 'what is ct' (the fundamental function of ct is to
> transfer
> context), and this addresses the question 'how'.
> 
> >
> > >
> > >    The proactive mode of context transfer is an attempt to further
> >
> >    The ability to transfer context proactively is an attempt to further
> > ...
> 
> an ability is not an attempt.
> 
> Henrik, I hope that this helped alleviate your concerns,
> best regards,
> 
> Cedric.
> 
> >
> >
> > > reduce any disruption of the service provided to the MN's traffic by
> > > making the context available to an AR prior to it being needed for
> > > forwarding. This implies that some network event will occur at the IP
> > > level to indicate the potential for a handover, prior to the handover
> > > being initiated (c.f. requirements 4.1 and 4.2). This event would
> > > trigger a proactive context transfer if there is confidence the context
> > > transfer can complete before the arrival of MN's packet at the target AR.
> > > There can be no guarantee that this event will occur or that this confidence
> > > will be acquired, and thus, a reactive context transfer is
> > > always required as a contingency.
> > >
> > >    This also means that a context transfer that begins in proactive mode
> > > may, as a result of the MN moving or other changes to the wireless
> > > environment, be required to complete in reactive mode.  If the target
> > > AR stays the same, then the same proactive context transfer attempt
> > > should evolve into a reactive context transfer attempt.
> >
> >    This also means that a context transfer that begins as a proactive transfer
> > may, as a result of the MN moving or other changes to the wireless
> > environment, be required to complete as a reactive transfer.  If the target
> > AR stays the same, then the same proactive context transfer attempt
> > should evolve into a reactive context transfer attempt.
> 
> >
> > >
> > >    As the proactive mode of context transfer is an enhancement, there may be
> > > situations where the reactive mode is considered a sufficient solution.
> > > While it is required that the context transfer protocol support proactive
> > > mode, its use is optional.
> >
> >    As proactive context transfer is an enhancement, there may be
> > situations where reactive transfer is considered a sufficient solution.
> > While it is required that the context transfer protocol support proactive
> > context transfer, this ability may not always be implemented or used.
> >    <<<The last sentence limps a bit, I think. Maybe you'll find
> >       a better formulation that doesn't go into Modes. /Henrik>>>


From owner-seamoby@diameter.org  Tue Jul 17 08:26:30 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22795
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 08:26:25 -0400 (EDT)
Received: (qmail 31643 invoked by alias); 17 Jul 2001 12:13:26 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 31637 invoked by uid 200); 17 Jul 2001 12:13:26 -0000
Received: (qmail 31632 invoked from network); 17 Jul 2001 12:13:24 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 12:13:24 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id FAA08177;
	Tue, 17 Jul 2001 05:23:42 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6HCNfJ27391;
	Tue, 17 Jul 2001 05:23:41 -0700
X-mProtect:  Tue, 17 Jul 2001 05:23:41 -0700 Nokia Silicon Valley Messaging Protection
Received: from UNKNOWN (172.21.40.193, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdncMGQc; Tue, 17 Jul 2001 05:23:38 PDT
Message-ID: <3B542E46.1C49C0E@iprg.nokia.com>
Date: Tue, 17 Jul 2001 05:23:35 -0700
From: Cedric Westphal <cedric@IPRG.nokia.com>
Organization: NOKIA
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Henrik Levkowetz <henrik@ipunplugged.com>, seamoby@diameter.org
Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive
References: <GMEEKDGLAJJFGAFEMMPIIEEMCEAA.henrik@ipunplugged.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Henrik,

let's not argue, since we agree. I just replied to your posting for clarification.
Still, there are _eight_ mentions of the word mode in the current requirement
draft, and _all_ the sentences in the proposed words that include the word
mode are in the current draft. Nobody objected to these 8 mentions earlier.
Nobody posted an issue saying: 'modes' are bad. So I hope your understand
my surprise, and my reply. Am I wrong in assuming that words that have been
accepted for several months are satisfying the working group consensus?

Cheers,

Cedric.

Henrik Levkowetz wrote:

> Cedric,
>
>         Your are quite right in that mode may be used more generally, as it was in the
> introduction sentence. This is not what I object to.  It is the much more specific
> usage and examples at the end of the text which I object to, as they actually seem
> to require two separate, different, modes of operation.

>         I'm not in any way particular about the specific wording I proposed, any wording
> that does not enforce two modes would be Ok; I simply submitted text as the decent
> thing to do when proposing a change. If you don't like it, different words could
> be just as fine.
>
>         However, if you don't mean to require that the protocol has two separate,
> different modes, I believe that the text will have to change somewhat. I understand
> the way you wish to use mode, but the current text does not clearly read in that
> manner -- quite the contrary, actually, which is why I commented in the first place.
>
>         Regards,
>                 Henrik
>
> Cedric wrote:
> >
> > Henrik,
> >
> > thanks for the comment. One general reply, before more specific ones in line.
> > You are concerned about something that was present in earlier versions of the
> > requirement draft, and that did not raise any issues back then. The introduction
> > sentence in section 4.5 of draft-ietf-seamoby-ct-reqs-00.txt is:
> > 'it is useful to consider two modes of operation'. Nobody objected to that. People
> > discussed at length what those modes were, but never the term _mode_.
> >
> > So why discuss something that had been accepted? If I hear where you come from,
> > I'd say there is the new multi-phase req that induces changes (so now there is the
> > added 'non exclusive', to underline that both modes can work cooperatively in the
> > same ct if need be). Other cautionary words should be in that multi-phase req.
> >
> > Going through your suggestions, you try to replace 'mode' by 'ability'. I disagree
> > with this. A mode is a way of doing things (how do you attempt ct?), an ability is
> > the capacity of doing things (can you achieve this ct?), these are different notions.
> >
> > A little bit more in-line.
> >
> > Henrik Levkowetz wrote:
> >
> > > Cedric, Gary
> > >
> > >         I find the background explanatory text very good but when you get
> > > into describing the way the protocol will work, I see an assumption
> > > sneaking in which I don't agree to, namely that the protocol will need
> > > to have two _modes_ of operation.
> >
> > For sure, we agree, and I personnaly did not
> > see or intend the implication that you see. I think the very first sentence
> > ('two complementray, non exclusive modes of operation') is clear enough
> > to dispell any doubt about getting locked into one _mode_. There's also
> > a paragraph talking on how proactive evolves into reactive if need be.
> >
> > > Maybe it will, or maybe we will be
> > > able to define / design the triggers and handling at the destination
> > > in such a way that there really will be only one mode. But I think
> > > it's premature to imply two modes, ... maybe you didn't really mean to?
> >
> > To tell you the truth, maybe we don't understand mode the same way. Let me
> > give a picturesque, snow-plowing the driveway kinda example:
> > a car transmission might have a sporty mode and a comfort
> > mode. Marketing guys in Detroit did the requirement: we must support sporty,
> > we must support comfort. Do engineers build two different cars? No, it's just
> > a switch on the dashboard: up, sporty, down, comfort.
> > My point is, a _mode_ is not a _protocol_.
> >
> > >       Anyway, I've suggested revised text inline, below.
> > >
> > >         Best,
> > >                 Henrik
> > >
> > > >
> > > > Hey,
> > > >
> > > > Gary and myself have worked on a new proactive/reactive paragraph
> > > > to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> > > > same terminology.
> > > > Here it is, please comment, thanks,
> > > >
> > > > Cedric.
> > > > -------------------------------------------------------------------------
> > > >
> > > >
> > > > 4.4 The context transfer framework MUST support proactive context transfer.
> > > >
> > > > 4.5 The context transfer framework MUST support reactive context transfer.
> > > >
> > > >    It is useful to consider two complementary, non exclusive
> > > > modes of operation for context transfer:
> > > > proactive and reactive.
> > > >
> > > >    The context transfer process is said to be proactive when the required
> > > > contexts are requested to be in place at the target AR  prior to the arrival of
> > > > MN's packet
> > > > at target AR.
> > > >
> > > >    With proactive context transfer, the idea is to make the context available
> > > > to an AR before it is needed. This means that the context is
> > > > available at the AR before it is required to forward the first
> > > > packet arrival in the MN's traffic. Proactive context transfer is
> > > > coupled to mobile handover only by the requirement that the context
> > > > be in place before the handover of the MN's traffic is complete.
> > > >
> > > >    The context transfer is said to be reactive when it is not proactive.
> > > >
> > > >    The idea is that in a reactive context transfer, no guarantee is made as to
> > > > when the context will be in place at newAR. The context transfer process reacts
> > > > to the handover, but has no control over or knowledge of the handover to ensure
> > > > that it is in places before the arrival of MN's packet at the target AR.
> > > > Reactive context transfer is coupled to mobile handover only by the requirement
> > > > that some handover event is triggering the reaction. Reactive context transfer
> > > > completes as soon as possible, but its completion is independent of the handover
> > > > process.
> > > >
> > > >    Depending upon the network configuration, the MN's velocity and the behavior
> > > > of the mobility solution, a reactive context transfer may or may not complete
> > > > quickly enough for the new forwarding AR to provide a consistent service to
> > > > the first packets of the re-directed traffic.
> > > >
> > > >    In many situations there is no forewarning available of a handover
> > > > and context transfer must be initiated simply because the
> > > > re-direction of the MN's traffic is in progress and the AR needs the
> > > > forwarding context immediately. Because of the physical constraints,
> > > > these situations can  never be completely avoided. Thus, if context
> > > > transfer is to be  performed at all, the fundamental mode of operation
> > > > must be reactive.
> > >
> > > .................................................. Thus, if context
> > > transfer is to be performed at all, its fundamental function must be
> > > reactive context transfer.
> > >
> >
> > I understand what you are trying to do, but saying 'the fundamental function of
> > ct' replies to the question 'what is ct' (the fundamental function of ct is to
> > transfer
> > context), and this addresses the question 'how'.
> >
> > >
> > > >
> > > >    The proactive mode of context transfer is an attempt to further
> > >
> > >    The ability to transfer context proactively is an attempt to further
> > > ...
> >
> > an ability is not an attempt.
> >
> > Henrik, I hope that this helped alleviate your concerns,
> > best regards,
> >
> > Cedric.
> >
> > >
> > >
> > > > reduce any disruption of the service provided to the MN's traffic by
> > > > making the context available to an AR prior to it being needed for
> > > > forwarding. This implies that some network event will occur at the IP
> > > > level to indicate the potential for a handover, prior to the handover
> > > > being initiated (c.f. requirements 4.1 and 4.2). This event would
> > > > trigger a proactive context transfer if there is confidence the context
> > > > transfer can complete before the arrival of MN's packet at the target AR.
> > > > There can be no guarantee that this event will occur or that this confidence
> > > > will be acquired, and thus, a reactive context transfer is
> > > > always required as a contingency.
> > > >
> > > >    This also means that a context transfer that begins in proactive mode
> > > > may, as a result of the MN moving or other changes to the wireless
> > > > environment, be required to complete in reactive mode.  If the target
> > > > AR stays the same, then the same proactive context transfer attempt
> > > > should evolve into a reactive context transfer attempt.
> > >
> > >    This also means that a context transfer that begins as a proactive transfer
> > > may, as a result of the MN moving or other changes to the wireless
> > > environment, be required to complete as a reactive transfer.  If the target
> > > AR stays the same, then the same proactive context transfer attempt
> > > should evolve into a reactive context transfer attempt.
> >
> > >
> > > >
> > > >    As the proactive mode of context transfer is an enhancement, there may be
> > > > situations where the reactive mode is considered a sufficient solution.
> > > > While it is required that the context transfer protocol support proactive
> > > > mode, its use is optional.
> > >
> > >    As proactive context transfer is an enhancement, there may be
> > > situations where reactive transfer is considered a sufficient solution.
> > > While it is required that the context transfer protocol support proactive
> > > context transfer, this ability may not always be implemented or used.
> > >    <<<The last sentence limps a bit, I think. Maybe you'll find
> > >       a better formulation that doesn't go into Modes. /Henrik>>>



From owner-seamoby@diameter.org  Tue Jul 17 09:12:26 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01461
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 09:12:23 -0400 (EDT)
Received: (qmail 32178 invoked by alias); 17 Jul 2001 12:42:24 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 32172 invoked by uid 200); 17 Jul 2001 12:42:24 -0000
Received: (qmail 32167 invoked from network); 17 Jul 2001 12:42:21 -0000
Received: from 217.134.88.213.host.tele1europe.se (HELO mailgw.ipunplugged.com) (@213.88.134.217)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 12:42:21 -0000
Received: from Gioconda (c2.local.ipunplugged.com [192.168.4.201])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id OAA15668;
	Tue, 17 Jul 2001 14:54:56 +0200
From: "Henrik Levkowetz" <henrik@ipunplugged.com>
To: <seamoby@diameter.org>
Cc: "Cedric Westphal" <cedric@iprg.nokia.com>
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Tue, 17 Jul 2001 14:53:04 +0200
Message-ID: <GMEEKDGLAJJFGAFEMMPIIEEPCEAA.henrik@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <3B542E46.1C49C0E@iprg.nokia.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Cedric,

	You're right, and I'm to blame for not bringing this up earlier, to the
extent that it would need fixing. Somehow the current wording gives me a more
definite sense of requireing the implementation of two distinct modes, which
I didn't get from the previous wording.

	Maybe I was in too much of a hurry when I read the -00 draft, I don't know.
If everybody else concurs with the current wording, fine, -- I'm still not
convinced that we need to implement separate modes, but if nobody will read
the draft as requireing that, we're fine. It's not the word mode I object to,
it was the possible binding interpretation that jumped out and bit me a little
bit (bite? byte? :-)  ).  Change the wording or not, at will.

	Best regards,
		Henrik


Cedric wrote:
> Henrik,
> 
> let's not argue, since we agree. I just replied to your posting for clarification.
> Still, there are _eight_ mentions of the word mode in the current requirement
> draft, and _all_ the sentences in the proposed words that include the word
> mode are in the current draft. Nobody objected to these 8 mentions earlier.
> Nobody posted an issue saying: 'modes' are bad. So I hope your understand
> my surprise, and my reply. Am I wrong in assuming that words that have been
> accepted for several months are satisfying the working group consensus?
> 
> Cheers,
> 
> Cedric.
> 
> Henrik Levkowetz wrote:
> 
> > Cedric,
> >
> >         Your are quite right in that mode may be used more generally, as it was in the
> > introduction sentence. This is not what I object to.  It is the much more specific
> > usage and examples at the end of the text which I object to, as they actually seem
> > to require two separate, different, modes of operation.
> 
> >         I'm not in any way particular about the specific wording I proposed, any wording
> > that does not enforce two modes would be Ok; I simply submitted text as the decent
> > thing to do when proposing a change. If you don't like it, different words could
> > be just as fine.
> >
> >         However, if you don't mean to require that the protocol has two separate,
> > different modes, I believe that the text will have to change somewhat. I understand
> > the way you wish to use mode, but the current text does not clearly read in that
> > manner -- quite the contrary, actually, which is why I commented in the first place.
> >
> >         Regards,
> >                 Henrik
> >
> > Cedric wrote:
> > >
> > > Henrik,
> > >
> > > thanks for the comment. One general reply, before more specific ones in line.
> > > You are concerned about something that was present in earlier versions of the
> > > requirement draft, and that did not raise any issues back then. The introduction
> > > sentence in section 4.5 of draft-ietf-seamoby-ct-reqs-00.txt is:
> > > 'it is useful to consider two modes of operation'. Nobody objected to that. People
> > > discussed at length what those modes were, but never the term _mode_.
> > >
> > > So why discuss something that had been accepted? If I hear where you come from,
> > > I'd say there is the new multi-phase req that induces changes (so now there is the
> > > added 'non exclusive', to underline that both modes can work cooperatively in the
> > > same ct if need be). Other cautionary words should be in that multi-phase req.
> > >
> > > Going through your suggestions, you try to replace 'mode' by 'ability'. I disagree
> > > with this. A mode is a way of doing things (how do you attempt ct?), an ability is
> > > the capacity of doing things (can you achieve this ct?), these are different notions.
> > >
> > > A little bit more in-line.
> > >
> > > Henrik Levkowetz wrote:
> > >
> > > > Cedric, Gary
> > > >
> > > >         I find the background explanatory text very good but when you get
> > > > into describing the way the protocol will work, I see an assumption
> > > > sneaking in which I don't agree to, namely that the protocol will need
> > > > to have two _modes_ of operation.
> > >
> > > For sure, we agree, and I personnaly did not
> > > see or intend the implication that you see. I think the very first sentence
> > > ('two complementray, non exclusive modes of operation') is clear enough
> > > to dispell any doubt about getting locked into one _mode_. There's also
> > > a paragraph talking on how proactive evolves into reactive if need be.
> > >
> > > > Maybe it will, or maybe we will be
> > > > able to define / design the triggers and handling at the destination
> > > > in such a way that there really will be only one mode. But I think
> > > > it's premature to imply two modes, ... maybe you didn't really mean to?
> > >
> > > To tell you the truth, maybe we don't understand mode the same way. Let me
> > > give a picturesque, snow-plowing the driveway kinda example:
> > > a car transmission might have a sporty mode and a comfort
> > > mode. Marketing guys in Detroit did the requirement: we must support sporty,
> > > we must support comfort. Do engineers build two different cars? No, it's just
> > > a switch on the dashboard: up, sporty, down, comfort.
> > > My point is, a _mode_ is not a _protocol_.
> > >
> > > >       Anyway, I've suggested revised text inline, below.
> > > >
> > > >         Best,
> > > >                 Henrik
> > > >
> > > > >
> > > > > Hey,
> > > > >
> > > > > Gary and myself have worked on a new proactive/reactive paragraph
> > > > > to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> > > > > same terminology.
> > > > > Here it is, please comment, thanks,
> > > > >
> > > > > Cedric.
> > > > > -------------------------------------------------------------------------
> > > > >
> > > > >
> > > > > 4.4 The context transfer framework MUST support proactive context transfer.
> > > > >
> > > > > 4.5 The context transfer framework MUST support reactive context transfer.
> > > > >
> > > > >    It is useful to consider two complementary, non exclusive
> > > > > modes of operation for context transfer:
> > > > > proactive and reactive.
> > > > >
> > > > >    The context transfer process is said to be proactive when the required
> > > > > contexts are requested to be in place at the target AR  prior to the arrival of
> > > > > MN's packet
> > > > > at target AR.
> > > > >
> > > > >    With proactive context transfer, the idea is to make the context available
> > > > > to an AR before it is needed. This means that the context is
> > > > > available at the AR before it is required to forward the first
> > > > > packet arrival in the MN's traffic. Proactive context transfer is
> > > > > coupled to mobile handover only by the requirement that the context
> > > > > be in place before the handover of the MN's traffic is complete.
> > > > >
> > > > >    The context transfer is said to be reactive when it is not proactive.
> > > > >
> > > > >    The idea is that in a reactive context transfer, no guarantee is made as to
> > > > > when the context will be in place at newAR. The context transfer process reacts
> > > > > to the handover, but has no control over or knowledge of the handover to ensure
> > > > > that it is in places before the arrival of MN's packet at the target AR.
> > > > > Reactive context transfer is coupled to mobile handover only by the requirement
> > > > > that some handover event is triggering the reaction. Reactive context transfer
> > > > > completes as soon as possible, but its completion is independent of the handover
> > > > > process.
> > > > >
> > > > >    Depending upon the network configuration, the MN's velocity and the behavior
> > > > > of the mobility solution, a reactive context transfer may or may not complete
> > > > > quickly enough for the new forwarding AR to provide a consistent service to
> > > > > the first packets of the re-directed traffic.
> > > > >
> > > > >    In many situations there is no forewarning available of a handover
> > > > > and context transfer must be initiated simply because the
> > > > > re-direction of the MN's traffic is in progress and the AR needs the
> > > > > forwarding context immediately. Because of the physical constraints,
> > > > > these situations can  never be completely avoided. Thus, if context
> > > > > transfer is to be  performed at all, the fundamental mode of operation
> > > > > must be reactive.
> > > >
> > > > .................................................. Thus, if context
> > > > transfer is to be performed at all, its fundamental function must be
> > > > reactive context transfer.
> > > >
> > >
> > > I understand what you are trying to do, but saying 'the fundamental function of
> > > ct' replies to the question 'what is ct' (the fundamental function of ct is to
> > > transfer
> > > context), and this addresses the question 'how'.
> > >
> > > >
> > > > >
> > > > >    The proactive mode of context transfer is an attempt to further
> > > >
> > > >    The ability to transfer context proactively is an attempt to further
> > > > ...
> > >
> > > an ability is not an attempt.
> > >
> > > Henrik, I hope that this helped alleviate your concerns,
> > > best regards,
> > >
> > > Cedric.
> > >
> > > >
> > > >
> > > > > reduce any disruption of the service provided to the MN's traffic by
> > > > > making the context available to an AR prior to it being needed for
> > > > > forwarding. This implies that some network event will occur at the IP
> > > > > level to indicate the potential for a handover, prior to the handover
> > > > > being initiated (c.f. requirements 4.1 and 4.2). This event would
> > > > > trigger a proactive context transfer if there is confidence the context
> > > > > transfer can complete before the arrival of MN's packet at the target AR.
> > > > > There can be no guarantee that this event will occur or that this confidence
> > > > > will be acquired, and thus, a reactive context transfer is
> > > > > always required as a contingency.
> > > > >
> > > > >    This also means that a context transfer that begins in proactive mode
> > > > > may, as a result of the MN moving or other changes to the wireless
> > > > > environment, be required to complete in reactive mode.  If the target
> > > > > AR stays the same, then the same proactive context transfer attempt
> > > > > should evolve into a reactive context transfer attempt.
> > > >
> > > >    This also means that a context transfer that begins as a proactive transfer
> > > > may, as a result of the MN moving or other changes to the wireless
> > > > environment, be required to complete as a reactive transfer.  If the target
> > > > AR stays the same, then the same proactive context transfer attempt
> > > > should evolve into a reactive context transfer attempt.
> > >
> > > >
> > > > >
> > > > >    As the proactive mode of context transfer is an enhancement, there may be
> > > > > situations where the reactive mode is considered a sufficient solution.
> > > > > While it is required that the context transfer protocol support proactive
> > > > > mode, its use is optional.
> > > >
> > > >    As proactive context transfer is an enhancement, there may be
> > > > situations where reactive transfer is considered a sufficient solution.
> > > > While it is required that the context transfer protocol support proactive
> > > > context transfer, this ability may not always be implemented or used.
> > > >    <<<The last sentence limps a bit, I think. Maybe you'll find
> > > >       a better formulation that doesn't go into Modes. /Henrik>>>


From owner-seamoby@diameter.org  Tue Jul 17 11:16:21 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27778
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 11:16:15 -0400 (EDT)
Received: (qmail 1264 invoked by alias); 17 Jul 2001 15:02:57 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 1258 invoked by uid 200); 17 Jul 2001 15:02:56 -0000
Received: (qmail 1251 invoked by uid 500); 17 Jul 2001 15:02:54 -0000
Date: Tue, 17 Jul 2001 08:02:54 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Henrik Levkowetz <henrik@ipunplugged.com>
Cc: seamoby@diameter.org, Cedric Westphal <cedric@iprg.nokia.com>
Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive
Message-ID: <20010717080254.Z1139@charizard.diameter.org>
Mail-Followup-To: Henrik Levkowetz <henrik@ipunplugged.com>,
	seamoby@diameter.org, Cedric Westphal <cedric@iprg.nokia.com>
References: <3B542E46.1C49C0E@iprg.nokia.com> <GMEEKDGLAJJFGAFEMMPIIEEPCEAA.henrik@ipunplugged.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <GMEEKDGLAJJFGAFEMMPIIEEPCEAA.henrik@ipunplugged.com>; from henrik@ipunplugged.com on Tue, Jul 17, 2001 at 02:53:04PM +0200
Sender: owner-seamoby@diameter.org
Precedence: bulk

Henrik,

The reason why I proposed the term "mode", was because I don't see the
protocol being any different when used in pro vs re. It's all a question
of timing, and how the nAR handles the CT packet. So, modes (in my mind)
do not imply any protocol changes, but may require some implementation 
tweaking.

Hope this makes sense,

PatC
On Tue, Jul 17, 2001 at 02:53:04PM +0200, Henrik Levkowetz wrote:
> Cedric,
> 
> 	You're right, and I'm to blame for not bringing this up earlier, to the
> extent that it would need fixing. Somehow the current wording gives me a more
> definite sense of requireing the implementation of two distinct modes, which
> I didn't get from the previous wording.
> 
> 	Maybe I was in too much of a hurry when I read the -00 draft, I don't know.
> If everybody else concurs with the current wording, fine, -- I'm still not
> convinced that we need to implement separate modes, but if nobody will read
> the draft as requireing that, we're fine. It's not the word mode I object to,
> it was the possible binding interpretation that jumped out and bit me a little
> bit (bite? byte? :-)  ).  Change the wording or not, at will.
> 
> 	Best regards,
> 		Henrik
> 
> 
> Cedric wrote:
> > Henrik,
> > 
> > let's not argue, since we agree. I just replied to your posting for clarification.
> > Still, there are _eight_ mentions of the word mode in the current requirement
> > draft, and _all_ the sentences in the proposed words that include the word
> > mode are in the current draft. Nobody objected to these 8 mentions earlier.
> > Nobody posted an issue saying: 'modes' are bad. So I hope your understand
> > my surprise, and my reply. Am I wrong in assuming that words that have been
> > accepted for several months are satisfying the working group consensus?
> > 
> > Cheers,
> > 
> > Cedric.
> > 
> > Henrik Levkowetz wrote:
> > 
> > > Cedric,
> > >
> > >         Your are quite right in that mode may be used more generally, as it was in the
> > > introduction sentence. This is not what I object to.  It is the much more specific
> > > usage and examples at the end of the text which I object to, as they actually seem
> > > to require two separate, different, modes of operation.
> > 
> > >         I'm not in any way particular about the specific wording I proposed, any wording
> > > that does not enforce two modes would be Ok; I simply submitted text as the decent
> > > thing to do when proposing a change. If you don't like it, different words could
> > > be just as fine.
> > >
> > >         However, if you don't mean to require that the protocol has two separate,
> > > different modes, I believe that the text will have to change somewhat. I understand
> > > the way you wish to use mode, but the current text does not clearly read in that
> > > manner -- quite the contrary, actually, which is why I commented in the first place.
> > >
> > >         Regards,
> > >                 Henrik
> > >
> > > Cedric wrote:
> > > >
> > > > Henrik,
> > > >
> > > > thanks for the comment. One general reply, before more specific ones in line.
> > > > You are concerned about something that was present in earlier versions of the
> > > > requirement draft, and that did not raise any issues back then. The introduction
> > > > sentence in section 4.5 of draft-ietf-seamoby-ct-reqs-00.txt is:
> > > > 'it is useful to consider two modes of operation'. Nobody objected to that. People
> > > > discussed at length what those modes were, but never the term _mode_.
> > > >
> > > > So why discuss something that had been accepted? If I hear where you come from,
> > > > I'd say there is the new multi-phase req that induces changes (so now there is the
> > > > added 'non exclusive', to underline that both modes can work cooperatively in the
> > > > same ct if need be). Other cautionary words should be in that multi-phase req.
> > > >
> > > > Going through your suggestions, you try to replace 'mode' by 'ability'. I disagree
> > > > with this. A mode is a way of doing things (how do you attempt ct?), an ability is
> > > > the capacity of doing things (can you achieve this ct?), these are different notions.
> > > >
> > > > A little bit more in-line.
> > > >
> > > > Henrik Levkowetz wrote:
> > > >
> > > > > Cedric, Gary
> > > > >
> > > > >         I find the background explanatory text very good but when you get
> > > > > into describing the way the protocol will work, I see an assumption
> > > > > sneaking in which I don't agree to, namely that the protocol will need
> > > > > to have two _modes_ of operation.
> > > >
> > > > For sure, we agree, and I personnaly did not
> > > > see or intend the implication that you see. I think the very first sentence
> > > > ('two complementray, non exclusive modes of operation') is clear enough
> > > > to dispell any doubt about getting locked into one _mode_. There's also
> > > > a paragraph talking on how proactive evolves into reactive if need be.
> > > >
> > > > > Maybe it will, or maybe we will be
> > > > > able to define / design the triggers and handling at the destination
> > > > > in such a way that there really will be only one mode. But I think
> > > > > it's premature to imply two modes, ... maybe you didn't really mean to?
> > > >
> > > > To tell you the truth, maybe we don't understand mode the same way. Let me
> > > > give a picturesque, snow-plowing the driveway kinda example:
> > > > a car transmission might have a sporty mode and a comfort
> > > > mode. Marketing guys in Detroit did the requirement: we must support sporty,
> > > > we must support comfort. Do engineers build two different cars? No, it's just
> > > > a switch on the dashboard: up, sporty, down, comfort.
> > > > My point is, a _mode_ is not a _protocol_.
> > > >
> > > > >       Anyway, I've suggested revised text inline, below.
> > > > >
> > > > >         Best,
> > > > >                 Henrik
> > > > >
> > > > > >
> > > > > > Hey,
> > > > > >
> > > > > > Gary and myself have worked on a new proactive/reactive paragraph
> > > > > > to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> > > > > > same terminology.
> > > > > > Here it is, please comment, thanks,
> > > > > >
> > > > > > Cedric.
> > > > > > -------------------------------------------------------------------------
> > > > > >
> > > > > >
> > > > > > 4.4 The context transfer framework MUST support proactive context transfer.
> > > > > >
> > > > > > 4.5 The context transfer framework MUST support reactive context transfer.
> > > > > >
> > > > > >    It is useful to consider two complementary, non exclusive
> > > > > > modes of operation for context transfer:
> > > > > > proactive and reactive.
> > > > > >
> > > > > >    The context transfer process is said to be proactive when the required
> > > > > > contexts are requested to be in place at the target AR  prior to the arrival of
> > > > > > MN's packet
> > > > > > at target AR.
> > > > > >
> > > > > >    With proactive context transfer, the idea is to make the context available
> > > > > > to an AR before it is needed. This means that the context is
> > > > > > available at the AR before it is required to forward the first
> > > > > > packet arrival in the MN's traffic. Proactive context transfer is
> > > > > > coupled to mobile handover only by the requirement that the context
> > > > > > be in place before the handover of the MN's traffic is complete.
> > > > > >
> > > > > >    The context transfer is said to be reactive when it is not proactive.
> > > > > >
> > > > > >    The idea is that in a reactive context transfer, no guarantee is made as to
> > > > > > when the context will be in place at newAR. The context transfer process reacts
> > > > > > to the handover, but has no control over or knowledge of the handover to ensure
> > > > > > that it is in places before the arrival of MN's packet at the target AR.
> > > > > > Reactive context transfer is coupled to mobile handover only by the requirement
> > > > > > that some handover event is triggering the reaction. Reactive context transfer
> > > > > > completes as soon as possible, but its completion is independent of the handover
> > > > > > process.
> > > > > >
> > > > > >    Depending upon the network configuration, the MN's velocity and the behavior
> > > > > > of the mobility solution, a reactive context transfer may or may not complete
> > > > > > quickly enough for the new forwarding AR to provide a consistent service to
> > > > > > the first packets of the re-directed traffic.
> > > > > >
> > > > > >    In many situations there is no forewarning available of a handover
> > > > > > and context transfer must be initiated simply because the
> > > > > > re-direction of the MN's traffic is in progress and the AR needs the
> > > > > > forwarding context immediately. Because of the physical constraints,
> > > > > > these situations can  never be completely avoided. Thus, if context
> > > > > > transfer is to be  performed at all, the fundamental mode of operation
> > > > > > must be reactive.
> > > > >
> > > > > .................................................. Thus, if context
> > > > > transfer is to be performed at all, its fundamental function must be
> > > > > reactive context transfer.
> > > > >
> > > >
> > > > I understand what you are trying to do, but saying 'the fundamental function of
> > > > ct' replies to the question 'what is ct' (the fundamental function of ct is to
> > > > transfer
> > > > context), and this addresses the question 'how'.
> > > >
> > > > >
> > > > > >
> > > > > >    The proactive mode of context transfer is an attempt to further
> > > > >
> > > > >    The ability to transfer context proactively is an attempt to further
> > > > > ...
> > > >
> > > > an ability is not an attempt.
> > > >
> > > > Henrik, I hope that this helped alleviate your concerns,
> > > > best regards,
> > > >
> > > > Cedric.
> > > >
> > > > >
> > > > >
> > > > > > reduce any disruption of the service provided to the MN's traffic by
> > > > > > making the context available to an AR prior to it being needed for
> > > > > > forwarding. This implies that some network event will occur at the IP
> > > > > > level to indicate the potential for a handover, prior to the handover
> > > > > > being initiated (c.f. requirements 4.1 and 4.2). This event would
> > > > > > trigger a proactive context transfer if there is confidence the context
> > > > > > transfer can complete before the arrival of MN's packet at the target AR.
> > > > > > There can be no guarantee that this event will occur or that this confidence
> > > > > > will be acquired, and thus, a reactive context transfer is
> > > > > > always required as a contingency.
> > > > > >
> > > > > >    This also means that a context transfer that begins in proactive mode
> > > > > > may, as a result of the MN moving or other changes to the wireless
> > > > > > environment, be required to complete in reactive mode.  If the target
> > > > > > AR stays the same, then the same proactive context transfer attempt
> > > > > > should evolve into a reactive context transfer attempt.
> > > > >
> > > > >    This also means that a context transfer that begins as a proactive transfer
> > > > > may, as a result of the MN moving or other changes to the wireless
> > > > > environment, be required to complete as a reactive transfer.  If the target
> > > > > AR stays the same, then the same proactive context transfer attempt
> > > > > should evolve into a reactive context transfer attempt.
> > > >
> > > > >
> > > > > >
> > > > > >    As the proactive mode of context transfer is an enhancement, there may be
> > > > > > situations where the reactive mode is considered a sufficient solution.
> > > > > > While it is required that the context transfer protocol support proactive
> > > > > > mode, its use is optional.
> > > > >
> > > > >    As proactive context transfer is an enhancement, there may be
> > > > > situations where reactive transfer is considered a sufficient solution.
> > > > > While it is required that the context transfer protocol support proactive
> > > > > context transfer, this ability may not always be implemented or used.
> > > > >    <<<The last sentence limps a bit, I think. Maybe you'll find
> > > > >       a better formulation that doesn't go into Modes. /Henrik>>>


From owner-seamoby@diameter.org  Tue Jul 17 11:20:18 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28593
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 11:20:15 -0400 (EDT)
Received: (qmail 644 invoked by alias); 17 Jul 2001 14:43:00 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 638 invoked by uid 200); 17 Jul 2001 14:42:59 -0000
Received: (qmail 627 invoked from network); 17 Jul 2001 14:42:58 -0000
Received: from netmail.alcatel.com (128.251.168.50)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 14:42:58 -0000
Received: from auds952.usa.alcatel.com (auds952.usa.alcatel.com [143.209.238.7])
	by netmail.alcatel.com (8.9.1/8.9.1) with ESMTP id JAA03217;
	Tue, 17 Jul 2001 09:53:45 -0500 (CDT)
Received: from usa.alcatel.com (localhost [127.0.0.1])
	by auds952.usa.alcatel.com (8.10.2/8.10.2) with ESMTP id f6HEri519329;
	Tue, 17 Jul 2001 09:53:44 -0500 (CDT)
Message-ID: <3B5451B6.D97E98B7@usa.alcatel.com>
Date: Tue, 17 Jul 2001 09:54:46 -0500
From: Behcet Sarikaya <behcet.sarikaya@usa.alcatel.com>
Organization: Alcatel USA
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>
CC: seamoby <seamoby@cdma-2000.org>
Subject: Re: [seamoby] Process Violation (was: no subject)
References: <200107091647.JAA17164@heliopolis.eng.sun.com> <3B52FC17.AA681AA1@usa.alcatel.com> <20010716100811.K1139@charizard.diameter.org> <3B533242.BB6E81E5@usa.alcatel.com> <20010716171120.A1139@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Today I had a phone conversation with Raj Patil who taught me a lot of things on these
issues.
Apologies for unnecessarily taking up the mailing list time.
--
Behcet



From owner-seamoby@diameter.org  Tue Jul 17 11:28:41 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29992
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 11:28:41 -0400 (EDT)
Received: (qmail 1811 invoked by alias); 17 Jul 2001 15:17:52 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 1805 invoked by uid 200); 17 Jul 2001 15:17:52 -0000
Received: (qmail 1799 invoked from network); 17 Jul 2001 15:17:50 -0000
Received: from sj-msg-core-2.cisco.com (171.69.24.11)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 15:17:50 -0000
Received: from mira-sjc5-4.cisco.com (mira-sjc5-4.cisco.com [171.71.163.21])
	by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f6HFSFH22223;
	Tue, 17 Jul 2001 08:28:15 -0700 (PDT)
Received: from NAUGA (dhcp-128-107-166-36.cisco.com [128.107.166.36])
	by mira-sjc5-4.cisco.com (Mirapoint)
	with SMTP id AQG06343;
	Tue, 17 Jul 2001 08:27:22 -0700 (PDT)
Message-ID: <07eb01c10ed4$ee4576f0$24a66b80@NAUGA>
From: "Melinda Shore" <mshore@cisco.com>
To: <john.loughney@nokia.com>, <Madjid.Nakhjiri@motorola.com>,
        <PNeumiller@MeshNetworks.com>, <pcalhoun@diameter.org>
Cc: <seamoby@cdma-2000.org>
References: <0C1353ABB1DEB74DB067ADFF749C4EEF09406F@esebe004.NOE.Nokia.com>
Subject: Re: [seamoby] RE: Yet another Security RANT was  L2 API (WAS: Ext. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
Date: Tue, 17 Jul 2001 11:26:48 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> For Phil - I think the idea is that if you leave your front door
> wide open, don't blame the police when you find that all of your
> stuff has been stolen.

The way I tend to look at it is that if you create a
security exposure that didn't exist previously, it's
your responsibility to take care of it.

Melinda




From owner-seamoby@diameter.org  Tue Jul 17 11:53:58 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06539
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 11:53:57 -0400 (EDT)
Received: (qmail 3543 invoked by alias); 17 Jul 2001 15:42:59 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 3537 invoked by uid 200); 17 Jul 2001 15:42:59 -0000
Received: (qmail 3532 invoked from network); 17 Jul 2001 15:42:57 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 15:42:57 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1KRQG>; Tue, 17 Jul 2001 11:53:13 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484455B7@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Melinda Shore'" <mshore@cisco.com>, john.loughney@nokia.com,
        Madjid.Nakhjiri@motorola.com
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] RE: Yet another Security RANT was  L2 API (WAS: Ext
	. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
Date: Tue, 17 Jul 2001 11:53:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Melinda, John, Madjid,

Hackers are very clever people in general.  Most IETF folk are
not that good at thinking about nefarious things to do with
their own creative efforts (which is the paranoid thinking
required by a security domain expert). 

Personally, I choose not to go through life worrying about every
possible attack, that's what various government agencies, the 
military, police forces, AND NOW the IETF Security WG are for! 
I do lock my doors at night and pack iron, but that has nothing
to do with the implicit trust I must place on local government
law enforcement agencies.  :-)  If WE are talking about locking
doors that is fine.  If we are talking about every WG creating
its own SWAT team, then that's where I object to the process.

REMEMBER:  The best hackers go undetected!  What you tend to do
by rolling your own security measures, is:

A).  Get rid of the amateurs: who probably won't cause much
     damage anyway, since they are quickly spotted/caught.

B).  Introduce new holes into the system by way of lax
     implementation of the security procedures themselves.  

Many cracks occur in the glue for the actual security procedures.
The IETF can not stop this, UNLESS it does things that are
systematically secure and embedded into the structure of global
Internet itself (succesively hardened by global repetitive use).

Best regards,

Phil Neumiller


> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Tuesday, July 17, 2001 11:27 AM
> To: john.loughney@nokia.com; Madjid.Nakhjiri@motorola.com;
> PNeumiller@MeshNetworks.com; pcalhoun@diameter.org
> Cc: seamoby@cdma-2000.org
> Subject: Re: [seamoby] RE: Yet another Security RANT was L2 API (WAS:
> Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)
> 
> 
> > For Phil - I think the idea is that if you leave your front door
> > wide open, don't blame the police when you find that all of your
> > stuff has been stolen.
> 
> The way I tend to look at it is that if you create a
> security exposure that didn't exist previously, it's
> your responsibility to take care of it.
> 
> Melinda
> 
> 


From owner-seamoby@diameter.org  Tue Jul 17 11:58:17 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07578
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 11:58:16 -0400 (EDT)
Received: (qmail 2332 invoked by alias); 17 Jul 2001 15:24:45 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2326 invoked by uid 200); 17 Jul 2001 15:24:45 -0000
Received: (qmail 2318 invoked from network); 17 Jul 2001 15:24:43 -0000
Received: from 217.134.88.213.host.tele1europe.se (HELO mailgw.ipunplugged.com) (@213.88.134.217)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 15:24:43 -0000
Received: from Gioconda (c40.local.ipunplugged.com [192.168.4.239])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id RAA18198;
	Tue, 17 Jul 2001 17:37:20 +0200
From: "Henrik Levkowetz" <henrik@ipunplugged.com>
To: "Pat Calhoun" <pcalhoun@diameter.org>
Cc: <seamoby@diameter.org>, "Cedric Westphal" <cedric@iprg.nokia.com>
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Tue, 17 Jul 2001 17:35:27 +0200
Message-ID: <GMEEKDGLAJJFGAFEMMPIMEFECEAA.henrik@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <20010717080254.Z1139@charizard.diameter.org>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Right. It seems we are in agreement. :-)	Best regards, Henrik

PatC wrote:
> 
> Henrik,
> 
> The reason why I proposed the term "mode", was because I don't see the
> protocol being any different when used in pro vs re. It's all a question
> of timing, and how the nAR handles the CT packet. So, modes (in my mind)
> do not imply any protocol changes, but may require some implementation 
> tweaking.
> 
> Hope this makes sense,
> 
> PatC
> On Tue, Jul 17, 2001 at 02:53:04PM +0200, Henrik Levkowetz wrote:
> > Cedric,
> > 
> > 	You're right, and I'm to blame for not bringing this up earlier, to the
> > extent that it would need fixing. Somehow the current wording gives me a more
> > definite sense of requireing the implementation of two distinct modes, which
> > I didn't get from the previous wording.
> > 
> > 	Maybe I was in too much of a hurry when I read the -00 draft, I don't know.
> > If everybody else concurs with the current wording, fine, -- I'm still not
> > convinced that we need to implement separate modes, but if nobody will read
> > the draft as requireing that, we're fine. It's not the word mode I object to,
> > it was the possible binding interpretation that jumped out and bit me a little
> > bit (bite? byte? :-)  ).  Change the wording or not, at will.
> > 
> > 	Best regards,
> > 		Henrik
> > 
> > 
> > Cedric wrote:
> > > Henrik,
> > > 
> > > let's not argue, since we agree. I just replied to your posting for clarification.
> > > Still, there are _eight_ mentions of the word mode in the current requirement
> > > draft, and _all_ the sentences in the proposed words that include the word
> > > mode are in the current draft. Nobody objected to these 8 mentions earlier.
> > > Nobody posted an issue saying: 'modes' are bad. So I hope your understand
> > > my surprise, and my reply. Am I wrong in assuming that words that have been
> > > accepted for several months are satisfying the working group consensus?
> > > 
> > > Cheers,
> > > 
> > > Cedric.
> > > 
> > > Henrik Levkowetz wrote:
> > > 
> > > > Cedric,
> > > >
> > > >         Your are quite right in that mode may be used more generally, as it was in the
> > > > introduction sentence. This is not what I object to.  It is the much more specific
> > > > usage and examples at the end of the text which I object to, as they actually seem
> > > > to require two separate, different, modes of operation.
> > > 
> > > >         I'm not in any way particular about the specific wording I proposed, any wording
> > > > that does not enforce two modes would be Ok; I simply submitted text as the decent
> > > > thing to do when proposing a change. If you don't like it, different words could
> > > > be just as fine.
> > > >
> > > >         However, if you don't mean to require that the protocol has two separate,
> > > > different modes, I believe that the text will have to change somewhat. I understand
> > > > the way you wish to use mode, but the current text does not clearly read in that
> > > > manner -- quite the contrary, actually, which is why I commented in the first place.
> > > >
> > > >         Regards,
> > > >                 Henrik
> > > >
> > > > Cedric wrote:
> > > > >
> > > > > Henrik,
> > > > >
> > > > > thanks for the comment. One general reply, before more specific ones in line.
> > > > > You are concerned about something that was present in earlier versions of the
> > > > > requirement draft, and that did not raise any issues back then. The introduction
> > > > > sentence in section 4.5 of draft-ietf-seamoby-ct-reqs-00.txt is:
> > > > > 'it is useful to consider two modes of operation'. Nobody objected to that. People
> > > > > discussed at length what those modes were, but never the term _mode_.
> > > > >
> > > > > So why discuss something that had been accepted? If I hear where you come from,
> > > > > I'd say there is the new multi-phase req that induces changes (so now there is the
> > > > > added 'non exclusive', to underline that both modes can work cooperatively in the
> > > > > same ct if need be). Other cautionary words should be in that multi-phase req.
> > > > >
> > > > > Going through your suggestions, you try to replace 'mode' by 'ability'. I disagree
> > > > > with this. A mode is a way of doing things (how do you attempt ct?), an ability is
> > > > > the capacity of doing things (can you achieve this ct?), these are different notions.
> > > > >
> > > > > A little bit more in-line.
> > > > >
> > > > > Henrik Levkowetz wrote:
> > > > >
> > > > > > Cedric, Gary
> > > > > >
> > > > > >         I find the background explanatory text very good but when you get
> > > > > > into describing the way the protocol will work, I see an assumption
> > > > > > sneaking in which I don't agree to, namely that the protocol will need
> > > > > > to have two _modes_ of operation.
> > > > >
> > > > > For sure, we agree, and I personnaly did not
> > > > > see or intend the implication that you see. I think the very first sentence
> > > > > ('two complementray, non exclusive modes of operation') is clear enough
> > > > > to dispell any doubt about getting locked into one _mode_. There's also
> > > > > a paragraph talking on how proactive evolves into reactive if need be.
> > > > >
> > > > > > Maybe it will, or maybe we will be
> > > > > > able to define / design the triggers and handling at the destination
> > > > > > in such a way that there really will be only one mode. But I think
> > > > > > it's premature to imply two modes, ... maybe you didn't really mean to?
> > > > >
> > > > > To tell you the truth, maybe we don't understand mode the same way. Let me
> > > > > give a picturesque, snow-plowing the driveway kinda example:
> > > > > a car transmission might have a sporty mode and a comfort
> > > > > mode. Marketing guys in Detroit did the requirement: we must support sporty,
> > > > > we must support comfort. Do engineers build two different cars? No, it's just
> > > > > a switch on the dashboard: up, sporty, down, comfort.
> > > > > My point is, a _mode_ is not a _protocol_.
> > > > >
> > > > > >       Anyway, I've suggested revised text inline, below.
> > > > > >
> > > > > >         Best,
> > > > > >                 Henrik
> > > > > >
> > > > > > >
> > > > > > > Hey,
> > > > > > >
> > > > > > > Gary and myself have worked on a new proactive/reactive paragraph
> > > > > > > to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> > > > > > > same terminology.
> > > > > > > Here it is, please comment, thanks,
> > > > > > >
> > > > > > > Cedric.
> > > > > > > -------------------------------------------------------------------------
> > > > > > >
> > > > > > >
> > > > > > > 4.4 The context transfer framework MUST support proactive context transfer.
> > > > > > >
> > > > > > > 4.5 The context transfer framework MUST support reactive context transfer.
> > > > > > >
> > > > > > >    It is useful to consider two complementary, non exclusive
> > > > > > > modes of operation for context transfer:
> > > > > > > proactive and reactive.
> > > > > > >
> > > > > > >    The context transfer process is said to be proactive when the required
> > > > > > > contexts are requested to be in place at the target AR  prior to the arrival of
> > > > > > > MN's packet
> > > > > > > at target AR.
> > > > > > >
> > > > > > >    With proactive context transfer, the idea is to make the context available
> > > > > > > to an AR before it is needed. This means that the context is
> > > > > > > available at the AR before it is required to forward the first
> > > > > > > packet arrival in the MN's traffic. Proactive context transfer is
> > > > > > > coupled to mobile handover only by the requirement that the context
> > > > > > > be in place before the handover of the MN's traffic is complete.
> > > > > > >
> > > > > > >    The context transfer is said to be reactive when it is not proactive.
> > > > > > >
> > > > > > >    The idea is that in a reactive context transfer, no guarantee is made as to
> > > > > > > when the context will be in place at newAR. The context transfer process reacts
> > > > > > > to the handover, but has no control over or knowledge of the handover to ensure
> > > > > > > that it is in places before the arrival of MN's packet at the target AR.
> > > > > > > Reactive context transfer is coupled to mobile handover only by the requirement
> > > > > > > that some handover event is triggering the reaction. Reactive context transfer
> > > > > > > completes as soon as possible, but its completion is independent of the handover
> > > > > > > process.
> > > > > > >
> > > > > > >    Depending upon the network configuration, the MN's velocity and the behavior
> > > > > > > of the mobility solution, a reactive context transfer may or may not complete
> > > > > > > quickly enough for the new forwarding AR to provide a consistent service to
> > > > > > > the first packets of the re-directed traffic.
> > > > > > >
> > > > > > >    In many situations there is no forewarning available of a handover
> > > > > > > and context transfer must be initiated simply because the
> > > > > > > re-direction of the MN's traffic is in progress and the AR needs the
> > > > > > > forwarding context immediately. Because of the physical constraints,
> > > > > > > these situations can  never be completely avoided. Thus, if context
> > > > > > > transfer is to be  performed at all, the fundamental mode of operation
> > > > > > > must be reactive.
> > > > > >
> > > > > > .................................................. Thus, if context
> > > > > > transfer is to be performed at all, its fundamental function must be
> > > > > > reactive context transfer.
> > > > > >
> > > > >
> > > > > I understand what you are trying to do, but saying 'the fundamental function of
> > > > > ct' replies to the question 'what is ct' (the fundamental function of ct is to
> > > > > transfer
> > > > > context), and this addresses the question 'how'.
> > > > >
> > > > > >
> > > > > > >
> > > > > > >    The proactive mode of context transfer is an attempt to further
> > > > > >
> > > > > >    The ability to transfer context proactively is an attempt to further
> > > > > > ...
> > > > >
> > > > > an ability is not an attempt.
> > > > >
> > > > > Henrik, I hope that this helped alleviate your concerns,
> > > > > best regards,
> > > > >
> > > > > Cedric.
> > > > >
> > > > > >
> > > > > >
> > > > > > > reduce any disruption of the service provided to the MN's traffic by
> > > > > > > making the context available to an AR prior to it being needed for
> > > > > > > forwarding. This implies that some network event will occur at the IP
> > > > > > > level to indicate the potential for a handover, prior to the handover
> > > > > > > being initiated (c.f. requirements 4.1 and 4.2). This event would
> > > > > > > trigger a proactive context transfer if there is confidence the context
> > > > > > > transfer can complete before the arrival of MN's packet at the target AR.
> > > > > > > There can be no guarantee that this event will occur or that this confidence
> > > > > > > will be acquired, and thus, a reactive context transfer is
> > > > > > > always required as a contingency.
> > > > > > >
> > > > > > >    This also means that a context transfer that begins in proactive mode
> > > > > > > may, as a result of the MN moving or other changes to the wireless
> > > > > > > environment, be required to complete in reactive mode.  If the target
> > > > > > > AR stays the same, then the same proactive context transfer attempt
> > > > > > > should evolve into a reactive context transfer attempt.
> > > > > >
> > > > > >    This also means that a context transfer that begins as a proactive transfer
> > > > > > may, as a result of the MN moving or other changes to the wireless
> > > > > > environment, be required to complete as a reactive transfer.  If the target
> > > > > > AR stays the same, then the same proactive context transfer attempt
> > > > > > should evolve into a reactive context transfer attempt.
> > > > >
> > > > > >
> > > > > > >
> > > > > > >    As the proactive mode of context transfer is an enhancement, there may be
> > > > > > > situations where the reactive mode is considered a sufficient solution.
> > > > > > > While it is required that the context transfer protocol support proactive
> > > > > > > mode, its use is optional.
> > > > > >
> > > > > >    As proactive context transfer is an enhancement, there may be
> > > > > > situations where reactive transfer is considered a sufficient solution.
> > > > > > While it is required that the context transfer protocol support proactive
> > > > > > context transfer, this ability may not always be implemented or used.
> > > > > >    <<<The last sentence limps a bit, I think. Maybe you'll find
> > > > > >       a better formulation that doesn't go into Modes. /Henrik>>>


From owner-seamoby@diameter.org  Tue Jul 17 12:04:53 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08870
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 12:04:53 -0400 (EDT)
Received: (qmail 4082 invoked by alias); 17 Jul 2001 15:53:48 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 4076 invoked by uid 200); 17 Jul 2001 15:53:48 -0000
Received: (qmail 4067 invoked by uid 500); 17 Jul 2001 15:53:46 -0000
Date: Tue, 17 Jul 2001 08:53:46 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: "'Melinda Shore'" <mshore@cisco.com>, john.loughney@nokia.com,
        Madjid.Nakhjiri@motorola.com, seamoby@cdma-2000.org
Subject: Re: [seamoby] RE: Yet another Security RANT was  L2 API (WAS: Ext . for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
Message-ID: <20010717085346.B1139@charizard.diameter.org>
Mail-Followup-To: Phillip Neumiller <PNeumiller@MeshNetworks.com>,
	'Melinda Shore' <mshore@cisco.com>, john.loughney@nokia.com,
	Madjid.Nakhjiri@motorola.com, seamoby@cdma-2000.org
References: <0DF9FBC42474A24CA50F7A27FB08E0484455B7@meshpdc.meshnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E0484455B7@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Tue, Jul 17, 2001 at 11:53:10AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

I'd recommend you take a look at http://search.ietf.org/internet-drafts/draft-ietf-saag-whyenc-00.txt

PatC
On Tue, Jul 17, 2001 at 11:53:10AM -0400, Phillip Neumiller wrote:
> Hi Melinda, John, Madjid,
> 
> Hackers are very clever people in general.  Most IETF folk are
> not that good at thinking about nefarious things to do with
> their own creative efforts (which is the paranoid thinking
> required by a security domain expert). 
> 
> Personally, I choose not to go through life worrying about every
> possible attack, that's what various government agencies, the 
> military, police forces, AND NOW the IETF Security WG are for! 
> I do lock my doors at night and pack iron, but that has nothing
> to do with the implicit trust I must place on local government
> law enforcement agencies.  :-)  If WE are talking about locking
> doors that is fine.  If we are talking about every WG creating
> its own SWAT team, then that's where I object to the process.
> 
> REMEMBER:  The best hackers go undetected!  What you tend to do
> by rolling your own security measures, is:
> 
> A).  Get rid of the amateurs: who probably won't cause much
>      damage anyway, since they are quickly spotted/caught.
> 
> B).  Introduce new holes into the system by way of lax
>      implementation of the security procedures themselves.  
> 
> Many cracks occur in the glue for the actual security procedures.
> The IETF can not stop this, UNLESS it does things that are
> systematically secure and embedded into the structure of global
> Internet itself (succesively hardened by global repetitive use).
> 
> Best regards,
> 
> Phil Neumiller
> 
> 
> > -----Original Message-----
> > From: Melinda Shore [mailto:mshore@cisco.com]
> > Sent: Tuesday, July 17, 2001 11:27 AM
> > To: john.loughney@nokia.com; Madjid.Nakhjiri@motorola.com;
> > PNeumiller@MeshNetworks.com; pcalhoun@diameter.org
> > Cc: seamoby@cdma-2000.org
> > Subject: Re: [seamoby] RE: Yet another Security RANT was L2 API (WAS:
> > Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)
> > 
> > 
> > > For Phil - I think the idea is that if you leave your front door
> > > wide open, don't blame the police when you find that all of your
> > > stuff has been stolen.
> > 
> > The way I tend to look at it is that if you create a
> > security exposure that didn't exist previously, it's
> > your responsibility to take care of it.
> > 
> > Melinda
> > 
> > 


From owner-seamoby@diameter.org  Tue Jul 17 16:10:34 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03225
	for <seamoby-archive@odin.ietf.org>; Tue, 17 Jul 2001 16:10:34 -0400 (EDT)
Received: (qmail 5957 invoked by alias); 17 Jul 2001 19:59:55 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5951 invoked by uid 200); 17 Jul 2001 19:59:54 -0000
Received: (qmail 5946 invoked from network); 17 Jul 2001 19:59:52 -0000
Received: from newdev.eecs.harvard.edu (HELO newdev.harvard.edu) (140.247.60.212)
  by c900656-a.plstn1.sfba.home.com with SMTP; 17 Jul 2001 19:59:52 -0000
Received: (from sob@localhost)
	by newdev.harvard.edu (8.9.3/8.9.3) id QAA16927
	for seamoby@cdma-2000.org; Tue, 17 Jul 2001 16:10:30 -0400 (EDT)
Date: Tue, 17 Jul 2001 16:10:30 -0400 (EDT)
From: Scott Bradner <sob@harvard.edu>
Message-Id: <200107172010.QAA16927@newdev.harvard.edu>
To: seamoby@cdma-2000.org
Subject: [seamoby] Re:
Sender: owner-seamoby@diameter.org
Precedence: bulk


Pat is right
	1/ there is no rule about getting agenda time if an ID gets 
	   published before the cutoff
	2/ the TSV area strongly discourages taking up scarce session time
	   to "present" IDs - people should discuss them on the list
	   agenda time should be reserved for resolving issues

Scott


From owner-seamoby@diameter.org  Wed Jul 18 07:00:22 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26103
	for <seamoby-archive@odin.ietf.org>; Wed, 18 Jul 2001 07:00:21 -0400 (EDT)
Received: (qmail 9550 invoked by alias); 18 Jul 2001 10:49:12 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 9544 invoked by uid 200); 18 Jul 2001 10:49:11 -0000
Received: (qmail 9539 invoked from network); 18 Jul 2001 10:49:10 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jul 2001 10:49:10 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25057;
	Wed, 18 Jul 2001 06:58:18 -0400 (EDT)
Message-Id: <200107181058.GAA25057@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: seamoby@cdma-2000.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [seamoby] I-D ACTION:draft-pagtzis-seamoby-proactivev6-00.txt,.ps
Date: Wed, 18 Jul 2001 06:58:18 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: A Framework for Seamless Proactive Mobility in Mobile 
                          IPv6
	Author(s)	: T. Pagtzis, P. Kirstein
	Filename	: draft-pagtzis-seamoby-proactivev6-00.txt,.ps
	Pages		: 
	Date		: 17-Jul-01
	
This document specifies a scheme to provide support for seamless
proactive mobility  for IPv6.  It encompasses a novel approach for seamless handoff and proactive roaming context transfer.  The latter establishes a generic method for proactive context transfer and manipulation of different classes of context relating to the state of IP connectivity for a mobile node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-pagtzis-seamoby-proactivev6-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010717133028.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-pagtzis-seamoby-proactivev6-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010717133028.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-seamoby@diameter.org  Wed Jul 18 07:02:51 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27460
	for <seamoby-archive@odin.ietf.org>; Wed, 18 Jul 2001 07:02:49 -0400 (EDT)
Received: (qmail 9598 invoked by alias); 18 Jul 2001 10:49:18 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 9591 invoked by uid 200); 18 Jul 2001 10:49:18 -0000
Received: (qmail 9582 invoked from network); 18 Jul 2001 10:49:15 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jul 2001 10:49:15 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25451;
	Wed, 18 Jul 2001 06:59:11 -0400 (EDT)
Message-Id: <200107181059.GAA25451@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: seamoby@cdma-2000.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [seamoby] I-D ACTION:draft-koodli-idle-mode-ctv6-00.txt
Date: Wed, 18 Jul 2001 06:59:11 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Idle Mode Handover Support in IPv6 Networks
	Author(s)	: R. Koodli, J. Malinen
	Filename	: draft-koodli-idle-mode-ctv6-00.txt
	Pages		: 16
	Date		: 17-Jul-01
	
This document considers the problem of expediting authenticated network
access as well as enabling authorized context transfer during idle-mode
handovers.  In essence, this document addresses idle-mode context
transfers, so that an idle-mode Mobile Node (MN) can resume its sessions
in a seamless fashion.  We propose supplying the session key in the
paging message to the Access Router (AR) that locates the idle Mobile
Node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-koodli-idle-mode-ctv6-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-koodli-idle-mode-ctv6-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-koodli-idle-mode-ctv6-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010717133204.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-koodli-idle-mode-ctv6-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-koodli-idle-mode-ctv6-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010717133204.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-seamoby@diameter.org  Wed Jul 18 07:08:39 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29279
	for <seamoby-archive@odin.ietf.org>; Wed, 18 Jul 2001 07:08:38 -0400 (EDT)
Received: (qmail 9691 invoked by alias); 18 Jul 2001 10:49:39 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 9684 invoked by uid 200); 18 Jul 2001 10:49:39 -0000
Received: (qmail 9670 invoked from network); 18 Jul 2001 10:49:35 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jul 2001 10:49:35 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25633;
	Wed, 18 Jul 2001 06:59:31 -0400 (EDT)
Message-Id: <200107181059.GAA25633@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: seamoby@cdma-2000.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [seamoby] I-D ACTION:draft-sarikaya-mobileip-mipv6hp-00.txt
Date: Wed, 18 Jul 2001 06:59:31 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Mobile IPv6 Hierarchical Paging
	Author(s)	: B. Sarikaya
	Filename	: draft-sarikaya-mobileip-mipv6hp-00.txt
	Pages		: 18
	Date		: 17-Jul-01
	
This document specifies Hierarchical Mobile IPv6 Hierarchical Paging
(HMIPv6HP), an IP host alerting protocol which is a link-layer
independent extension to Hierarchical Mobile IPv6. The extension
allows a mobile node to enter a power saving dormant mode during
which its location is known with coarse accuracy defined by a paging
area. In the visited domain only the paging mobility anchor point
(PMAP) is responsible for keeping the binding cache entries for
dormant mobile nodes and, it re-establishes the downlink routes on
demand by means of paging. Paging is initiated by the paging agent
(PA) and the access routers in paging areas and does not involve
periodic layer 3 messages to be sent except for time-slot based
paging which is optional and is to be used on links with no support
for layer 2 paging.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sarikaya-mobileip-mipv6hp-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-sarikaya-mobileip-mipv6hp-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-sarikaya-mobileip-mipv6hp-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010717133243.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-sarikaya-mobileip-mipv6hp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-sarikaya-mobileip-mipv6hp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010717133243.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-seamoby@diameter.org  Wed Jul 18 16:25:04 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25849
	for <seamoby-archive@odin.ietf.org>; Wed, 18 Jul 2001 16:25:04 -0400 (EDT)
Received: (qmail 14202 invoked by alias); 18 Jul 2001 20:14:12 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 14196 invoked by uid 200); 18 Jul 2001 20:14:12 -0000
Received: (qmail 14191 invoked by uid 500); 18 Jul 2001 20:14:10 -0000
Date: Wed, 18 Jul 2001 13:14:10 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: seamoby@cdma-2000.org
Subject: [seamoby] Paging Next Steps
Message-ID: <20010718131409.C1139@charizard.diameter.org>
Mail-Followup-To: seamoby@cdma-2000.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-seamoby@diameter.org
Precedence: bulk

All,

Now that the IESG has approved the paging (aka DMHA) requirements,
we are now ready to proceed to the next phase. The milestones
state that folks should be getting ready to submit their protocol
to the WG for consideration.

Here is a proposal on how to proceed:

1. Folks submit protocols by no later than September 14th.
2. Each protocol submission must also include an accompanying
   I-D that compares the protocol against the requirements. For
   each requirement, the author must state whether the protocol
   complies to the requirements, and if so, how. Note that we aren't
   looking for a dissertation, but also not looking for empty claims.
3. Myself (or an appointed editor) will compile the list into a
   single Internet Draft, which will be used to ease comparison. This
   draft will be available on September 28th.
4. The document will be submitted to the WG, and a Last Call will be
   made to make sure that the WG agrees with the comparison. WG Last
   Call ends Oct 12th.
5. If there is a clear winner, then we begin protocol design based on
   leading protocol. Otherwise, discussions within the WG will commence
   to determine which protocol is best for our purposes. In either case,
   the WG will not rubber stamp the protocol. Input from the WG will 
   be taken to ensure that the spec can withstand a WG Last Call.

Our milestones show that we have a potential interim meeting in September.
We can use this meeting for combined CT and paging work. Given the above,
I believe that perhaps a meeting in mid October would make more sense
for paging. At that time we would be at point 5 (above), which would
really benefit from a face to face (assuming that there is no clear
leading protocol).

Thoughts?

PatC


From owner-seamoby@diameter.org  Wed Jul 18 18:44:35 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23732
	for <seamoby-archive@odin.ietf.org>; Wed, 18 Jul 2001 18:44:33 -0400 (EDT)
Received: (qmail 15218 invoked by alias); 18 Jul 2001 22:31:09 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15212 invoked by uid 200); 18 Jul 2001 22:31:08 -0000
Received: (qmail 15204 invoked from network); 18 Jul 2001 22:31:06 -0000
Received: from motgate2.mot.com (136.182.1.10)
  by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jul 2001 22:31:06 -0000
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id PAA11734 for <seamoby@cdma-2000.org>; Wed, 18 Jul 2001 15:41:53 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id PAA21021 for <seamoby@cdma-2000.org>; Wed, 18 Jul 2001 15:41:53 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <3XDBTWMG>; Wed, 18 Jul 2001 17:41:52 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9EDE@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>,
        "'Melinda Shore'" <mshore@cisco.com>, john.loughney@nokia.com,
        Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] RE: Yet another Security RANT was  L2 API (WAS: Ext
	. for FMIPv6 - comments) (SHOULD be ,          RE: Issue #4)
Date: Wed, 18 Jul 2001 17:41:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Phil,

just one thing, so I have the last word (just kidding).
I think we are in agreement that we do not want to create
new security protocols and stuff them into CTP. The goal was
to rely on existing measures such IPSec, TLS or what have you.

But that does not mean we totally ignore any security issues that
CTP creates and ALSO comes to our minds.
If my neighbor wants to keep a tiger as a pet in his backyard,
he needs to put fence around his yard to not bite my leg off,
 we cannot rely on local government for that, 
if that would be the case, I would talk to a
realtor instead :)

Madjid

-----Original Message-----
From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
Sent: Tuesday, July 17, 2001 10:53 AM
To: 'Melinda Shore'; john.loughney@nokia.com; Madjid.Nakhjiri
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] RE: Yet another Security RANT was L2 API (WAS:
Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)


Hi Melinda, John, Madjid,

Hackers are very clever people in general.  Most IETF folk are
not that good at thinking about nefarious things to do with
their own creative efforts (which is the paranoid thinking
required by a security domain expert). 

Personally, I choose not to go through life worrying about every
possible attack, that's what various government agencies, the 
military, police forces, AND NOW the IETF Security WG are for! 
I do lock my doors at night and pack iron, but that has nothing
to do with the implicit trust I must place on local government
law enforcement agencies.  :-)  If WE are talking about locking
doors that is fine.  If we are talking about every WG creating
its own SWAT team, then that's where I object to the process.

REMEMBER:  The best hackers go undetected!  What you tend to do
by rolling your own security measures, is:

A).  Get rid of the amateurs: who probably won't cause much
     damage anyway, since they are quickly spotted/caught.

B).  Introduce new holes into the system by way of lax
     implementation of the security procedures themselves.  

Many cracks occur in the glue for the actual security procedures.
The IETF can not stop this, UNLESS it does things that are
systematically secure and embedded into the structure of global
Internet itself (succesively hardened by global repetitive use).

Best regards,

Phil Neumiller


> -----Original Message-----
> From: Melinda Shore [mailto:mshore@cisco.com]
> Sent: Tuesday, July 17, 2001 11:27 AM
> To: john.loughney@nokia.com; Madjid.Nakhjiri@motorola.com;
> PNeumiller@MeshNetworks.com; pcalhoun@diameter.org
> Cc: seamoby@cdma-2000.org
> Subject: Re: [seamoby] RE: Yet another Security RANT was L2 API (WAS:
> Ext. for FMIPv6 - comments) (SHOULD be , RE: Issue #4)
> 
> 
> > For Phil - I think the idea is that if you leave your front door
> > wide open, don't blame the police when you find that all of your
> > stuff has been stolen.
> 
> The way I tend to look at it is that if you create a
> security exposure that didn't exist previously, it's
> your responsibility to take care of it.
> 
> Melinda
> 
> 


From owner-seamoby@diameter.org  Wed Jul 18 19:00:57 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26968
	for <seamoby-archive@odin.ietf.org>; Wed, 18 Jul 2001 19:00:54 -0400 (EDT)
Received: (qmail 14870 invoked by alias); 18 Jul 2001 22:26:23 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 14864 invoked by uid 200); 18 Jul 2001 22:26:22 -0000
Received: (qmail 14859 invoked from network); 18 Jul 2001 22:26:21 -0000
Received: from motgate4.mot.com (144.189.100.102)
  by c900656-a.plstn1.sfba.home.com with SMTP; 18 Jul 2001 22:26:21 -0000
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate4.mot.com (motgate4 2.1) with ESMTP id PAA21281 for <seamoby@diameter.org>; Wed, 18 Jul 2001 15:37:08 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id PAA17614 for <seamoby@diameter.org>; Wed, 18 Jul 2001 15:37:07 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19)
	id <NKTA7Q78>; Wed, 18 Jul 2001 17:36:29 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B017A9EDD@IL27EXM10.cig.mot.com>
From: Nakhjiri Madjid-MNAKHJI1 <Madjid.Nakhjiri@motorola.com>
To: "'Cedric Westphal'" <cedric@IPRG.nokia.com>,
        Henrik Levkowetz <henrik@ipunplugged.com>, seamoby@diameter.org
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Wed, 18 Jul 2001 17:35:54 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

Cedric,

Shame on the DT, for having complete mutual understanding that both pro and
reactive
use the same procedures :) that is why we did not object to the word "mode".

If you have any suggestions, bring it on :)

Madjid

-----Original Message-----
From: Cedric Westphal [mailto:cedric@IPRG.nokia.com]
Sent: Tuesday, July 17, 2001 7:24 AM
To: Henrik Levkowetz; seamoby@diameter.org
Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive


Henrik,

let's not argue, since we agree. I just replied to your posting for
clarification.
Still, there are _eight_ mentions of the word mode in the current
requirement
draft, and _all_ the sentences in the proposed words that include the word
mode are in the current draft. Nobody objected to these 8 mentions earlier.
Nobody posted an issue saying: 'modes' are bad. So I hope your understand
my surprise, and my reply. Am I wrong in assuming that words that have been
accepted for several months are satisfying the working group consensus?

Cheers,

Cedric.

Henrik Levkowetz wrote:

> Cedric,
>
>         Your are quite right in that mode may be used more generally, as
it was in the
> introduction sentence. This is not what I object to.  It is the much more
specific
> usage and examples at the end of the text which I object to, as they
actually seem
> to require two separate, different, modes of operation.

>         I'm not in any way particular about the specific wording I
proposed, any wording
> that does not enforce two modes would be Ok; I simply submitted text as
the decent
> thing to do when proposing a change. If you don't like it, different words
could
> be just as fine.
>
>         However, if you don't mean to require that the protocol has two
separate,
> different modes, I believe that the text will have to change somewhat. I
understand
> the way you wish to use mode, but the current text does not clearly read
in that
> manner -- quite the contrary, actually, which is why I commented in the
first place.
>
>         Regards,
>                 Henrik
>
> Cedric wrote:
> >
> > Henrik,
> >
> > thanks for the comment. One general reply, before more specific ones in
line.
> > You are concerned about something that was present in earlier versions
of the
> > requirement draft, and that did not raise any issues back then. The
introduction
> > sentence in section 4.5 of draft-ietf-seamoby-ct-reqs-00.txt is:
> > 'it is useful to consider two modes of operation'. Nobody objected to
that. People
> > discussed at length what those modes were, but never the term _mode_.
> >
> > So why discuss something that had been accepted? If I hear where you
come from,
> > I'd say there is the new multi-phase req that induces changes (so now
there is the
> > added 'non exclusive', to underline that both modes can work
cooperatively in the
> > same ct if need be). Other cautionary words should be in that
multi-phase req.
> >
> > Going through your suggestions, you try to replace 'mode' by 'ability'.
I disagree
> > with this. A mode is a way of doing things (how do you attempt ct?), an
ability is
> > the capacity of doing things (can you achieve this ct?), these are
different notions.
> >
> > A little bit more in-line.
> >
> > Henrik Levkowetz wrote:
> >
> > > Cedric, Gary
> > >
> > >         I find the background explanatory text very good but when you
get
> > > into describing the way the protocol will work, I see an assumption
> > > sneaking in which I don't agree to, namely that the protocol will need
> > > to have two _modes_ of operation.
> >
> > For sure, we agree, and I personnaly did not
> > see or intend the implication that you see. I think the very first
sentence
> > ('two complementray, non exclusive modes of operation') is clear enough
> > to dispell any doubt about getting locked into one _mode_. There's also
> > a paragraph talking on how proactive evolves into reactive if need be.
> >
> > > Maybe it will, or maybe we will be
> > > able to define / design the triggers and handling at the destination
> > > in such a way that there really will be only one mode. But I think
> > > it's premature to imply two modes, ... maybe you didn't really mean
to?
> >
> > To tell you the truth, maybe we don't understand mode the same way. Let
me
> > give a picturesque, snow-plowing the driveway kinda example:
> > a car transmission might have a sporty mode and a comfort
> > mode. Marketing guys in Detroit did the requirement: we must support
sporty,
> > we must support comfort. Do engineers build two different cars? No, it's
just
> > a switch on the dashboard: up, sporty, down, comfort.
> > My point is, a _mode_ is not a _protocol_.
> >
> > >       Anyway, I've suggested revised text inline, below.
> > >
> > >         Best,
> > >                 Henrik
> > >
> > > >
> > > > Hey,
> > > >
> > > > Gary and myself have worked on a new proactive/reactive paragraph
> > > > to explain requirements 4.4/4.5 and solve Issue #4, while keeping
the
> > > > same terminology.
> > > > Here it is, please comment, thanks,
> > > >
> > > > Cedric.
> > > >
-------------------------------------------------------------------------
> > > >
> > > >
> > > > 4.4 The context transfer framework MUST support proactive context
transfer.
> > > >
> > > > 4.5 The context transfer framework MUST support reactive context
transfer.
> > > >
> > > >    It is useful to consider two complementary, non exclusive
> > > > modes of operation for context transfer:
> > > > proactive and reactive.
> > > >
> > > >    The context transfer process is said to be proactive when the
required
> > > > contexts are requested to be in place at the target AR  prior to the
arrival of
> > > > MN's packet
> > > > at target AR.
> > > >
> > > >    With proactive context transfer, the idea is to make the context
available
> > > > to an AR before it is needed. This means that the context is
> > > > available at the AR before it is required to forward the first
> > > > packet arrival in the MN's traffic. Proactive context transfer is
> > > > coupled to mobile handover only by the requirement that the context
> > > > be in place before the handover of the MN's traffic is complete.
> > > >
> > > >    The context transfer is said to be reactive when it is not
proactive.
> > > >
> > > >    The idea is that in a reactive context transfer, no guarantee is
made as to
> > > > when the context will be in place at newAR. The context transfer
process reacts
> > > > to the handover, but has no control over or knowledge of the
handover to ensure
> > > > that it is in places before the arrival of MN's packet at the target
AR.
> > > > Reactive context transfer is coupled to mobile handover only by the
requirement
> > > > that some handover event is triggering the reaction. Reactive
context transfer
> > > > completes as soon as possible, but its completion is independent of
the handover
> > > > process.
> > > >
> > > >    Depending upon the network configuration, the MN's velocity and
the behavior
> > > > of the mobility solution, a reactive context transfer may or may not
complete
> > > > quickly enough for the new forwarding AR to provide a consistent
service to
> > > > the first packets of the re-directed traffic.
> > > >
> > > >    In many situations there is no forewarning available of a
handover
> > > > and context transfer must be initiated simply because the
> > > > re-direction of the MN's traffic is in progress and the AR needs the
> > > > forwarding context immediately. Because of the physical constraints,
> > > > these situations can  never be completely avoided. Thus, if context
> > > > transfer is to be  performed at all, the fundamental mode of
operation
> > > > must be reactive.
> > >
> > > .................................................. Thus, if context
> > > transfer is to be performed at all, its fundamental function must be
> > > reactive context transfer.
> > >
> >
> > I understand what you are trying to do, but saying 'the fundamental
function of
> > ct' replies to the question 'what is ct' (the fundamental function of ct
is to
> > transfer
> > context), and this addresses the question 'how'.
> >
> > >
> > > >
> > > >    The proactive mode of context transfer is an attempt to further
> > >
> > >    The ability to transfer context proactively is an attempt to
further
> > > ...
> >
> > an ability is not an attempt.
> >
> > Henrik, I hope that this helped alleviate your concerns,
> > best regards,
> >
> > Cedric.
> >
> > >
> > >
> > > > reduce any disruption of the service provided to the MN's traffic by
> > > > making the context available to an AR prior to it being needed for
> > > > forwarding. This implies that some network event will occur at the
IP
> > > > level to indicate the potential for a handover, prior to the
handover
> > > > being initiated (c.f. requirements 4.1 and 4.2). This event would
> > > > trigger a proactive context transfer if there is confidence the
context
> > > > transfer can complete before the arrival of MN's packet at the
target AR.
> > > > There can be no guarantee that this event will occur or that this
confidence
> > > > will be acquired, and thus, a reactive context transfer is
> > > > always required as a contingency.
> > > >
> > > >    This also means that a context transfer that begins in proactive
mode
> > > > may, as a result of the MN moving or other changes to the wireless
> > > > environment, be required to complete in reactive mode.  If the
target
> > > > AR stays the same, then the same proactive context transfer attempt
> > > > should evolve into a reactive context transfer attempt.
> > >
> > >    This also means that a context transfer that begins as a proactive
transfer
> > > may, as a result of the MN moving or other changes to the wireless
> > > environment, be required to complete as a reactive transfer.  If the
target
> > > AR stays the same, then the same proactive context transfer attempt
> > > should evolve into a reactive context transfer attempt.
> >
> > >
> > > >
> > > >    As the proactive mode of context transfer is an enhancement,
there may be
> > > > situations where the reactive mode is considered a sufficient
solution.
> > > > While it is required that the context transfer protocol support
proactive
> > > > mode, its use is optional.
> > >
> > >    As proactive context transfer is an enhancement, there may be
> > > situations where reactive transfer is considered a sufficient
solution.
> > > While it is required that the context transfer protocol support
proactive
> > > context transfer, this ability may not always be implemented or used.
> > >    <<<The last sentence limps a bit, I think. Maybe you'll find
> > >       a better formulation that doesn't go into Modes. /Henrik>>>


From owner-seamoby@diameter.org  Wed Jul 18 20:45:21 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18564
	for <seamoby-archive@odin.ietf.org>; Wed, 18 Jul 2001 20:45:21 -0400 (EDT)
Received: (qmail 16146 invoked by alias); 19 Jul 2001 00:34:18 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16140 invoked by uid 200); 19 Jul 2001 00:34:17 -0000
Received: (qmail 16135 invoked by uid 500); 19 Jul 2001 00:34:16 -0000
Date: Wed, 18 Jul 2001 17:34:16 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: seamoby@cdma-2000.org
Subject: [seamoby] Latest Seamoby (proposed) Agenda
Message-ID: <20010718173416.R1139@charizard.diameter.org>
Mail-Followup-To: seamoby@cdma-2000.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-seamoby@diameter.org
Precedence: bulk

All,

Below is the latest proposed agenda. I believe that I have received
a few additional slot requests from folks, and I have sent them some
queries about the scope of the discussion, so we don't really have 
80 mins open. However, I MAY have missed some requests as my inbox 
sufferred from an interesting problem this morning.

If I missed your request, please ping me again. I did not intentionally
leave anyone out. Although the deadline is 7/31, my goal is to have our
agenda completed by 7/26, so please do respond asap.

Thanks,

PatC
----
Monday August 6th

1300-1500

Agenda Bashing                                  Chair           5 mins
Update on WG documents                          Chair           10 mins
Milestone Review                                Chair           10 mins
Context Transfer Requirements Discussions       All             95 mins
Adjourn (cookie hunting)


Wednesday August 8th

1530-1730

(open)                                          ????            80 mins
Handoff Candidate Discovery Issues              HCD Authors     15 mins
Proceeding on Paging (DMHA)                     All             10 mins
L2 Triggers and its relevance to Seamoby        Kempf            5 mins
Closure/Next Steps                              Chair           10 mins
Adjourn (bar hunting)


From owner-seamoby@diameter.org  Thu Jul 19 02:40:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16783
	for <seamoby-archive@odin.ietf.org>; Thu, 19 Jul 2001 02:40:10 -0400 (EDT)
Received: (qmail 16886 invoked by alias); 19 Jul 2001 06:29:07 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16880 invoked by uid 200); 19 Jul 2001 06:29:06 -0000
Received: (qmail 16875 invoked from network); 19 Jul 2001 06:29:04 -0000
Received: from mgw-x3.nokia.com (131.228.20.26)
  by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jul 2001 06:29:04 -0000
Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35])
	by mgw-x3.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6J6eTI25437
	for <seamoby@cdma-2000.org>; Thu, 19 Jul 2001 09:40:29 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54d6f46534ac158f2313e2@esvir03nok.nokia.com>;
 Thu, 19 Jul 2001 09:39:53 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <3MSVB4BG>; Thu, 19 Jul 2001 09:39:48 +0300
Message-ID: <0C1353ABB1DEB74DB067ADFF749C4EEF0940AD@esebe004.NOE.Nokia.com>
From: john.loughney@nokia.com
To: pcalhoun@diameter.org, seamoby@cdma-2000.org
Subject: RE: [seamoby] Latest Seamoby (proposed) Agenda
Date: Thu, 19 Jul 2001 09:39:46 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hi Pat,

A quick question:

> Monday August 6th
> 
> 1300-1500
> 
> Agenda Bashing                                  Chair           5 mins
> Update on WG documents                          Chair         
>   10 mins
> Milestone Review                                Chair         
>   10 mins
> Context Transfer Requirements Discussions       All           
>   95 mins

We have 95 minutes allocated for CT reqs (presented by all).  How do
you intend to handle this?  If someone had 2 or 3 slides for a specific
issue, could that be considered part of this 95 minutes?

best regards,
John


From owner-seamoby@diameter.org  Thu Jul 19 07:07:08 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28935
	for <seamoby-archive@odin.ietf.org>; Thu, 19 Jul 2001 07:07:06 -0400 (EDT)
Received: (qmail 21552 invoked by alias); 19 Jul 2001 10:53:45 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 21545 invoked by uid 200); 19 Jul 2001 10:53:43 -0000
Received: (qmail 21536 invoked from network); 19 Jul 2001 10:53:29 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jul 2001 10:53:29 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27485;
	Thu, 19 Jul 2001 07:03:23 -0400 (EDT)
Message-Id: <200107191103.HAA27485@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: seamoby@cdma-2000.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [seamoby] I-D ACTION:draft-westphal-seamoby-qos-relocate-00.txt
Date: Thu, 19 Jul 2001 07:03:23 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: Context Relocation of QoS Parameters in IP Networks
	Author(s)	: C. Westphal, C. Perkins et al.
	Filename	: draft-westphal-seamoby-qos-relocate-00.txt
	Pages		: 20
	Date		: 18-Jul-01
	
Seamless offering of Quality of Service (QoS) to a Mobile Node during
handovers is considered crucial for enabling a variety of application
services in the Mobile Internet.  In this document, we define the QoS
contexts and show how they could be transferred to enable seamless QoS
operation during handovers.  We introduce the notion of QoS Profile
Types and the associated QoS Profiles, which together constitute QoS
contexts, that facilitate QoS inter-operability among the pariticipating
access routers.  We also illustrate how these contexts can be used with
fast handover signaling.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-westphal-seamoby-qos-relocate-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-westphal-seamoby-qos-relocate-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-westphal-seamoby-qos-relocate-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010718141806.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-westphal-seamoby-qos-relocate-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-westphal-seamoby-qos-relocate-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010718141806.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-seamoby@diameter.org  Thu Jul 19 08:21:33 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11238
	for <seamoby-archive@odin.ietf.org>; Thu, 19 Jul 2001 08:21:32 -0400 (EDT)
Received: (qmail 24294 invoked by alias); 19 Jul 2001 12:07:17 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 24287 invoked by uid 200); 19 Jul 2001 12:07:15 -0000
Received: (qmail 24277 invoked from network); 19 Jul 2001 12:07:02 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jul 2001 12:07:03 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <3JV1KTTJ>; Thu, 19 Jul 2001 08:17:16 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484455C5@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: RE: [seamoby] Latest Seamoby (proposed) Agenda
Date: Thu, 19 Jul 2001 08:17:09 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Pat,

You left out "fish and chips" hunting.  80 minutes to spare????
Better throw a few "technology presentations" in there just 
to show we care, no? :-)

-pdn

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Wednesday, July 18, 2001 8:34 PM
> To: seamoby@cdma-2000.org
> Subject: [seamoby] Latest Seamoby (proposed) Agenda
> 
<snur>
> 
<snap>
> Adjourn (cookie hunting)
<snip>
> Adjourn (bar hunting)
<pluck>


From owner-seamoby@diameter.org  Thu Jul 19 09:21:07 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26575
	for <seamoby-archive@odin.ietf.org>; Thu, 19 Jul 2001 09:21:05 -0400 (EDT)
Received: (qmail 26600 invoked by alias); 19 Jul 2001 13:06:24 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26593 invoked by uid 200); 19 Jul 2001 13:06:22 -0000
Received: (qmail 26579 invoked by uid 500); 19 Jul 2001 13:06:07 -0000
Date: Thu, 19 Jul 2001 06:06:05 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: john.loughney@nokia.com
Cc: pcalhoun@diameter.org, seamoby@cdma-2000.org
Subject: Re: [seamoby] Latest Seamoby (proposed) Agenda
Message-ID: <20010719060604.A26500@charizard.diameter.org>
Mail-Followup-To: john.loughney@nokia.com, pcalhoun@diameter.org,
	seamoby@cdma-2000.org
References: <0C1353ABB1DEB74DB067ADFF749C4EEF0940AD@esebe004.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0C1353ABB1DEB74DB067ADFF749C4EEF0940AD@esebe004.NOE.Nokia.com>; from john.loughney@nokia.com on Thu, Jul 19, 2001 at 09:39:46AM +0300
Sender: owner-seamoby@diameter.org
Precedence: bulk

We need to get through our current set of issues, and I'll be updating the 
CT issues list tomorrow. For those on the list, I think we all know the ones
we need to discuss. 

If you think that you have 2 slides, let me know, but I will limit time. This
is an open discussion, but will permit someone to "kick off" a particular topic.

Also, I was reminded that 60 minutes of the second session is reserved for the
MORE BOF. I somehow forgot that since it wasn't on the final agenda. So, we
are down to 20 mins on the  second slot.

PatC
On Thu, Jul 19, 2001 at 09:39:46AM +0300, john.loughney@nokia.com wrote:
> Hi Pat,
> 
> A quick question:
> 
> > Monday August 6th
> > 
> > 1300-1500
> > 
> > Agenda Bashing                                  Chair           5 mins
> > Update on WG documents                          Chair         
> >   10 mins
> > Milestone Review                                Chair         
> >   10 mins
> > Context Transfer Requirements Discussions       All           
> >   95 mins
> 
> We have 95 minutes allocated for CT reqs (presented by all).  How do
> you intend to handle this?  If someone had 2 or 3 slides for a specific
> issue, could that be considered part of this 95 minutes?
> 
> best regards,
> John


From owner-seamoby@diameter.org  Thu Jul 19 09:32:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29443
	for <seamoby-archive@odin.ietf.org>; Thu, 19 Jul 2001 09:32:09 -0400 (EDT)
Received: (qmail 26759 invoked by alias); 19 Jul 2001 13:08:12 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26744 invoked by uid 200); 19 Jul 2001 13:08:01 -0000
Received: (qmail 26723 invoked by uid 500); 19 Jul 2001 13:07:45 -0000
Date: Thu, 19 Jul 2001 06:07:45 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: [seamoby] Latest Seamoby (proposed) Agenda
Message-ID: <20010719060745.B26500@charizard.diameter.org>
Mail-Followup-To: Phillip Neumiller <PNeumiller@MeshNetworks.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>, seamoby@cdma-2000.org
References: <0DF9FBC42474A24CA50F7A27FB08E0484455C5@meshpdc.meshnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <0DF9FBC42474A24CA50F7A27FB08E0484455C5@meshpdc.meshnetworks.com>; from PNeumiller@MeshNetworks.com on Thu, Jul 19, 2001 at 08:17:09AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Thu, Jul 19, 2001 at 08:17:09AM -0400, Phillip Neumiller wrote:
> You left out "fish and chips" hunting.  

I suspect pubs will be easier to find than fish and chips, but replace
bar with your favorite destination :)

> 80 minutes to spare????
> Better throw a few "technology presentations" in there just 
> to show we care, no? :-)

As I mentioned in another e-mail, we were asked some time back to reserve
60 minutes for the MORE BOF, so we are down to 20 mins.

PatC


From owner-seamoby@diameter.org  Thu Jul 19 18:00:47 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25576
	for <seamoby-archive@odin.ietf.org>; Thu, 19 Jul 2001 18:00:46 -0400 (EDT)
Received: (qmail 11334 invoked by alias); 19 Jul 2001 21:45:33 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 11327 invoked by uid 200); 19 Jul 2001 21:45:30 -0000
Received: (qmail 11309 invoked from network); 19 Jul 2001 21:45:17 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 19 Jul 2001 21:45:17 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23877;
	Thu, 19 Jul 2001 17:55:00 -0400 (EDT)
Message-Id: <200107192155.RAA23877@ietf.org>
To: IETF-Announce: ;
Cc: RFC Editor <rfc-editor@isi.edu>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: seamoby@cdma-2000.org
From: The IESG <iesg-secretary@ietf.org>
Subject: [seamoby] Document Action: Requirements for an IP Mobile Node Alerting
	 Protocol to Informational
Date: Thu, 19 Jul 2001 17:55:00 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk



The IESG has approved the Internet-Draft 'Requirements for an IP Mobile
Node Alerting Protocol' <draft-ietf-seamoby-paging-requirements-01.txt>
as an Informational RFC.  This document is the product of the Context
Transfer, Handoff Candidate Discovery and Dormant Mode Host Alerting
Working Group.  The IESG contact persons are Allison Mankin and Scott
Bradner.



From owner-seamoby@diameter.org  Fri Jul 20 06:38:01 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21155
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 06:37:59 -0400 (EDT)
Received: (qmail 25611 invoked by alias); 20 Jul 2001 10:26:45 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 25605 invoked by uid 200); 20 Jul 2001 10:26:45 -0000
Received: (qmail 25600 invoked from network); 20 Jul 2001 10:26:43 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jul 2001 10:26:43 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20977;
	Fri, 20 Jul 2001 06:36:44 -0400 (EDT)
Message-Id: <200107201036.GAA20977@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: seamoby@cdma-2000.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [seamoby] I-D ACTION:draft-pagtzis-seamoby-proactivev6-00.txt,.ps
Date: Fri, 20 Jul 2001 06:36:44 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: A Framework for Seamless Proactive Mobility in Mobile 
                          IPv6
	Author(s)	: T. Pagtzis, P. Kirstein
	Filename	: draft-pagtzis-seamoby-proactivev6-00.txt,.ps
	Pages		: 
	Date		: 17-Jul-01
	
This document specifies a scheme to provide support for seamless
proactive mobility  for IPv6.  It encompasses a novel approach for seamless handoff and proactive roaming context transfer.  The latter establishes a generic method for proactive context transfer and manipulation of different classes of context relating to the state of IP connectivity for a mobile node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-pagtzis-seamoby-proactivev6-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010720063613.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-pagtzis-seamoby-proactivev6-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010720063613.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-seamoby@diameter.org  Fri Jul 20 07:03:04 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26870
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 07:03:03 -0400 (EDT)
Received: (qmail 26105 invoked by alias); 20 Jul 2001 10:51:55 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26099 invoked by uid 200); 20 Jul 2001 10:51:55 -0000
Received: (qmail 26094 invoked from network); 20 Jul 2001 10:51:54 -0000
Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176)
  by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jul 2001 10:51:54 -0000
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26723;
	Fri, 20 Jul 2001 07:01:55 -0400 (EDT)
Message-Id: <200107201101.HAA26723@ietf.org>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
CC: seamoby@cdma-2000.org
From: Internet-Drafts@ietf.org
Reply-to: Internet-Drafts@ietf.org
Subject: [seamoby] I-D ACTION:draft-pagtzis-seamoby-proactivev6-00.txt,.ps
Date: Fri, 20 Jul 2001 07:01:55 -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: A Framework for Seamless Proactive Mobility in Mobile 
                          IPv6
	Author(s)	: T. Pagtzis, P. Kirstein
	Filename	: draft-pagtzis-seamoby-proactivev6-00.txt,.ps
	Pages		: 
	Date		: 17-Jul-01
	
This document specifies a scheme to provide support for seamless
proactive mobility  for IPv6.  It encompasses a novel approach for seamless handoff and proactive roaming context transfer.  The latter establishes a generic method for proactive context transfer and manipulation of different classes of context relating to the state of IP connectivity for a mobile node.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-pagtzis-seamoby-proactivev6-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv@ietf.org.
In the body type:
	"FILE /internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="mailserv@ietf.org"

Content-Type: text/plain
Content-ID:	<20010720063613.I-D@ietf.org>

ENCODING mime
FILE /internet-drafts/draft-pagtzis-seamoby-proactivev6-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-pagtzis-seamoby-proactivev6-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<20010720063613.I-D@ietf.org>

--OtherAccess--

--NextPart--




From owner-seamoby@diameter.org  Fri Jul 20 10:20:29 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16491
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 10:20:28 -0400 (EDT)
Received: (qmail 27566 invoked by alias); 20 Jul 2001 14:09:13 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27560 invoked by uid 200); 20 Jul 2001 14:09:12 -0000
Received: (qmail 27551 invoked by uid 500); 20 Jul 2001 14:09:11 -0000
Date: Fri, 20 Jul 2001 07:09:11 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
Cc: Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: [seamoby] Paging Next Steps
Message-ID: <20010720070911.G14672@charizard.diameter.org>
Mail-Followup-To: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>,
	Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
References: <20010718131409.C1139@charizard.diameter.org> <3B58405C.A789A6B8@ccrle.nec.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B58405C.A789A6B8@ccrle.nec.de>; from Marco.Liebsch@ccrle.nec.de on Fri, Jul 20, 2001 at 04:29:48PM +0200
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Fri, Jul 20, 2001 at 04:29:48PM +0200, Marco Liebsch wrote:
> > 2. Each protocol submission must also include an accompanying
> >    I-D that compares the protocol against the requirements. For
> >    each requirement, the author must state whether the protocol
> >    complies to the requirements, and if so, how. Note that we aren't
> >    looking for a dissertation, but also not looking for empty claims.
> 
> I think having a separate I-D coming with each protocol proposal introduces a
> lot of overhead. The individual I-Ds on the protocols comformance to the
> requirements will probably lead to discussions on the mailing list anyway. So
> why not comparing the submissions directly on the list, initiated by the
> authors of the submissions sending an e-mail to the list with similar contents
> as you proposed to be in the extra I-D? 

Of course, that is one alternative. However, I have always found that
finding an internet draft is so much easier than having to plow through
archives. This is for nothing other than mere convenience.

As far as overhead, what kind of overhead are we talking about here? On
the part of the protocol submitter? The working group? In either case, the
protocol submitter has to put this list together. Adding the nroff (or pick
your favorite processor) is trivial compared to creating the protocol
specification. 

If you recall, the process I described would only leave one week to combine
all comparisons, so the easier it is on that editor, the better.

> I do not expect kind of 'ranking list'
> of protocols conformance to the requirements will help to design the seamoby
> paging protocol, but I expect to take over the best ideas and mechanism
> described in the different submissions and to merge them to a common proposal,
> which could be the basis for the seamoby protocol. What do you think?

Well, we will have to start somewhere. We can opt to start from scratch, and
pick features from individual protocol submissions, but I'm not sure that's
the quickest (and best approach). So, I suspect that if one protocol does 
seem favored by the WG, it would be the starting point. At that point, folks
may want to pull in features from other submissions.

Does that make sense?

> Having the meeting on paging in September or not should be fixed and notified
> as soon as possible in order to allow further plannings.

Of course, which is why I am initiating this discussion now.

> Do you really think
> it is good to have a combined meeting for CT and for paging? This would
> require strict plannings of an appropriate agenda. I would like to refer to
> James comment on having at least 2 -3 days in order to meet on paging.

Yes, it does make sense. This is one WG. However, we can split the work
such that the first couple of days is reserved for a particular topic (e.g. CT),
and the next couple of days for another.

As a chair, I much prefer this than to have 2 days in one location, followed
by another couple of days in another.

PatC


From owner-seamoby@diameter.org  Fri Jul 20 10:30:44 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19471
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 10:30:43 -0400 (EDT)
Received: (qmail 27068 invoked by alias); 20 Jul 2001 13:59:18 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27062 invoked by uid 200); 20 Jul 2001 13:59:18 -0000
Received: (qmail 27052 invoked from network); 20 Jul 2001 13:59:14 -0000
Received: from yamato.ccrle.nec.de (195.37.70.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jul 2001 13:59:14 -0000
Received: from wallace.heidelberg.ccrle.nec.de (root@wallace.heidelberg.ccrle.nec.de [192.168.102.1])
	by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f6KEAqb89228;
	Fri, 20 Jul 2001 16:10:52 +0200 (CEST)
Received: from ccrle.nec.de (judiciary.heidelberg.ccrle.nec.de [192.168.102.83])
	by wallace.heidelberg.ccrle.nec.de (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA12511;
	Fri, 20 Jul 2001 16:03:18 +0200
Message-ID: <3B58405C.A789A6B8@ccrle.nec.de>
Date: Fri, 20 Jul 2001 16:29:48 +0200
From: Marco Liebsch <Marco.Liebsch@ccrle.nec.de>
Organization: NEC Europe Ltd.
X-Mailer: Mozilla 4.6 [de] (WinNT; I)
X-Accept-Language: de
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>
CC: seamoby@cdma-2000.org
Subject: Re: [seamoby] Paging Next Steps
References: <20010718131409.C1139@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi all,

please see between the lines for comments.

Pat Calhoun schrieb:

> All,
>
> Now that the IESG has approved the paging (aka DMHA) requirements,
> we are now ready to proceed to the next phase. The milestones
> state that folks should be getting ready to submit their protocol
> to the WG for consideration.
>
> Here is a proposal on how to proceed:
>
> 1. Folks submit protocols by no later than September 14th.
> 2. Each protocol submission must also include an accompanying
>    I-D that compares the protocol against the requirements. For
>    each requirement, the author must state whether the protocol
>    complies to the requirements, and if so, how. Note that we aren't
>    looking for a dissertation, but also not looking for empty claims.

I think having a separate I-D coming with each protocol proposal introduces a
lot of overhead. The individual I-Ds on the protocols comformance to the
requirements will probably lead to discussions on the mailing list anyway. So
why not comparing the submissions directly on the list, initiated by the
authors of the submissions sending an e-mail to the list with similar contents
as you proposed to be in the extra I-D? I do not expect kind of 'ranking list'
of protocols conformance to the requirements will help to design the seamoby
paging protocol, but I expect to take over the best ideas and mechanism
described in the different submissions and to merge them to a common proposal,
which could be the basis for the seamoby protocol. What do you think?

>
> 3. Myself (or an appointed editor) will compile the list into a
>    single Internet Draft, which will be used to ease comparison. This
>    draft will be available on September 28th.
> 4. The document will be submitted to the WG, and a Last Call will be
>    made to make sure that the WG agrees with the comparison. WG Last
>    Call ends Oct 12th.
> 5. If there is a clear winner, then we begin protocol design based on
>    leading protocol. Otherwise, discussions within the WG will commence
>    to determine which protocol is best for our purposes. In either case,
>    the WG will not rubber stamp the protocol. Input from the WG will
>    be taken to ensure that the spec can withstand a WG Last Call.
>
> Our milestones show that we have a potential interim meeting in September.
> We can use this meeting for combined CT and paging work. Given the above,
> I believe that perhaps a meeting in mid October would make more sense
> for paging. At that time we would be at point 5 (above), which would
> really benefit from a face to face (assuming that there is no clear
> leading protocol).
>

Having the meeting on paging in September or not should be fixed and notified
as soon as possible in order to allow further plannings. Do you really think
it is good to have a combined meeting for CT and for paging? This would
require strict plannings of an appropriate agenda. I would like to refer to
James comment on having at least 2 -3 days in order to meet on paging.

>
> Thoughts?
>
> PatC

Have a nice weekend.

Regards,

Marco




From owner-seamoby@diameter.org  Fri Jul 20 12:02:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13396
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 12:02:36 -0400 (EDT)
Received: (qmail 28526 invoked by alias); 20 Jul 2001 15:51:21 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28520 invoked by uid 200); 20 Jul 2001 15:51:21 -0000
Received: (qmail 28515 invoked from network); 20 Jul 2001 15:51:19 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jul 2001 15:51:19 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA13273
	for <seamoby@cdma-2000.org>; Fri, 20 Jul 2001 10:02:15 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id JAA12062;
	Fri, 20 Jul 2001 09:02:15 -0700 (PDT)
Message-Id: <200107201602.JAA12062@heliopolis.eng.sun.com>
Date: Fri, 20 Jul 2001 09:02:15 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: RE: [seamoby] Re: [mobile-ip] Comments on:  I-D ACTION:draft-many folks-l2-mobilereq-00.txt
To: mobile-ip@sunroof.eng.sun.com, seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: EJf47Ekc2LIIGpqHUeHnZg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

George,

>The AP *may* have an IP address if it is engaged in, say, IAPP like
>traffic to propogate L2 trigger information. At that point, it
>is acting like an IP host.
>
>I agree that, on a particular IP entity identified as a target,
>the IP stack is the recepient of the trigger. 
>
>Does this correspond to what you are saying?
>
>GT> Hmmm...you see that is what I do not like about this...I would much
>better prefer not to refer to APs in this way...The L2 triggers always go to
>an IP router or a host as you said...if one wants to implement an IP host in
>an AP then as far as this mechanism goes this is an IP host (not an AP!).
>The reason I am fussy about this is that any IETF mechanism/protocol should
>be designed for the clear architectural case so it is correct...then it can
>be implemented in whatever way fits the specific scenario. The other way
>never works quit so well...So, lets just define the API and let people
>implement it the way they need...you can even give the AP case as an
>example...
>

I agree that the trigger ends up on the IP stack of the AR. The AP is
the generating agent for the trigger, not the recipient. The table
is confusing, I'll change it.

>GT> I fully agree that CT should not be tight to one single mobility
>protocol but I also think the API described in this spec should not be
>either...these are *generic* triggers "I am coming from there"...or "I am
>going there"...some of them not even mobility specific i.e.: "link up",
>"link down"....These have nothing to do with any particular mobility
>protocol and some of them can be used by non mobility protocols...So, I
>think we should start the opposite way...assume they are the same triggers
>until you find a strong reason why CT needs its own specific triggers.
>Otherwise protocol X will also come later on and demand its own specific
>triggers => no good....
>

Actually, the spec is not describing an API, it is describing requirements.
There is a separate spec in preparation for the API. As such, the
requirements in Section 6.2 reflect those that come out of the CT discussion.
The requirements are formulated as descriptions of abstract triggers.
I agree that an API should consolodate the trigger descriptions so
that only a single set appears, but they reflect the requirements
from all the areas.

One area that wasn't discussed in the paper is header compression. 
There may also be requirements for header compression, I hope perhaps
to have an opportunity to speak with the ROHC folks in London on it.


>P.S.: BTW, I am a bit confused with the seamoby list...you use the
>seamoby@cdma-2000.org address...but when I go to though this is
>seamoby@diameter.org...is this an alias of the same list?

It's the same alias.

		jak



From owner-seamoby@diameter.org  Fri Jul 20 14:30:17 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22602
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 14:30:16 -0400 (EDT)
Received: (qmail 29889 invoked by alias); 20 Jul 2001 18:19:07 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 29883 invoked by uid 200); 20 Jul 2001 18:19:07 -0000
Received: (qmail 29878 invoked from network); 20 Jul 2001 18:19:05 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jul 2001 18:19:05 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA16797;
	Fri, 20 Jul 2001 12:30:00 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA20322;
	Fri, 20 Jul 2001 11:30:01 -0700 (PDT)
Message-Id: <200107201830.LAA20322@heliopolis.eng.sun.com>
Date: Fri, 20 Jul 2001 11:30:01 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [seamoby] Paging Next Steps
To: seamoby@cdma-2000.org, pcalhoun@diameter.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 5nb4sUUSLdWC+daGrnh8Bw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Pat,

Did you also want to include the CT topic in a mid-October meeting, or
have that be separate? 

Again, I'll offer to have Sun host it, so we can get free room space.
Mid-October works fine.

		jak
		
>Delivered-To: seamoby-list@charizard.diameter.org
>Date: Wed, 18 Jul 2001 13:14:10 -0700
>From: Pat Calhoun <pcalhoun@diameter.org>
>To: seamoby@cdma-2000.org
>Subject: [seamoby] Paging Next Steps
>Mail-Followup-To: seamoby@cdma-2000.org
>Content-Disposition: inline
>User-Agent: Mutt/1.2.5i
>
>All,
>
>Now that the IESG has approved the paging (aka DMHA) requirements,
>we are now ready to proceed to the next phase. The milestones
>state that folks should be getting ready to submit their protocol
>to the WG for consideration.
>
>Here is a proposal on how to proceed:
>
>1. Folks submit protocols by no later than September 14th.
>2. Each protocol submission must also include an accompanying
>   I-D that compares the protocol against the requirements. For
>   each requirement, the author must state whether the protocol
>   complies to the requirements, and if so, how. Note that we aren't
>   looking for a dissertation, but also not looking for empty claims.
>3. Myself (or an appointed editor) will compile the list into a
>   single Internet Draft, which will be used to ease comparison. This
>   draft will be available on September 28th.
>4. The document will be submitted to the WG, and a Last Call will be
>   made to make sure that the WG agrees with the comparison. WG Last
>   Call ends Oct 12th.
>5. If there is a clear winner, then we begin protocol design based on
>   leading protocol. Otherwise, discussions within the WG will commence
>   to determine which protocol is best for our purposes. In either case,
>   the WG will not rubber stamp the protocol. Input from the WG will 
>   be taken to ensure that the spec can withstand a WG Last Call.
>
>Our milestones show that we have a potential interim meeting in September.
>We can use this meeting for combined CT and paging work. Given the above,
>I believe that perhaps a meeting in mid October would make more sense
>for paging. At that time we would be at point 5 (above), which would
>really benefit from a face to face (assuming that there is no clear
>leading protocol).
>
>Thoughts?
>
>PatC



From owner-seamoby@diameter.org  Fri Jul 20 16:23:37 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05653
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 16:23:36 -0400 (EDT)
Received: (qmail 30816 invoked by alias); 20 Jul 2001 20:12:08 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30810 invoked by uid 200); 20 Jul 2001 20:12:07 -0000
Received: (qmail 30801 invoked by uid 500); 20 Jul 2001 20:12:06 -0000
Date: Fri, 20 Jul 2001 13:12:06 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: James Kempf <James.Kempf@Sun.COM>
Cc: seamoby@cdma-2000.org, pcalhoun@diameter.org
Subject: Re: [seamoby] Paging Next Steps
Message-ID: <20010720131205.Q14672@charizard.diameter.org>
Mail-Followup-To: James Kempf <James.Kempf@Sun.COM>, seamoby@cdma-2000.org,
	pcalhoun@diameter.org
References: <200107201830.LAA20322@heliopolis.eng.sun.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <200107201830.LAA20322@heliopolis.eng.sun.com>; from James.Kempf@Sun.COM on Fri, Jul 20, 2001 at 11:30:01AM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

Yes, I'd like to include both CT and Paging in the mid-October timeframe
if the WG doesn't disagree with my proposed timing.

PatC
On Fri, Jul 20, 2001 at 11:30:01AM -0700, James Kempf wrote:
> Pat,
> 
> Did you also want to include the CT topic in a mid-October meeting, or
> have that be separate? 
> 
> Again, I'll offer to have Sun host it, so we can get free room space.
> Mid-October works fine.
> 
> 		jak
> 		
> >Delivered-To: seamoby-list@charizard.diameter.org
> >Date: Wed, 18 Jul 2001 13:14:10 -0700
> >From: Pat Calhoun <pcalhoun@diameter.org>
> >To: seamoby@cdma-2000.org
> >Subject: [seamoby] Paging Next Steps
> >Mail-Followup-To: seamoby@cdma-2000.org
> >Content-Disposition: inline
> >User-Agent: Mutt/1.2.5i
> >
> >All,
> >
> >Now that the IESG has approved the paging (aka DMHA) requirements,
> >we are now ready to proceed to the next phase. The milestones
> >state that folks should be getting ready to submit their protocol
> >to the WG for consideration.
> >
> >Here is a proposal on how to proceed:
> >
> >1. Folks submit protocols by no later than September 14th.
> >2. Each protocol submission must also include an accompanying
> >   I-D that compares the protocol against the requirements. For
> >   each requirement, the author must state whether the protocol
> >   complies to the requirements, and if so, how. Note that we aren't
> >   looking for a dissertation, but also not looking for empty claims.
> >3. Myself (or an appointed editor) will compile the list into a
> >   single Internet Draft, which will be used to ease comparison. This
> >   draft will be available on September 28th.
> >4. The document will be submitted to the WG, and a Last Call will be
> >   made to make sure that the WG agrees with the comparison. WG Last
> >   Call ends Oct 12th.
> >5. If there is a clear winner, then we begin protocol design based on
> >   leading protocol. Otherwise, discussions within the WG will commence
> >   to determine which protocol is best for our purposes. In either case,
> >   the WG will not rubber stamp the protocol. Input from the WG will 
> >   be taken to ensure that the spec can withstand a WG Last Call.
> >
> >Our milestones show that we have a potential interim meeting in September.
> >We can use this meeting for combined CT and paging work. Given the above,
> >I believe that perhaps a meeting in mid October would make more sense
> >for paging. At that time we would be at point 5 (above), which would
> >really benefit from a face to face (assuming that there is no clear
> >leading protocol).
> >
> >Thoughts?
> >
> >PatC
> 


From owner-seamoby@diameter.org  Fri Jul 20 18:12:23 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09698
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 18:12:22 -0400 (EDT)
Received: (qmail 18666 invoked by alias); 20 Jul 2001 22:01:17 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18659 invoked by uid 200); 20 Jul 2001 22:01:17 -0000
Received: (qmail 18653 invoked from network); 20 Jul 2001 22:01:14 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jul 2001 22:01:14 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA11808;
	Fri, 20 Jul 2001 16:12:11 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA01066;
	Fri, 20 Jul 2001 15:12:12 -0700 (PDT)
Message-Id: <200107202212.PAA01066@heliopolis.eng.sun.com>
Date: Fri, 20 Jul 2001 15:12:12 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [seamoby] Paging Next Steps
To: pcalhoun@diameter.org, Marco.Liebsch@ccrle.nec.de
Cc: seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: tlmQf3sMIBHFf+Aqya7zHQ==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Marco,

>
>I think having a separate I-D coming with each protocol proposal introduces a
>lot of overhead. The individual I-Ds on the protocols comformance to the
>requirements will probably lead to discussions on the mailing list anyway. So
>why not comparing the submissions directly on the list, initiated by the
>authors of the submissions sending an e-mail to the list with similar contents
>as you proposed to be in the extra I-D? I do not expect kind of 'ranking list'
>of protocols conformance to the requirements will help to design the seamoby
>paging protocol, but I expect to take over the best ideas and mechanism
>described in the different submissions and to merge them to a common proposal,
>which could be the basis for the seamoby protocol. What do you think?
>

Actually, I prefer to have the requriments tracability for the protocol
directly in the spec itself. That way, it becomes part of the linked
definition of the protocol. I also think the requirements tracability
should be in the ultimate RFC'ed protocol spec as well. Requirements
may change over time and if tracability is part of the spec, it is easier to 
return to the requirements if modifications are needed than to simply hack the
protocol.


>Having the meeting on paging in September or not should be fixed and notified
>as soon as possible in order to allow further plannings. Do you really think
>it is good to have a combined meeting for CT and for paging? This would
>require strict plannings of an appropriate agenda. I would like to refer to
>James comment on having at least 2 -3 days in order to meet on paging.
>

I agree with Pat that we should have both together because it is
one working group. Oct. 12 works, and I am prepared to get a room
at Sun for the meeting. I do think we will need at least 2 1/2 days
for the paging meeting (provided we get protocol proposals and
requirements tracability by then). How long will CT need?

		jak



From owner-seamoby@diameter.org  Fri Jul 20 18:25:53 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14592
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 18:25:52 -0400 (EDT)
Received: (qmail 19152 invoked by alias); 20 Jul 2001 22:14:51 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 19146 invoked by uid 200); 20 Jul 2001 22:14:51 -0000
Received: (qmail 19141 invoked from network); 20 Jul 2001 22:14:49 -0000
Received: from mercury.sun.com (192.9.25.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jul 2001 22:14:49 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA07181;
	Fri, 20 Jul 2001 15:25:47 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA01739;
	Fri, 20 Jul 2001 15:25:47 -0700 (PDT)
Message-Id: <200107202225.PAA01739@heliopolis.eng.sun.com>
Date: Fri, 20 Jul 2001 15:25:47 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [seamoby] Re: [seamoby-paging] ICMP destination dormant
To: pars.mutaf@inrialpes.fr
Cc: seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: Wh2mYO4qmgtEzI5QQO1zhA==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Pars,

Please don't use the seamoby-paging list. It is now defunct.

Regarding your suggestion, for multicast, I can't see any reason
for returning anything. Reliable multicast protocols have
floundered on this issue.

Regarding unicast, it might perhaps be useful to return some
indication that the mobile node is dormant if the packet
was rejected due to a filter. 

		jak

>Delivered-To: seamoby-paging-list@charizard.diameter.org
>Date: Fri, 20 Jul 2001 19:06:33 +0200
>From: Pars MUTAF <pars.mutaf@inrialpes.fr>
>CC: seamoby-paging@cdma-2000.org
>Subject: [seamoby-paging] ICMP destination dormant
>
>
>Hello all,
>
>The IP PAging Requirement "4.3. Control of Broadcast/
>Multicast/Anycast" requires a filtering mechanism for not
>awakening dormant mode hosts unnecessarily  (completely agreed
>with that).
>
>So, in those cases where a packet should not active a page,
>Should the paging agent return an ICMP destination uncreachable
>message? Or, the packet should be silently discarded?
>
>I had a look at the rfc on ICMPv6. Possible ICMP destination
>uncreachable codes are:
>
>0- no route to destination
>1- communication with destination administratively prohibited
>    (e.g., by a firewall)
>
>I think if we use one of those codes, the client may have a wrong
>idea about the situation. This may block his/her further attempts
>to reach the destination.
>
>So, a new code "destination dormant" or something like that
>would not be useful?
>
>Comments? Thank you...
>
>Regards,
>pars
>
>
>
>
>



From owner-seamoby@diameter.org  Fri Jul 20 19:07:20 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26276
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 19:07:19 -0400 (EDT)
Received: (qmail 19725 invoked by alias); 20 Jul 2001 22:55:50 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 19719 invoked by uid 200); 20 Jul 2001 22:55:49 -0000
Received: (qmail 19714 invoked from network); 20 Jul 2001 22:55:48 -0000
Received: from femail2.rdc1.on.home.com (24.2.9.89)
  by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jul 2001 22:55:48 -0000
Received: from cr851003a ([24.157.232.166]) by femail2.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010720230639.OONP16663.femail2.rdc1.on.home.com@cr851003a>;
          Fri, 20 Jul 2001 16:06:39 -0700
Message-ID: <001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com>
Reply-To: "Kulwinder Atwal" <katwal2200@home.com>
From: "Kulwinder Atwal" <katwal2200@home.com>
To: "James Kempf" <James.Kempf@Sun.COM>, <pars.mutaf@inrialpes.fr>
Cc: <seamoby@cdma-2000.org>
References: <200107202225.PAA01739@heliopolis.eng.sun.com>
Subject: Re: [seamoby] Re: [seamoby-paging] ICMP destination dormant
Date: Fri, 20 Jul 2001 19:06:54 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "James Kempf" <James.Kempf@Sun.COM>
To: <pars.mutaf@inrialpes.fr>
Cc: <seamoby@cdma-2000.org>
Sent: Friday, July 20, 2001 6:25 PM
Subject: [seamoby] Re: [seamoby-paging] ICMP destination dormant


> Pars,
>
> Please don't use the seamoby-paging list. It is now defunct.
>
> Regarding your suggestion, for multicast, I can't see any reason
> for returning anything. Reliable multicast protocols have
> floundered on this issue.

Actually, RFC 1122, page 39, states that error messages for IP broadcast and
IP multicast are disallowed to prevent "broadcast storms".

But since in IP paging, Multicast is used to deliver a "unicast" message,
the actual AR to which the MN is attached is not covered by the RFC 1122
restriction after it looks at the unicast message and realizes that the MN
is indeed attached.

Therefore, all of the ARs that the MN is NOT attached cannot send an error
message as this would certainly create a "broadcast storm" condition.

But, the AR that the MN IS attached is not creating a "broadcast storm"
condition, by responding with an error message, because it is the _only_ AR
that can respond.

In this instance, the reception of an error does not voilate intent of RFC
1122.

Further, RFC 2463, page 7, states that error code 3 (address unreachable)
should be used for stituations where the router entry is valid (MN is
attached), but for some other reason the packet cannot be forwarded.

RFC 2463:

"If the reason for the failure to deliver is lack of a matching entry
   in the forwarding node's routing table, the Code field is set to 0
   (NOTE: this error can occur only in nodes that do not hold a "default
   route" in their routing tables).

   If the reason for the failure to deliver is administrative
   prohibition, e.g., a "firewall filter", the Code field is set to 1.

   If there is any other reason for the failure to deliver, e.g.,
   inability to resolve the IPv6 destination address into a
   corresponding link address, or a link-specific problem of some sort,
   then the Code field is set to 3."

Therefore, the same error code ( error code = 3 ) can be returned for both
multicast and unicast.

- Kulwinder.

>
> Regarding unicast, it might perhaps be useful to return some
> indication that the mobile node is dormant if the packet
> was rejected due to a filter.
>
> jak
>
> >Delivered-To: seamoby-paging-list@charizard.diameter.org
> >Date: Fri, 20 Jul 2001 19:06:33 +0200
> >From: Pars MUTAF <pars.mutaf@inrialpes.fr>
> >CC: seamoby-paging@cdma-2000.org
> >Subject: [seamoby-paging] ICMP destination dormant
> >
> >
> >Hello all,
> >
> >The IP PAging Requirement "4.3. Control of Broadcast/
> >Multicast/Anycast" requires a filtering mechanism for not
> >awakening dormant mode hosts unnecessarily  (completely agreed
> >with that).
> >
> >So, in those cases where a packet should not active a page,
> >Should the paging agent return an ICMP destination uncreachable
> >message? Or, the packet should be silently discarded?
> >
> >I had a look at the rfc on ICMPv6. Possible ICMP destination
> >unc
    reachable codes are:
> >
> >0- no route to destination
> >1- communication with destination administratively prohibited
> >    (e.g., by a firewall)
> >
> >I think if we use one of those codes, the client may have a wrong
> >idea about the situation. This may block his/her further attempts
> >to reach the destination.
> >
> >So, a new code "destination dormant" or something like that
> >would not be useful?
> >
> >Comments? Thank you...
> >
> >Regards,
> >pars
> >
> >
> >
> >
> >
>



From owner-seamoby@diameter.org  Fri Jul 20 19:29:15 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05813
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 19:29:13 -0400 (EDT)
Received: (qmail 20406 invoked by alias); 20 Jul 2001 23:17:13 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20401 invoked by uid 200); 20 Jul 2001 23:17:12 -0000
Received: (qmail 20395 invoked from network); 20 Jul 2001 23:17:08 -0000
Received: from thumper.research.telcordia.com (128.96.41.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 20 Jul 2001 23:17:08 -0000
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f6KNRRm08511;
	Fri, 20 Jul 2001 19:27:27 -0400 (EDT)
Received: from tuna.research.telcordia.com (ohba@tari-dhcp5.research.telcordia.com [207.3.232.119])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id TAA03527;
	Fri, 20 Jul 2001 19:29:35 -0400 (EDT)
Date: Fri, 20 Jul 2001 20:27:05 -0400
Message-ID: <87bsmf1606.wl@tuna.research.telcordia.com>
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
To: "Kulwinder Atwal" <katwal2200@home.com>
Cc: "James Kempf" <James.Kempf@sun.com>, <pars.mutaf@inrialpes.fr>,
        <seamoby@cdma-2000.org>
Subject: Re: [seamoby] Re: [seamoby-paging] ICMP destination dormant
In-Reply-To: <001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com>
References: <200107202225.PAA01739@heliopolis.eng.sun.com>
	<001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com>
User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

At Fri, 20 Jul 2001 19:06:54 -0400,
Kulwinder Atwal wrote:
> 
> 
> ----- Original Message -----
> From: "James Kempf" <James.Kempf@Sun.COM>
> To: <pars.mutaf@inrialpes.fr>
> Cc: <seamoby@cdma-2000.org>
> Sent: Friday, July 20, 2001 6:25 PM
> Subject: [seamoby] Re: [seamoby-paging] ICMP destination dormant
> 
> 
> > Pars,
> >
> > Please don't use the seamoby-paging list. It is now defunct.
> >
> > Regarding your suggestion, for multicast, I can't see any reason
> > for returning anything. Reliable multicast protocols have
> > floundered on this issue.
> 
> Actually, RFC 1122, page 39, states that error messages for IP broadcast and
> IP multicast are disallowed to prevent "broadcast storms".
> 
> But since in IP paging, Multicast is used to deliver a "unicast" message,
> the actual AR to which the MN is attached is not covered by the RFC 1122
> restriction after it looks at the unicast message and realizes that the MN
> is indeed attached.

First, I don't think there is a requirement for using multicast to
deliver a unicast message.

> 
> Therefore, all of the ARs that the MN is NOT attached cannot send an error
> message as this would certainly create a "broadcast storm" condition.
> 
> But, the AR that the MN IS attached is not creating a "broadcast storm"
> condition, by responding with an error message, because it is the _only_ AR
> that can respond.

If there are multiple dormant hosts joins the same multicast, a sender
will still result in receiving multiple ICMP errors for each multicast
packet.  This is not desirable.

Yoshihiro Ohba

> 
> In this instance, the reception of an error does not voilate intent of RFC
> 1122.
> 
> Further, RFC 2463, page 7, states that error code 3 (address unreachable)
> should be used for stituations where the router entry is valid (MN is
> attached), but for some other reason the packet cannot be forwarded.
> 
> RFC 2463:
> 
> "If the reason for the failure to deliver is lack of a matching entry
>    in the forwarding node's routing table, the Code field is set to 0
>    (NOTE: this error can occur only in nodes that do not hold a "default
>    route" in their routing tables).
> 
>    If the reason for the failure to deliver is administrative
>    prohibition, e.g., a "firewall filter", the Code field is set to 1.
> 
>    If there is any other reason for the failure to deliver, e.g.,
>    inability to resolve the IPv6 destination address into a
>    corresponding link address, or a link-specific problem of some sort,
>    then the Code field is set to 3."
> 
> Therefore, the same error code ( error code = 3 ) can be returned for both
> multicast and unicast.
> 
> - Kulwinder.
> 
> >
> > Regarding unicast, it might perhaps be useful to return some
> > indication that the mobile node is dormant if the packet
> > was rejected due to a filter.
> >
> > jak
> >
> > >Delivered-To: seamoby-paging-list@charizard.diameter.org
> > >Date: Fri, 20 Jul 2001 19:06:33 +0200
> > >From: Pars MUTAF <pars.mutaf@inrialpes.fr>
> > >CC: seamoby-paging@cdma-2000.org
> > >Subject: [seamoby-paging] ICMP destination dormant
> > >
> > >
> > >Hello all,
> > >
> > >The IP PAging Requirement "4.3. Control of Broadcast/
> > >Multicast/Anycast" requires a filtering mechanism for not
> > >awakening dormant mode hosts unnecessarily  (completely agreed
> > >with that).
> > >
> > >So, in those cases where a packet should not active a page,
> > >Should the paging agent return an ICMP destination uncreachable
> > >message? Or, the packet should be silently discarded?
> > >
> > >I had a look at the rfc on ICMPv6. Possible ICMP destination
> > >unc
>     reachable codes are:
> > >
> > >0- no route to destination
> > >1- communication with destination administratively prohibited
> > >    (e.g., by a firewall)
> > >
> > >I think if we use one of those codes, the client may have a wrong
> > >idea about the situation. This may block his/her further attempts
> > >to reach the destination.
> > >
> > >So, a new code "destination dormant" or something like that
> > >would not be useful?
> > >
> > >Comments? Thank you...
> > >
> > >Regards,
> > >pars
> > >
> > >
> > >
> > >
> > >
> >
> 
> 


From owner-seamoby@diameter.org  Fri Jul 20 21:17:54 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11677
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 21:17:53 -0400 (EDT)
Received: (qmail 1745 invoked by alias); 21 Jul 2001 01:07:11 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 1739 invoked by uid 200); 21 Jul 2001 01:07:10 -0000
Received: (qmail 1734 invoked from network); 21 Jul 2001 01:07:09 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jul 2001 01:07:09 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id SAA22862
	for <seamoby@cdma-2000.org>; Fri, 20 Jul 2001 18:17:23 -0700 (PDT)
X-Delivered-For: <seamoby@cdma-2000.org>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6L1HNo11798
	for <seamoby@cdma-2000.org>; Fri, 20 Jul 2001 18:17:23 -0700
X-mProtect:  Fri, 20 Jul 2001 18:17:23 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdbbx19Q; Fri, 20 Jul 2001 18:17:21 PDT
Message-ID: <3B58D822.29222285@iprg.nokia.com>
Date: Fri, 20 Jul 2001 18:17:22 -0700
From: Rajeev Koodli <rajeev@IPRG.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@cdma-2000.org
Subject: [seamoby] Revised drafts
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



Hello folks,

we have revised the following drafts and submitted them to the working
group.

1. Context Transfer framework draft: describes authorized context
transfers and how they could be achieved with handovers.

Thanks to James Kempf and PatC for the comments.

2. Header Compression context relocation draft: uplink and downlink
context defintions, new-IP address extension and tunneling extensions
using [rohc] RTP framework.

Both the drafts can be accessed via http://people.nokia.net/~rajeev/

Comments welcome!

Regards,

-Rajeev






From owner-seamoby@diameter.org  Fri Jul 20 22:43:46 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11131
	for <seamoby-archive@odin.ietf.org>; Fri, 20 Jul 2001 22:43:42 -0400 (EDT)
Received: (qmail 2323 invoked by alias); 21 Jul 2001 02:32:06 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2317 invoked by uid 200); 21 Jul 2001 02:32:05 -0000
Received: (qmail 2312 invoked from network); 21 Jul 2001 02:32:04 -0000
Received: from femail2.rdc1.on.home.com (24.2.9.89)
  by c900656-a.plstn1.sfba.home.com with SMTP; 21 Jul 2001 02:32:04 -0000
Received: from cr851003a ([24.157.232.166]) by femail2.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010721024242.RMWZ16663.femail2.rdc1.on.home.com@cr851003a>;
          Fri, 20 Jul 2001 19:42:42 -0700
Message-ID: <006601c1118e$d9f62520$a6e89d18@slnt1.on.wave.home.com>
From: "Kulwinder Atwal" <katwal2200@home.com>
To: "Yoshihiro Ohba" <yohba@tari.toshiba.com>
Cc: "James Kempf" <James.Kempf@sun.com>, <pars.mutaf@inrialpes.fr>,
        <seamoby@cdma-2000.org>
References: <200107202225.PAA01739@heliopolis.eng.sun.com><001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com>
Subject: Re: [seamoby] Re: [seamoby-paging] ICMP destination dormant
Date: Fri, 20 Jul 2001 22:42:57 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Yoshihiro Ohba" <yohba@tari.toshiba.com>
To: "Kulwinder Atwal" <katwal2200@home.com>
Cc: "James Kempf" <James.Kempf@sun.com>; <pars.mutaf@inrialpes.fr>;
<seamoby@cdma-2000.org>
Sent: Friday, July 20, 2001 8:27 PM
Subject: Re: [seamoby] Re: [seamoby-paging] ICMP destination dormant


> At Fri, 20 Jul 2001 19:06:54 -0400,
> Kulwinder Atwal wrote:
> >
> >
> > ----- Original Message -----
> > From: "James Kempf" <James.Kempf@Sun.COM>
> > To: <pars.mutaf@inrialpes.fr>
> > Cc: <seamoby@cdma-2000.org>
> > Sent: Friday, July 20, 2001 6:25 PM
> > Subject: [seamoby] Re: [seamoby-paging] ICMP destination dormant
> >
> >
> > > Pars,
> > >
> > > Please don't use the seamoby-paging list. It is now defunct.
> > >
> > > Regarding your suggestion, for multicast, I can't see any reason
> > > for returning anything. Reliable multicast protocols have
> > > floundered on this issue.
> >
> > Actually, RFC 1122, page 39, states that error messages for IP broadcast
and
> > IP multicast are disallowed to prevent "broadcast storms".
> >
> > But since in IP paging, Multicast is used to deliver a "unicast"
message,
> > the actual AR to which the MN is attached is not covered by the RFC 1122
> > restriction after it looks at the unicast message and realizes that the
MN
> > is indeed attached.
>
> First, I don't think there is a requirement for using multicast to
> deliver a unicast message.
>
> >
> > Therefore, all of the ARs that the MN is NOT attached cannot send an
error
> > message as this would certainly create a "broadcast storm" condition.
> >
> > But, the AR that the MN IS attached is not creating a "broadcast storm"
> > condition, by responding with an error message, because it is the _only_
AR
> > that can respond.
>
> If there are multiple dormant hosts joins the same multicast, a sender
> will still result in receiving multiple ICMP errors for each multicast
> packet.  This is not desirable.

Not for every dormant host that joins the same multicast,  _only_ for the
small subset
that do not wish to be awakened.

It is not a "broadcast storm" if the message is sent at the time the Host
becomes dormant, instead of when a multicast packet is recieved.  Different
Hosts will become dormant asynchronously with respect to each other.

- Kulwinder.

>
> Yoshihiro Ohba
>
> >
> > In this instance, the reception of an error does not voilate intent of
RFC
> > 1122.
> >
> > Further, RFC 2463, page 7, states that error code 3 (address
unreachable)
> > should be used for stituations where the router entry is valid (MN is
> > attached), but for some other reason the packet cannot be forwarded.
> >
> > RFC 2463:
> >
> > "If the reason for the failure to deliver is lack of a matching entry
> >    in the forwarding node's routing table, the Code field is set to 0
> >    (NOTE: this error can occur only in nodes that do not hold a "default
> >    route" in their routing tables).
> >
> >    If the reason for the failure to deliver is administrative
> >    prohibition, e.g., a "firewall filter", the Code field is set to 1.
> >
> >    If there is any other reason for the failure to deliver, e.g.,
> >    inability to resolve the IPv6 destination address into a
> >    corresponding link address, or a link-specific problem of some sort,
> >    then the Code field is set to 3."
> >
> > Therefore, the same error code ( error code = 3 ) can be returned for
both
> > multicast and unicast.
> >
> > - Kulwinder.
> >
> > >
> > > Regarding unicast, it might perhaps be useful to return some
> > > indication that the mobile node is dormant if the packet
> > > was rejected due to a filter.
> > >
> > > jak
> > >
> > > >Delivered-To: seamoby-paging-list@charizard.diameter.org
> > > >Date: Fri, 20 Jul 2001 19:06:33 +0200
> > > >From: Pars MUTAF <pars.mutaf@inrialpes.fr>
> > > >CC: seamoby-paging@cdma-2000.org
> > > >Subject: [seamoby-paging] ICMP destination dormant
> > > >
> > > >
> > > >Hello all,
> > > >
> > > >The IP PAging Requirement "4.3. Control of Broadcast/
> > > >Multicast/Anycast" requires a filtering mechanism for not
> > > >awakening dormant mode hosts unnecessarily  (completely agreed
> > > >with that).
> > > >
> > > >So, in those cases where a packet should not active a page,
> > > >Should the paging agent return an ICMP destination uncreachable
> > > >message? Or, the packet should be silently discarded?
> > > >
> > > >I had a look at the rfc on ICMPv6. Possible ICMP destination
> > > >unc
> >     reachable codes are:
> > > >
> > > >0- no route to destination
> > > >1- communication with destination administratively prohibited
> > > >    (e.g., by a firewall)
> > > >
> > > >I think if we use one of those codes, the client may have a wrong
> > > >idea about the situation. This may block his/her further attempts
> > > >to reach the destination.
> > > >
> > > >So, a new code "destination dormant" or something like that
> > > >would not be useful?
> > > >
> > > >Comments? Thank you...
> > > >
> > > >Regards,
> > > >pars
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >



From owner-seamoby@diameter.org  Mon Jul 23 11:06:14 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27093
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 11:06:10 -0400 (EDT)
Received: (qmail 13901 invoked by alias); 23 Jul 2001 14:54:49 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 13895 invoked by uid 200); 23 Jul 2001 14:54:49 -0000
Received: (qmail 13890 invoked from network); 23 Jul 2001 14:54:47 -0000
Received: from ebene.inrialpes.fr (194.199.18.70)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 14:54:47 -0000
Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114])
	by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6NF2gB07434;
	Mon, 23 Jul 2001 17:02:43 +0200 (MEST)
Message-ID: <3B5C3D46.743D88CB@inrialpes.fr>
Date: Mon, 23 Jul 2001 17:05:42 +0200
From: Pars MUTAF <pars.mutaf@inrialpes.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Yoshihiro Ohba <yohba@tari.toshiba.com>
CC: Kulwinder Atwal <katwal2200@home.com>, James Kempf <James.Kempf@sun.com>,
        seamoby@cdma-2000.org
Subject: Re: [seamoby] ICMP destination dormant
References: <200107202225.PAA01739@heliopolis.eng.sun.com>
		<001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


James, Kulwinder, Yoshihiro, all;

Thanks for your precious comments.

However, the replies were too multicast-centered. Have I
missed something? This is already a requirement?

Secondly, I don't understand why broadcast storms is an issue.
I suggest that an "agent" filters the correspondent node's
packet and returns an appropriate ICMP message. In this case
the packet is filtered before the page is initiated. As a result,
the ARs comprised in the paging area do not receive any page
packet.

For example, in HMIPv6HP such filtering can be done by the
PMAP. On the other hand, in LH-DMHA, this is the
"Paging Server".

Now, I formulate my question differently. Please take the
following scenario:

I'm pinging (ICMP echo) a dormant peer (in fact I don't know
whether it is dormant or not). A PMAP, Paging Server, or
whatever you call it, receives this packet. I'll call it a
"paging agent" in this e-mail.

At this point the paging agent should make a decision:
Should I page the dormant node for a ping packet? I think the
answer is CERTAINLY NOT. Paging a dormant node is costly
in terms of network bandwidth and battery power (i.e., wakes up
a mobile node). Ping is a diagnostic tool thus it should not call
for battery consumption on the destination node.

So the paging agent doesn't page the destination dormant node
for my ping packets (i.e., filters them). At that point the paging
agent has the following alternatives:

A. Silently discard the packet.
B. Return an ICMP destination unreachable message.

Clearly, A is not acceptable. In this case my diagnostic tool ping
will not work. So, B: the paging agent should return an ICMP dest.
unreachable message. The following codes are available:

CODE 0- no route to destination: this would be PREMATURE,
i.e., we can't know that before paging the dormant node. There
are possibly other routers between the paging agent and the AR to
which the dormant host is attached.

CODE 1- communication with destination administratively
prohibited: this would be FALSE, because communication is not
prohibited. Other packets can pass. In fact, security is out of scope.
Ping is not an attack tool.

CODE 2- not assigned.

CODE 3- address unreachable: this again would be PREMATURE.
Such a message is returned when there is a route to the destination
link but the host attached to that link cannot be reached. For
example, its L2 address cannot be resolved etc... Again, we can't
know that before paging the dormant node.

CODE 4- port unreachable: Has nothing to do here.

Note that all codes described above are typically
used to report a network failure.

However, in our case we don't know about such a
failure. The destination host is in dormant mode (which
is quite normal) and we don't want to disturb it. I don't see
any network failure (hard or soft) here.

So, the paging agent should return an ICMP destination
dormant code? In this case I (the pinger) would have
a correct diagnosis and the dormant host (the pingee)
would not consume battery for nothing.

I hope that I've made myself clear.

Comments? Thank you...

pars

------------------------------------------
PS: I used the "ping" example for simplicity. This can be
generalized.



From owner-seamoby@diameter.org  Mon Jul 23 11:23:06 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28416
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 11:23:04 -0400 (EDT)
Received: (qmail 14687 invoked by alias); 23 Jul 2001 15:12:27 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 14679 invoked by uid 200); 23 Jul 2001 15:12:26 -0000
Received: (qmail 14670 invoked from network); 23 Jul 2001 15:12:24 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 15:12:24 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA12103;
	Mon, 23 Jul 2001 09:23:15 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA17488;
	Mon, 23 Jul 2001 08:23:16 -0700 (PDT)
Message-Id: <200107231523.IAA17488@heliopolis.eng.sun.com>
Date: Mon, 23 Jul 2001 08:23:15 -0700 (PDT)
From: James Kempf <James.Kempf@sun.com>
Reply-To: James Kempf <James.Kempf@sun.com>
Subject: Re: [seamoby] Re: [seamoby-paging] ICMP destination dormant
To: yohba@tari.toshiba.com, katwal2200@home.com
Cc: James.Kempf@sun.com, pars.mutaf@inrialpes.fr, seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: tGsfvORVmtci0ihhrJIYAg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

Kulwinder,

>>
>> If there are multiple dormant hosts joins the same multicast, a sender
>> will still result in receiving multiple ICMP errors for each multicast
>> packet.  This is not desirable.
>
>Not for every dormant host that joins the same multicast,  _only_ for the
>small subset
>that do not wish to be awakened.
>
>It is not a "broadcast storm" if the message is sent at the time the Host
>becomes dormant, instead of when a multicast packet is recieved.  Different
>Hosts will become dormant asynchronously with respect to each other.
>
>

This is certainly possible and covered by the paging requirements.
The filters, however, which were the subject of Pars's question, 
are designed to filter dynamically.

		jak



From owner-seamoby@diameter.org  Mon Jul 23 11:56:27 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01354
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 11:56:15 -0400 (EDT)
Received: (qmail 15352 invoked by alias); 23 Jul 2001 15:41:28 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15345 invoked by uid 200); 23 Jul 2001 15:41:27 -0000
Received: (qmail 15340 invoked from network); 23 Jul 2001 15:41:25 -0000
Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 15:41:25 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6NFpL929327
	for <seamoby@cdma-2000.org>; Mon, 23 Jul 2001 11:51:21 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 23 Jul 2001 11:51:33 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMVSBQ7Q>; Mon, 23 Jul 2001 11:51:35 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E54@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Henrik Levkowetz'" <henrik@levkowetz.com>,
        seamoby <seamoby@cdma-2000.org>
Cc: Cedric Westphal <cedric@IPRG.nokia.com>
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Mon, 23 Jul 2001 11:51:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C1138F.593E22E0"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1138F.593E22E0
Content-Type: text/plain;
	charset="iso-8859-1"

Henrik:

  I agree with the comments concerning "modes of operation for the
protocol". The original intent was not to imply a modal protocol,
but clearly that has happened. Again, "proactive", and "reactive", are
attributes of the objective: which is context transfer.

  You (indirectly) suggest below that "proactive" and "reactive" are 
"capabilities" of ct. I prefer this term, and suggest that we revise
the requirement to talk about "capabilities" rather then "modes"
or "functions".

  I've added some comments below (indicated by the lines starting with
"**").

Gary

-----Original Message-----
From: Henrik Levkowetz [mailto:henrik@levkowetz.com]
Sent: July 16, 2001 04:25
To: seamoby
Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Cedric Westphal
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive


Cedric, Gary

	I find the background explanatory text very good but when you get
into describing the way the protocol will work, I see an assumption
sneaking in which I don't agree to, namely that the protocol will need
to have two _modes_ of operation.  Maybe it will, or maybe we will be
able to define / design the triggers and handling at the destination
in such a way that there really will be only one mode. But I think
it's premature to imply two modes, ... maybe you didn't really mean to?

	Anyway, I've suggested revised text inline, below.

	Best,
		Henrik

> 
> Hey,
> 
> Gary and myself have worked on a new proactive/reactive paragraph
> to explain requirements 4.4/4.5 and solve Issue #4, while keeping the
> same terminology.
> Here it is, please comment, thanks,
> 
> Cedric.
> -------------------------------------------------------------------------
> 
> 
> 4.4 The context transfer framework MUST support proactive context
transfer.
> 
> 4.5 The context transfer framework MUST support reactive context transfer.
> 
>    It is useful to consider two complementary, non exclusive
> modes of operation for context transfer:
> proactive and reactive.
> 
>    The context transfer process is said to be proactive when the required
> contexts are requested to be in place at the target AR  prior to the
arrival of
> MN's packet
> at target AR.
> 
>    With proactive context transfer, the idea is to make the context
available
> to an AR before it is needed. This means that the context is
> available at the AR before it is required to forward the first
> packet arrival in the MN's traffic. Proactive context transfer is
> coupled to mobile handover only by the requirement that the context
> be in place before the handover of the MN's traffic is complete.
> 
>    The context transfer is said to be reactive when it is not proactive.
> 
>    The idea is that in a reactive context transfer, no guarantee is made
as to
> when the context will be in place at newAR. The context transfer process
reacts
> to the handover, but has no control over or knowledge of the handover to
ensure
> that it is in places before the arrival of MN's packet at the target AR.
> Reactive context transfer is coupled to mobile handover only by the
requirement
> that some handover event is triggering the reaction. Reactive context
transfer
> completes as soon as possible, but its completion is independent of the
handover
> process.
> 
>    Depending upon the network configuration, the MN's velocity and the
behavior
> of the mobility solution, a reactive context transfer may or may not
complete
> quickly enough for the new forwarding AR to provide a consistent service
to
> the first packets of the re-directed traffic.
> 
>    In many situations there is no forewarning available of a handover
> and context transfer must be initiated simply because the
> re-direction of the MN's traffic is in progress and the AR needs the
> forwarding context immediately. Because of the physical constraints,
> these situations can  never be completely avoided. Thus, if context
> transfer is to be  performed at all, the fundamental mode of operation
> must be reactive.

.................................................. Thus, if context
transfer is to be performed at all, its fundamental function must be
reactive context transfer.

** I agree with the intent of this change, but not the proposed text.
** The fundamental function of ct is context transfer. I think calling
** "reactive" a "function" is worse then suggesting it is a "mode of
operation".

> 
>    The proactive mode of context transfer is an attempt to further

   The ability to transfer context proactively is an attempt to further
...

** Ahh, maybe you have hit upon it here: "proactive" and "reactive" are 
** "capabilities" of ct?

> reduce any disruption of the service provided to the MN's traffic by
> making the context available to an AR prior to it being needed for
> forwarding. This implies that some network event will occur at the IP
> level to indicate the potential for a handover, prior to the handover
> being initiated (c.f. requirements 4.1 and 4.2). This event would
> trigger a proactive context transfer if there is confidence the context
> transfer can complete before the arrival of MN's packet at the target AR.
> There can be no guarantee that this event will occur or that this
confidence
> will be acquired, and thus, a reactive context transfer is
> always required as a contingency.
> 
>    This also means that a context transfer that begins in proactive mode
> may, as a result of the MN moving or other changes to the wireless
> environment, be required to complete in reactive mode.  If the target
> AR stays the same, then the same proactive context transfer attempt
> should evolve into a reactive context transfer attempt.

   This also means that a context transfer that begins as a proactive
transfer
may, as a result of the MN moving or other changes to the wireless
environment, be required to complete as a reactive transfer.  If the target
AR stays the same, then the same proactive context transfer attempt
should evolve into a reactive context transfer attempt.

** With you up to the last sentence. If the target AR changes, will ct have
to
become reactive also? I do not understand the qualification.

> 
>    As the proactive mode of context transfer is an enhancement, there may
be
> situations where the reactive mode is considered a sufficient solution.
> While it is required that the context transfer protocol support proactive
> mode, its use is optional.

   As proactive context transfer is an enhancement, there may be
situations where reactive transfer is considered a sufficient solution.
While it is required that the context transfer protocol support proactive
context transfer, this ability may not always be implemented or used.
   <<<The last sentence limps a bit, I think. Maybe you'll find
      a better formulation that doesn't go into Modes. /Henrik>>>


------_=_NextPart_001_01C1138F.593E22E0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] New words for Req's 4.4reactive/4.5proactive</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Henrik:</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I agree with the comments concerning &quot;modes of operation for the</FONT>
<BR><FONT SIZE=2>protocol&quot;. The original intent was not to imply a modal protocol,</FONT>
<BR><FONT SIZE=2>but clearly that has happened. Again, &quot;proactive&quot;, and &quot;reactive&quot;, are</FONT>
<BR><FONT SIZE=2>attributes of the objective: which is context transfer.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; You (indirectly) suggest below that &quot;proactive&quot; and &quot;reactive&quot; are </FONT>
<BR><FONT SIZE=2>&quot;capabilities&quot; of ct. I prefer this term, and suggest that we revise</FONT>
<BR><FONT SIZE=2>the requirement to talk about &quot;capabilities&quot; rather then &quot;modes&quot;</FONT>
<BR><FONT SIZE=2>or &quot;functions&quot;.</FONT>
</P>

<P><FONT SIZE=2>&nbsp; I've added some comments below (indicated by the lines starting with &quot;**&quot;).</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Henrik Levkowetz [<A HREF="mailto:henrik@levkowetz.com">mailto:henrik@levkowetz.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: July 16, 2001 04:25</FONT>
<BR><FONT SIZE=2>To: seamoby</FONT>
<BR><FONT SIZE=2>Cc: Kenward, Gary [WDLN2:AN10:EXCH]; Cedric Westphal</FONT>
<BR><FONT SIZE=2>Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive</FONT>
</P>
<BR>

<P><FONT SIZE=2>Cedric, Gary</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>I find the background explanatory text very good but when you get</FONT>
<BR><FONT SIZE=2>into describing the way the protocol will work, I see an assumption</FONT>
<BR><FONT SIZE=2>sneaking in which I don't agree to, namely that the protocol will need</FONT>
<BR><FONT SIZE=2>to have two _modes_ of operation.&nbsp; Maybe it will, or maybe we will be</FONT>
<BR><FONT SIZE=2>able to define / design the triggers and handling at the destination</FONT>
<BR><FONT SIZE=2>in such a way that there really will be only one mode. But I think</FONT>
<BR><FONT SIZE=2>it's premature to imply two modes, ... maybe you didn't really mean to?</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Anyway, I've suggested revised text inline, below.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Best,</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>Henrik</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hey,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Gary and myself have worked on a new proactive/reactive paragraph</FONT>
<BR><FONT SIZE=2>&gt; to explain requirements 4.4/4.5 and solve Issue #4, while keeping the</FONT>
<BR><FONT SIZE=2>&gt; same terminology.</FONT>
<BR><FONT SIZE=2>&gt; Here it is, please comment, thanks,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Cedric.</FONT>
<BR><FONT SIZE=2>&gt; -------------------------------------------------------------------------</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 4.4 The context transfer framework MUST support proactive context transfer.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 4.5 The context transfer framework MUST support reactive context transfer.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; It is useful to consider two complementary, non exclusive</FONT>
<BR><FONT SIZE=2>&gt; modes of operation for context transfer:</FONT>
<BR><FONT SIZE=2>&gt; proactive and reactive.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; The context transfer process is said to be proactive when the required</FONT>
<BR><FONT SIZE=2>&gt; contexts are requested to be in place at the target AR&nbsp; prior to the arrival of</FONT>
<BR><FONT SIZE=2>&gt; MN's packet</FONT>
<BR><FONT SIZE=2>&gt; at target AR.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; With proactive context transfer, the idea is to make the context available</FONT>
<BR><FONT SIZE=2>&gt; to an AR before it is needed. This means that the context is</FONT>
<BR><FONT SIZE=2>&gt; available at the AR before it is required to forward the first</FONT>
<BR><FONT SIZE=2>&gt; packet arrival in the MN's traffic. Proactive context transfer is</FONT>
<BR><FONT SIZE=2>&gt; coupled to mobile handover only by the requirement that the context</FONT>
<BR><FONT SIZE=2>&gt; be in place before the handover of the MN's traffic is complete.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; The context transfer is said to be reactive when it is not proactive.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; The idea is that in a reactive context transfer, no guarantee is made as to</FONT>
<BR><FONT SIZE=2>&gt; when the context will be in place at newAR. The context transfer process reacts</FONT>
<BR><FONT SIZE=2>&gt; to the handover, but has no control over or knowledge of the handover to ensure</FONT>
<BR><FONT SIZE=2>&gt; that it is in places before the arrival of MN's packet at the target AR.</FONT>
<BR><FONT SIZE=2>&gt; Reactive context transfer is coupled to mobile handover only by the requirement</FONT>
<BR><FONT SIZE=2>&gt; that some handover event is triggering the reaction. Reactive context transfer</FONT>
<BR><FONT SIZE=2>&gt; completes as soon as possible, but its completion is independent of the handover</FONT>
<BR><FONT SIZE=2>&gt; process.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; Depending upon the network configuration, the MN's velocity and the behavior</FONT>
<BR><FONT SIZE=2>&gt; of the mobility solution, a reactive context transfer may or may not complete</FONT>
<BR><FONT SIZE=2>&gt; quickly enough for the new forwarding AR to provide a consistent service to</FONT>
<BR><FONT SIZE=2>&gt; the first packets of the re-directed traffic.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; In many situations there is no forewarning available of a handover</FONT>
<BR><FONT SIZE=2>&gt; and context transfer must be initiated simply because the</FONT>
<BR><FONT SIZE=2>&gt; re-direction of the MN's traffic is in progress and the AR needs the</FONT>
<BR><FONT SIZE=2>&gt; forwarding context immediately. Because of the physical constraints,</FONT>
<BR><FONT SIZE=2>&gt; these situations can&nbsp; never be completely avoided. Thus, if context</FONT>
<BR><FONT SIZE=2>&gt; transfer is to be&nbsp; performed at all, the fundamental mode of operation</FONT>
<BR><FONT SIZE=2>&gt; must be reactive.</FONT>
</P>

<P><FONT SIZE=2>.................................................. Thus, if context</FONT>
<BR><FONT SIZE=2>transfer is to be performed at all, its fundamental function must be</FONT>
<BR><FONT SIZE=2>reactive context transfer.</FONT>
</P>

<P><FONT SIZE=2>** I agree with the intent of this change, but not the proposed text.</FONT>
<BR><FONT SIZE=2>** The fundamental function of ct is context transfer. I think calling</FONT>
<BR><FONT SIZE=2>** &quot;reactive&quot; a &quot;function&quot; is worse then suggesting it is a &quot;mode of operation&quot;.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; The proactive mode of context transfer is an attempt to further</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; The ability to transfer context proactively is an attempt to further</FONT>
<BR><FONT SIZE=2>...</FONT>
</P>

<P><FONT SIZE=2>** Ahh, maybe you have hit upon it here: &quot;proactive&quot; and &quot;reactive&quot; are </FONT>
<BR><FONT SIZE=2>** &quot;capabilities&quot; of ct?</FONT>
</P>

<P><FONT SIZE=2>&gt; reduce any disruption of the service provided to the MN's traffic by</FONT>
<BR><FONT SIZE=2>&gt; making the context available to an AR prior to it being needed for</FONT>
<BR><FONT SIZE=2>&gt; forwarding. This implies that some network event will occur at the IP</FONT>
<BR><FONT SIZE=2>&gt; level to indicate the potential for a handover, prior to the handover</FONT>
<BR><FONT SIZE=2>&gt; being initiated (c.f. requirements 4.1 and 4.2). This event would</FONT>
<BR><FONT SIZE=2>&gt; trigger a proactive context transfer if there is confidence the context</FONT>
<BR><FONT SIZE=2>&gt; transfer can complete before the arrival of MN's packet at the target AR.</FONT>
<BR><FONT SIZE=2>&gt; There can be no guarantee that this event will occur or that this confidence</FONT>
<BR><FONT SIZE=2>&gt; will be acquired, and thus, a reactive context transfer is</FONT>
<BR><FONT SIZE=2>&gt; always required as a contingency.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; This also means that a context transfer that begins in proactive mode</FONT>
<BR><FONT SIZE=2>&gt; may, as a result of the MN moving or other changes to the wireless</FONT>
<BR><FONT SIZE=2>&gt; environment, be required to complete in reactive mode.&nbsp; If the target</FONT>
<BR><FONT SIZE=2>&gt; AR stays the same, then the same proactive context transfer attempt</FONT>
<BR><FONT SIZE=2>&gt; should evolve into a reactive context transfer attempt.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; This also means that a context transfer that begins as a proactive transfer</FONT>
<BR><FONT SIZE=2>may, as a result of the MN moving or other changes to the wireless</FONT>
<BR><FONT SIZE=2>environment, be required to complete as a reactive transfer.&nbsp; If the target</FONT>
<BR><FONT SIZE=2>AR stays the same, then the same proactive context transfer attempt</FONT>
<BR><FONT SIZE=2>should evolve into a reactive context transfer attempt.</FONT>
</P>

<P><FONT SIZE=2>** With you up to the last sentence. If the target AR changes, will ct have to</FONT>
<BR><FONT SIZE=2>become reactive also? I do not understand the qualification.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp; As the proactive mode of context transfer is an enhancement, there may be</FONT>
<BR><FONT SIZE=2>&gt; situations where the reactive mode is considered a sufficient solution.</FONT>
<BR><FONT SIZE=2>&gt; While it is required that the context transfer protocol support proactive</FONT>
<BR><FONT SIZE=2>&gt; mode, its use is optional.</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp; As proactive context transfer is an enhancement, there may be</FONT>
<BR><FONT SIZE=2>situations where reactive transfer is considered a sufficient solution.</FONT>
<BR><FONT SIZE=2>While it is required that the context transfer protocol support proactive</FONT>
<BR><FONT SIZE=2>context transfer, this ability may not always be implemented or used.</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp; &lt;&lt;&lt;The last sentence limps a bit, I think. Maybe you'll find</FONT>
<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a better formulation that doesn't go into Modes. /Henrik&gt;&gt;&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1138F.593E22E0--


From owner-seamoby@diameter.org  Mon Jul 23 12:05:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02072
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 12:05:23 -0400 (EDT)
Received: (qmail 15704 invoked by alias); 23 Jul 2001 15:48:42 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 15698 invoked by uid 200); 23 Jul 2001 15:48:41 -0000
Received: (qmail 15691 invoked from network); 23 Jul 2001 15:48:36 -0000
Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 15:48:36 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6NFwW900407
	for <seamoby@cdma-2000.org>; Mon, 23 Jul 2001 11:58:32 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 23 Jul 2001 11:58:37 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMVSBRD2>; Mon, 23 Jul 2001 11:58:39 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E55@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'tpagtzis@IPRG.nokia.com'" <tpagtzis@IPRG.nokia.com>,
        Emil Sturniolo <emils@netmotionwireless.com>
Cc: Cedric Westphal <cedric@IPRG.nokia.com>,
        Pat Calhoun <pcalhoun@diameter.org>, seamoby <seamoby@cdma-2000.org>
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Mon, 23 Jul 2001 11:58:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11390.564F9900"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11390.564F9900
Content-Type: text/plain;
	charset="iso-8859-1"

At one point, many, many moons ago, I tried to capture this issue
by suggesting that "the context essential to IP packet forwarding must
be in place". In my mind, this is the essence of the multi-phase ct
proposal - there is context that is required to support the forwarding
service for each packet, and there is other context that is important,
but not as imperative.

Anyhow, this is how I see the two concepts of "proactive/reactive" and
multiphase ct relate.

Gary


-----Original Message-----
From: Theo Pagtzis [mailto:tpagtzis@IPRG.nokia.com]
Sent: July 16, 2001 13:46
To: Emil Sturniolo
Cc: Cedric Westphal; Pat Calhoun; Kenward, Gary [WDLN2:AN10:EXCH];
seamoby
Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive


Hi Emil,

    While I would agree with the terminology over proactive context
transfer, I would have to disagree on the atomicity of tranfer with
respect to proactivity. Proactivity must not require that all context is
transfered to the new point of attachement. This is bound to be too
costly should the selection decision of the new CAR misses the correct
candidate; this is bound to be the case a lot until...something 'else' is
in place. More on that 'else' later.

The transfer of context must be bound by the context constituents that
are sufficient and necessary for the node to transit over a proactive
transition mode. This implies partial context existence in the new
candidate points of attachement. Partiality must not mean that something
critical for seamlessness is not in place in terms of context at the
CARs. Thus partial context transfer over proactive transition mode(s)
must imply a totality of context necessary to effect seamlessness.
Depending on what is considered as a seamlessness factor in each context
ontology, then the totality and partiality over transfer of a discrete
number of constituents in new CARs is defined accordingly.

I would like to expand the set of transition modes to the CT requirements
document by adding an extra transition mode. It can be found in
draft-pagtzis-mobileip-proactivev6-00.txt or ps file.

This is the transition mode of "forward reactive handoff". I personally
consider it as equally important since it provides the intermediate step
between a pure reactive and a pure proactive handoff.

I would appreciate the view of the constituency on this transition mode
for the purposes of context transfer.

Theo

UCL/ Mobile Systems


Emil Sturniolo wrote:

> Hi folks,
>         I just have one observation. From reading the new text:
>
> "This means that the context is available at the AR before it is
> required to forward the first
> packet arrival in the MN's traffic. Proactive context transfer is
> coupled to mobile handover only by the requirement that the context be
> in place before the handover of the MN's traffic is complete."
>
> My interpretation of this is that a "proactive context transfer" must
> be totally completed prior to HO. If one considers a multi-phasic
> transfer, and only enough context is transfer proactively to allow
> packet forwarding, but other ancillary information is subsequently
> communicated, I believe from the current definition that the
> completion of this transfer is deemed a "reactive process". I am fine
> with this distinction,  but I would like to see it be specifically
> stated rather then just implied. Alternatively, we could change the
> text slightly to account for this case and still allow it to be a
> completed within the scope of a proactive transfer. Suggested text:
>
> "This means that enough of the context is available at the AR before
> it is required to process any of the MN's traffic. Proactive context
> transfer is coupled to mobile handover only by the prerequisite that
> elements of the context that enable packet forwarding be in place
> before the handover of the MN's traffic is complete."
>
> Comments?
>
> Cordially,
> Emil Sturniolo
> EmilS@NetMotionWireless.Com
> www.NetMotionWireless.com
> 330-723-9099
> 330-461-0326 - Mobile/Voice Mail
> =====================


------_=_NextPart_001_01C11390.564F9900
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] New words for Req's 4.4reactive/4.5proactive</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>At one point, many, many moons ago, I tried to capture this issue</FONT>
<BR><FONT SIZE=2>by suggesting that &quot;the context essential to IP packet forwarding must</FONT>
<BR><FONT SIZE=2>be in place&quot;. In my mind, this is the essence of the multi-phase ct</FONT>
<BR><FONT SIZE=2>proposal - there is context that is required to support the forwarding</FONT>
<BR><FONT SIZE=2>service for each packet, and there is other context that is important,</FONT>
<BR><FONT SIZE=2>but not as imperative.</FONT>
</P>

<P><FONT SIZE=2>Anyhow, this is how I see the two concepts of &quot;proactive/reactive&quot; and</FONT>
<BR><FONT SIZE=2>multiphase ct relate.</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Theo Pagtzis [<A HREF="mailto:tpagtzis@IPRG.nokia.com">mailto:tpagtzis@IPRG.nokia.com</A>]</FONT>
<BR><FONT SIZE=2>Sent: July 16, 2001 13:46</FONT>
<BR><FONT SIZE=2>To: Emil Sturniolo</FONT>
<BR><FONT SIZE=2>Cc: Cedric Westphal; Pat Calhoun; Kenward, Gary [WDLN2:AN10:EXCH];</FONT>
<BR><FONT SIZE=2>seamoby</FONT>
<BR><FONT SIZE=2>Subject: Re: [seamoby] New words for Req's 4.4reactive/4.5proactive</FONT>
</P>
<BR>

<P><FONT SIZE=2>Hi Emil,</FONT>
</P>

<P><FONT SIZE=2>&nbsp;&nbsp;&nbsp; While I would agree with the terminology over proactive context</FONT>
<BR><FONT SIZE=2>transfer, I would have to disagree on the atomicity of tranfer with</FONT>
<BR><FONT SIZE=2>respect to proactivity. Proactivity must not require that all context is</FONT>
<BR><FONT SIZE=2>transfered to the new point of attachement. This is bound to be too</FONT>
<BR><FONT SIZE=2>costly should the selection decision of the new CAR misses the correct</FONT>
<BR><FONT SIZE=2>candidate; this is bound to be the case a lot until...something 'else' is</FONT>
<BR><FONT SIZE=2>in place. More on that 'else' later.</FONT>
</P>

<P><FONT SIZE=2>The transfer of context must be bound by the context constituents that</FONT>
<BR><FONT SIZE=2>are sufficient and necessary for the node to transit over a proactive</FONT>
<BR><FONT SIZE=2>transition mode. This implies partial context existence in the new</FONT>
<BR><FONT SIZE=2>candidate points of attachement. Partiality must not mean that something</FONT>
<BR><FONT SIZE=2>critical for seamlessness is not in place in terms of context at the</FONT>
<BR><FONT SIZE=2>CARs. Thus partial context transfer over proactive transition mode(s)</FONT>
<BR><FONT SIZE=2>must imply a totality of context necessary to effect seamlessness.</FONT>
<BR><FONT SIZE=2>Depending on what is considered as a seamlessness factor in each context</FONT>
<BR><FONT SIZE=2>ontology, then the totality and partiality over transfer of a discrete</FONT>
<BR><FONT SIZE=2>number of constituents in new CARs is defined accordingly.</FONT>
</P>

<P><FONT SIZE=2>I would like to expand the set of transition modes to the CT requirements</FONT>
<BR><FONT SIZE=2>document by adding an extra transition mode. It can be found in</FONT>
<BR><FONT SIZE=2>draft-pagtzis-mobileip-proactivev6-00.txt or ps file.</FONT>
</P>

<P><FONT SIZE=2>This is the transition mode of &quot;forward reactive handoff&quot;. I personally</FONT>
<BR><FONT SIZE=2>consider it as equally important since it provides the intermediate step</FONT>
<BR><FONT SIZE=2>between a pure reactive and a pure proactive handoff.</FONT>
</P>

<P><FONT SIZE=2>I would appreciate the view of the constituency on this transition mode</FONT>
<BR><FONT SIZE=2>for the purposes of context transfer.</FONT>
</P>

<P><FONT SIZE=2>Theo</FONT>
</P>

<P><FONT SIZE=2>UCL/ Mobile Systems</FONT>
</P>
<BR>

<P><FONT SIZE=2>Emil Sturniolo wrote:</FONT>
</P>

<P><FONT SIZE=2>&gt; Hi folks,</FONT>
<BR><FONT SIZE=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I just have one observation. From reading the new text:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &quot;This means that the context is available at the AR before it is</FONT>
<BR><FONT SIZE=2>&gt; required to forward the first</FONT>
<BR><FONT SIZE=2>&gt; packet arrival in the MN's traffic. Proactive context transfer is</FONT>
<BR><FONT SIZE=2>&gt; coupled to mobile handover only by the requirement that the context be</FONT>
<BR><FONT SIZE=2>&gt; in place before the handover of the MN's traffic is complete.&quot;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; My interpretation of this is that a &quot;proactive context transfer&quot; must</FONT>
<BR><FONT SIZE=2>&gt; be totally completed prior to HO. If one considers a multi-phasic</FONT>
<BR><FONT SIZE=2>&gt; transfer, and only enough context is transfer proactively to allow</FONT>
<BR><FONT SIZE=2>&gt; packet forwarding, but other ancillary information is subsequently</FONT>
<BR><FONT SIZE=2>&gt; communicated, I believe from the current definition that the</FONT>
<BR><FONT SIZE=2>&gt; completion of this transfer is deemed a &quot;reactive process&quot;. I am fine</FONT>
<BR><FONT SIZE=2>&gt; with this distinction,&nbsp; but I would like to see it be specifically</FONT>
<BR><FONT SIZE=2>&gt; stated rather then just implied. Alternatively, we could change the</FONT>
<BR><FONT SIZE=2>&gt; text slightly to account for this case and still allow it to be a</FONT>
<BR><FONT SIZE=2>&gt; completed within the scope of a proactive transfer. Suggested text:</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; &quot;This means that enough of the context is available at the AR before</FONT>
<BR><FONT SIZE=2>&gt; it is required to process any of the MN's traffic. Proactive context</FONT>
<BR><FONT SIZE=2>&gt; transfer is coupled to mobile handover only by the prerequisite that</FONT>
<BR><FONT SIZE=2>&gt; elements of the context that enable packet forwarding be in place</FONT>
<BR><FONT SIZE=2>&gt; before the handover of the MN's traffic is complete.&quot;</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Comments?</FONT>
<BR><FONT SIZE=2>&gt;</FONT>
<BR><FONT SIZE=2>&gt; Cordially,</FONT>
<BR><FONT SIZE=2>&gt; Emil Sturniolo</FONT>
<BR><FONT SIZE=2>&gt; EmilS@NetMotionWireless.Com</FONT>
<BR><FONT SIZE=2>&gt; www.NetMotionWireless.com</FONT>
<BR><FONT SIZE=2>&gt; 330-723-9099</FONT>
<BR><FONT SIZE=2>&gt; 330-461-0326 - Mobile/Voice Mail</FONT>
<BR><FONT SIZE=2>&gt; =====================</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11390.564F9900--


From owner-seamoby@diameter.org  Mon Jul 23 12:10:50 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02570
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 12:10:49 -0400 (EDT)
Received: (qmail 16358 invoked by alias); 23 Jul 2001 15:59:23 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16349 invoked by uid 200); 23 Jul 2001 15:59:23 -0000
Received: (qmail 16343 invoked from network); 23 Jul 2001 15:59:21 -0000
Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 15:59:21 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6NG9F901639
	for <seamoby@cdma-2000.org>; Mon, 23 Jul 2001 12:09:15 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Mon, 23 Jul 2001 12:09:17 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMVSBRLS>; Mon, 23 Jul 2001 12:09:19 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E56@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] Latest Seamoby (proposed) Agenda
Date: Mon, 23 Jul 2001 12:09:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11391.D2F14F20"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11391.D2F14F20
Content-Type: text/plain;
	charset="iso-8859-1"



-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: July 19, 2001 09:08
To: Phillip Neumiller
Cc: 'Pat Calhoun'; seamoby@cdma-2000.org
Subject: Re: [seamoby] Latest Seamoby (proposed) Agenda


> On Thu, Jul 19, 2001 at 08:17:09AM -0400, Phillip Neumiller wrote:
> > You left out "fish and chips" hunting.  

> I suspect pubs will be easier to find than fish and chips, but replace
> bar with your favorite destination :)

The two are one and the same. An English pub without fish and chips. That
would be like the Queen without pomp and circumstance. It just isn't done
lad!

> > 80 minutes to spare????
> > Better throw a few "technology presentations" in there just 
> > to show we care, no? :-)

> As I mentioned in another e-mail, we were asked some time back to reserve
> 60 minutes for the MORE BOF, so we are down to 20 mins.

I will bring the deck of cards....

> PatC

Gary

------_=_NextPart_001_01C11391.D2F14F20
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] Latest Seamoby (proposed) Agenda</TITLE>
</HEAD>
<BODY>
<BR>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Pat Calhoun [<A HREF="mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]</FONT>
<BR><FONT SIZE=2>Sent: July 19, 2001 09:08</FONT>
<BR><FONT SIZE=2>To: Phillip Neumiller</FONT>
<BR><FONT SIZE=2>Cc: 'Pat Calhoun'; seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=2>Subject: Re: [seamoby] Latest Seamoby (proposed) Agenda</FONT>
</P>
<BR>

<P><FONT SIZE=2>&gt; On Thu, Jul 19, 2001 at 08:17:09AM -0400, Phillip Neumiller wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; You left out &quot;fish and chips&quot; hunting.&nbsp; </FONT>
</P>

<P><FONT SIZE=2>&gt; I suspect pubs will be easier to find than fish and chips, but replace</FONT>
<BR><FONT SIZE=2>&gt; bar with your favorite destination :)</FONT>
</P>

<P><FONT SIZE=2>The two are one and the same. An English pub without fish and chips. That</FONT>
<BR><FONT SIZE=2>would be like the Queen without pomp and circumstance. It just isn't done lad!</FONT>
</P>

<P><FONT SIZE=2>&gt; &gt; 80 minutes to spare????</FONT>
<BR><FONT SIZE=2>&gt; &gt; Better throw a few &quot;technology presentations&quot; in there just </FONT>
<BR><FONT SIZE=2>&gt; &gt; to show we care, no? :-)</FONT>
</P>

<P><FONT SIZE=2>&gt; As I mentioned in another e-mail, we were asked some time back to reserve</FONT>
<BR><FONT SIZE=2>&gt; 60 minutes for the MORE BOF, so we are down to 20 mins.</FONT>
</P>

<P><FONT SIZE=2>I will bring the deck of cards....</FONT>
</P>

<P><FONT SIZE=2>&gt; PatC</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11391.D2F14F20--


From owner-seamoby@diameter.org  Mon Jul 23 13:59:36 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11269
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 13:59:34 -0400 (EDT)
Received: (qmail 17122 invoked by alias); 23 Jul 2001 17:48:10 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 17116 invoked by uid 200); 23 Jul 2001 17:48:10 -0000
Received: (qmail 17111 invoked from network); 23 Jul 2001 17:48:08 -0000
Received: from 217.134.88.213.host.tele1europe.se (HELO mailgw.ipunplugged.com) (@213.88.134.217)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 17:48:08 -0000
Received: from Gioconda ([192.168.4.44])
	by mailgw.ipunplugged.com (8.9.3/8.9.3) with ESMTP id UAA30705;
	Mon, 23 Jul 2001 20:00:32 +0200
From: "Henrik Levkowetz" <henrik@ipunplugged.com>
To: "Gary Kenward" <gkenward@nortelnetworks.com>,
        "'Henrik Levkowetz'" <henrik@levkowetz.com>,
        "seamoby" <seamoby@cdma-2000.org>
Cc: "Cedric Westphal" <cedric@IPRG.nokia.com>
Subject: RE: [seamoby] New words for Req's 4.4reactive/4.5proactive
Date: Mon, 23 Jul 2001 19:58:46 +0200
Message-ID: <GMEEKDGLAJJFGAFEMMPIGEKCCEAA.henrik@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E54@zcard031.ca.nortel.com>
Importance: Normal
X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Gary,

There's a saying in Swedish which goes something like this:
  "Even a blind hen sometimes finds a seed."
i.e. I may have inadvertently hit upon something that makes sense :-) 

A few more words inline, below.

	Best, Henrik


Gary wrote:
> 
> 
> Henrik: 
> 
>   I agree with the comments concerning "modes of operation for the 
> protocol". The original intent was not to imply a modal protocol, 
> but clearly that has happened. Again, "proactive", and "reactive", are 
> attributes of the objective: which is context transfer. 
> 
>   You (indirectly) suggest below that "proactive" and "reactive" are 
> "capabilities" of ct. I prefer this term, and suggest that we revise 
> the requirement to talk about "capabilities" rather then "modes" 
> or "functions". 
> 
>   I've added some comments below (indicated by the lines starting with "**"). 
> 
> Gary 
> 

... <snip>

> >    In many situations there is no forewarning available of a handover 
> > and context transfer must be initiated simply because the 
> > re-direction of the MN's traffic is in progress and the AR needs the 
> > forwarding context immediately. Because of the physical constraints, 
> > these situations can  never be completely avoided. Thus, if context 
> > transfer is to be  performed at all, the fundamental mode of operation 
> > must be reactive. 
> 
> .................................................. Thus, if context 
> transfer is to be performed at all, its fundamental function must be 
> reactive context transfer. 
> 
> ** I agree with the intent of this change, but not the proposed text. 
> ** The fundamental function of ct is context transfer. I think calling 
> ** "reactive" a "function" is worse then suggesting it is a "mode of operation". 

Um, I think you right. If we don't end up implying fixed modes
further down, maybe 'mode' is the best choice here. Or maybe something
with capability, but a good formulation doesn't spring to mind.

> 
> > 
> >    The proactive mode of context transfer is an attempt to further 
> 
>    The ability to transfer context proactively is an attempt to further 
> ... 
> 
> ** Ahh, maybe you have hit upon it here: "proactive" and "reactive" are 
> ** "capabilities" of ct? 


Yes, it does make sense.

... <snip>

> >    This also means that a context transfer that begins in proactive mode 
> > may, as a result of the MN moving or other changes to the wireless 
> > environment, be required to complete in reactive mode.  If the target 
> > AR stays the same, then the same proactive context transfer attempt 
> > should evolve into a reactive context transfer attempt. 
> 
>    This also means that a context transfer that begins as a proactive transfer 
> may, as a result of the MN moving or other changes to the wireless 
> environment, be required to complete as a reactive transfer.  If the target 
> AR stays the same, then the same proactive context transfer attempt 
> should evolve into a reactive context transfer attempt. 
> 
> ** With you up to the last sentence. If the target AR changes, will ct have to 
> become reactive also? I do not understand the qualification. 

I agree fully. (Note that I haven't touched that last sentence...)

... <snip>

 


From owner-seamoby@diameter.org  Mon Jul 23 14:02:50 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11558
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 14:02:48 -0400 (EDT)
Received: (qmail 17339 invoked by alias); 23 Jul 2001 17:49:29 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 17332 invoked by uid 200); 23 Jul 2001 17:49:29 -0000
Received: (qmail 17326 invoked from network); 23 Jul 2001 17:49:27 -0000
Received: from hoemail2.lucent.com (HELO hoemail2.firewall.lucent.com) (192.11.226.163)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 17:49:27 -0000
Received: from nwmail.wh.lucent.com (h135-5-40-100.lucent.com [135.5.40.100])
	by hoemail2.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id f6NI0I001155
	for <seamoby@cdma-2000.org>; Mon, 23 Jul 2001 14:00:18 -0400 (EDT)
Received: by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA08696; Mon, 23 Jul 2001 14:00:14 -0400 (EDT)
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com>,
        Kulwinder Atwal <katwal2200@home.com>,
        James Kempf <James.Kempf@sun.com>, seamoby@cdma-2000.org
Received: from lucent.com by nwmail.wh.lucent.com (8.8.8+Sun/EMS-1.5 sol2)
	id OAA08663; Mon, 23 Jul 2001 14:00:06 -0400 (EDT)
Message-ID: <3B5C6628.63AA87D0@lucent.com>
Date: Mon, 23 Jul 2001 14:00:08 -0400
From: Erik Anderlind <eanderlind@lucent.com>
X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony}  (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Pars MUTAF <pars.mutaf@inrialpes.fr>
Original-CC: Yoshihiro Ohba <yohba@tari.toshiba.com>,
        Kulwinder Atwal <katwal2200@home.com>,
        James Kempf <James.Kempf@sun.com>, seamoby@cdma-2000.org
Subject: Re: [seamoby] ICMP destination dormant
References: <200107202225.PAA01739@heliopolis.eng.sun.com>
			<001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pars,
I think that in your scenario the paging server should not report an
error.
The route is routable to the paging server and since the paging sever 
locally makes the decision that it does not want to wake up the 
mobile, the paging server is currently the final destination of this
route.
(It acts as an agent on behalf of the mobile.)

From a corresponednt node' perspective, the path to the mobile is
routeable. When the 
dormant mobile needs to be wakened it can be determined if the 
mobile is still reachable on the segment mobile-to-paging_server.

I am not even sure a moible user would even want the correspondent node
to know
it is possibly using IP paging. (Privacy issues)
...Erik

Pars MUTAF wrote:
> 
> James, Kulwinder, Yoshihiro, all;
> 
> Thanks for your precious comments.
> 
> However, the replies were too multicast-centered. Have I
> missed something? This is already a requirement?
> 
> Secondly, I don't understand why broadcast storms is an issue.
> I suggest that an "agent" filters the correspondent node's
> packet and returns an appropriate ICMP message. In this case
> the packet is filtered before the page is initiated. As a result,
> the ARs comprised in the paging area do not receive any page
> packet.
> 
> For example, in HMIPv6HP such filtering can be done by the
> PMAP. On the other hand, in LH-DMHA, this is the
> "Paging Server".
> 
> Now, I formulate my question differently. Please take the
> following scenario:
> 
> I'm pinging (ICMP echo) a dormant peer (in fact I don't know
> whether it is dormant or not). A PMAP, Paging Server, or
> whatever you call it, receives this packet. I'll call it a
> "paging agent" in this e-mail.
> 
> At this point the paging agent should make a decision:
> Should I page the dormant node for a ping packet? I think the
> answer is CERTAINLY NOT. Paging a dormant node is costly
> in terms of network bandwidth and battery power (i.e., wakes up
> a mobile node). Ping is a diagnostic tool thus it should not call
> for battery consumption on the destination node.
> 
> So the paging agent doesn't page the destination dormant node
> for my ping packets (i.e., filters them). At that point the paging
> agent has the following alternatives:
> 
> A. Silently discard the packet.
> B. Return an ICMP destination unreachable message.
> 
> Clearly, A is not acceptable. In this case my diagnostic tool ping
> will not work. So, B: the paging agent should return an ICMP dest.
> unreachable message. The following codes are available:
> 
> CODE 0- no route to destination: this would be PREMATURE,
> i.e., we can't know that before paging the dormant node. There
> are possibly other routers between the paging agent and the AR to
> which the dormant host is attached.
> 
> CODE 1- communication with destination administratively
> prohibited: this would be FALSE, because communication is not
> prohibited. Other packets can pass. In fact, security is out of scope.
> Ping is not an attack tool.
> 
> CODE 2- not assigned.
> 
> CODE 3- address unreachable: this again would be PREMATURE.
> Such a message is returned when there is a route to the destination
> link but the host attached to that link cannot be reached. For
> example, its L2 address cannot be resolved etc... Again, we can't
> know that before paging the dormant node.
> 
> CODE 4- port unreachable: Has nothing to do here.
> 
> Note that all codes described above are typically
> used to report a network failure.
> 
> However, in our case we don't know about such a
> failure. The destination host is in dormant mode (which
> is quite normal) and we don't want to disturb it. I don't see
> any network failure (hard or soft) here.
> 
> So, the paging agent should return an ICMP destination
> dormant code? In this case I (the pinger) would have
> a correct diagnosis and the dormant host (the pingee)
> would not consume battery for nothing.
> 
> I hope that I've made myself clear.
> 
> Comments? Thank you...
> 
> pars
> 
> ------------------------------------------
> PS: I used the "ping" example for simplicity. This can be
> generalized.


From owner-seamoby@diameter.org  Mon Jul 23 16:46:28 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22423
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 16:46:26 -0400 (EDT)
Received: (qmail 18377 invoked by alias); 23 Jul 2001 20:35:16 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18371 invoked by uid 200); 23 Jul 2001 20:35:16 -0000
Received: (qmail 18366 invoked from network); 23 Jul 2001 20:35:14 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 20:35:14 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA11541
	for <seamoby@cdma-2000.org>; Mon, 23 Jul 2001 13:45:38 -0700 (PDT)
X-Delivered-For: <seamoby@cdma-2000.org>
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6NKjbQ00549
	for <seamoby@cdma-2000.org>; Mon, 23 Jul 2001 13:45:37 -0700
X-mProtect:  Mon, 23 Jul 2001 13:45:37 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpdvP7xBs; Mon, 23 Jul 2001 12:50:08 PDT
Message-ID: <3B5C7FF1.BA548ABD@iprg.nokia.com>
Date: Mon, 23 Jul 2001 12:50:09 -0700
From: Rajeev Koodli <rajeev@IPRG.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@cdma-2000.org
Subject: [seamoby] CT Applicability
Content-Type: multipart/mixed;
 boundary="------------15107F5A3C4F3388721795B4"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.
--------------15107F5A3C4F3388721795B4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



--------------15107F5A3C4F3388721795B4
Content-Type: message/rfc822
Content-Disposition: inline

X-Mozilla-Status2: 00000000
Message-ID: <3B5C6160.8882FB2F@iprg.nokia.com>
Date: Mon, 23 Jul 2001 10:39:44 -0700
From: Rajeev Koodli <rajeev@iprg.nokia.com>
Reply-To: rajeev.koodli@nokia.com
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@cdma-2000.org
Subject: CT Applicability
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Hello folks,

does anyone have any idea about the transport "constraints" for CT ? I
think this is important because, among others, it will determine the CT
applicability. Clearly we cannot expect CT to work in a MANET cloud (as
Vijay pointed out sometime ago) assuming pre-existing associations
between CT peers. How about Paging ? If I wish to transfer contexts
while alerting a dormant mode (e.g., using multicast), what transport
assumptions are necessary ? Comments ?

Driven by this thought, I have a proposal.

- we should focus on defining the context defintions (blobs) for
individual feature contexts
- we should identify, in detail, the requirements of individual contexts
and the associated protocol processing at CT peers. And,
- we must allow for using these context blobs in different environments,
e.g., including (but not limited to) handover signaling, paging, MANET
clouds, networks with any arbitrary topology..

Comments ?

Regards,

-Rajeev




--------------15107F5A3C4F3388721795B4--



From owner-seamoby@diameter.org  Mon Jul 23 17:46:47 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA26417
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 17:46:47 -0400 (EDT)
Received: (qmail 18946 invoked by alias); 23 Jul 2001 21:35:58 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18940 invoked by uid 200); 23 Jul 2001 21:35:58 -0000
Received: (qmail 18935 invoked by uid 500); 23 Jul 2001 21:35:56 -0000
Date: Mon, 23 Jul 2001 14:35:56 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: seamoby@cdma-2000.org
Subject: [seamoby] Final Seamoby Agenda
Message-ID: <20010723143556.O10225@charizard.diameter.org>
Mail-Followup-To: seamoby@cdma-2000.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-seamoby@diameter.org
Precedence: bulk

All,

Below is the final Seamoby Agenda. Please note that the first 60 minutes of
the Monday session is allocated to the MORE BOF, chaired by James Kempf and
Paul Reynolds.

Further, if your name appears below, you are on the hook to provide your
presentation material to me by no later than 7/30. I need to review the
material to ensure that it conforms to our discussion policy.

Monday August 6th

1300-1500

MORE BOF                                        Kempf/Reynold   60 mins
Agenda Bashing					Chair		 5 mins
Update on WG documents				Chair		10 mins
Milestone Review				Chair		10 mins
L2 Triggers and its relevance to Seamoby        Kempf            5 mins
  (draft-manyfolks-l2-mobilereq-00.txt)
Handoff Candidate Discovery Issues              HCD Authors     15 mins
  (draft-ietf-seamoby-CARdiscovery-issues-00.txt)
Proceeding on Paging (DMHA)			All		10 mins
Adjourn


Wednesday August 8th

1530-1730

CT Framework Issues                             Kenward         10 mins
  (draft-hamid-seamoby-ct-fwk-00.txt)
CT Applicability                                Koodli          10 mins
  (draft-koodli-seamoby-ctv6-00.txt)
Context Transfer Requirements Discussions	All		90 mins
  (draft-ietf-seamoby-ct-reqs-00.txt)
Closure/Next Steps				Chair		10 mins
Adjourn

Thanks,

PatC


From owner-seamoby@diameter.org  Mon Jul 23 18:04:30 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27136
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 18:04:29 -0400 (EDT)
Received: (qmail 19527 invoked by alias); 23 Jul 2001 21:53:37 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 19521 invoked by uid 200); 23 Jul 2001 21:53:37 -0000
Received: (qmail 19512 invoked by uid 500); 23 Jul 2001 21:53:35 -0000
Date: Mon, 23 Jul 2001 14:53:35 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Pars MUTAF <pars.mutaf@inrialpes.fr>
Cc: Yoshihiro Ohba <yohba@tari.toshiba.com>,
        Kulwinder Atwal <katwal2200@home.com>,
        James Kempf <James.Kempf@sun.com>, seamoby@cdma-2000.org
Subject: Re: [seamoby] ICMP destination dormant
Message-ID: <20010723145335.V10225@charizard.diameter.org>
Mail-Followup-To: Pars MUTAF <pars.mutaf@inrialpes.fr>,
	Yoshihiro Ohba <yohba@tari.toshiba.com>,
	Kulwinder Atwal <katwal2200@home.com>,
	James Kempf <James.Kempf@sun.com>, seamoby@cdma-2000.org
References: <200107202225.PAA01739@heliopolis.eng.sun.com> <001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B5C3D46.743D88CB@inrialpes.fr>; from pars.mutaf@inrialpes.fr on Mon, Jul 23, 2001 at 05:05:42PM +0200
Sender: owner-seamoby@diameter.org
Precedence: bulk

> I'm pinging (ICMP echo) a dormant peer (in fact I don't know
> whether it is dormant or not). A PMAP, Paging Server, or
> whatever you call it, receives this packet. I'll call it a
> "paging agent" in this e-mail.
> 

I'd like to know how the IP packet destined for a dormant peer was
received by the PMAP, which initiates your paging example.

PatC


From owner-seamoby@diameter.org  Mon Jul 23 18:33:47 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28413
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 18:33:45 -0400 (EDT)
Received: (qmail 20078 invoked by alias); 23 Jul 2001 22:22:34 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20072 invoked by uid 200); 23 Jul 2001 22:22:34 -0000
Received: (qmail 20067 invoked from network); 23 Jul 2001 22:22:31 -0000
Received: from patan.sun.com (192.18.98.43)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 22:22:31 -0000
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA23767
	for <seamoby@cdma-2000.org>; Mon, 23 Jul 2001 16:33:23 -0600 (MDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA09330
	for <seamoby@cdma-2000.org>; Mon, 23 Jul 2001 15:33:24 -0700 (PDT)
Message-Id: <200107232233.PAA09330@heliopolis.eng.sun.com>
Date: Mon, 23 Jul 2001 15:33:23 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [seamoby] Final Seamoby Agenda
To: seamoby@cdma-2000.org
MIME-Version: 1.0
Content-Type: MULTIPART/mixed; BOUNDARY=Descent_of_Woodpeckers_432_000
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-seamoby@diameter.org
Precedence: bulk

--Descent_of_Woodpeckers_432_000
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: qCnwwWDP2HwGRhDOGKBPWQ==

Attached is a description of the MORE BOF and an agenda. We would like
to use the bulk of the time to discuss mobile wireless service providers'
requirements for IETF protocols, though there are also a few presentations
on specific items. The requirements will be folded into an informational
RFC and circulated to the mobility related WGs. Paul Reynolds and I
will be co-chairing. Many thanx to Pat and Allison for helping get
this scheduled. 

		jak

--Descent_of_Woodpeckers_432_000
Content-Type: TEXT/plain; name="bof-description.txt"; charset=us-ascii; x-unix-mode=0664
Content-Description: bof-description.txt
Content-MD5: +Cik+lam/BFHKMnL8/ePxA==

For many years, individuals involved in ISPs have been an important component
of IETF, as they have brought experience and requirements to the task
of developing protocols for the Internet. Until recently, most ISPs
were involved in providing service through standard wired networks.
With the growth of the wireless Internet, the technology and business
of mobile operators are becoming more like that of an ISP and less like
that of a telephone company. Mobile operators have traditionally not had as 
close a relationship with the IETF. In this BOF, we would like to discuss 
the requirements from wireless ISPs presented in the recently released 
Internet Draft draft-reynolds-mobile-isp-requirements-00.txt. Many 
individuals are now coming to the IETF with requirements and suggestions 
for mobile networking protocol development. This BOF is an opportunity for
those who will have to deploy and offer Internet
services on wireless networks to present what they think the
requirements for the protocols to support those services should be,
and for equipment vendors, software developers, academic researchers, and
others involved in engineering and development of mobile networking
protocols to engage in a discussion about wireless ISP
requirements. The discussion in the BOF and on the MORE mailing list
will be folded into the draft, and the draft will be circulated
among interested working groups for development of IETF concensus,
before publishing as an Informational RFC.

--Descent_of_Woodpeckers_432_000
Content-Type: TEXT/plain; name="bof-agenda.txt"; charset=us-ascii; x-unix-mode=0664
Content-Description: bof-agenda.txt
Content-MD5: uCkw1UbTVcUrgcv5285T5w==

Introduction/Agenda Bashing (James Kempf, james.kempf@sun.com) - 5 min.

Discussion of issues from the mailing   
list regarding the draft (Paul Reynolds, paul.reynolds@orange.uk.co) - 5 min.

Application protocol requirements for
the mobile Internet (John  Waclawsky, jgw@cisco.com ) - 5 min.

Classification of requirements to working - 5 min.
groups (or other topic) (Atsushi Takeshita, takeshita@dcl.docomo-usa.com) 

Micro/macrocellular interaction requirements - 5 min.
(Rich Robinson, RRobin01@sprintspectrum.com)

Dynamic service negotiation requirements
(Jyh-Cheng Chen, jcchen@research.telcordia.com) - 10 min.

Discussion - 25 min.

--Descent_of_Woodpeckers_432_000--


From owner-seamoby@diameter.org  Mon Jul 23 18:54:11 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29199
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 18:54:11 -0400 (EDT)
Received: (qmail 20587 invoked by alias); 23 Jul 2001 22:43:06 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20581 invoked by uid 200); 23 Jul 2001 22:43:06 -0000
Received: (qmail 20575 invoked from network); 23 Jul 2001 22:43:04 -0000
Received: from mailhost.iprg.nokia.com (205.226.5.12)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 22:43:04 -0000
Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69])
	by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA12540;
	Mon, 23 Jul 2001 15:53:28 -0700 (PDT)
Received: (from root@localhost)
	by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6NMrRv14827;
	Mon, 23 Jul 2001 15:53:27 -0700
X-mProtect:  Mon, 23 Jul 2001 15:53:27 -0700 Nokia Silicon Valley Messaging Protection
Received: from rajeev.iprg.nokia.com (205.226.2.90, claiming to be "iprg.nokia.com")
	by darkstar.iprg.nokia.com(P1.5 smtpd8HKst5; Mon, 23 Jul 2001 15:49:44 PDT
Message-ID: <3B5CAA09.D0A642E4@iprg.nokia.com>
Date: Mon, 23 Jul 2001 15:49:45 -0700
From: Rajeev Koodli <rajeev@IPRG.nokia.com>
Organization: Nokia Research Center
X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>
CC: seamoby@cdma-2000.org
Subject: Re: [seamoby] Final Seamoby Agenda
References: <20010723143556.O10225@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Pat,

a small correction. Version 01 of the draft below should be considered for
discussion. It should be available from the IETF website. Otherwise it is
available from

http://people.nokia.net/~rajeev/draft-koodli-seamoby-ctv6-01.txt

Regards,

-Rajeev


Pat Calhoun wrote:

> All,
>
> Below is the final Seamoby Agenda. Please note that the first 60 minutes of
> the Monday session is allocated to the MORE BOF, chaired by James Kempf and
> Paul Reynolds.
>
> Further, if your name appears below, you are on the hook to provide your
> presentation material to me by no later than 7/30. I need to review the
> material to ensure that it conforms to our discussion policy.
>
> Monday August 6th
>
> 1300-1500
>
> MORE BOF                                        Kempf/Reynold   60 mins
> Agenda Bashing                                  Chair            5 mins
> Update on WG documents                          Chair           10 mins
> Milestone Review                                Chair           10 mins
> L2 Triggers and its relevance to Seamoby        Kempf            5 mins
>   (draft-manyfolks-l2-mobilereq-00.txt)
> Handoff Candidate Discovery Issues              HCD Authors     15 mins
>   (draft-ietf-seamoby-CARdiscovery-issues-00.txt)
> Proceeding on Paging (DMHA)                     All             10 mins
> Adjourn
>
> Wednesday August 8th
>
> 1530-1730
>
> CT Framework Issues                             Kenward         10 mins
>   (draft-hamid-seamoby-ct-fwk-00.txt)
> CT Applicability                                Koodli          10 mins
>   (draft-koodli-seamoby-ctv6-00.txt)
> Context Transfer Requirements Discussions       All             90 mins
>   (draft-ietf-seamoby-ct-reqs-00.txt)
> Closure/Next Steps                              Chair           10 mins
> Adjourn
>
> Thanks,
>
> PatC



From owner-seamoby@diameter.org  Mon Jul 23 19:21:54 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00467
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 19:21:52 -0400 (EDT)
Received: (qmail 21136 invoked by alias); 23 Jul 2001 23:10:56 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 21130 invoked by uid 200); 23 Jul 2001 23:10:56 -0000
Received: (qmail 21125 invoked from network); 23 Jul 2001 23:10:54 -0000
Received: from femail4.rdc1.on.home.com (24.2.9.91)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 23:10:54 -0000
Received: from cr851003a ([24.157.232.166]) by femail4.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010723232115.DUBW28246.femail4.rdc1.on.home.com@cr851003a>;
          Mon, 23 Jul 2001 16:21:15 -0700
Message-ID: <004501c113ce$38e66ae0$a6e89d18@slnt1.on.wave.home.com>
From: "Kulwinder Atwal" <katwal2200@home.com>
To: <rajeev.koodli@nokia.com>, <seamoby@cdma-2000.org>
References: <3B5C6160.8882FB2F@iprg.nokia.com>
Subject: [seamoby] Re: CT Applicability
Date: Mon, 23 Jul 2001 19:21:27 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Rajeev Koodli" <rajeev@iprg.nokia.com>
To: <seamoby@cdma-2000.org>
Sent: Monday, July 23, 2001 1:39 PM
Subject: CT Applicability


>
>
> Hello folks,
>
> does anyone have any idea about the transport "constraints" for CT ? I
> think this is important because, among others, it will determine the CT
> applicability.


> Clearly we cannot expect CT to work in a MANET cloud (as
> Vijay pointed out sometime ago) assuming pre-existing associations
> between CT peers.

I believe this statement does not allow for the development of more dynamic
stituations.
For example, the use of GSM CellPhone "SIM Card-like" credentials in a
mobile enviroment could provide dynamic security associations.

A more correct statement maybe:

CT requires an asscociation to exist between CT Peers prior to, and for the
duration of  the Context Transfer operation.  The creation and termination
of this assocation is out of scope of the Context Transfer Protocol.

Therefore, any solution (including a  MANET solution) must ensure that such
an association exists prior to initiating Context Transfer and for the
duration of the Context Transfer operation between CT peers.

- Kulwinder.

 How about Paging ? If I wish to transfer contexts
> while alerting a dormant mode (e.g., using multicast), what transport
> assumptions are necessary ? Comments ?
>
> Driven by this thought, I have a proposal.
>
> - we should focus on defining the context defintions (blobs) for
> individual feature contexts
> - we should identify, in detail, the requirements of individual contexts
> and the associated protocol processing at CT peers. And,
> - we must allow for using these context blobs in different environments,
> e.g., including (but not limited to) handover signaling, paging, MANET
> clouds, networks with any arbitrary topology..
>
> Comments ?
>
> Regards,
>
> -Rajeev
>
>
>
>



From owner-seamoby@diameter.org  Mon Jul 23 19:36:53 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01422
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 19:36:51 -0400 (EDT)
Received: (qmail 21649 invoked by alias); 23 Jul 2001 23:25:39 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 21643 invoked by uid 200); 23 Jul 2001 23:25:39 -0000
Received: (qmail 21638 invoked from network); 23 Jul 2001 23:25:37 -0000
Received: from mgw-dax2.ext.nokia.com (63.78.179.217)
  by c900656-a.plstn1.sfba.home.com with SMTP; 23 Jul 2001 23:25:37 -0000
Received: from davir01nok.americas.nokia.com (davir01nok.americas.nokia.com [172.18.242.84])
	by mgw-dax2.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f6NNavI08833
	for <seamoby@cdma-2000.org>; Mon, 23 Jul 2001 18:37:07 -0500 (CDT)
Received: from daebh001.NOE.Nokia.com (unverified) by davir01nok.americas.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T54ed78a11dac12f254079@davir01nok.americas.nokia.com>;
 Mon, 23 Jul 2001 18:35:58 -0500
content-class: urn:content-classes:message
Subject: [seamoby] RE: CT Applicability
Date: Mon, 23 Jul 2001 18:34:14 -0500
Message-ID: <B9CFA6CE8FFDD211A1FB0008C7894E4601A65BC0@bseis01nok>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Thread-Topic: CT Applicability
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Thread-Index: AcETztCfPMixDn+/EdWBSQBQi2X+DwAAJdEw
From: "Koodli Rajeev \(NRC/MtView\)" <rajeev.koodli@nokia.com>
To: "'ext Kulwinder Atwal'" <katwal2200@home.com>,
        "Koodli Rajeev \(NRC/MtView\)" <rajeev.koodli@nokia.com>,
        <seamoby@cdma-2000.org>
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id TAA01422


Kulwinder,


> 
> >
> >
> > Hello folks,
> >
> > does anyone have any idea about the transport "constraints" 
> for CT ? I
> > think this is important because, among others, it will 
> determine the CT
> > applicability.
> 
> 
> > Clearly we cannot expect CT to work in a MANET cloud (as
> > Vijay pointed out sometime ago) assuming pre-existing associations
> > between CT peers.
> 
> I believe this statement does not allow for the development 
> of more dynamic
> stituations.
> For example, the use of GSM CellPhone "SIM Card-like" credentials in a
> mobile enviroment could provide dynamic security associations.
> 

Well, I didn't mean security associations when I used the word
association. Perhaps I should have been explicit. I meant a transport
association, as in SCTP association.

In any case, the point is that if we require pre-existing transport
associations, we will restrict CT to those peers that have such
associations. Else, we need to make the case for creating such
associations dynamically.

Regards,

-Rajeev


> A more correct statement maybe:
> 
> CT requires an asscociation to exist between CT Peers prior 
> to, and for the
> duration of  the Context Transfer operation.  The creation 
> and termination
> of this assocation is out of scope of the Context Transfer Protocol.
> 
> Therefore, any solution (including a  MANET solution) must 
> ensure that such
> an association exists prior to initiating Context Transfer and for the
> duration of the Context Transfer operation between CT peers.
> 
> - Kulwinder.
> 
>  How about Paging ? If I wish to transfer contexts
> > while alerting a dormant mode (e.g., using multicast), what 
> transport
> > assumptions are necessary ? Comments ?
> >
> > Driven by this thought, I have a proposal.
> >
> > - we should focus on defining the context defintions (blobs) for
> > individual feature contexts
> > - we should identify, in detail, the requirements of 
> individual contexts
> > and the associated protocol processing at CT peers. And,
> > - we must allow for using these context blobs in different 
> environments,
> > e.g., including (but not limited to) handover signaling, 
> paging, MANET
> > clouds, networks with any arbitrary topology..
> >
> > Comments ?
> >
> > Regards,
> >
> > -Rajeev
> >
> >
> >
> >
> 


From owner-seamoby@diameter.org  Mon Jul 23 20:13:35 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03258
	for <seamoby-archive@odin.ietf.org>; Mon, 23 Jul 2001 20:13:32 -0400 (EDT)
Received: (qmail 22168 invoked by alias); 24 Jul 2001 00:01:40 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 22162 invoked by uid 200); 24 Jul 2001 00:01:39 -0000
Received: (qmail 22157 invoked from network); 24 Jul 2001 00:01:38 -0000
Received: from femail4.rdc1.on.home.com (24.2.9.91)
  by c900656-a.plstn1.sfba.home.com with SMTP; 24 Jul 2001 00:01:38 -0000
Received: from cr851003a ([24.157.232.166]) by femail4.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010724001212.FXXR28246.femail4.rdc1.on.home.com@cr851003a>;
          Mon, 23 Jul 2001 17:12:12 -0700
Message-ID: <005e01c113d5$5723a480$a6e89d18@slnt1.on.wave.home.com>
From: "Kulwinder Atwal" <katwal2200@home.com>
To: "Pars MUTAF" <pars.mutaf@inrialpes.fr>,
        "Yoshihiro Ohba" <yohba@tari.toshiba.com>
Cc: "James Kempf" <James.Kempf@sun.com>, <seamoby@cdma-2000.org>
References: <200107202225.PAA01739@heliopolis.eng.sun.com>	<001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr>
Subject: Re: [seamoby] ICMP destination dormant
Date: Mon, 23 Jul 2001 20:12:28 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Pars MUTAF" <pars.mutaf@inrialpes.fr>
To: "Yoshihiro Ohba" <yohba@tari.toshiba.com>
Cc: "Kulwinder Atwal" <katwal2200@home.com>; "James Kempf"
<James.Kempf@sun.com>; <seamoby@cdma-2000.org>
Sent: Monday, July 23, 2001 11:05 AM
Subject: Re: [seamoby] ICMP destination dormant


>
> James, Kulwinder, Yoshihiro, all;
>
> Thanks for your precious comments.
>
> However, the replies were too multicast-centered. Have I
> missed something? This is already a requirement?
>
> Secondly, I don't understand why broadcast storms is an issue.
> I suggest that an "agent" filters the correspondent node's
> packet and returns an appropriate ICMP message. In this case
> the packet is filtered before the page is initiated. As a result,
> the ARs comprised in the paging area do not receive any page
> packet.
>
> For example, in HMIPv6HP such filtering can be done by the
> PMAP. On the other hand, in LH-DMHA, this is the
> "Paging Server".
>
> Now, I formulate my question differently. Please take the
> following scenario:
>
> I'm pinging (ICMP echo) a dormant peer (in fact I don't know
> whether it is dormant or not). A PMAP, Paging Server, or
> whatever you call it, receives this packet. I'll call it a
> "paging agent" in this e-mail.
>
> At this point the paging agent should make a decision:
> Should I page the dormant node for a ping packet? I think the
> answer is CERTAINLY NOT. Paging a dormant node is costly
> in terms of network bandwidth and battery power (i.e., wakes up
> a mobile node). Ping is a diagnostic tool thus it should not call
> for battery consumption on the destination node.
>
> So the paging agent doesn't page the destination dormant node
> for my ping packets (i.e., filters them). At that point the paging
> agent has the following alternatives:
>
> A. Silently discard the packet.
> B. Return an ICMP destination unreachable message.
>
> Clearly, A is not acceptable. In this case my diagnostic tool ping
> will not work. So, B: the paging agent should return an ICMP dest.
> unreachable message. The following codes are available:
>
> CODE 0- no route to destination: this would be PREMATURE,
> i.e., we can't know that before paging the dormant node. There
> are possibly other routers between the paging agent and the AR to
> which the dormant host is attached.

It is not necessary to page the dormant node, this communication (or
communication error) is only between ARs.  It can be known if it is known
that the node was unreachable for the last page and had been 'unregistered'
for this paging area.  (That is until it re-associates with an AR).

This could happen if its battery died.


>
> CODE 1- communication with destination administratively
> prohibited: this would be FALSE, because communication is not
> prohibited. Other packets can pass. In fact, security is out of scope.
> Ping is not an attack tool.
>
> CODE 2- not assigned.
>
> CODE 3- address unreachable: this again would be PREMATURE.
> Such a message is returned when there is a route to the destination
> link but the host attached to that link cannot be reached. For
> example, its L2 address cannot be resolved etc... Again, we can't
> know that before paging the dormant node.


1. Again, this communication is between ARs only.  There is no need to wake
the dormant node.  The AR to which the node is atached can respond with this
error code.

2. Also, the AR to which the node is attached can notify the Paging Agent
that a particular node is now dormant.


>
> CODE 4- port unreachable: Has nothing to do here.
>
> Note that all codes described above are typically
> used to report a network failure.

Even if they are typically used in a slightly different manner, what is
important is whether they will cause a behaviour that is appropriate for IP
paging.

If equating Dormant Mode to Address Unreachable causes the network to behave
in a manner that we like, then it is just a matter of changing some ICMP
terminology to match our thinking.

- Kulwinder.

>
> However, in our case we don't know about such a
> failure. The destination host is in dormant mode (which
> is quite normal) and we don't want to disturb it. I don't see
> any network failure (hard or soft) here.
>
> So, the paging agent should return an ICMP destination
> dormant code? In this case I (the pinger) would have
> a correct diagnosis and the dormant host (the pingee)
> would not consume battery for nothing.
>
> I hope that I've made myself clear.
>
> Comments? Thank you...
>
> pars
>
> ------------------------------------------
> PS: I used the "ping" example for simplicity. This can be
> generalized.
>



From owner-seamoby@diameter.org  Tue Jul 24 08:42:11 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13862
	for <seamoby-archive@odin.ietf.org>; Tue, 24 Jul 2001 08:42:10 -0400 (EDT)
Received: (qmail 24574 invoked by alias); 24 Jul 2001 12:31:12 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 24568 invoked by uid 200); 24 Jul 2001 12:31:11 -0000
Received: (qmail 24563 invoked from network); 24 Jul 2001 12:31:10 -0000
Received: from ebene.inrialpes.fr (194.199.18.70)
  by c900656-a.plstn1.sfba.home.com with SMTP; 24 Jul 2001 12:31:10 -0000
Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114])
	by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6OCdNB26666
	for <seamoby@cdma-2000.org>; Tue, 24 Jul 2001 14:39:23 +0200 (MEST)
Message-ID: <3B5D6D32.D73B5DA@inrialpes.fr>
Date: Tue, 24 Jul 2001 14:42:26 +0200
From: Pars MUTAF <pars.mutaf@inrialpes.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: seamoby@cdma-2000.org
Subject: Re: [seamoby] ICMP destination dormant
References: <200107202225.PAA01739@heliopolis.eng.sun.com>
				<001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr> <3B5C6628.63AA87D0@lucent.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi Erik,

Thanks for your comments. So, you agree that the dormant
node should not be paged for an ICMP echo request?

You suggest that the paging agent silently discards the ping
packets? But, in this case we can't differentiate an operational mode
(where the dest. is simply dormant) from congestion or another
network problem. Am I wrong?

As for the privacy concerns, you are right this can be important.
But, in cellular systems mobiles are in dormant mode during ~90%
of time for saving battery. This quite normal. So I don't see any
private information here.

Another issue is security. You could say that an attacker can profit
from that information (ICMP host dormant message) to launch
attacks (as described in the paging-requirements draft). But my
answer would be the same as above: the proportion of dormant nodes
is very high. If I was an attacker I'd simply prefer to sent 100000s of
packets to a destination network without checking whether the
destinations are dormant or not.

regards,
pars



Erik Anderlind wrote:

> Hi Pars,
> I think that in your scenario the paging server should not report an
> error.
> The route is routable to the paging server and since the paging sever
> locally makes the decision that it does not want to wake up the
> mobile, the paging server is currently the final destination of this
> route.
> (It acts as an agent on behalf of the mobile.)
>
> >From a corresponednt node' perspective, the path to the mobile is
> routeable. When the
> dormant mobile needs to be wakened it can be determined if the
> mobile is still reachable on the segment mobile-to-paging_server.
>
> I am not even sure a moible user would even want the correspondent node
> to know
> it is possibly using IP paging. (Privacy issues)
> ...Erik



From owner-seamoby@diameter.org  Tue Jul 24 08:45:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14030
	for <seamoby-archive@odin.ietf.org>; Tue, 24 Jul 2001 08:45:37 -0400 (EDT)
Received: (qmail 25065 invoked by alias); 24 Jul 2001 12:35:01 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 25059 invoked by uid 200); 24 Jul 2001 12:35:01 -0000
Received: (qmail 25054 invoked from network); 24 Jul 2001 12:34:59 -0000
Received: from ebene.inrialpes.fr (194.199.18.70)
  by c900656-a.plstn1.sfba.home.com with SMTP; 24 Jul 2001 12:34:59 -0000
Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114])
	by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6OChBB26784;
	Tue, 24 Jul 2001 14:43:11 +0200 (MEST)
Message-ID: <3B5D6E17.56F96EBD@inrialpes.fr>
Date: Tue, 24 Jul 2001 14:46:15 +0200
From: Pars MUTAF <pars.mutaf@inrialpes.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>
CC: seamoby@cdma-2000.org
Subject: Re: [seamoby] ICMP destination dormant
References: <200107202225.PAA01739@heliopolis.eng.sun.com> <001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr> <20010723145335.V10225@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello,

I'm not the author of HMIPv6HP draft but I would
say just like in HMIPv6. I'm sorry if a made a mistake.

regards,
pars

Pat Calhoun wrote:

> > I'm pinging (ICMP echo) a dormant peer (in fact I don't know
> > whether it is dormant or not). A PMAP, Paging Server, or
> > whatever you call it, receives this packet. I'll call it a
> > "paging agent" in this e-mail.
> >
>
> I'd like to know how the IP packet destined for a dormant peer was
> received by the PMAP, which initiates your paging example.
>
> PatC





From owner-seamoby@diameter.org  Tue Jul 24 09:27:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16578
	for <seamoby-archive@odin.ietf.org>; Tue, 24 Jul 2001 09:27:37 -0400 (EDT)
Received: (qmail 25646 invoked by alias); 24 Jul 2001 13:16:35 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 25640 invoked by uid 200); 24 Jul 2001 13:16:35 -0000
Received: (qmail 25635 invoked from network); 24 Jul 2001 13:16:33 -0000
Received: from ebene.inrialpes.fr (194.199.18.70)
  by c900656-a.plstn1.sfba.home.com with SMTP; 24 Jul 2001 13:16:33 -0000
Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114])
	by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6ODOXB28211;
	Tue, 24 Jul 2001 15:24:34 +0200 (MEST)
Message-ID: <3B5D77C9.2C88E2BA@inrialpes.fr>
Date: Tue, 24 Jul 2001 15:27:37 +0200
From: Pars MUTAF <pars.mutaf@inrialpes.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Kulwinder Atwal <katwal2200@home.com>
CC: seamoby@cdma-2000.org
Subject: Re: [seamoby] ICMP destination dormant
References: <200107202225.PAA01739@heliopolis.eng.sun.com>	<001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr> <005e01c113d5$5723a480$a6e89d18@slnt1.on.wave.home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello Kulwinder;


> >
> > CODE 0- no route to destination: this would be PREMATURE,
> > i.e., we can't know that before paging the dormant node. There
> > are possibly other routers between the paging agent and the AR to
> > which the dormant host is attached.
>
> It is not necessary to page the dormant node, this communication (or
> communication error) is only between ARs.  It can be known if it is known
> that the node was unreachable for the last page and had been 'unregistered'
> for this paging area.  (That is until it re-associates with an AR).

I'm not sure if we can make such assumptions about the network's
state.


>
>
> This could happen if its battery died.

> >
> > CODE 1- communication with destination administratively
> > prohibited: this would be FALSE, because communication is not
> > prohibited. Other packets can pass. In fact, security is out of scope.
> > Ping is not an attack tool.
> >
> > CODE 2- not assigned.
> >
> > CODE 3- address unreachable: this again would be PREMATURE.
> > Such a message is returned when there is a route to the destination
> > link but the host attached to that link cannot be reached. For
> > example, its L2 address cannot be resolved etc... Again, we can't
> > know that before paging the dormant node.
>
> 1. Again, this communication is between ARs only.  There is no need to wake
> the dormant node.  The AR to which the node is atached can respond with this
> error code.

But, if the packet is filtered by the paging agent we can avoid an unnecessary
page, hence consumption of precious bandwidth.


> 2. Also, the AR to which the node is attached can notify the Paging Agent
> that a particular node is now dormant.

The paging agent already knows that. I'm missing something?


>
> >
> > CODE 4- port unreachable: Has nothing to do here.
> >
> > Note that all codes described above are typically
> > used to report a network failure.
>
> Even if they are typically used in a slightly different manner, what is
> important is whether they will cause a behaviour that is appropriate for IP
> paging.
>
> If equating Dormant Mode to Address Unreachable causes the network to behave
> in a manner that we like, then it is just a matter of changing some ICMP
> terminology to match our thinking.
>
> - Kulwinder.

But, in my opinion there is big difference between a failure (covered by
current ICMP messages) and an operational mode (but dormant).

regards,
pars



From owner-seamoby@diameter.org  Tue Jul 24 09:51:44 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17865
	for <seamoby-archive@odin.ietf.org>; Tue, 24 Jul 2001 09:51:43 -0400 (EDT)
Received: (qmail 26222 invoked by alias); 24 Jul 2001 13:41:05 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26216 invoked by uid 200); 24 Jul 2001 13:41:05 -0000
Received: (qmail 26207 invoked by uid 500); 24 Jul 2001 13:41:03 -0000
Date: Tue, 24 Jul 2001 06:41:03 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Pars MUTAF <pars.mutaf@inrialpes.fr>
Cc: Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: [seamoby] ICMP destination dormant
Message-ID: <20010724064103.J10225@charizard.diameter.org>
Mail-Followup-To: Pars MUTAF <pars.mutaf@inrialpes.fr>,
	Pat Calhoun <pcalhoun@diameter.org>, seamoby@cdma-2000.org
References: <200107202225.PAA01739@heliopolis.eng.sun.com> <001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr> <20010723145335.V10225@charizard.diameter.org> <3B5D6E17.56F96EBD@inrialpes.fr>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <3B5D6E17.56F96EBD@inrialpes.fr>; from pars.mutaf@inrialpes.fr on Tue, Jul 24, 2001 at 02:46:15PM +0200
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Tue, Jul 24, 2001 at 02:46:15PM +0200, Pars MUTAF wrote:
> I'm not the author of HMIPv6HP draft but I would
> say just like in HMIPv6. I'm sorry if a made a mistake.

Ah, well perhaps I need to read that draft, but I am uncomfortable
with imposing that all packets in the network traverse through a *specific*
router in the network. Networks are built to be resilient, and enforcing
a single point of failure seems like a bad idea to me.

What's that?!? Incoming flames....

PatC


From owner-seamoby@diameter.org  Tue Jul 24 10:07:45 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18735
	for <seamoby-archive@odin.ietf.org>; Tue, 24 Jul 2001 10:07:44 -0400 (EDT)
Received: (qmail 26743 invoked by alias); 24 Jul 2001 13:56:39 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 26737 invoked by uid 200); 24 Jul 2001 13:56:39 -0000
Received: (qmail 26732 invoked from network); 24 Jul 2001 13:56:37 -0000
Received: from femail1.rdc1.on.home.com (24.2.9.88)
  by c900656-a.plstn1.sfba.home.com with SMTP; 24 Jul 2001 13:56:37 -0000
Received: from cr851003a ([24.157.232.166]) by femail1.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010724140710.YEUP903.femail1.rdc1.on.home.com@cr851003a>;
          Tue, 24 Jul 2001 07:07:10 -0700
Message-ID: <006101c11449$e5abe360$a6e89d18@slnt1.on.wave.home.com>
From: "Kulwinder Atwal" <katwal2200@home.com>
To: "Pars MUTAF" <pars.mutaf@inrialpes.fr>
Cc: <seamoby@cdma-2000.org>
References: <200107202225.PAA01739@heliopolis.eng.sun.com>	<001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr> <005e01c113d5$5723a480$a6e89d18@slnt1.on.wave.home.com> <3B5D77C9.2C88E2BA@inrialpes.fr>
Subject: Re: [seamoby] ICMP destination dormant
Date: Tue, 24 Jul 2001 10:06:30 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Pars MUTAF" <pars.mutaf@inrialpes.fr>
To: "Kulwinder Atwal" <katwal2200@home.com>
Cc: <seamoby@cdma-2000.org>
Sent: Tuesday, July 24, 2001 9:27 AM
Subject: Re: [seamoby] ICMP destination dormant


>
> Hello Kulwinder;
>

> The paging agent already knows that. I'm missing something?
>

I think it is that requirement 4.3 does not state which entity will preform
the filtering.  Whetther it will be just the Paging Agent, or a combination
of the Paging Agent and the AR to which the node is attached.

>
> > Even if they are typically used in a slightly different manner, what is
> > important is whether they will cause a behaviour that is appropriate for
IP
> > paging.
> >
> > If equating Dormant Mode to Address Unreachable causes the network to
behave
> > in a manner that we like, then it is just a matter of changing some ICMP
> > terminology to match our thinking.
> >
> > - Kulwinder.
>
> But, in my opinion there is big difference between a failure (covered by
> current ICMP messages) and an operational mode (but dormant).

How does the behaviour at the other end of the network differ (at the
sender)?

What would the sender do differently, if it were to recieve a different
code?

- Kulwinder.

>
> regards,
> pars
>



From owner-seamoby@diameter.org  Tue Jul 24 10:34:34 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20887
	for <seamoby-archive@odin.ietf.org>; Tue, 24 Jul 2001 10:34:33 -0400 (EDT)
Received: (qmail 27355 invoked by alias); 24 Jul 2001 14:23:40 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27349 invoked by uid 200); 24 Jul 2001 14:23:40 -0000
Received: (qmail 27344 invoked from network); 24 Jul 2001 14:23:38 -0000
Received: from thumper.research.telcordia.com (128.96.41.1)
  by c900656-a.plstn1.sfba.home.com with SMTP; 24 Jul 2001 14:23:38 -0000
Received: from tari.research.telcordia.com (tari [207.3.232.66])
	by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f6OEY0m09983;
	Tue, 24 Jul 2001 10:34:01 -0400 (EDT)
Received: from tuna.research.telcordia.com (ohba@tari-dhcp7.research.telcordia.com [207.3.232.121])
	by tari.research.telcordia.com (8.8.8/8.8.8) with ESMTP id KAA09754;
	Tue, 24 Jul 2001 10:36:08 -0400 (EDT)
Date: Tue, 24 Jul 2001 11:33:27 -0400
Message-ID: <87snfmxry0.wl@tuna.research.telcordia.com>
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
To: "Kulwinder Atwal" <katwal2200@home.com>
Cc: "Pars MUTAF" <pars.mutaf@inrialpes.fr>, <seamoby@cdma-2000.org>
Subject: Re: [seamoby] ICMP destination dormant
In-Reply-To: <006101c11449$e5abe360$a6e89d18@slnt1.on.wave.home.com>
References: <200107202225.PAA01739@heliopolis.eng.sun.com>
	<001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com>
	<87bsmf1606.wl@tuna.research.telcordia.com>
	<3B5C3D46.743D88CB@inrialpes.fr>
	<005e01c113d5$5723a480$a6e89d18@slnt1.on.wave.home.com>
	<3B5D77C9.2C88E2BA@inrialpes.fr>
	<006101c11449$e5abe360$a6e89d18@slnt1.on.wave.home.com>
User-Agent: Wanderlust/2.6.0 (Twist And Shout-pre) SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.3 MULE XEmacs/21.4 (patch 1) (Copyleft) (i386-debian-linux)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Sender: owner-seamoby@diameter.org
Precedence: bulk

> > But, in my opinion there is big difference between a failure (covered by
> > current ICMP messages) and an operational mode (but dormant).
> 
> How does the behaviour at the other end of the network differ (at the
> sender)?
> 
> What would the sender do differently, if it were to recieve a different
> code?
> 
> - Kulwinder.
> 

That would be useful in terms of diagnostics especially for remote
management of devices that are connected to network and capable of
being dormant.  If an ICMP error with "dormant unreachable" is
received then both the network and dormant device are working
correctly and no special action would be taken.  If other ICMP error
such as "no route to destination" is received, an action to recover
connectivity would be taken.

I'm still doing security analysis for Pars' proposal (so far 
it seems ok).

Yoshihiro Ohba


From owner-seamoby@diameter.org  Tue Jul 24 11:03:49 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23002
	for <seamoby-archive@odin.ietf.org>; Tue, 24 Jul 2001 11:03:48 -0400 (EDT)
Received: (qmail 27915 invoked by alias); 24 Jul 2001 14:52:41 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 27909 invoked by uid 200); 24 Jul 2001 14:52:40 -0000
Received: (qmail 27904 invoked from network); 24 Jul 2001 14:52:38 -0000
Received: from ebene.inrialpes.fr (194.199.18.70)
  by c900656-a.plstn1.sfba.home.com with SMTP; 24 Jul 2001 14:52:38 -0000
Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114])
	by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6OF0bB00694;
	Tue, 24 Jul 2001 17:00:37 +0200 (MEST)
Message-ID: <3B5D8E4C.DC68E5DD@inrialpes.fr>
Date: Tue, 24 Jul 2001 17:03:40 +0200
From: Pars MUTAF <pars.mutaf@inrialpes.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Kulwinder Atwal <katwal2200@home.com>
CC: seamoby@cdma-2000.org
Subject: Re: [seamoby] ICMP destination dormant
References: <200107202225.PAA01739@heliopolis.eng.sun.com>	<001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr> <005e01c113d5$5723a480$a6e89d18@slnt1.on.wave.home.com> <3B5D77C9.2C88E2BA@inrialpes.fr> <006101c11449$e5abe360$a6e89d18@slnt1.on.wave.home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello Kulwinder;

Kulwinder Atwal wrote:

> >
> > But, in my opinion there is big difference between a failure (covered by
> > current ICMP messages) and an operational mode (but dormant).
>
> How does the behaviour at the other end of the network differ (at the
> sender)?
>
> What would the sender do differently, if it were to recieve a different
> code?

I think this question doesn't make sense. Let me explain. Your
reasoning could apply to currently available ICMP message codes
as well.

So, we could ask,  why we have different messages for "host
unreachable" and "no route to host", etc. ?

This would be senseless.

The motivation here is to have a correct idea about the network's mode of
operation...

Thanks,
pars



From owner-seamoby@diameter.org  Tue Jul 24 11:11:57 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23691
	for <seamoby-archive@odin.ietf.org>; Tue, 24 Jul 2001 11:11:57 -0400 (EDT)
Received: (qmail 28484 invoked by alias); 24 Jul 2001 15:01:07 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 28478 invoked by uid 200); 24 Jul 2001 15:01:07 -0000
Received: (qmail 28472 invoked from network); 24 Jul 2001 15:01:03 -0000
Received: from ebene.inrialpes.fr (194.199.18.70)
  by c900656-a.plstn1.sfba.home.com with SMTP; 24 Jul 2001 15:01:03 -0000
Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114])
	by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6OF9CB00961;
	Tue, 24 Jul 2001 17:09:12 +0200 (MEST)
Message-ID: <3B5D904F.4841FAC7@inrialpes.fr>
Date: Tue, 24 Jul 2001 17:12:15 +0200
From: Pars MUTAF <pars.mutaf@inrialpes.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Pat Calhoun <pcalhoun@diameter.org>
CC: seamoby@cdma-2000.org
Subject: Re: [seamoby] ICMP destination dormant
References: <200107202225.PAA01739@heliopolis.eng.sun.com> <001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr> <20010723145335.V10225@charizard.diameter.org> <3B5D6E17.56F96EBD@inrialpes.fr> <20010724064103.J10225@charizard.diameter.org>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi,

Well, I'm not promoting HMIPv6  :-)  here.
I think the discussion is completely independent.
I mean the other IP paging proposal LH-DMHA
is also subject of the discussion... In fact this
is generic...

regards,
pars


Pat Calhoun wrote:

> On Tue, Jul 24, 2001 at 02:46:15PM +0200, Pars MUTAF wrote:
> > I'm not the author of HMIPv6HP draft but I would
> > say just like in HMIPv6. I'm sorry if a made a mistake.
>
> Ah, well perhaps I need to read that draft, but I am uncomfortable
> with imposing that all packets in the network traverse through a *specific*
> router in the network. Networks are built to be resilient, and enforcing
> a single point of failure seems like a bad idea to me.
>
> What's that?!? Incoming flames....
>
> PatC



From owner-seamoby@diameter.org  Tue Jul 24 12:43:29 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00625
	for <seamoby-archive@odin.ietf.org>; Tue, 24 Jul 2001 12:43:28 -0400 (EDT)
Received: (qmail 29247 invoked by alias); 24 Jul 2001 16:32:36 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 29241 invoked by uid 200); 24 Jul 2001 16:32:36 -0000
Received: (qmail 29236 invoked by uid 500); 24 Jul 2001 16:32:34 -0000
Date: Tue, 24 Jul 2001 09:32:34 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: seamoby@cdma-2000.org
Subject: [seamoby] Reminder: Design Team Lists are shutdown
Message-ID: <20010724093234.S10225@charizard.diameter.org>
Mail-Followup-To: seamoby@cdma-2000.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-seamoby@diameter.org
Precedence: bulk

All,

Just a reminder that all of the design team lists are shutdown, and I
just now actually disabled them. The archives will remain accessible.

Thanks,

PatC


From owner-seamoby@diameter.org  Wed Jul 25 16:20:01 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03158
	for <seamoby-archive@odin.ietf.org>; Wed, 25 Jul 2001 16:19:59 -0400 (EDT)
Received: (qmail 4491 invoked by alias); 25 Jul 2001 16:05:54 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 4485 invoked by uid 200); 25 Jul 2001 16:05:54 -0000
Received: (qmail 4476 invoked by uid 500); 25 Jul 2001 16:05:52 -0000
Date: Wed, 25 Jul 2001 09:05:52 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Hamid Syed <hmsyed@nortelnetworks.com>
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: Re: [seamoby] Final Seamoby Agenda
Message-ID: <20010725090552.G10225@charizard.diameter.org>
Mail-Followup-To: Hamid Syed <hmsyed@nortelnetworks.com>,
	'Pat Calhoun' <pcalhoun@diameter.org>, seamoby@cdma-2000.org
References: <9FBD322B7824D511B36900508BF93C9C1CD155@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C1CD155@zcard031.ca.nortel.com>; from hmsyed@nortelnetworks.com on Wed, Jul 25, 2001 at 12:04:17PM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

Thanks for the reminder, but adding a new item to the milestones requires:
1. WG rough consensus, and
2. AD approval

We can, however, discuss it and see where it leads.

PatC
On Wed, Jul 25, 2001 at 12:04:17PM -0400, Hamid Syed wrote:
> Hello Pat,
> 
> As the milestones review is the part of Seamoby Agenda, I just wanted to put
> this freindly reminder that a ct framework should be included as one of the
> milestones for context transfer.
> 
> cheers
> 
> -Hamid Syed
> 
> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Monday, July 23, 2001 5:36 PM
> To: seamoby@cdma-2000.org
> Subject: [seamoby] Final Seamoby Agenda
> 
> 
> All,
> 
> Below is the final Seamoby Agenda. Please note that the first 60 minutes of
> the Monday session is allocated to the MORE BOF, chaired by James Kempf and
> Paul Reynolds.
> 
> Further, if your name appears below, you are on the hook to provide your
> presentation material to me by no later than 7/30. I need to review the
> material to ensure that it conforms to our discussion policy.
> 
> Monday August 6th
> 
> 1300-1500
> 
> MORE BOF                                        Kempf/Reynold   60 mins
> Agenda Bashing					Chair		 5 mins
> Update on WG documents				Chair		10 mins
> Milestone Review				Chair		10 mins
> L2 Triggers and its relevance to Seamoby        Kempf            5 mins
>   (draft-manyfolks-l2-mobilereq-00.txt)
> Handoff Candidate Discovery Issues              HCD Authors     15 mins
>   (draft-ietf-seamoby-CARdiscovery-issues-00.txt)
> Proceeding on Paging (DMHA)			All		10 mins
> Adjourn
> 
> 
> Wednesday August 8th
> 
> 1530-1730
> 
> CT Framework Issues                             Kenward         10 mins
>   (draft-hamid-seamoby-ct-fwk-00.txt)
> CT Applicability                                Koodli          10 mins
>   (draft-koodli-seamoby-ctv6-00.txt)
> Context Transfer Requirements Discussions	All		90 mins
>   (draft-ietf-seamoby-ct-reqs-00.txt)
> Closure/Next Steps				Chair		10 mins
> Adjourn
> 
> Thanks,
> 
> PatC


From owner-seamoby@diameter.org  Wed Jul 25 16:31:49 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04307
	for <seamoby-archive@odin.ietf.org>; Wed, 25 Jul 2001 16:31:41 -0400 (EDT)
Received: (qmail 31289 invoked by alias); 24 Jul 2001 22:34:57 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 31283 invoked by uid 200); 24 Jul 2001 22:34:57 -0000
Received: (qmail 31278 invoked from network); 24 Jul 2001 22:34:55 -0000
Received: from femail2.rdc1.on.home.com (24.2.9.89)
  by c900656-a.plstn1.sfba.home.com with SMTP; 24 Jul 2001 22:34:55 -0000
Received: from cr851003a ([24.157.232.166]) by femail2.rdc1.on.home.com
          (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP
          id <20010724224534.WTH10784.femail2.rdc1.on.home.com@cr851003a>;
          Tue, 24 Jul 2001 15:45:34 -0700
Message-ID: <009801c11492$4e3bb0c0$a6e89d18@slnt1.on.wave.home.com>
From: "Kulwinder Atwal" <katwal2200@home.com>
To: "Pars MUTAF" <pars.mutaf@inrialpes.fr>
Cc: <seamoby@cdma-2000.org>
References: <200107202225.PAA01739@heliopolis.eng.sun.com>	<001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr> <005e01c113d5$5723a480$a6e89d18@slnt1.on.wave.home.com> <3B5D77C9.2C88E2BA@inrialpes.fr> <006101c11449$e5abe360$a6e89d18@slnt1.on.wave.home.com> <3B5D8E4C.DC68E5DD@inrialpes.fr>
Subject: Re: [seamoby] ICMP destination dormant
Date: Tue, 24 Jul 2001 18:43:21 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


----- Original Message -----
From: "Pars MUTAF" <pars.mutaf@inrialpes.fr>
To: "Kulwinder Atwal" <katwal2200@home.com>
Cc: <seamoby@cdma-2000.org>
Sent: Tuesday, July 24, 2001 11:03 AM
Subject: Re: [seamoby] ICMP destination dormant


>
> Hello Kulwinder;
>
> Kulwinder Atwal wrote:
>
> > >
> > > But, in my opinion there is big difference between a failure (covered
by
> > > current ICMP messages) and an operational mode (but dormant).
> >
> > How does the behaviour at the other end of the network differ (at the
> > sender)?
> >
> > What would the sender do differently, if it were to recieve a different
> > code?
>
> I think this question doesn't make sense. Let me explain. Your
> reasoning could apply to currently available ICMP message codes
> as well.
>
> So, we could ask,  why we have different messages for "host
> unreachable" and "no route to host", etc. ?

With "no route to host" the network can try an alternate route.

But, with "Address Unreachable" as far as I can tell, it has two choices:

1. Give up now.

2. Set Timer. Try again when Timer runs out.  Give up when some other Timer
runs out.
Here Multicast Listener Discovery, RFC 2710, might be useful for ARs to know
how long other ARs will wait for node to come out of dormant mode.

If you add a new code, can you describe a choice 3, and how it differs from
the functionality provided by Multicast Listener Discovery?

Thanks, Kulwinder.

>
> This would be senseless.
>
> The motivation here is to have a correct idea about the network's mode of
> operation...
>
> Thanks,
> pars
>



From owner-seamoby@diameter.org  Wed Jul 25 16:40:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05231
	for <seamoby-archive@odin.ietf.org>; Wed, 25 Jul 2001 16:40:37 -0400 (EDT)
Received: (qmail 5884 invoked by alias); 25 Jul 2001 19:28:31 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5878 invoked by uid 200); 25 Jul 2001 19:28:31 -0000
Received: (qmail 5873 invoked by uid 500); 25 Jul 2001 19:28:29 -0000
Date: Wed, 25 Jul 2001 12:28:29 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: seamoby@cdma-2000.org
Subject: [seamoby] My Sun e-mail address
Message-ID: <20010725122829.Q10225@charizard.diameter.org>
Mail-Followup-To: seamoby@cdma-2000.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-seamoby@diameter.org
Precedence: bulk

I would ask that folks refrain from using my Sun e-mail account. Although
it is still working, it will be turned off on 8/3. My diameter.org account
is a safe bet (and a new one to be announced very soon).

PatC


From owner-seamoby@diameter.org  Wed Jul 25 16:59:26 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07439
	for <seamoby-archive@odin.ietf.org>; Wed, 25 Jul 2001 16:59:25 -0400 (EDT)
Received: (qmail 2599 invoked by alias); 25 Jul 2001 11:43:21 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2593 invoked by uid 200); 25 Jul 2001 11:43:21 -0000
Received: (qmail 2584 invoked from network); 25 Jul 2001 11:43:18 -0000
Received: from albatross-ext.wise.edt.ericsson.se (194.237.142.116)
  by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jul 2001 11:43:18 -0000
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f6PBsEN10896
	for <seamoby@cdma-2000.org>; Wed, 25 Jul 2001 13:54:15 +0200 (MEST)
Received: FROM esealnt400.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Jul 25 13:54:10 2001 +0200
Received: by esealnt400 with Internet Mail Service (5.5.2653.19)
	id <NBW46D5A>; Wed, 25 Jul 2001 13:54:14 +0200
Message-ID: <034BEFD03799D411A59F00508BDF754603008B55@esealnt448.al.sw.ericsson.se>
From: "Hesham Soliman  \(ERA\)" <Hesham.Soliman@era.ericsson.se>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: seamoby@cdma-2000.org
Subject: RE: [seamoby] ICMP destination dormant
Date: Wed, 25 Jul 2001 13:54:04 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-seamoby@diameter.org
Precedence: bulk

	Hi Pat, 

	No incoming flames :)
	This is a side topic to the thread, but just a small clarification
	below.

> > I'm not the author of HMIPv6HP draft but I would
> > say just like in HMIPv6. I'm sorry if a made a mistake.
> 
> Ah, well perhaps I need to read that draft, but I am uncomfortable
> with imposing that all packets in the network traverse through a *specific*
> router in the network. Networks are built to be resilient, and enforcing
> a single point of failure seems like a bad idea to me.
> 
	=> I agree, but there is work going on ( a new draft) fo HA redundancy 
	which can quite easily be used for MAPs in HMIPv6 or 
	the GFA in Reg Reg for MIPv4. Of course the problem you mention
	here is valid to MIP in general starting from the HA (particularly for 
	MIPv4 where there is no "real" route opt). 

> What's that?!? Incoming flames....
> 
> 
	Hesham


From owner-seamoby@diameter.org  Wed Jul 25 17:35:31 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11370
	for <seamoby-archive@odin.ietf.org>; Wed, 25 Jul 2001 17:35:30 -0400 (EDT)
Received: (qmail 3902 invoked by alias); 25 Jul 2001 15:54:07 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 3896 invoked by uid 200); 25 Jul 2001 15:54:07 -0000
Received: (qmail 3891 invoked from network); 25 Jul 2001 15:54:04 -0000
Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 25 Jul 2001 15:54:04 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6PG4A921085
	for <seamoby@cdma-2000.org>; Wed, 25 Jul 2001 12:04:10 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Wed, 25 Jul 2001 12:04:16 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMVSC4ML>; Wed, 25 Jul 2001 12:04:18 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C1CD155@zcard031.ca.nortel.com>
From: "Hamid Syed" <hmsyed@nortelnetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>, seamoby@cdma-2000.org
Subject: RE: [seamoby] Final Seamoby Agenda
Date: Wed, 25 Jul 2001 12:04:17 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C11523.74D2DF60"
X-Orig: <hmsyed@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C11523.74D2DF60
Content-Type: text/plain;
	charset="iso-8859-1"

Hello Pat,

As the milestones review is the part of Seamoby Agenda, I just wanted to put
this freindly reminder that a ct framework should be included as one of the
milestones for context transfer.

cheers

-Hamid Syed

-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: Monday, July 23, 2001 5:36 PM
To: seamoby@cdma-2000.org
Subject: [seamoby] Final Seamoby Agenda


All,

Below is the final Seamoby Agenda. Please note that the first 60 minutes of
the Monday session is allocated to the MORE BOF, chaired by James Kempf and
Paul Reynolds.

Further, if your name appears below, you are on the hook to provide your
presentation material to me by no later than 7/30. I need to review the
material to ensure that it conforms to our discussion policy.

Monday August 6th

1300-1500

MORE BOF                                        Kempf/Reynold   60 mins
Agenda Bashing					Chair		 5 mins
Update on WG documents				Chair		10 mins
Milestone Review				Chair		10 mins
L2 Triggers and its relevance to Seamoby        Kempf            5 mins
  (draft-manyfolks-l2-mobilereq-00.txt)
Handoff Candidate Discovery Issues              HCD Authors     15 mins
  (draft-ietf-seamoby-CARdiscovery-issues-00.txt)
Proceeding on Paging (DMHA)			All		10 mins
Adjourn


Wednesday August 8th

1530-1730

CT Framework Issues                             Kenward         10 mins
  (draft-hamid-seamoby-ct-fwk-00.txt)
CT Applicability                                Koodli          10 mins
  (draft-koodli-seamoby-ctv6-00.txt)
Context Transfer Requirements Discussions	All		90 mins
  (draft-ietf-seamoby-ct-reqs-00.txt)
Closure/Next Steps				Chair		10 mins
Adjourn

Thanks,

PatC

------_=_NextPart_001_01C11523.74D2DF60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.89">
<TITLE>RE: [seamoby] Final Seamoby Agenda</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hello Pat,</FONT>
</P>

<P><FONT SIZE=3D2>As the milestones review is the part of Seamoby =
Agenda, I just wanted to put this freindly reminder that a ct framework =
should be included as one of the milestones for context =
transfer.</FONT></P>

<P><FONT SIZE=3D2>cheers</FONT>
</P>

<P><FONT SIZE=3D2>-Hamid Syed</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Pat Calhoun [<A =
HREF=3D"mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Monday, July 23, 2001 5:36 PM</FONT>
<BR><FONT SIZE=3D2>To: seamoby@cdma-2000.org</FONT>
<BR><FONT SIZE=3D2>Subject: [seamoby] Final Seamoby Agenda</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>All,</FONT>
</P>

<P><FONT SIZE=3D2>Below is the final Seamoby Agenda. Please note that =
the first 60 minutes of</FONT>
<BR><FONT SIZE=3D2>the Monday session is allocated to the MORE BOF, =
chaired by James Kempf and</FONT>
<BR><FONT SIZE=3D2>Paul Reynolds.</FONT>
</P>

<P><FONT SIZE=3D2>Further, if your name appears below, you are on the =
hook to provide your</FONT>
<BR><FONT SIZE=3D2>presentation material to me by no later than 7/30. I =
need to review the</FONT>
<BR><FONT SIZE=3D2>material to ensure that it conforms to our =
discussion policy.</FONT>
</P>

<P><FONT SIZE=3D2>Monday August 6th</FONT>
</P>

<P><FONT SIZE=3D2>1300-1500</FONT>
</P>

<P><FONT SIZE=3D2>MORE =
BOF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp; Kempf/Reynold&nbsp;&nbsp; 60 mins</FONT>
<BR><FONT SIZE=3D2>Agenda Bashing&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chair&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5 mins</FONT>
<BR><FONT SIZE=3D2>Update on WG documents&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chair&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 mins</FONT>
<BR><FONT SIZE=3D2>Milestone =
Review&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chair&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 mins</FONT>
<BR><FONT SIZE=3D2>L2 Triggers and its relevance to =
Seamoby&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Kempf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
5 mins</FONT>
<BR><FONT SIZE=3D2>&nbsp; (draft-manyfolks-l2-mobilereq-00.txt)</FONT>
<BR><FONT SIZE=3D2>Handoff Candidate Discovery =
Issues&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; HCD Authors&nbsp;&nbsp;&nbsp;&nbsp; 15 mins</FONT>
<BR><FONT SIZE=3D2>&nbsp; =
(draft-ietf-seamoby-CARdiscovery-issues-00.txt)</FONT>
<BR><FONT SIZE=3D2>Proceeding on Paging (DMHA)&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 mins</FONT>
<BR><FONT SIZE=3D2>Adjourn</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Wednesday August 8th</FONT>
</P>

<P><FONT SIZE=3D2>1530-1730</FONT>
</P>

<P><FONT SIZE=3D2>CT Framework =
Issues&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Kenward&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 mins</FONT>
<BR><FONT SIZE=3D2>&nbsp; (draft-hamid-seamoby-ct-fwk-00.txt)</FONT>
<BR><FONT SIZE=3D2>CT =
Applicability&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Koodli&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 =
mins</FONT>
<BR><FONT SIZE=3D2>&nbsp; (draft-koodli-seamoby-ctv6-00.txt)</FONT>
<BR><FONT SIZE=3D2>Context Transfer Requirements =
Discussions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
All&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
90 mins</FONT>
<BR><FONT SIZE=3D2>&nbsp; (draft-ietf-seamoby-ct-reqs-00.txt)</FONT>
<BR><FONT SIZE=3D2>Closure/Next Steps&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chair&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 mins</FONT>
<BR><FONT SIZE=3D2>Adjourn</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>PatC</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C11523.74D2DF60--


From owner-seamoby@diameter.org  Wed Jul 25 18:57:46 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19115
	for <seamoby-archive@odin.ietf.org>; Wed, 25 Jul 2001 18:57:45 -0400 (EDT)
Received: (qmail 30671 invoked by alias); 24 Jul 2001 21:47:42 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 30665 invoked by uid 200); 24 Jul 2001 21:47:41 -0000
Received: (qmail 30660 invoked from network); 24 Jul 2001 21:47:40 -0000
Received: from idcmail.interdigital.com (HELO idcpa4.pa.interdigital.com) (12.32.197.142)
  by c900656-a.plstn1.sfba.home.com with SMTP; 24 Jul 2001 21:47:40 -0000
Received: by idcpa4.pa.interdigital.com with Internet Mail Service (5.5.2653.19)
	id <NG3RNBS7>; Tue, 24 Jul 2001 17:56:57 -0400
Message-ID: <A1170612471BD21185B90008C7FA0A0D01F1F9A6@idcpa4.pa.interdigital.com>
From: "Shahrier, Sharif M." <Sharif.Shahrier@InterDigital.com>
To: "'James Kempf'" <James.Kempf@Sun.COM>, seamoby@cdma-2000.org
Subject: RE: [seamoby] Final Seamoby Agenda
Date: Tue, 24 Jul 2001 17:56:56 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

James,

	Could you please tell me the time and the place when this BOF is
held? I would like to
attend. Thanks.

Sharif.


-----Original Message-----
From: James Kempf [mailto:James.Kempf@Sun.COM]
Sent: Monday, July 23, 2001 6:33 PM
To: seamoby@cdma-2000.org
Subject: Re: [seamoby] Final Seamoby Agenda


Attached is a description of the MORE BOF and an agenda. We would like
to use the bulk of the time to discuss mobile wireless service providers'
requirements for IETF protocols, though there are also a few presentations
on specific items. The requirements will be folded into an informational
RFC and circulated to the mobility related WGs. Paul Reynolds and I
will be co-chairing. Many thanx to Pat and Allison for helping get
this scheduled. 

		jak


From owner-seamoby@diameter.org  Thu Jul 26 11:14:53 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16658
	for <seamoby-archive@odin.ietf.org>; Thu, 26 Jul 2001 11:14:52 -0400 (EDT)
Received: (qmail 10118 invoked by alias); 26 Jul 2001 15:03:42 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 10112 invoked by uid 200); 26 Jul 2001 15:03:42 -0000
Received: (qmail 10107 invoked from network); 26 Jul 2001 15:03:40 -0000
Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jul 2001 15:03:40 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6QFDg921687
	for <seamoby@diameter.org>; Thu, 26 Jul 2001 11:13:43 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Thu, 26 Jul 2001 11:13:38 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMVSD10R>; Thu, 26 Jul 2001 11:13:40 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E90@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "seamoby \(E-mail\)" <seamoby@diameter.org>
Subject: [seamoby] Seamoby
Date: Thu, 26 Jul 2001 11:13:42 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C115E5.8E83F030"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C115E5.8E83F030
Content-Type: text/plain;
	charset="iso-8859-1"

Pat:

  I just noticed something that has me confused. On the IETF
www page, Seamoby is listed as the "Context and MicroMobility
Routing" working group. It's probably a case of my not paying attention,
but I had thought that Seamoby had dropped the MicroMobility 
Routing work, and the name of the group was something like
"Context and Mobile Host Paging" or such.

Gary


------_=_NextPart_001_01C115E5.8E83F030
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>Seamoby</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR="#000080" FACE="Comic Sans MS">Pat:</FONT>
</P>

<P><FONT COLOR="#000080" FACE="Comic Sans MS">&nbsp; I just noticed something that has me confused. On the IETF</FONT>
<BR><FONT COLOR="#000080" FACE="Comic Sans MS">www page, Seamoby is listed as the &quot;Context and MicroMobility</FONT>
<BR><FONT COLOR="#000080" FACE="Comic Sans MS">Routing&quot; working group. It's probably a case of my not paying attention,</FONT>
<BR><FONT COLOR="#000080" FACE="Comic Sans MS">but I had thought that Seamoby had dropped the MicroMobility </FONT>
<BR><FONT COLOR="#000080" FACE="Comic Sans MS">Routing work, and the name of the group was something like</FONT>
<BR><FONT COLOR="#000080" FACE="Comic Sans MS">&quot;Context and Mobile Host Paging&quot; or such.</FONT>
</P>

<P><FONT COLOR="#000080" FACE="Comic Sans MS">Gary</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C115E5.8E83F030--


From owner-seamoby@diameter.org  Thu Jul 26 12:29:56 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA20703
	for <seamoby-archive@odin.ietf.org>; Thu, 26 Jul 2001 12:29:55 -0400 (EDT)
Received: (qmail 10686 invoked by alias); 26 Jul 2001 15:29:26 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 10680 invoked by uid 200); 26 Jul 2001 15:29:26 -0000
Received: (qmail 10674 invoked by uid 500); 26 Jul 2001 15:29:24 -0000
Date: Thu, 26 Jul 2001 08:29:24 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Gary Kenward <gkenward@nortelnetworks.com>
Cc: "seamoby \(E-mail\)" <seamoby@diameter.org>
Subject: Re: [seamoby] Seamoby
Message-ID: <20010726082924.N6433@charizard.diameter.org>
Mail-Followup-To: Gary Kenward <gkenward@nortelnetworks.com>,
	"seamoby (E-mail)" <seamoby@diameter.org>
References: <9FBD322B7824D511B36900508BF93C9C9F5E90@zcard031.ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <9FBD322B7824D511B36900508BF93C9C9F5E90@zcard031.ca.nortel.com>; from gkenward@nortelnetworks.com on Thu, Jul 26, 2001 at 11:13:42AM -0400
Sender: owner-seamoby@diameter.org
Precedence: bulk

This was recently changed (perhaps yesterday) and is obviously an error.
It was OK previously.

I'll ping the web server admin.

PatC
On Thu, Jul 26, 2001 at 11:13:42AM -0400, Gary Kenward wrote:
> Pat:
> 
>   I just noticed something that has me confused. On the IETF
> www page, Seamoby is listed as the "Context and MicroMobility
> Routing" working group. It's probably a case of my not paying attention,
> but I had thought that Seamoby had dropped the MicroMobility 
> Routing work, and the name of the group was something like
> "Context and Mobile Host Paging" or such.
> 
> Gary
> 


From owner-seamoby@diameter.org  Thu Jul 26 14:36:10 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02056
	for <seamoby-archive@odin.ietf.org>; Thu, 26 Jul 2001 14:36:10 -0400 (EDT)
Received: (qmail 8601 invoked by alias); 26 Jul 2001 09:25:51 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 8595 invoked by uid 200); 26 Jul 2001 09:25:50 -0000
Received: (qmail 8590 invoked from network); 26 Jul 2001 09:25:49 -0000
Received: from ebene.inrialpes.fr (194.199.18.70)
  by c900656-a.plstn1.sfba.home.com with SMTP; 26 Jul 2001 09:25:49 -0000
Received: from inrialpes.fr (lalena.inrialpes.fr [194.199.24.114])
	by ebene.inrialpes.fr (8.11.3/8.11.3) with ESMTP id f6Q9QS808231;
	Thu, 26 Jul 2001 11:26:29 +0200 (MEST)
Message-ID: <3B5FE301.E2EEA1E7@inrialpes.fr>
Date: Thu, 26 Jul 2001 11:29:37 +0200
From: Pars MUTAF <pars.mutaf@inrialpes.fr>
X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: Kulwinder Atwal <katwal2200@home.com>
CC: seamoby@cdma-2000.org
Subject: Re: [seamoby] ICMP destination dormant
References: <200107202225.PAA01739@heliopolis.eng.sun.com>	<001201c11170$ab33e9c0$a6e89d18@slnt1.on.wave.home.com> <87bsmf1606.wl@tuna.research.telcordia.com> <3B5C3D46.743D88CB@inrialpes.fr> <005e01c113d5$5723a480$a6e89d18@slnt1.on.wave.home.com> <3B5D77C9.2C88E2BA@inrialpes.fr> <006101c11449$e5abe360$a6e89d18@slnt1.on.wave.home.com> <3B5D8E4C.DC68E5DD@inrialpes.fr> <009801c11492$4e3bb0c0$a6e89d18@slnt1.on.wave.home.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hi Kulwinder,

Sorry for the late reply. I think the answer of Yoshihiro
(to your question below) was superior to mine. Thanks
for helping clarify that.

We will post a more detailed description of DMHA filters,
along with a detailed discussion on ICMP host dormant
message. This way we can refer to a well organized text
and see whether this is important or not.

I hope to have more comments then.

Thank you,

regards,
pars


Kulwinder Atwal wrote:

> > Hello Kulwinder;
> >
> > Kulwinder Atwal wrote:
> >
> > > >
> > > > But, in my opinion there is big difference between a failure (covered
> by
> > > > current ICMP messages) and an operational mode (but dormant).
> > >
> > > How does the behaviour at the other end of the network differ (at the
> > > sender)?
> > >
> > > What would the sender do differently, if it were to recieve a different
> > > code?
> >



From owner-seamoby@diameter.org  Fri Jul 27 10:28:02 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21540
	for <seamoby-archive@odin.ietf.org>; Fri, 27 Jul 2001 10:27:58 -0400 (EDT)
Received: (qmail 16647 invoked by alias); 27 Jul 2001 14:13:57 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 16639 invoked by uid 200); 27 Jul 2001 14:13:56 -0000
Received: (qmail 16633 invoked from network); 27 Jul 2001 14:13:54 -0000
Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jul 2001 14:13:54 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6RENw918089
	for <seamoby@cdma-2000.org>; Fri, 27 Jul 2001 10:24:03 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 27 Jul 2001 10:24:03 -0400
Received: from zcard031.ca.nortel.com ([47.129.242.121]) 
          by zcard015.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id PMVSD4Q4; Fri, 27 Jul 2001 10:24:05 -0400
Received: from cr541699a (acart41n.ca.nortel.com [47.129.49.158]) 
          by zcard031.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id PXPDSSZP; Fri, 27 Jul 2001 10:24:04 -0400
Message-ID: <003b01c116c0$e67d7c80$9e31812f@ca.nortel.com>
X-Sybari-Space: 00000000 00000000 00000000
From: "Hamid Syed" <hmsyed@nortelnetworks.com>
To: Pat Calhoun <pcalhoun@diameter.org>
Cc: seamoby <seamoby@cdma-2000.org>
References: <20010725090552.G10225@charizard.diameter.org>
Subject: Re: [seamoby] Final Seamoby Agenda
Date: Fri, 27 Jul 2001 10:23:49 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0038_01C11686.39D3DFE0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Orig: <hmsyed@nortelnetworks.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0038_01C11686.39D3DFE0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: [seamoby] Final Seamoby AgendaPat,

I think a framework definition is very important to capture the various =
aspects of ct that can enable a seamless handover. We had some very good =
disicussions on the list regarding proactive/reactive ct modes , the =
triggers to initiate each of them and a handover candidate discovery =
mechanism is under considerations too. All these bits and pieces are =
taken, for the time being as separate items but in reality they are =
inter-related. The ordering and timing of various network events =
together with handoff candidate discovery and context transfer between =
ARs should follow some specified patterns.=20

Seamoby definitely needs a CT framework that can capture the =
relationship between all the pieces we are discussing today. Otherwise, =
defining a protocol to carry some information from one point to the =
other is not that trivial and would not help improving the performance =
of handover.

my 2 cents..

-Hamid
  ----- Original Message -----=20
  From: Pat Calhoun=20
  To: Syed, Hamid [WDLN2:AN22:EXCH]=20
  Cc: 'Pat Calhoun' ; seamoby@cdma-2000.org=20
  Sent: Wednesday, July 25, 2001 9:05 AM
  Subject: Re: [seamoby] Final Seamoby Agenda


  Thanks for the reminder, but adding a new item to the milestones =
requires:=20
  1. WG rough consensus, and=20
  2. AD approval=20

  We can, however, discuss it and see where it leads.=20

  PatC=20
  On Wed, Jul 25, 2001 at 12:04:17PM -0400, Hamid Syed wrote:=20
  > Hello Pat,=20
  >=20
  > As the milestones review is the part of Seamoby Agenda, I just =
wanted to put=20
  > this freindly reminder that a ct framework should be included as one =
of the=20
  > milestones for context transfer.=20
  >=20
  > cheers=20
  >=20
  > -Hamid Syed=20
  >=20
  > -----Original Message-----=20
  > From: Pat Calhoun [mailto:pcalhoun@diameter.org]=20
  > Sent: Monday, July 23, 2001 5:36 PM=20
  > To: seamoby@cdma-2000.org=20
  > Subject: [seamoby] Final Seamoby Agenda=20
  >=20
  >=20
  > All,=20
  >=20
  > Below is the final Seamoby Agenda. Please note that the first 60 =
minutes of=20
  > the Monday session is allocated to the MORE BOF, chaired by James =
Kempf and=20
  > Paul Reynolds.=20
  >=20
  > Further, if your name appears below, you are on the hook to provide =
your=20
  > presentation material to me by no later than 7/30. I need to review =
the=20
  > material to ensure that it conforms to our discussion policy.=20
  >=20
  > Monday August 6th=20
  >=20
  > 1300-1500=20
  >=20
  > MORE BOF                                        Kempf/Reynold   60 =
mins=20
  > Agenda Bashing                                        Chair          =
  5 mins=20
  > Update on WG documents                                Chair          =
 10 mins=20
  > Milestone Review                              Chair           10 =
mins=20
  > L2 Triggers and its relevance to Seamoby        Kempf            5 =
mins=20
  >   (draft-manyfolks-l2-mobilereq-00.txt)=20
  > Handoff Candidate Discovery Issues              HCD Authors     15 =
mins=20
  >   (draft-ietf-seamoby-CARdiscovery-issues-00.txt)=20
  > Proceeding on Paging (DMHA)                   All             10 =
mins=20
  > Adjourn=20
  >=20
  >=20
  > Wednesday August 8th=20
  >=20
  > 1530-1730=20
  >=20
  > CT Framework Issues                             Kenward         10 =
mins=20
  >   (draft-hamid-seamoby-ct-fwk-00.txt)=20
  > CT Applicability                                Koodli          10 =
mins=20
  >   (draft-koodli-seamoby-ctv6-00.txt)=20
  > Context Transfer Requirements Discussions     All             90 =
mins=20
  >   (draft-ietf-seamoby-ct-reqs-00.txt)=20
  > Closure/Next Steps                            Chair           10 =
mins=20
  > Adjourn=20
  >=20
  > Thanks,=20
  >=20
  > PatC=20


------=_NextPart_000_0038_01C11686.39D3DFE0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [seamoby] Final Seamoby Agenda</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Pat,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I think a framework definition is very =
important to=20
capture the various aspects of ct that can enable a seamless handover. =
We had=20
some very good disicussions on the list&nbsp;regarding =
proactive/reactive ct=20
modes , the triggers to initiate each of them and&nbsp;a handover =
candidate=20
discovery mechanism is under considerations too. All these bits and =
pieces are=20
taken, for the time being as separate items but in reality they are=20
inter-related. The ordering and timing of various network events =
together with=20
handoff candidate discovery and context transfer between ARs should =
follow some=20
specified patterns. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Seamoby&nbsp;definitely needs a CT=20
framework&nbsp;that can capture the relationship between all the pieces =
we are=20
discussing today. Otherwise, defining a protocol to carry some =
information from=20
one point to the other is not that trivial and would not help improving =
the=20
performance of handover.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>my 2 cents..</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-Hamid</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dpcalhoun@diameter.org =
href=3D"mailto:pcalhoun@diameter.org">Pat=20
  Calhoun</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dhmsyed@americasm01.nt.com=20
  href=3D"mailto:hmsyed@americasm01.nt.com">Syed, Hamid =
[WDLN2:AN22:EXCH]</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Dpcalhoun@diameter.org=20
  href=3D"mailto:pcalhoun@diameter.org">'Pat Calhoun'</A> ; <A=20
  title=3Dseamoby@cdma-2000.org=20
  href=3D"mailto:seamoby@cdma-2000.org">seamoby@cdma-2000.org</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, July 25, 2001 =
9:05=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [seamoby] Final =
Seamoby=20
  Agenda</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>Thanks for the reminder, but adding a new item to =
the=20
  milestones requires:</FONT> <BR><FONT size=3D2>1. WG rough consensus, =
and</FONT>=20
  <BR><FONT size=3D2>2. AD approval</FONT> </P>
  <P><FONT size=3D2>We can, however, discuss it and see where it =
leads.</FONT>=20
</P>
  <P><FONT size=3D2>PatC</FONT> <BR><FONT size=3D2>On Wed, Jul 25, 2001 =
at=20
  12:04:17PM -0400, Hamid Syed wrote:</FONT> <BR><FONT size=3D2>&gt; =
Hello=20
  Pat,</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; As =
the=20
  milestones review is the part of Seamoby Agenda, I just wanted to =
put</FONT>=20
  <BR><FONT size=3D2>&gt; this freindly reminder that a ct framework =
should be=20
  included as one of the</FONT> <BR><FONT size=3D2>&gt; milestones for =
context=20
  transfer.</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  cheers</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
-Hamid=20
  Syed</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
-----Original=20
  Message-----</FONT> <BR><FONT size=3D2>&gt; From: Pat Calhoun [<A=20
  =
href=3D"mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]</=
FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Monday, July 23, 2001 5:36 PM</FONT> =
<BR><FONT=20
  size=3D2>&gt; To: seamoby@cdma-2000.org</FONT> <BR><FONT size=3D2>&gt; =
Subject:=20
  [seamoby] Final Seamoby Agenda</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; All,</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Below is the final Seamoby Agenda. =
Please note=20
  that the first 60 minutes of</FONT> <BR><FONT size=3D2>&gt; the Monday =
session=20
  is allocated to the MORE BOF, chaired by James Kempf and</FONT> =
<BR><FONT=20
  size=3D2>&gt; Paul Reynolds.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; Further, if your name appears below, you are on the hook =
to=20
  provide your</FONT> <BR><FONT size=3D2>&gt; presentation material to =
me by no=20
  later than 7/30. I need to review the</FONT> <BR><FONT size=3D2>&gt; =
material to=20
  ensure that it conforms to our discussion policy.</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Monday August 6th</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; 1300-1500</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; MORE=20
  =
BOF&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;=20
  Kempf/Reynold&nbsp;&nbsp; 60 mins</FONT> <BR><FONT size=3D2>&gt; =
Agenda=20
  Bashing&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chair&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5 mins</FONT> =
<BR><FONT=20
  size=3D2>&gt; Update on WG =
documents&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chair&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 mins</FONT> <BR><FONT=20
  size=3D2>&gt; Milestone Review&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chair&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 mins</FONT> <BR><FONT=20
  size=3D2>&gt; L2 Triggers and its relevance to=20
  Seamoby&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
Kempf&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
5=20
  mins</FONT> <BR><FONT size=3D2>&gt;&nbsp;&nbsp;=20
  (draft-manyfolks-l2-mobilereq-00.txt)</FONT> <BR><FONT size=3D2>&gt; =
Handoff=20
  Candidate Discovery=20
  =
Issues&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;=20
  HCD Authors&nbsp;&nbsp;&nbsp;&nbsp; 15 mins</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp; =
(draft-ietf-seamoby-CARdiscovery-issues-00.txt)</FONT>=20
  <BR><FONT size=3D2>&gt; Proceeding on Paging (DMHA)&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; All&nbsp;&nbsp;&nbsp;&nbsp; =

  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 mins</FONT> <BR><FONT=20
  size=3D2>&gt; Adjourn</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Wednesday August 8th</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; 1530-1730</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; CT Framework=20
  =
Issues&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Kenward&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 mins</FONT> =

  <BR><FONT size=3D2>&gt;&nbsp;&nbsp; =
(draft-hamid-seamoby-ct-fwk-00.txt)</FONT>=20
  <BR><FONT size=3D2>&gt; CT=20
  =
Applicability&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  Koodli&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 =
mins</FONT>=20
  <BR><FONT size=3D2>&gt;&nbsp;&nbsp; =
(draft-koodli-seamoby-ctv6-00.txt)</FONT>=20
  <BR><FONT size=3D2>&gt; Context Transfer Requirements=20
  Discussions&nbsp;&nbsp;&nbsp;&nbsp; All&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 90 mins</FONT> <BR><FONT=20
  size=3D2>&gt;&nbsp;&nbsp; (draft-ietf-seamoby-ct-reqs-00.txt)</FONT> =
<BR><FONT=20
  size=3D2>&gt; Closure/Next Steps&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Chair&nbsp;&nbsp;=20
  &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10 mins</FONT> <BR><FONT=20
  size=3D2>&gt; Adjourn</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  Thanks,</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
PatC</FONT>=20
  </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0038_01C11686.39D3DFE0--



From owner-seamoby@diameter.org  Fri Jul 27 10:37:01 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22298
	for <seamoby-archive@odin.ietf.org>; Fri, 27 Jul 2001 10:37:00 -0400 (EDT)
Received: (qmail 17197 invoked by alias); 27 Jul 2001 14:25:57 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 17191 invoked by uid 200); 27 Jul 2001 14:25:57 -0000
Received: (qmail 17182 invoked by uid 500); 27 Jul 2001 14:25:55 -0000
Date: Fri, 27 Jul 2001 07:25:55 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Hamid Syed <hmsyed@nortelnetworks.com>
Cc: Pat Calhoun <pcalhoun@diameter.org>, seamoby <seamoby@cdma-2000.org>
Subject: Re: [seamoby] Final Seamoby Agenda
Message-ID: <20010727072555.V13541@charizard.diameter.org>
Mail-Followup-To: Hamid Syed <hmsyed@nortelnetworks.com>,
	Pat Calhoun <pcalhoun@diameter.org>,
	seamoby <seamoby@cdma-2000.org>
References: <20010725090552.G10225@charizard.diameter.org> <003b01c116c0$e67d7c80$9e31812f@ca.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <003b01c116c0$e67d7c80$9e31812f@ca.nortel.com>; from hmsyed@nortelnetworks.com on Fri, Jul 27, 2001 at 10:23:49AM -0700
Sender: owner-seamoby@diameter.org
Precedence: bulk

On Fri, Jul 27, 2001 at 10:23:49AM -0700, Hamid Syed wrote:
> Re: [seamoby] Final Seamoby AgendaPat,
> 
> I think a framework definition is very important to capture the various aspects of ct that can enable a seamless handover. We had some very good disicussions on the list regarding proactive/reactive ct modes , the triggers to initiate each of them and a handover candidate discovery mechanism is under considerations too. All these bits and pieces are taken, for the time being as separate items but in reality they are inter-related. The ordering and timing of various network events together with handoff candidate discovery and context transfer between ARs should follow some specified patterns. 
> 

ok, let me try. So, a framework kind of puts everything in perspective?
How is it better than just defining a protocol? Does it describe how it is
actually used? You mention triggers, but there is separate effort under
way to define triggers, and as you know, they are very technology specific.
Speaking of, CT will behave differently based on the mobility management
protocol used. 

> Seamoby definitely needs a CT framework that can capture the relationship between all the pieces we are discussing today. Otherwise, defining a protocol to carry some information from one point to the other is not that trivial and would not help improving the performance of handover.

So what are all the pieces? You mean all of the Seamoby protocol(s) and
perhaps even mobility management protocols as well? If this is what you
mean, then I would tend to agree. Some guidance on how to take these
protocols and implement them in such a way that it actually works, would
be beneficial.

PatC


From owner-seamoby@diameter.org  Fri Jul 27 10:51:58 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23809
	for <seamoby-archive@odin.ietf.org>; Fri, 27 Jul 2001 10:51:48 -0400 (EDT)
Received: (qmail 17753 invoked by alias); 27 Jul 2001 14:40:25 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 17747 invoked by uid 200); 27 Jul 2001 14:40:25 -0000
Received: (qmail 17739 invoked from network); 27 Jul 2001 14:40:23 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jul 2001 14:40:23 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <PT5HX5FH>; Fri, 27 Jul 2001 10:50:52 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484455F3@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>,
        Hamid Syed <hmsyed@nortelnetworks.com>
Cc: seamoby <seamoby@cdma-2000.org>
Subject: RE: [seamoby] Final Seamoby Agenda
Date: Fri, 27 Jul 2001 10:50:43 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-seamoby@diameter.org
Precedence: bulk

Hello Hamid,

Framework is another one of those "overloaded" words to be
consider dangerous.  Typically, I think of things like the
"don't call us, we'll call you" paradigm of software
development, i.e. somebody has identified the useful design
patterns for a particular problem domain and has provided
a framework, upon which you can build your own applications.
Microsoft's Foundation Classes (MFC) come to mind, and there
are lots of other commercial OO frameworks.  

I have seen the word "framework" abused in the embedded real
time community to mean something like the main event loop 
logic.  

Your use of the term *seems* to be the one I love to hate,
i.e. some kind of monolothic all knowing scroll that tells
you what all the problems you are going to encounter are
going to be.  We have been down this path MANY times in
SeaMoby and each time we have come to the same "cul de sac".

The IETF ain't a good place to do architectural work!!!!

So, what I am saying, is though a framework may be useful
for you in your company's development and documentation
efforts, it is not likely to fly very far in the IETF.
At least that has been my experience so far...

Thanks,

Phil

> -----Original Message-----
> From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> Sent: Friday, July 27, 2001 10:26 AM
> To: Hamid Syed
> Cc: Pat Calhoun; seamoby
> Subject: Re: [seamoby] Final Seamoby Agenda
> 
> 
> On Fri, Jul 27, 2001 at 10:23:49AM -0700, Hamid Syed wrote:
> > Re: [seamoby] Final Seamoby AgendaPat,
> > 
> > I think a framework definition is very important to capture 
> the various aspects of ct that can enable a seamless 
> handover. We had some very good disicussions on the list 
> regarding proactive/reactive ct modes , the triggers to 
> initiate each of them and a handover candidate discovery 
> mechanism is under considerations too. All these bits and 
> pieces are taken, for the time being as separate items but in 
> reality they are inter-related. The ordering and timing of 
> various network events together with handoff candidate 
> discovery and context transfer between ARs should follow some 
> specified patterns. 
> > 
> 
> ok, let me try. So, a framework kind of puts everything in 
> perspective?
> How is it better than just defining a protocol? Does it 
> describe how it is
> actually used? You mention triggers, but there is separate 
> effort under
> way to define triggers, and as you know, they are very 
> technology specific.
> Speaking of, CT will behave differently based on the mobility 
> management
> protocol used. 
> 
> > Seamoby definitely needs a CT framework that can capture 
> the relationship between all the pieces we are discussing 
> today. Otherwise, defining a protocol to carry some 
> information from one point to the other is not that trivial 
> and would not help improving the performance of handover.
> 
> So what are all the pieces? You mean all of the Seamoby 
> protocol(s) and
> perhaps even mobility management protocols as well? If this 
> is what you
> mean, then I would tend to agree. Some guidance on how to take these
> protocols and implement them in such a way that it actually 
> works, would
> be beneficial.
> 
> PatC
> 


From owner-seamoby@diameter.org  Fri Jul 27 11:06:38 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25345
	for <seamoby-archive@odin.ietf.org>; Fri, 27 Jul 2001 11:06:34 -0400 (EDT)
Received: (qmail 18289 invoked by alias); 27 Jul 2001 14:53:53 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18283 invoked by uid 200); 27 Jul 2001 14:53:53 -0000
Received: (qmail 18275 invoked from network); 27 Jul 2001 14:53:50 -0000
Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jul 2001 14:53:50 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6RF3x904908
	for <seamoby@cdma-2000.org>; Fri, 27 Jul 2001 11:03:59 -0400 (EDT)
Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 27 Jul 2001 11:03:55 -0400
Received: from zcard031.ca.nortel.com ([47.129.242.121]) 
          by zcard015.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id PMVSDVZK; Fri, 27 Jul 2001 11:03:57 -0400
Received: from cr541699a (acart41n.ca.nortel.com [47.129.49.158]) 
          by zcard031.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id PXPDSSZY; Fri, 27 Jul 2001 11:03:57 -0400
Message-ID: <009701c116c6$7855a920$9e31812f@ca.nortel.com>
X-Sybari-Space: 00000000 00000000 00000000
From: "Hamid Syed" <hmsyed@nortelnetworks.com>
To: Pat Calhoun <pcalhoun@diameter.org>,
        "Hamid Syed" <hmsyed@nortelnetworks.com>
Cc: Pat Calhoun <pcalhoun@diameter.org>, seamoby <seamoby@cdma-2000.org>
References: <20010727072555.V13541@charizard.diameter.org>
Subject: Re: [seamoby] Final Seamoby Agenda
Date: Fri, 27 Jul 2001 11:03:41 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_0094_01C1168B.CB8A7AC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Orig: <hmsyed@nortelnetworks.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0094_01C1168B.CB8A7AC0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Re: [seamoby] Final Seamoby Agenda
  ----- Original Message -----=20
  From: Pat Calhoun=20
  To: Syed, Hamid [WDLN2:AN22:EXCH]=20
  Cc: Pat Calhoun ; seamoby=20
  Sent: Friday, July 27, 2001 7:25 AM
  Subject: Re: [seamoby] Final Seamoby Agenda


  On Fri, Jul 27, 2001 at 10:23:49AM -0700, Hamid Syed wrote:=20
  > Re: [seamoby] Final Seamoby AgendaPat,=20
  >=20
  > I think a framework definition is very important to capture the =
various aspects of ct that can enable a seamless handover. We had some =
very good disicussions on the list regarding proactive/reactive ct modes =
, the triggers to initiate each of them and a handover candidate =
discovery mechanism is under considerations too. All these bits and =
pieces are taken, for the time being as separate items but in reality =
they are inter-related. The ordering and timing of various network =
events together with handoff candidate discovery and context transfer =
between ARs should follow some specified patterns.=20

  >=20

  ok, let me try. So, a framework kind of puts everything in =
perspective?=20
  How is it better than just defining a protocol? Does it describe how =
it is=20
  actually used? You mention triggers, but there is separate effort =
under=20
  way to define triggers, and as you know, they are very technology =
specific.=20
  Speaking of, CT will behave differently based on the mobility =
management=20
  protocol used.=20

  I know some efforts are being taken like the triggers at the seamoby. =
The framework does not mean to define every protocols. It rather =
provides the ordering of events and messages happening, identifies the =
entiteis and required protocols between various entities. The identified =
protoocls and any events then can be taken separately

  > Seamoby definitely needs a CT framework that can capture the =
relationship between all the pieces we are discussing today. Otherwise, =
defining a protocol to carry some information from one point to the =
other is not that trivial and would not help improving the performance =
of handover.

  So what are all the pieces? You mean all of the Seamoby protocol(s) =
and=20
  perhaps even mobility management protocols as well? If this is what =
you=20
  mean, then I would tend to agree. Some guidance on how to take these=20
  protocols and implement them in such a way that it actually works, =
would=20
  be beneficial.=20



  This is exactly what I mean. We should know ho wthw various protocols =
and events are going to work with each other while the designing of each =
protocol can be taken as a separate workitem.

  PatC=20



  Hamid


------=_NextPart_000_0094_01C1168B.CB8A7AC0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [seamoby] Final Seamoby Agenda</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3Dpcalhoun@diameter.org =
href=3D"mailto:pcalhoun@diameter.org">Pat=20
  Calhoun</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dhmsyed@americasm01.nt.com=20
  href=3D"mailto:hmsyed@americasm01.nt.com">Syed, Hamid =
[WDLN2:AN22:EXCH]</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Dpcalhoun@diameter.org=20
  href=3D"mailto:pcalhoun@diameter.org">Pat Calhoun</A> ; <A=20
  title=3Dseamoby@cdma-2000.org =
href=3D"mailto:seamoby@cdma-2000.org">seamoby</A>=20
  </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, July 27, 2001 =
7:25 AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: [seamoby] Final =
Seamoby=20
  Agenda</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>On Fri, Jul 27, 2001 at 10:23:49AM -0700, Hamid Syed =

  wrote:</FONT> <BR><FONT size=3D2>&gt; Re: [seamoby] Final Seamoby=20
  AgendaPat,</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; I think a=20
  framework definition is very important to capture the various aspects =
of ct=20
  that can enable a seamless handover. We had some very good =
disicussions on the=20
  list regarding proactive/reactive ct modes , the triggers to initiate =
each of=20
  them and a handover candidate discovery mechanism is under =
considerations too.=20
  All these bits and pieces are taken, for the time being as separate =
items but=20
  in reality they are inter-related. The ordering and timing of various =
network=20
  events together with handoff candidate discovery and context transfer =
between=20
  ARs should follow some specified patterns. </FONT></P>
  <P><FONT size=3D2>&gt; </FONT></P>
  <P><FONT size=3D2>ok, let me try. So, a framework kind of puts =
everything in=20
  perspective?</FONT> <BR><FONT size=3D2>How is it better than just =
defining a=20
  protocol? Does it describe how it is</FONT> <BR><FONT =
size=3D2>actually used?=20
  You mention triggers, but there is separate effort under</FONT> =
<BR><FONT=20
  size=3D2>way to define triggers, and as you know, they are very =
technology=20
  specific.</FONT> <BR><FONT size=3D2>Speaking of, CT will behave =
differently=20
  based on the mobility management</FONT> <BR><FONT size=3D2>protocol =
used.=20
  </FONT></P>
  <P><FONT color=3D#0000ff size=3D2>I know some efforts are being taken =
like the=20
  triggers at the seamoby. The framework does not mean to define every=20
  protocols. It rather provides the ordering of events and messages =
happening,=20
  identifies the entiteis and required protocols between various =
entities. The=20
  identified protoocls and any events then can be taken =
separately</FONT></P>
  <P><FONT size=3D2>&gt; Seamoby definitely needs a CT framework that =
can capture=20
  the relationship between all the pieces we are discussing today. =
Otherwise,=20
  defining a protocol to carry some information from one point to the =
other is=20
  not that trivial and would not help improving the performance of=20
  handover.</FONT></P>
  <P><FONT size=3D2>So what are all the pieces? You mean all of the =
Seamoby=20
  protocol(s) and</FONT> <BR><FONT size=3D2>perhaps even mobility =
management=20
  protocols as well? If this is what you</FONT> <BR><FONT size=3D2>mean, =
then I=20
  would tend to agree. Some guidance on how to take these</FONT> =
<BR><FONT=20
  size=3D2>protocols and implement them in such a way that it actually =
works,=20
  would</FONT> <BR><FONT size=3D2>be beneficial.</FONT> </P>
  <P><FONT size=3D2></FONT>&nbsp;</P>
  <P><FONT size=3D2><FONT color=3D#0000ff>This is exactly what I mean. =
We should=20
  know ho wthw various protocols and events are going to work with each =
other=20
  while the designing of each protocol can be taken as a separate=20
  workitem</FONT>.</FONT></P>
  <P><FONT size=3D2>PatC</FONT> </P>
  <P><FONT size=3D2></FONT>&nbsp;</P>
  <P><FONT color=3D#0000ff =
size=3D2>Hamid</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0094_01C1168B.CB8A7AC0--



From owner-seamoby@diameter.org  Fri Jul 27 11:13:28 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25962
	for <seamoby-archive@odin.ietf.org>; Fri, 27 Jul 2001 11:13:19 -0400 (EDT)
Received: (qmail 18484 invoked by alias); 27 Jul 2001 14:55:52 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18478 invoked by uid 200); 27 Jul 2001 14:55:52 -0000
Received: (qmail 18468 invoked from network); 27 Jul 2001 14:55:49 -0000
Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jul 2001 14:55:49 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6RF5v905620
	for <seamoby@cdma-2000.org>; Fri, 27 Jul 2001 11:05:57 -0400 (EDT)
Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 27 Jul 2001 11:05:52 -0400
Received: from zcard031.ca.nortel.com ([47.129.242.121]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id PQFPX5XD; Fri, 27 Jul 2001 11:05:51 -0400
Received: from cr541699a (acart41n.ca.nortel.com [47.129.49.158]) 
          by zcard031.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id PXPDSSZ6; Fri, 27 Jul 2001 11:05:51 -0400
Message-ID: <00a201c116c6$bc2bb040$9e31812f@ca.nortel.com>
X-Sybari-Space: 00000000 00000000 00000000
From: "Hamid Syed" <hmsyed@nortelnetworks.com>
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>,
        "Hamid Syed" <hmsyed@nortelnetworks.com>
Cc: seamoby <seamoby@cdma-2000.org>
References: <0DF9FBC42474A24CA50F7A27FB08E0484455F3@meshpdc.meshnetworks.com>
Subject: Re: [seamoby] Final Seamoby Agenda
Date: Fri, 27 Jul 2001 11:05:35 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_009F_01C1168C.0F682300"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Orig: <hmsyed@nortelnetworks.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_009F_01C1168C.0F682300
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [seamoby] Final Seamoby AgendaPhil,

I can point you to number of IETF WGs that did define frameowrks and =
then worked on the protocol design. This is not true to say that =
frameworks does not fly at the IETF.=20

-Hamid
  ----- Original Message -----=20
  From: Phillip Neumiller=20
  To: 'Pat Calhoun' ; Syed, Hamid [WDLN2:AN22:EXCH]=20
  Cc: seamoby=20
  Sent: Friday, July 27, 2001 7:50 AM
  Subject: RE: [seamoby] Final Seamoby Agenda


  Hello Hamid,=20

  Framework is another one of those "overloaded" words to be=20
  consider dangerous.  Typically, I think of things like the=20
  "don't call us, we'll call you" paradigm of software=20
  development, i.e. somebody has identified the useful design=20
  patterns for a particular problem domain and has provided=20
  a framework, upon which you can build your own applications.=20
  Microsoft's Foundation Classes (MFC) come to mind, and there=20
  are lots of other commercial OO frameworks. =20

  I have seen the word "framework" abused in the embedded real=20
  time community to mean something like the main event loop=20
  logic. =20

  Your use of the term *seems* to be the one I love to hate,=20
  i.e. some kind of monolothic all knowing scroll that tells=20
  you what all the problems you are going to encounter are=20
  going to be.  We have been down this path MANY times in=20
  SeaMoby and each time we have come to the same "cul de sac".=20

  The IETF ain't a good place to do architectural work!!!!=20

  So, what I am saying, is though a framework may be useful=20
  for you in your company's development and documentation=20
  efforts, it is not likely to fly very far in the IETF.=20
  At least that has been my experience so far...=20

  Thanks,=20

  Phil=20

  > -----Original Message-----=20
  > From: Pat Calhoun [mailto:pcalhoun@diameter.org]=20
  > Sent: Friday, July 27, 2001 10:26 AM=20
  > To: Hamid Syed=20
  > Cc: Pat Calhoun; seamoby=20
  > Subject: Re: [seamoby] Final Seamoby Agenda=20
  >=20
  >=20
  > On Fri, Jul 27, 2001 at 10:23:49AM -0700, Hamid Syed wrote:=20
  > > Re: [seamoby] Final Seamoby AgendaPat,=20
  > >=20
  > > I think a framework definition is very important to capture=20
  > the various aspects of ct that can enable a seamless=20
  > handover. We had some very good disicussions on the list=20
  > regarding proactive/reactive ct modes , the triggers to=20
  > initiate each of them and a handover candidate discovery=20
  > mechanism is under considerations too. All these bits and=20
  > pieces are taken, for the time being as separate items but in=20
  > reality they are inter-related. The ordering and timing of=20
  > various network events together with handoff candidate=20
  > discovery and context transfer between ARs should follow some=20
  > specified patterns.=20
  > >=20
  >=20
  > ok, let me try. So, a framework kind of puts everything in=20
  > perspective?=20
  > How is it better than just defining a protocol? Does it=20
  > describe how it is=20
  > actually used? You mention triggers, but there is separate=20
  > effort under=20
  > way to define triggers, and as you know, they are very=20
  > technology specific.=20
  > Speaking of, CT will behave differently based on the mobility=20
  > management=20
  > protocol used.=20
  >=20
  > > Seamoby definitely needs a CT framework that can capture=20
  > the relationship between all the pieces we are discussing=20
  > today. Otherwise, defining a protocol to carry some=20
  > information from one point to the other is not that trivial=20
  > and would not help improving the performance of handover.=20
  >=20
  > So what are all the pieces? You mean all of the Seamoby=20
  > protocol(s) and=20
  > perhaps even mobility management protocols as well? If this=20
  > is what you=20
  > mean, then I would tend to agree. Some guidance on how to take these =

  > protocols and implement them in such a way that it actually=20
  > works, would=20
  > be beneficial.=20
  >=20
  > PatC=20
  >=20


------=_NextPart_000_009F_01C1168C.0F682300
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [seamoby] Final Seamoby Agenda</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Phil,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>I can point you to number of IETF WGs =
that did=20
define frameowrks and then worked on the protocol design. This is not =
true to=20
say that frameworks does not fly at the IETF. </FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-Hamid</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3DPNeumiller@MeshNetworks.com=20
  href=3D"mailto:PNeumiller@MeshNetworks.com">Phillip Neumiller</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dpcalhoun@diameter.org=20
  href=3D"mailto:pcalhoun@diameter.org">'Pat Calhoun'</A> ; <A=20
  title=3Dhmsyed@americasm01.nt.com =
href=3D"mailto:hmsyed@americasm01.nt.com">Syed,=20
  Hamid [WDLN2:AN22:EXCH]</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Dseamoby@cdma-2000.org=20
  href=3D"mailto:seamoby@cdma-2000.org">seamoby</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, July 27, 2001 =
7:50 AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [seamoby] Final =
Seamoby=20
  Agenda</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>Hello Hamid,</FONT> </P>
  <P><FONT size=3D2>Framework is another one of those "overloaded" words =
to=20
  be</FONT> <BR><FONT size=3D2>consider dangerous.&nbsp; Typically, I =
think of=20
  things like the</FONT> <BR><FONT size=3D2>"don't call us, we'll call =
you"=20
  paradigm of software</FONT> <BR><FONT size=3D2>development, i.e. =
somebody has=20
  identified the useful design</FONT> <BR><FONT size=3D2>patterns for a =
particular=20
  problem domain and has provided</FONT> <BR><FONT size=3D2>a framework, =
upon=20
  which you can build your own applications.</FONT> <BR><FONT =
size=3D2>Microsoft's=20
  Foundation Classes (MFC) come to mind, and there</FONT> <BR><FONT =
size=3D2>are=20
  lots of other commercial OO frameworks.&nbsp; </FONT></P>
  <P><FONT size=3D2>I have seen the word "framework" abused in the =
embedded=20
  real</FONT> <BR><FONT size=3D2>time community to mean something like =
the main=20
  event loop </FONT><BR><FONT size=3D2>logic.&nbsp; </FONT></P>
  <P><FONT size=3D2>Your use of the term *seems* to be the one I love to =

  hate,</FONT> <BR><FONT size=3D2>i.e. some kind of monolothic all =
knowing scroll=20
  that tells</FONT> <BR><FONT size=3D2>you what all the problems you are =
going to=20
  encounter are</FONT> <BR><FONT size=3D2>going to be.&nbsp; We have =
been down=20
  this path MANY times in</FONT> <BR><FONT size=3D2>SeaMoby and each =
time we have=20
  come to the same "cul de sac".</FONT> </P>
  <P><FONT size=3D2>The IETF ain't a good place to do architectural=20
  work!!!!</FONT> </P>
  <P><FONT size=3D2>So, what I am saying, is though a framework may be=20
  useful</FONT> <BR><FONT size=3D2>for you in your company's development =
and=20
  documentation</FONT> <BR><FONT size=3D2>efforts, it is not likely to =
fly very=20
  far in the IETF.</FONT> <BR><FONT size=3D2>At least that has been my =
experience=20
  so far...</FONT> </P>
  <P><FONT size=3D2>Thanks,</FONT> </P>
  <P><FONT size=3D2>Phil</FONT> </P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Pat Calhoun [<A=20
  =
href=3D"mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]</=
FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Friday, July 27, 2001 10:26 AM</FONT> =
<BR><FONT=20
  size=3D2>&gt; To: Hamid Syed</FONT> <BR><FONT size=3D2>&gt; Cc: Pat =
Calhoun;=20
  seamoby</FONT> <BR><FONT size=3D2>&gt; Subject: Re: [seamoby] Final =
Seamoby=20
  Agenda</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; On Fri, Jul 27, 2001 at 10:23:49AM =
-0700, Hamid=20
  Syed wrote:</FONT> <BR><FONT size=3D2>&gt; &gt; Re: [seamoby] Final =
Seamoby=20
  AgendaPat,</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  I think a framework definition is very important to capture =
</FONT><BR><FONT=20
  size=3D2>&gt; the various aspects of ct that can enable a seamless=20
  </FONT><BR><FONT size=3D2>&gt; handover. We had some very good =
disicussions on=20
  the list </FONT><BR><FONT size=3D2>&gt; regarding proactive/reactive =
ct modes ,=20
  the triggers to </FONT><BR><FONT size=3D2>&gt; initiate each of them =
and a=20
  handover candidate discovery </FONT><BR><FONT size=3D2>&gt; mechanism =
is under=20
  considerations too. All these bits and </FONT><BR><FONT size=3D2>&gt; =
pieces are=20
  taken, for the time being as separate items but in </FONT><BR><FONT=20
  size=3D2>&gt; reality they are inter-related. The ordering and timing =
of=20
  </FONT><BR><FONT size=3D2>&gt; various network events together with =
handoff=20
  candidate </FONT><BR><FONT size=3D2>&gt; discovery and context =
transfer between=20
  ARs should follow some </FONT><BR><FONT size=3D2>&gt; specified =
patterns.=20
  </FONT><BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; ok, let me try. So, a framework kind of =
puts=20
  everything in </FONT><BR><FONT size=3D2>&gt; perspective?</FONT> =
<BR><FONT=20
  size=3D2>&gt; How is it better than just defining a protocol? Does it=20
  </FONT><BR><FONT size=3D2>&gt; describe how it is</FONT> <BR><FONT =
size=3D2>&gt;=20
  actually used? You mention triggers, but there is separate =
</FONT><BR><FONT=20
  size=3D2>&gt; effort under</FONT> <BR><FONT size=3D2>&gt; way to =
define triggers,=20
  and as you know, they are very </FONT><BR><FONT size=3D2>&gt; =
technology=20
  specific.</FONT> <BR><FONT size=3D2>&gt; Speaking of, CT will behave =
differently=20
  based on the mobility </FONT><BR><FONT size=3D2>&gt; management</FONT> =
<BR><FONT=20
  size=3D2>&gt; protocol used. </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; Seamoby definitely needs a CT framework that can =
capture=20
  </FONT><BR><FONT size=3D2>&gt; the relationship between all the pieces =
we are=20
  discussing </FONT><BR><FONT size=3D2>&gt; today. Otherwise, defining a =
protocol=20
  to carry some </FONT><BR><FONT size=3D2>&gt; information from one =
point to the=20
  other is not that trivial </FONT><BR><FONT size=3D2>&gt; and would not =
help=20
  improving the performance of handover.</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; So what are all the pieces? You mean =
all of the=20
  Seamoby </FONT><BR><FONT size=3D2>&gt; protocol(s) and</FONT> =
<BR><FONT=20
  size=3D2>&gt; perhaps even mobility management protocols as well? If =
this=20
  </FONT><BR><FONT size=3D2>&gt; is what you</FONT> <BR><FONT =
size=3D2>&gt; mean,=20
  then I would tend to agree. Some guidance on how to take these</FONT>=20
  <BR><FONT size=3D2>&gt; protocols and implement them in such a way =
that it=20
  actually </FONT><BR><FONT size=3D2>&gt; works, would</FONT> <BR><FONT=20
  size=3D2>&gt; be beneficial.</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; PatC</FONT> <BR><FONT size=3D2>&gt;=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_009F_01C1168C.0F682300--



From owner-seamoby@diameter.org  Fri Jul 27 11:27:04 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27286
	for <seamoby-archive@odin.ietf.org>; Fri, 27 Jul 2001 11:27:03 -0400 (EDT)
Received: (qmail 19724 invoked by alias); 27 Jul 2001 15:13:47 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 19717 invoked by uid 200); 27 Jul 2001 15:13:47 -0000
Received: (qmail 19705 invoked from network); 27 Jul 2001 15:13:43 -0000
Received: from softdnserror (HELO meshpdc.meshnetworks.com) (205.245.27.196)
  by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jul 2001 15:13:44 -0000
Received: by meshpdc.meshnetworks.com with Internet Mail Service (5.5.2653.19)
	id <PT5HX5G0>; Fri, 27 Jul 2001 11:24:13 -0400
Message-ID: <0DF9FBC42474A24CA50F7A27FB08E0484455F4@meshpdc.meshnetworks.com>
From: Phillip Neumiller <PNeumiller@MeshNetworks.com>
To: "'Hamid Syed'" <hmsyed@nortelnetworks.com>,
        Phillip Neumiller <PNeumiller@MeshNetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: seamoby <seamoby@cdma-2000.org>
Subject: RE: [seamoby] Final Seamoby Agenda
Date: Fri, 27 Jul 2001 11:24:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C116B0.2CD7CD40"
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C116B0.2CD7CD40
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Hamid,
 
I stand corrected then.  Could you please go ahead and point them out to us?

I for one would like to see some evidence of this.  I am probably on your
side,
but I need to know WHAT it is you MEAN by framework and some IETF examples
would be extremely useful.
 
Thanks,
 
Phil

-----Original Message-----
From: Hamid Syed [mailto:hmsyed@nortelnetworks.com]
Sent: Friday, July 27, 2001 2:06 PM
To: Phillip Neumiller; 'Pat Calhoun'; Hamid Syed
Cc: seamoby
Subject: Re: [seamoby] Final Seamoby Agenda


Phil,
 
I can point you to number of IETF WGs that did define frameowrks and then
worked on the protocol design. This is not true to say that frameworks does
not fly at the IETF. 
 
-Hamid

 


------_=_NextPart_001_01C116B0.2CD7CD40
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: [seamoby] Final Seamoby Agenda</TITLE>

<META content="MSHTML 5.00.3103.1000" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=106532115-27072001>Hi 
Hamid,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=106532115-27072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=106532115-27072001>I 
stand corrected then.&nbsp; Could you please go ahead and point them out to 
us?&nbsp; </SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=106532115-27072001>I for 
one would like to see some evidence of this.&nbsp; I am probably on your 
side,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=106532115-27072001>but I 
need to know WHAT it is you MEAN by framework and some</SPAN></FONT><FONT 
color=#0000ff face=Arial size=2><SPAN class=106532115-27072001>&nbsp;IETF 
examples</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN class=106532115-27072001>would 
be extremely useful.</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=106532115-27072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=106532115-27072001>Thanks,</SPAN></FONT></DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=106532115-27072001></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=#0000ff face=Arial size=2><SPAN 
class=106532115-27072001>Phil</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hamid Syed 
  [mailto:hmsyed@nortelnetworks.com]<BR><B>Sent:</B> Friday, July 27, 2001 2:06 
  PM<BR><B>To:</B> Phillip Neumiller; 'Pat Calhoun'; Hamid Syed<BR><B>Cc:</B> 
  seamoby<BR><B>Subject:</B> Re: [seamoby] Final Seamoby 
  Agenda<BR><BR></DIV></FONT>
  <DIV><FONT face=Arial size=2>Phil,</FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>I can point you to number of IETF WGs that did 
  define frameowrks and then worked on the protocol design. This is not true to 
  say that frameworks does not fly at the IETF. </FONT></DIV>
  <DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
  <DIV><FONT face=Arial size=2>-Hamid</FONT></DIV>
  <BLOCKQUOTE dir=ltr 
  style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
    <DIV 
style="FONT: 10pt arial">&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C116B0.2CD7CD40--


From owner-seamoby@diameter.org  Fri Jul 27 11:40:40 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28455
	for <seamoby-archive@odin.ietf.org>; Fri, 27 Jul 2001 11:40:39 -0400 (EDT)
Received: (qmail 18628 invoked by alias); 27 Jul 2001 14:57:26 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 18622 invoked by uid 200); 27 Jul 2001 14:57:25 -0000
Received: (qmail 18614 invoked from network); 27 Jul 2001 14:57:22 -0000
Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jul 2001 14:57:22 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6RF7V906203
	for <seamoby@cdma-2000.org>; Fri, 27 Jul 2001 11:07:31 -0400 (EDT)
Received: from zcard015.ca.nortel.com (actually zcard015) 
          by zcars04e.ca.nortel.com; Fri, 27 Jul 2001 11:07:32 -0400
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <PMVSDV7V>; Fri, 27 Jul 2001 11:07:33 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C9F5E9E@zcard031.ca.nortel.com>
From: "Gary Kenward" <gkenward@nortelnetworks.com>
To: "'Phillip Neumiller'" <PNeumiller@MeshNetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: seamoby <seamoby@cdma-2000.org>
Subject: RE: [seamoby] Final Seamoby Agenda
Date: Fri, 27 Jul 2001 11:07:30 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C116AD.DAEF3E70"
X-Orig: <gkenward@americasm01.nt.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C116AD.DAEF3E70
Content-Type: text/plain;
	charset="iso-8859-1"

Yes, Phil, bottom up design works so very well ;^|

Gary

> -----Original Message-----
> From: Phillip Neumiller [mailto:PNeumiller@MeshNetworks.com]
> Sent: July 27, 2001 10:51
> To: 'Pat Calhoun'; Syed, Hamid [WDLN2:AN22:EXCH]
> Cc: seamoby
> Subject: RE: [seamoby] Final Seamoby Agenda
> 
> 
> Hello Hamid,
> 
> Framework is another one of those "overloaded" words to be
> consider dangerous.  Typically, I think of things like the
> "don't call us, we'll call you" paradigm of software
> development, i.e. somebody has identified the useful design
> patterns for a particular problem domain and has provided
> a framework, upon which you can build your own applications.
> Microsoft's Foundation Classes (MFC) come to mind, and there
> are lots of other commercial OO frameworks.  
> 
> I have seen the word "framework" abused in the embedded real
> time community to mean something like the main event loop 
> logic.  
> 
> Your use of the term *seems* to be the one I love to hate,
> i.e. some kind of monolothic all knowing scroll that tells
> you what all the problems you are going to encounter are
> going to be.  We have been down this path MANY times in
> SeaMoby and each time we have come to the same "cul de sac".
> 
> The IETF ain't a good place to do architectural work!!!!
> 
> So, what I am saying, is though a framework may be useful
> for you in your company's development and documentation
> efforts, it is not likely to fly very far in the IETF.
> At least that has been my experience so far...
> 
> Thanks,
> 
> Phil
> 
> > -----Original Message-----
> > From: Pat Calhoun [mailto:pcalhoun@diameter.org]
> > Sent: Friday, July 27, 2001 10:26 AM
> > To: Hamid Syed
> > Cc: Pat Calhoun; seamoby
> > Subject: Re: [seamoby] Final Seamoby Agenda
> > 
> > 
> > On Fri, Jul 27, 2001 at 10:23:49AM -0700, Hamid Syed wrote:
> > > Re: [seamoby] Final Seamoby AgendaPat,
> > > 
> > > I think a framework definition is very important to capture 
> > the various aspects of ct that can enable a seamless 
> > handover. We had some very good disicussions on the list 
> > regarding proactive/reactive ct modes , the triggers to 
> > initiate each of them and a handover candidate discovery 
> > mechanism is under considerations too. All these bits and 
> > pieces are taken, for the time being as separate items but in 
> > reality they are inter-related. The ordering and timing of 
> > various network events together with handoff candidate 
> > discovery and context transfer between ARs should follow some 
> > specified patterns. 
> > > 
> > 
> > ok, let me try. So, a framework kind of puts everything in 
> > perspective?
> > How is it better than just defining a protocol? Does it 
> > describe how it is
> > actually used? You mention triggers, but there is separate 
> > effort under
> > way to define triggers, and as you know, they are very 
> > technology specific.
> > Speaking of, CT will behave differently based on the mobility 
> > management
> > protocol used. 
> > 
> > > Seamoby definitely needs a CT framework that can capture 
> > the relationship between all the pieces we are discussing 
> > today. Otherwise, defining a protocol to carry some 
> > information from one point to the other is not that trivial 
> > and would not help improving the performance of handover.
> > 
> > So what are all the pieces? You mean all of the Seamoby 
> > protocol(s) and
> > perhaps even mobility management protocols as well? If this 
> > is what you
> > mean, then I would tend to agree. Some guidance on how to take these
> > protocols and implement them in such a way that it actually 
> > works, would
> > be beneficial.
> > 
> > PatC
> > 
> 

------_=_NextPart_001_01C116AD.DAEF3E70
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.89">
<TITLE>RE: [seamoby] Final Seamoby Agenda</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Yes, Phil, bottom up design works so very well ;^|</FONT>
</P>

<P><FONT SIZE=2>Gary</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Phillip Neumiller [<A HREF="mailto:PNeumiller@MeshNetworks.com">mailto:PNeumiller@MeshNetworks.com</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: July 27, 2001 10:51</FONT>
<BR><FONT SIZE=2>&gt; To: 'Pat Calhoun'; Syed, Hamid [WDLN2:AN22:EXCH]</FONT>
<BR><FONT SIZE=2>&gt; Cc: seamoby</FONT>
<BR><FONT SIZE=2>&gt; Subject: RE: [seamoby] Final Seamoby Agenda</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Hello Hamid,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Framework is another one of those &quot;overloaded&quot; words to be</FONT>
<BR><FONT SIZE=2>&gt; consider dangerous.&nbsp; Typically, I think of things like the</FONT>
<BR><FONT SIZE=2>&gt; &quot;don't call us, we'll call you&quot; paradigm of software</FONT>
<BR><FONT SIZE=2>&gt; development, i.e. somebody has identified the useful design</FONT>
<BR><FONT SIZE=2>&gt; patterns for a particular problem domain and has provided</FONT>
<BR><FONT SIZE=2>&gt; a framework, upon which you can build your own applications.</FONT>
<BR><FONT SIZE=2>&gt; Microsoft's Foundation Classes (MFC) come to mind, and there</FONT>
<BR><FONT SIZE=2>&gt; are lots of other commercial OO frameworks.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I have seen the word &quot;framework&quot; abused in the embedded real</FONT>
<BR><FONT SIZE=2>&gt; time community to mean something like the main event loop </FONT>
<BR><FONT SIZE=2>&gt; logic.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Your use of the term *seems* to be the one I love to hate,</FONT>
<BR><FONT SIZE=2>&gt; i.e. some kind of monolothic all knowing scroll that tells</FONT>
<BR><FONT SIZE=2>&gt; you what all the problems you are going to encounter are</FONT>
<BR><FONT SIZE=2>&gt; going to be.&nbsp; We have been down this path MANY times in</FONT>
<BR><FONT SIZE=2>&gt; SeaMoby and each time we have come to the same &quot;cul de sac&quot;.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The IETF ain't a good place to do architectural work!!!!</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So, what I am saying, is though a framework may be useful</FONT>
<BR><FONT SIZE=2>&gt; for you in your company's development and documentation</FONT>
<BR><FONT SIZE=2>&gt; efforts, it is not likely to fly very far in the IETF.</FONT>
<BR><FONT SIZE=2>&gt; At least that has been my experience so far...</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thanks,</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Phil</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; &gt; From: Pat Calhoun [<A HREF="mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]</FONT>
<BR><FONT SIZE=2>&gt; &gt; Sent: Friday, July 27, 2001 10:26 AM</FONT>
<BR><FONT SIZE=2>&gt; &gt; To: Hamid Syed</FONT>
<BR><FONT SIZE=2>&gt; &gt; Cc: Pat Calhoun; seamoby</FONT>
<BR><FONT SIZE=2>&gt; &gt; Subject: Re: [seamoby] Final Seamoby Agenda</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; On Fri, Jul 27, 2001 at 10:23:49AM -0700, Hamid Syed wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Re: [seamoby] Final Seamoby AgendaPat,</FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; I think a framework definition is very important to capture </FONT>
<BR><FONT SIZE=2>&gt; &gt; the various aspects of ct that can enable a seamless </FONT>
<BR><FONT SIZE=2>&gt; &gt; handover. We had some very good disicussions on the list </FONT>
<BR><FONT SIZE=2>&gt; &gt; regarding proactive/reactive ct modes , the triggers to </FONT>
<BR><FONT SIZE=2>&gt; &gt; initiate each of them and a handover candidate discovery </FONT>
<BR><FONT SIZE=2>&gt; &gt; mechanism is under considerations too. All these bits and </FONT>
<BR><FONT SIZE=2>&gt; &gt; pieces are taken, for the time being as separate items but in </FONT>
<BR><FONT SIZE=2>&gt; &gt; reality they are inter-related. The ordering and timing of </FONT>
<BR><FONT SIZE=2>&gt; &gt; various network events together with handoff candidate </FONT>
<BR><FONT SIZE=2>&gt; &gt; discovery and context transfer between ARs should follow some </FONT>
<BR><FONT SIZE=2>&gt; &gt; specified patterns. </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; ok, let me try. So, a framework kind of puts everything in </FONT>
<BR><FONT SIZE=2>&gt; &gt; perspective?</FONT>
<BR><FONT SIZE=2>&gt; &gt; How is it better than just defining a protocol? Does it </FONT>
<BR><FONT SIZE=2>&gt; &gt; describe how it is</FONT>
<BR><FONT SIZE=2>&gt; &gt; actually used? You mention triggers, but there is separate </FONT>
<BR><FONT SIZE=2>&gt; &gt; effort under</FONT>
<BR><FONT SIZE=2>&gt; &gt; way to define triggers, and as you know, they are very </FONT>
<BR><FONT SIZE=2>&gt; &gt; technology specific.</FONT>
<BR><FONT SIZE=2>&gt; &gt; Speaking of, CT will behave differently based on the mobility </FONT>
<BR><FONT SIZE=2>&gt; &gt; management</FONT>
<BR><FONT SIZE=2>&gt; &gt; protocol used. </FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; &gt; Seamoby definitely needs a CT framework that can capture </FONT>
<BR><FONT SIZE=2>&gt; &gt; the relationship between all the pieces we are discussing </FONT>
<BR><FONT SIZE=2>&gt; &gt; today. Otherwise, defining a protocol to carry some </FONT>
<BR><FONT SIZE=2>&gt; &gt; information from one point to the other is not that trivial </FONT>
<BR><FONT SIZE=2>&gt; &gt; and would not help improving the performance of handover.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; So what are all the pieces? You mean all of the Seamoby </FONT>
<BR><FONT SIZE=2>&gt; &gt; protocol(s) and</FONT>
<BR><FONT SIZE=2>&gt; &gt; perhaps even mobility management protocols as well? If this </FONT>
<BR><FONT SIZE=2>&gt; &gt; is what you</FONT>
<BR><FONT SIZE=2>&gt; &gt; mean, then I would tend to agree. Some guidance on how to take these</FONT>
<BR><FONT SIZE=2>&gt; &gt; protocols and implement them in such a way that it actually </FONT>
<BR><FONT SIZE=2>&gt; &gt; works, would</FONT>
<BR><FONT SIZE=2>&gt; &gt; be beneficial.</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; &gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; &gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C116AD.DAEF3E70--


From owner-seamoby@diameter.org  Fri Jul 27 12:17:05 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02346
	for <seamoby-archive@odin.ietf.org>; Fri, 27 Jul 2001 12:17:03 -0400 (EDT)
Received: (qmail 20947 invoked by alias); 27 Jul 2001 16:04:44 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20941 invoked by uid 200); 27 Jul 2001 16:04:44 -0000
Received: (qmail 20932 invoked from network); 27 Jul 2001 16:04:42 -0000
Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jul 2001 16:04:42 -0000
Received: from zcars04e.ca.nortel.com (zcars04e.ca.nortel.com [47.129.242.56])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6RGEp902498
	for <seamoby@cdma-2000.org>; Fri, 27 Jul 2001 12:14:51 -0400 (EDT)
Received: from zcard00n.ca.nortel.com by zcars04e.ca.nortel.com;
          Fri, 27 Jul 2001 12:14:52 -0400
Received: from zcard031.ca.nortel.com ([47.129.242.121]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id PQFPY1WC; Fri, 27 Jul 2001 12:14:48 -0400
Received: from cr541699a (acart41n.ca.nortel.com [47.129.49.158]) 
          by zcard031.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id PXPDSS5Q; Fri, 27 Jul 2001 12:14:48 -0400
Message-ID: <00e901c116d0$5de0b260$9e31812f@ca.nortel.com>
X-Sybari-Space: 00000000 00000000 00000000
From: "Hamid Syed" <hmsyed@nortelnetworks.com>
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: seamoby <seamoby@cdma-2000.org>, "Hamid Syed" <hmsyed@nortelnetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>
References: <0DF9FBC42474A24CA50F7A27FB08E0484455F4@meshpdc.meshnetworks.com>
Subject: Re: [seamoby] Final Seamoby Agenda
Date: Fri, 27 Jul 2001 12:14:30 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_00E6_01C11695.B042F1C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Orig: <hmsyed@nortelnetworks.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00E6_01C11695.B042F1C0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [seamoby] Final Seamoby AgendaHello Phil,

One very recent work in progress is "draft-ietf-midcom-framework-03.txt" =
at the midcom WG.

-Hamid
  ----- Original Message -----=20
  From: Phillip Neumiller=20
  To: Syed, Hamid [WDLN2:AN22:EXCH] ; Phillip Neumiller ; 'Pat Calhoun'=20
  Cc: seamoby=20
  Sent: Friday, July 27, 2001 8:24 AM
  Subject: RE: [seamoby] Final Seamoby Agenda


  Hi Hamid,

  I stand corrected then.  Could you please go ahead and point them out =
to us? =20
  I for one would like to see some evidence of this.  I am probably on =
your side,
  but I need to know WHAT it is you MEAN by framework and some IETF =
examples
  would be extremely useful.

  Thanks,

  Phil
    -----Original Message-----
    From: Hamid Syed [mailto:hmsyed@nortelnetworks.com]
    Sent: Friday, July 27, 2001 2:06 PM
    To: Phillip Neumiller; 'Pat Calhoun'; Hamid Syed
    Cc: seamoby
    Subject: Re: [seamoby] Final Seamoby Agenda


    Phil,

    I can point you to number of IETF WGs that did define frameowrks and =
then worked on the protocol design. This is not true to say that =
frameworks does not fly at the IETF.=20

    -Hamid


------=_NextPart_000_00E6_01C11695.B042F1C0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [seamoby] Final Seamoby Agenda</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hello Phil,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>One very recent work in progress is =
"d</FONT><FONT=20
face=3DArial size=3D2>raft-ietf-midcom-framework-03.txt" at the midcom=20
WG.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-Hamid</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3DPNeumiller@MeshNetworks.com=20
  href=3D"mailto:PNeumiller@MeshNetworks.com">Phillip Neumiller</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dhmsyed@americasm01.nt.com=20
  href=3D"mailto:hmsyed@americasm01.nt.com">Syed, Hamid =
[WDLN2:AN22:EXCH]</A> ; <A=20
  title=3DPNeumiller@MeshNetworks.com=20
  href=3D"mailto:PNeumiller@MeshNetworks.com">Phillip Neumiller</A> ; <A =

  title=3Dpcalhoun@diameter.org =
href=3D"mailto:pcalhoun@diameter.org">'Pat=20
  Calhoun'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Dseamoby@cdma-2000.org=20
  href=3D"mailto:seamoby@cdma-2000.org">seamoby</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, July 27, 2001 =
8:24 AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [seamoby] Final =
Seamoby=20
  Agenda</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D106532115-27072001>Hi=20
  Hamid,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D106532115-27072001>I=20
  stand corrected then.&nbsp; Could you please go ahead and point them =
out to=20
  us?&nbsp; </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D106532115-27072001>I=20
  for one would like to see some evidence of this.&nbsp; I am probably =
on your=20
  side,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D106532115-27072001>but=20
  I need to know WHAT it is you MEAN by framework and =
some</SPAN></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D106532115-27072001>&nbsp;IETF=20
  examples</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001>would be extremely =
useful.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001>Phil</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Hamid Syed=20
    [mailto:hmsyed@nortelnetworks.com]<BR><B>Sent:</B> Friday, July 27, =
2001=20
    2:06 PM<BR><B>To:</B> Phillip Neumiller; 'Pat Calhoun'; Hamid=20
    Syed<BR><B>Cc:</B> seamoby<BR><B>Subject:</B> Re: [seamoby] Final =
Seamoby=20
    Agenda<BR><BR></DIV></FONT>
    <DIV><FONT face=3DArial size=3D2>Phil,</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>I can point you to number of IETF =
WGs that did=20
    define frameowrks and then worked on the protocol design. This is =
not true=20
    to say that frameworks does not fly at the IETF. </FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>-Hamid</FONT></DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
      <DIV=20
style=3D"FONT: 10pt =
arial">&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00E6_01C11695.B042F1C0--



From owner-seamoby@diameter.org  Fri Jul 27 12:21:33 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02777
	for <seamoby-archive@odin.ietf.org>; Fri, 27 Jul 2001 12:21:32 -0400 (EDT)
Received: (qmail 20427 invoked by alias); 27 Jul 2001 15:48:07 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 20421 invoked by uid 200); 27 Jul 2001 15:48:07 -0000
Received: (qmail 20413 invoked from network); 27 Jul 2001 15:48:05 -0000
Received: from softdnserror (HELO zcars0m9.ca.nortel.com) (47.129.242.157)
  by c900656-a.plstn1.sfba.home.com with SMTP; 27 Jul 2001 15:48:05 -0000
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zcars0m9.ca.nortel.com (8.11.0/8.11.0) with ESMTP id f6RFwI926883
	for <seamoby@cdma-2000.org>; Fri, 27 Jul 2001 11:58:18 -0400 (EDT)
Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com;
          Fri, 27 Jul 2001 11:58:20 -0400
Received: from zcard031.ca.nortel.com ([47.129.242.121]) 
          by zcard00n.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id PQFPYCQA; Fri, 27 Jul 2001 11:58:22 -0400
Received: from cr541699a (acart41n.ca.nortel.com [47.129.49.158]) 
          by zcard031.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id PXPDSS51; Fri, 27 Jul 2001 11:58:21 -0400
Message-ID: <00c701c116ce$11ff42a0$9e31812f@ca.nortel.com>
X-Sybari-Space: 00000000 00000000 00000000
From: "Hamid Syed" <hmsyed@nortelnetworks.com>
To: Phillip Neumiller <PNeumiller@MeshNetworks.com>
Cc: seamoby <seamoby@cdma-2000.org>, "Hamid Syed" <hmsyed@nortelnetworks.com>,
        "'Pat Calhoun'" <pcalhoun@diameter.org>
References: <0DF9FBC42474A24CA50F7A27FB08E0484455F4@meshpdc.meshnetworks.com>
Subject: Re: [seamoby] Final Seamoby Agenda
Date: Fri, 27 Jul 2001 11:58:05 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
              boundary="----=_NextPart_000_00C4_01C11693.652AEC80"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Orig: <hmsyed@nortelnetworks.com>
Sender: owner-seamoby@diameter.org
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_00C4_01C11693.652AEC80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: [seamoby] Final Seamoby AgendaPhil,

Two classic examples are the outcome of RAP and Diffserv WGs. Here are =
the links.

http://www.ietf.org/rfc/rfc2753.txt

http://www.ietf.org/rfc/rfc2475.txt

-Hamid
  ----- Original Message -----=20
  From: Phillip Neumiller=20
  To: Syed, Hamid [WDLN2:AN22:EXCH] ; Phillip Neumiller ; 'Pat Calhoun'=20
  Cc: seamoby=20
  Sent: Friday, July 27, 2001 8:24 AM
  Subject: RE: [seamoby] Final Seamoby Agenda


  Hi Hamid,

  I stand corrected then.  Could you please go ahead and point them out =
to us? =20
  I for one would like to see some evidence of this.  I am probably on =
your side,
  but I need to know WHAT it is you MEAN by framework and some IETF =
examples
  would be extremely useful.

  Thanks,

  Phil
    -----Original Message-----
    From: Hamid Syed [mailto:hmsyed@nortelnetworks.com]
    Sent: Friday, July 27, 2001 2:06 PM
    To: Phillip Neumiller; 'Pat Calhoun'; Hamid Syed
    Cc: seamoby
    Subject: Re: [seamoby] Final Seamoby Agenda


    Phil,

    I can point you to number of IETF WGs that did define frameowrks and =
then worked on the protocol design. This is not true to say that =
frameworks does not fly at the IETF.=20

    -Hamid


------=_NextPart_000_00C4_01C11693.652AEC80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [seamoby] Final Seamoby Agenda</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Phil,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Two classic examples are the outcome of =
RAP and=20
Diffserv WGs. Here are the links.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.ietf.org/rfc/rfc2753.txt">http://www.ietf.org/rfc/rfc2=
753.txt</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://www.ietf.org/rfc/rfc2475.txt">http://www.ietf.org/rfc/rfc2=
475.txt</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>-Hamid</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A title=3DPNeumiller@MeshNetworks.com=20
  href=3D"mailto:PNeumiller@MeshNetworks.com">Phillip Neumiller</A> =
</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
title=3Dhmsyed@americasm01.nt.com=20
  href=3D"mailto:hmsyed@americasm01.nt.com">Syed, Hamid =
[WDLN2:AN22:EXCH]</A> ; <A=20
  title=3DPNeumiller@MeshNetworks.com=20
  href=3D"mailto:PNeumiller@MeshNetworks.com">Phillip Neumiller</A> ; <A =

  title=3Dpcalhoun@diameter.org =
href=3D"mailto:pcalhoun@diameter.org">'Pat=20
  Calhoun'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
title=3Dseamoby@cdma-2000.org=20
  href=3D"mailto:seamoby@cdma-2000.org">seamoby</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, July 27, 2001 =
8:24 AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: [seamoby] Final =
Seamoby=20
  Agenda</DIV>
  <DIV><BR></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D106532115-27072001>Hi=20
  Hamid,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D106532115-27072001>I=20
  stand corrected then.&nbsp; Could you please go ahead and point them =
out to=20
  us?&nbsp; </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D106532115-27072001>I=20
  for one would like to see some evidence of this.&nbsp; I am probably =
on your=20
  side,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D106532115-27072001>but=20
  I need to know WHAT it is you MEAN by framework and =
some</SPAN></FONT><FONT=20
  face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D106532115-27072001>&nbsp;IETF=20
  examples</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001>would be extremely =
useful.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001>Thanks,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D106532115-27072001>Phil</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Hamid Syed=20
    [mailto:hmsyed@nortelnetworks.com]<BR><B>Sent:</B> Friday, July 27, =
2001=20
    2:06 PM<BR><B>To:</B> Phillip Neumiller; 'Pat Calhoun'; Hamid=20
    Syed<BR><B>Cc:</B> seamoby<BR><B>Subject:</B> Re: [seamoby] Final =
Seamoby=20
    Agenda<BR><BR></DIV></FONT>
    <DIV><FONT face=3DArial size=3D2>Phil,</FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>I can point you to number of IETF =
WGs that did=20
    define frameowrks and then worked on the protocol design. This is =
not true=20
    to say that frameworks does not fly at the IETF. </FONT></DIV>
    <DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial size=3D2>-Hamid</FONT></DIV>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
      <DIV=20
style=3D"FONT: 10pt =
arial">&nbsp;</DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_00C4_01C11693.652AEC80--



From owner-seamoby@diameter.org  Mon Jul 30 06:13:16 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA13501
	for <seamoby-archive@odin.ietf.org>; Mon, 30 Jul 2001 06:13:14 -0400 (EDT)
Received: (qmail 2062 invoked by alias); 30 Jul 2001 10:02:08 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 2056 invoked by uid 200); 30 Jul 2001 10:02:08 -0000
Date: 30 Jul 2001 10:02:08 -0000
Message-ID: <20010730100208.2054.qmail@charizard.diameter.org>
Received: (qmail 2045 invoked from network); 30 Jul 2001 10:02:06 -0000
Received: from unknown (HELO unicorn.saver.ne.jp) (61.115.196.10)
  by c900656-a.plstn1.sfba.home.com with SMTP; 30 Jul 2001 10:02:06 -0000
Received: (qmail 15752 invoked from network); 30 Jul 2001 10:19:55 -0000
Received: from unknown (HELO mc3.law13.hotmail.com) (61.115.196.131)
  by 61.115.196.132 with SMTP; 30 Jul 2001 10:19:55 -0000
Reply-To: <dfweq23@hotmail.com>
From: "gfyt563@hotmail.com" <gfyt563@hotmail.com>
To: "0411@yahoo.com" <0411@yahoo.com>
Subject: [seamoby] WE PAY CASH NOW!
Content-Type: text/plain; charset="us-ascii";format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-seamoby@diameter.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

WE PAY CASH, NOW!

We will pay you a lump sum of cash for Eight years of your Military and Government pensions, or your VA diusability.
We pay top dollar!

Go to: www.tfund2000.com and click on Military/Government pensions.




                                                     www.tfund2000.com









To be removed, please send a blank email with the word remove in the subject line.



From owner-seamoby@diameter.org  Mon Jul 30 14:01:44 2001
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11458
	for <seamoby-archive@odin.ietf.org>; Mon, 30 Jul 2001 14:01:43 -0400 (EDT)
Received: (qmail 5464 invoked by alias); 30 Jul 2001 17:50:44 -0000
Delivered-To: seamoby-list@charizard.diameter.org
Received: (qmail 5458 invoked by uid 200); 30 Jul 2001 17:50:43 -0000
Received: (qmail 5451 invoked by uid 500); 30 Jul 2001 17:50:41 -0000
Date: Mon, 30 Jul 2001 10:50:41 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: seamoby@cdma-2000.org
Subject: [seamoby] Reminder to folks with meeting slots
Message-ID: <20010730105041.M4496@charizard.diameter.org>
Mail-Followup-To: seamoby@cdma-2000.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-seamoby@diameter.org
Precedence: bulk

As I have previously stated, I need your powerpoint slides by today
COB. I need to review them to make sure that the discussion will follow
the guidelines.

Thanks for your understanding,

PatC