Subject: [seamoby] Concise Context Transfer Problem Statement

From: [email-masked]
Date: Fri, 26 Jan 2001 12:01:09 -0600

Gary,

Here is my best shot a "concise" problem statement.  Please hack on it.

Service discovery may indeed overlap with context transfer in many ways.
To avoid future problems we should cooperate with the service discovery
SDOs like UPnP, SLP (IETF WG), and Jini/Java folks.  I believe there
 is also interest in the OSGi SDO.

All these competing SDOs (we currently have "discovery Babylon", kind of like
wireless hey?) recognize a need for context transfer and context discovery.
I think the discovery portion of this problem can be mentioned in the draft but
should be stated to be out of scope.

CONCISE PROBLEM STATEMENT
--------------------------------------------
Mobile and portable devices will encounter each other and different access
networks as they move.  To allow seamless service mobility, these devices
need to negotiate transport paths for their anchored services as they move.
In addition to services, the mobile nodes have trust relationships, AAA
requirements, link compression  transport requirements and QoS
Requirements.  A protocol capable of transporting the state of the  mobile's
current service transport states is needed.   This same protocol will also be
used for transferring and negotiation of state during handovers between edge
mobility access equipment.  This protocol MUST also have the ability to
negotiate these parameters so that maximal connectivity is acheivable.

The SeaMoby context transfer working area is responsible for creating
a robust context transfer and negotiation protocol to facility seamless service
mobility.  This protocol may also prove useful for use in UPnP, SLP, and other
discovery related work in other SDOs.

Thanks,

Phil

Sent by:  "Gary Kenward" <[email-masked]>

To:   "'john.loughney @nokia.com'" <[email-masked]>,
      [email-masked], [email-masked],
      "Hongyi Li" <[email-masked]>, [email-masked]
cc:    (Phil Neumiller/MW/US/3Com)
Subject:  RE: [seamoby-mm] Negotiation & plug 'n play

John:

  We are in agreement. It would seem that knowing the capability
of the neighbouring ARs would be useful to context transfer,
however, as we haven't had much discussion around the context
transfer solution, it is unclear as how it would be used, nor how
useful it would be.

  Capability discovery is a new capability, and different from
context negotiation. It is not clear to me that you need capability
discovery if you have context negotiation (or even if you need
context negotiation if you have capability discovery).

  The only question at this point is whether we need to include both
of these approaches in the problem statement, or if there is a high
level description of the problem that covers both approaches?
I believe there is, and it concerns the difficult of sustaining the
communications service to a mobile node when the context includes
the support for N microflows, each requiring different network
resources.

Gary

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 26, 2001 2:45 AM
> To: [email-masked];
> [email-masked]; Li, Hongyi
> [WDLN2:AN22:EXCH]; [email-masked]
> Subject: [seamoby-mm] Negotiation & plug 'n play
>
>
> Hi Gary,
>
> > The need for negotiation is not so much an issue concerning
> > capabilities (at the very least, capabitilies are static and
> > IMHO, should be provisioned), as it is a requirement for proper
> > resource management. An AR may have the
> > capabitility to support set of microflows and the requisite
> > context, but it may not have the resources to support each
> > and every microflow.
>
> I'm (context) transfering from the MM design team, to the CT
> design team.
>
> Hongyi has stated a requirement:
>
>   Mobile location aware nodes (MLAN) in an edge mobility
> domain should be
> able
>   to learn of their neighbors (and their neighbors
> capability). The access
> points,
>   routers, and mobile agents (e.g., foreign agent) could be
> potential MLAN
> in an
>   edge mobility domain.
>
> This is more CT than MM, in my opinion.  This is something additional
> to CT, however.  Should we consider this?  Henrik has given a
> micromobility
> example, where such plug and play functionality would be useful.
>
> In my opinion, I think that there will less network planning with
> WLAN & Bluetooth than there is with cellular networks, so I think
> that we may want to have this functionality.
>
> best regards,
> John
>

---

From: "Gary Kenward" <[email-masked]>
Date: Fri, 26 Jan 2001 13:18:04 -0500

Thanks Phil. Hopefully we can integrate this into the problem
definition ID that Henrik is working on. I do have some questions,
inserted below....

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 26, 2001 1:01 PM
> To: Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: [email-masked]
> Subject: Concise Context Transfer Problem Statement
> 
> Gary,
> 

While I can see the dependency of service discovery on
capability discovery, I do not see them overlapping. I guess
it all depends on what one defines as being the service to
be discovered. Nonetheless, I see capability discovery as
focussed upon one type of node, at the edge of the network.
One node does not constitute a service.

> mobility access equipment.  This protocol MUST also have the 

I don't understand the "also": I do not see the differentiation between
these two statements, unless it is between mobile held state and network
held state. I do not understand the purpose of transferring mobile held
state.

> ability to
> negotiate these parameters so that maximal connectivity is achievable.

"maximal connectivity"? the purpose of negotiation for context transfer is
to ensure that the service is sustained to some degree when the new node
has insufficient resources to support the full context.  

To me, connectivity is a binary condition.

> discovery related work in other SDOs.

I do not believe that this latter statement belongs in the problem
statement,
for two reasons:
	1. the possibility for spin off applications of a protocol always
exists, and
	    is unpredictable (look at the various strange proposals for
RSVP). 
	2. CT is not about discovery. I remain unconvinced that capability
discovery
                is required, but regardless, capability discovery is not the
problem that
                needs to be solve; service sustainment through a mobile
handoff is the
                problem, and the mitigating factor is the inability to
ensure that a given
                node can support the context being transferred.

Cheers,
Gary

>       [email-masked], 
> [email-masked],

---

From: James Kempf <[email-masked]>
Date: Mon, 29 Jan 2001 05:57:46 -0800

Gary,

The problem is nobody takes service discovery seriously. It is always
an afterthought. Everbody thinks their discovery problem is unique
and requires a special solution for their protocol. Consequently,
there is a proliferation of specialized discovery solutions. Service
discovery is always an afterthough.

I wouldn't hold my breath until this changes. Until the IESG or some
IETF working group decides
to push for some kind of unified solution, it will probably continue
to be this way.

		jak

PS: I'm just speaking from an IETF perspective here, not including
UpNP (which has its own history) nor Jini.

---

From: "Gary Kenward" <[email-masked]>
Date: Mon, 29 Jan 2001 16:29:38 -0500

James:

   Ok, so no one takes service discovery seriously, and there
are many solutions. Does that make it a SeaMoby problem?

Gary

> From: James Kempf [mailto:[email-masked]]
> Sent: Monday, January 29, 2001 8:58 AM
> To: Phil_Neumiller; Kenward, Gary [WDLN2:AN10:EXCH]
> Cc: seamoby
> Subject: Re: [seamoby] Concise Context Transfer Problem Statement
> 
> 
> Gary,
>

---

From: James Kempf <[email-masked]>
Date: Mon, 29 Jan 2001 13:57:21 -0800

Dunno. Probably not, considering that various types of mobile systems
will want to do it differently. Unless you consider some kind of
context transfer.

		jak

PS: Sorry for the flame. I've just been somewhat frustrated lately after
having two working groups go off and decide to do their own, custom
service discovery protocol because their problem was soooo unique. And,
Phil's creative flaming served as an inspiration...:-)