Subject: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt

From: [email-masked]
Date: Wed, 06 Jun 2001 07:01:06 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Context Transfer Framework
	Author(s)	: H. Syed, G. Kenward
	Filename	: draft-hamid-seamoby-ct-fwk-00.txt
	Pages		: 14
	Date		: 05-Jun-01
	
This document proposes a framework for context transfer between the
access routers. The framework identifies the various functional
elements that participate in the process of context transfer and the
protocols required to exchange information between the functional
entities. Included are a few samples of context transfer scenarios
to assist in explaining the interactions of the entities in the
framework.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-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-hamid-seamoby-ct-fwk-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:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-hamid-seamoby-ct-fwk-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.

---

From: "Gary Kenward" <[email-masked]>
Date: Thu, 7 Jun 2001 14:58:36 -0400

Rajeev

> -----Original Message-----
> From: Rajeev Koodli [mailto:[email-masked]]
> Sent: Thursday, June 07, 2001 2:03 PM
> To: Syed, Hamid [WDLN2:AN22:EXCH]
> Cc: 'Charles E. Perkins'; Kenward, Gary [WDLN2:AN10:EXCH]; Seamless
> Mobility Working Group
> Subject: Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt
> 
> 
> 

> In the CT problem statement draft, we have identified the 
> entities: AR,
> AP, MN, MH
> 

You need to read the second version of the draft, and the archives
to read the explanation I gave for changing the nomenclature.

To be fair (to myself), I was expecting many comments about this change.
None were forthcomming, and a last call was issued for the problem
statement.

Gary

---

From: "Hamid Syed" <[email-masked]>
Date: Fri, 8 Jun 2001 09:41:57 -0400

Rajeev,

see my response below.

> From:	Rajeev Koodli [SMTP:[email-masked]]
> Sent:	Thursday, June 07, 2001 10:56 PM
> Hamid Syed wrote:
> >      "Shipping" contexts (some folks call it transferring contexts
> >      BTW) is an
> >      integral part of the Context Transfer Protocol. Indeed, you need
> >      to know
> >      the target router, which is a separate protocol/mechanism. Once
> >      you do
> >      know the target router, I guess you would be interested in
> >      transferring
> >      contexts in CT. It seems intuitively obvious to do CT along with
> >      handovers.
> >      [Syed, Hamid [WDLN2:AN22:EXCH]]  I agree that handoff candidate
> >      discovery could be done through a separate protocol (and btw that
> >      is what our framework is suggesting) but I disagree isolating the
> >      two problems or making assumptions about their interworking. How
> >      the other protocol would work with any context transfer
> >      protocol?. which entity would determine or enable a suitable
> >      candidate discovery?. what are the related triggers or events?.
> >      All this is the part of context transfer problem domain and we
> >      cannot deny it. Any framework for context transfer must address
> >      all the issues. We cannot go making assupmtions about phenomenon
> >      that are closely realted to the context transfer.
> >
> >
> >
> 
> Well, I don't deny that there are problems to consider in target router
> selection. Indeed, because the space is open and yet unknown, we cannot
> go into speculation. That's the point. The CT protocol work can continue
> without having to speculate on target router selection. I hope you would
> agree.
	[Syed, Hamid [WDLN2:AN22:EXCH]]  I disagree. I guess the whole
purpose of this long process of going through the problem statement and
capturing requirements was to understand the problem space in depth. Now as
we know that the context transfer between ARs is not the only problem area
in support of seamless mobility (which I believe is the goal for Seamoby
WG), you are suggesting to make a short cut and define context transfer
protocol only. Then why did we spent six months at least for problem
statement and requirements gathering?. The inter AR context transfer problem
was known from the begining and we only found out the other aspects (handoff
candidate discovery for example) during this whole six months exercise. I
dont believe that we just wasted time in the past. We had very useful
discussions on the list and we had a better understanding of the problem. So
lets work to understand the how these different problem areas are related to
each other and how better solutions can be developed instead of rushing for
context transfer protocol definition which is ,of course, one major aspect
of the problem and we need to do this part. But the Wg is moving forward in
steps (and I support this approach), we should first define a high level
framework or design to show how different protocols can interact. This is
exactly the way other WGs has been working in IETF (RAP WG is one example on
top of my head).
	Now I hope that you would agree.....:-)

> >      >      handover. Identifying the potential context candidates and
> >      a
> >      >      close interworking with the mobility mechanism are equally
> >
> >      >      important to be addressed in the context transfer
> >      framework. Our
> >      >      draft is focused on distributing the functional roles to
> >      the ct
> >      >      entities and defining interfaces between them. The context
> >
> >      >      transfer protocol is only one
> >      >
> >
> >      [Syed, Hamid [WDLN2:AN22:EXCH]]  Well..i do not disagree but AR
> >      is a an entity that contains more than one function in it (see
> >      the definition of AR). While our framework identifies the
> >      entities that are specific to context transfer and actively
> >      participates in the context transfer process.
> >
> >      >      aspect of the over all problem domain and that is what
> >      your draft
> >      >      is proposing, a solution for shipping context from one AR
> >      to the
> >      >      other. I may consider your submission as a candidate
> >      solution for
> >      >      context trasnfer protocol but this is not a framework. I
> >      believe
> >      >      that frameworks should focus on functional models and
> >      interface
> >      >      definitions and the details of individual protocols must
> >      be taken
> >      >      ouitside the framework document.
> >      >
> >
> >      By interface defintions do you mean protocol messages ? Or do you
> >      have
> >      3G interfaces in mind ?
> >      [Syed, Hamid [WDLN2:AN22:EXCH]]  IETF protocols. which are
> >      definitely interfaces between entities.
> >
> >
> 
> I guess I don't have the same terminology as you do. I cannot think of a
> protocol as an interface between two entities (which BTW sounds lot like
> the 3G jargon). To me, a protocol is an understanding (formal rules)
> between communicating peers, whereas an interface is a boundary between
> two entities.
> [this is purely academic, but has some value to clear confusion in the
> future]
	[Syed, Hamid [WDLN2:AN22:EXCH]]  Well. I dont want to start a debate
on it..I guess we are on the same page. So I agree with you here..

> >
> >      >
> >      >
> >      >      I would like to suggest that establishing communities or
> >      >      neighborhoods
> >      >      or groups of access routers could be handled by a protocol
> >      which
> >      >      would
> >      >      be separate than the protocol for doing the context
> >      transfer, and
> >      >
> >      >      further that in many instances it wouldn't be necessary to
> >      make
> >      >      the
> >      >      access router groups at all.
> >      >      [Syed, Hamid [WDLN2:AN22:EXCH]]   This is what the
> >      framework has
> >      >      captured, a separate protocol for context group management
> >      and
> >      >      another protocol for context transfer. I would say,
> >      identifying a
> >      >      suitable candidate for handover amongst the context group
> >      members
> >      >      will help minimizing the service disruption during
> >      handover.
> >      >      Defining a handover candidate discovery protocol is
> >      already part
> >      >      of Seamoby WG charter and our framework shows how the
> >      functional
> >      >      entities interact with each other through the standard
> >      >      interfaces.
> >      >
> >      >
> >      >
> >      You are right that target router discovery is part of seamoby
> >      work. We
> >      all have our views on how this would work with CT. Once we have
> >      that
> >      work (target router selection) done, we will be able to better
> >      relate to
> >      it. Until then, I think it suffices to say that some seamoby
> >      entity
> >      provides us the target router address.
> >      [Syed, Hamid [WDLN2:AN22:EXCH]]  Again..why try solving problems
> >      by making assumptions about the important details. Why not work
> >      on a framework that covers all the problem areas with no
> >      assumptions. Try a high level design first and then go for
> >      individual protocol definition. I do not understand the need for
> >      a shortcut approach.
> >
> >
> >
> 
> Why create a complex problem space when you can work on modular problems
> ? When there is better visibility, things will unfold.
	[Syed, Hamid [WDLN2:AN22:EXCH]]  See my response above. We did spent
time to understand a "complex problem space" and we should define a modular
high level design first. I do not believe that the ct problem areas are
isolated from each other. There is a lot of dependency and we need to
understand it.

	cheers

	Hamid

> Regards,
> 
> -Rajeev
> 
> 
> 
> 
> >      >
> >      >      I wondered whether you had taken a look at our previous
> >      framework
> >      >
> >      >      draft, and if so whether you think meet the requirements.
> >      If you
> >      >
> >      >      didn't see it yet, and if you'd like to take a look, here
> >      is the
> >      >      URL:
> >      >
> >      >
> >
> http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt
> >
> >      >
> >      >      Regards,
> >      >      Charlie P.
> >      >      [Syed, Hamid [WDLN2:AN22:EXCH]]  Thanx for your comments.
> >      >
> >      >      > Hamid Syed wrote:
> >      >      >
> >      >      > Hello CT Folks,
> >      >      >
> >      >      > I have submitted a framework draft for context transfer.
> >      I
> >      >      would appreciate
> >      >      > and welcome any comments on the draft.
> >      >      >
> >      >      > cheers
> >      >      > -Hamid