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

From: "Hamid Syed" <[email-masked]>
Date: Thu, 7 Jun 2001 08:49:44 -0400

Hello Charlie,

I am glad that you read the draft. Please see my comments below.

> -----Original Message-----
> From:	Charles E. Perkins [SMTP:[email-masked]]
> Sent:	Wednesday, June 06, 2001 1:39 PM
> To:	Syed, Hamid [WDLN2:AN22:EXCH]
> Cc:	Kenward, Gary [WDLN2:AN10:EXCH]; Seamless Mobility Working Group
> Subject:	Re: [seamoby] I-D ACTION:draft-hamid-seamoby-ct-fwk-00.txt
> 
> 
> Hello Hamid,
> 
> We previously published a framework document for consideration
> within [seamoby].  Our emphasis was on context feature classification
> and message flows.  Your document (which I reckon is to be considered
> an individual submission) does not have much about feature
> classfication, and at first glance seems to be a lot more emphasis
> on groupings of access routers.
	[Syed, Hamid [WDLN2:AN22:EXCH]]  I disagree. Infact the draft
attempts to cover a broader range of the over all problem. We do not believe
that just shipping the context from one access router to another can provide
a "seamless" 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 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.

> 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.
>  
> 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.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-hamid-seamoby-ct-fwk-00.txt
> > 
> > cheers
> > 
> > -Hamid

---

From: Cedric Westphal <[email-masked]>
Date: Thu, 07 Jun 2001 07:36:47 -0700

Hamid,

here are a couple comments on draft-hamid-seamoby-ct-qos-context-00.txt.

First, I think the title 'QoS (Diffserv) Context Transfer' is somewhat
misleading,
'Requirements for...' would be more appropriate.

Otherwise, I am quite confused by what you mean. About the timing
requirement:
why is 7.2.2 a MUST NOT and 7.2.3 a SHOULD. If you allow for packets to
go
unaccounted, then they go unaccounted at oldAR as well as newAR?

Also, configuration context MUST be transferred before state context, so
that newAR
can make sense of the state context.
Also, configuration context MUST be transferred to newAR before first
packet arrival at the newAR, so that newAR can start metering, marking
and such even though state context
is missing.

Now if you allow the metering to start before state context has arrived,
then you assume
the router has the ability to merge two states (the new state at newAR
with the old (transferred)
state), and thus 7.2.2 should be rephrased as something like: A state
context transfer
MUST be sent after the last packet arrival at the oldAR.

Transport reliability section does not distinguish between state and
config, and thus it is
hard to know what you mean.

Now, these are details. What I am confused about is this: you make the
assumption that
both oldAR and newAR are DS capable routers in the same domain. Which
means that
first the newAR has to tell this to the oldAR. So CT becomes
oldAR ------> newAR: request for QoS CT classification
          <-------            : QoS CT classification: DS/same domain:
ok, so I'll use the QoS CT
requirements
          ------->            : config
          -------->          : state

which also means that a contest transfer context transfer (or meta-CT)
has to be defined :)

In the framework document
(http://search.ietf.org/internet-drafts/draft-koodli-seamoby-ctv6-00.txt)
is described a
general framework to transfer QoS that does not requires a preliminary
handshake between
oldAR and newAR.

Take care,

Cedric.

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 07 Jun 2001 11:02:50 -0700

Hello Hamid,

some comments below.

Regards,

-Rajeev

Hamid Syed wrote:

>      attempts to cover a broader range of the over all problem. We do
>      not believe that just shipping the context from one access router
>      to another can provide a "seamless"
>
"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.

>      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
>

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

>      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

By interface defintions do you mean protocol messages ? Or do you have
3G interfaces in mind ?

>      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.

>      > I have submitted a framework draft for context transfer. I
>      would appreciate