Re: [Seamoby] Proposal on Sync/NoSync Requirement

["James Kempf" <[e-mail]>]

Gary,

I'm fine with your proposed changes. Any further comments from the WG?

            jak

----- Original Message -----
From: "Gary Kenward" <[e-mail]>
To: "'James Kempf'" <[e-mail]>; <[e-mail]>;
<[e-mail]>
Sent: Monday, July 15, 2002 7:56 AM
Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement


> I don't think this requirement really resolves much of the issue
> that has been under discussion, namely the level of synchronization
> that is to be possible using CT.
>
> CT for updates (as a result of new flows, or flows being discontinued)
> is, I think, pretty straightforward. CT for state maintenance where the
> state may change while a transfer is in progress is a much harder problem.
>
> It matters not whether we say that CT solves this latter problem, or
> provides
> the support mechanisms, the demands that this would impose on the protocol
> are extreme.
>
> We need a requirement that clearly identifies what is meant by CT
> synchronization:
>
> Currently:
>
> 5.5 Context Update and Synchronization
>
> 5.5.1 The context transfer protocol MUST be capable of updating
>       context information when it changes.
>
> 5.5.2 A context update MUST preserve the integrity, and thus the
>       meaning, of the context at each receiving AR.
>
>    The context at the AR actually supporting an MN's traffic will
>    change with time. For example, the MN may initiate new microflow(s),
>    or discontinue existing microflows. Any change of context at the
>    supporting AR must be replicated at those ARs that have already
>    received context for that MN.
>
> Proposed:
>
> 5.5 Context Update and Synchronization
>
> 5.5.1 The context transfer protocol MUST be capable of supporting the
>       updates to context information when it changes.
>
> 5.5.2 Context updates SHOULD complete before the context is needed at
>       the receiving AR.
>
>    The context at the AR actually supporting an MN's traffic will
>    change with time. For example, the MN may initiate new microflow(s),
>    or discontinue existing microflows. Any change of context at the
>    supporting AR must be replicated at those ARs that have already
>    received context for that MN.
>
>    However, context changes are often driven by events external to the
>    sending AR, and will thus be asynchronous to any on-going context
>    updates. Given that context transfers will take a finite amount of
>    time to complete, it is possible that a change in context cannot be
>    conveyed in time to the destination AR to avoid any impact on a possible
>    handover. The objective of the context transfer design must be to make
>    the likelihood of this delay, and its magnitude, as low as possible.
>
>
> This is not perfect: the desire to avoid a requirement for an extreme degree
> of synchronization is only implied by the soft "SHOULD" in 5.5.2.
>
> Regards,
> Gary
>
>
> > -----Original Message-----
> > From: James Kempf [mailto:[e-mail]]
> > Sent: July 14, 2002 18:52
> > To: [e-mail]; [e-mail]
> > Subject: Re: [Seamoby] Proposal on Sync/NoSync Requirement
> >
> >
> > That sounds better.
> >
> >             jak
> >
> > ----- Original Message -----
> > From: <[e-mail]>
> > To: <[e-mail]>; <[e-mail]>
> > Sent: Sunday, July 14, 2002 3:01 PM
> > Subject: RE: [Seamoby] Proposal on Sync/NoSync Requirement
> >
> >
> > > Hi James,
> > >
> > > > "Out of scope" is typically WG charter language. I know the
> > > > SHOULD/SHOULD NOT sounds a bit funny, but I think we need to
> > > > express this in a way that is more requirements language.
> > >
> > > Then how about changing:
> > >
> > >       ... the CT solution need
> > >       not support it, but it should not provide a
> > hinderance to those feature contexts
> > >       that do.
> > >
> > > to:
> > >       ... the CT solution is not requireed to directly
> > support synchronization, but
> > >       may support simple methods for the synchronization
> > context for feature contexts
> > >       that do.
> > >
> > > John
> > >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>


_______________________________________________
Seamoby mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/seamoby