Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context Specifications

From: "James Kempf" <[email-masked]>
Date: Fri, 19 Jul 2002 18:25:58 -0700

I'd like to propose the following new section for the CT requirments listing
requirements on feature context specifications. Note that this section does not
place requirements on the feature context protocols themselves, but only on
their specifications.

            jak

------------------------------------------

5.8 Feature Context Specifications

The context transfer protocol provides a basic framework in which feature
contexts of varying types can be transfered. Recognizing that the particular
feature contexts may have very different needs with regard to update,
synchronization, and transport, this section contains requirements on the
feature context specifications. Note that these requirements do not constrain
the actual feature context protocols themselves, but only their specification.

5.8.1 A feature context specification MUST contain an IANA assigned type code
for the particular feature context. If an experimental feature context protocol
is being developed, a type code from the context transfer protocol's
experimental range SHOULD be used. The type code is used in the context transfer
container to identify the feature context.

5.8.2 A feature context specification MUST define the byte layout of the
individual elements of the feature context, and how those map into the context
transfer protocol's container. The byte layout SHOULD obey standard IETF
conventions with regard to mapping of data into on the wire format.

5.8.3 A feature context specification MUST define the transport to be used. If
the feature context is transferred using an IETF transport layer protocol , then
the feature context specification MUST include the full details of how the
transport layer protocol is used. If the feature context is transferred as an
option on another IETF protocol, then the feature context specification MUST
define the mapping of the context transfer container into the other protocol's
standard option format. If the feature context is transferred through a non-IETF
protocol (such as IAPP [4]), then the feature context protocol specification
MUST define how the standard context transfer container is mapped into the
non-IETF transport.

5.8.4 A feature context specification MUST indicate whether update to context
information is allowed if changes in the source occur after the context is
transferred. If such changes are allowed, the feature context specification MUST
define the change protocol message format using the standard context transfer
container, and MUST include details of how the update is accomplished.

5.8.5 A feature context specification MUST indicate whether the context transfer
is tightly synchronized with external events, such as handover. The freature
context specification MUST indicate what event or events trigger transfer.

6.0 References

[4]  "Recommended Practice for Multi-vendor Interaccess Point Interoperability
via an Inter-access Point Protocol Across Distribution Systems Supporting IEEE
802.11 Operation," IEEE Std. 802.11f/D3,  January, 2002.

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

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Tue, 23 Jul 2002 15:54:33 -0500

Rajeev,

please see below,

Regards,

Madjid

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 3:43 PM
To: James Kempf
Cc: Nakhjiri Madjid-MNAKHJI1; [email-masked]
Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context
Specifications

Madjid, Jim,

I have few comments.

- it is not clear to me, from the proposed text, what requirements do the
requirements on feature context specification impose on the CT protocol.
Shouldn't we be concerned with requirements of the CT protocol in this
particular document ?

Madjid>> Agreed, That is why I have been advocating for SHOULDs whenever
there is a requirement that is not needed for all features, and striving
to keep requirements as generic as possible.

- regarding the transport text, if a particular feature indicates UDP/TCP
or SCTP, isn't that sufficient ? Even if it can provide more information,
how
is that going to be useful if it is not supported by the underlying
transport
protocol ?

Madjid>> First of all, not everybody and every feature need an advanced
transport and I know we agree on this.
However, say in 6 months we are debating an specific feature that does need
reliability. This text is to protect us from sloppy design. 
If you remember Jeff Schiller saying: Don't come and say use
IPSec if you want security, you need to work on the security details.

Example of a case which even SCTP is not going to cut it (this is
answer to your next question as well): say you are sending a very
dynamic context (packet count or HC context) and you want reliability
(and you got time to resend stuff...).
You send the context, but due to do channel conditions don't get it through,
next time, you have to send updates. This has to come from the feature unit
and
not from transport layer. If had just said use SCTP for reliability that
would not be a robust design.

- which scenarios demand context updates ?
It seems to me that once you transfer state, you would
like to use the state on the new node as soon as possible (right away) and
stop
using state on the old node as the reference.
Since this does not impose any special requirements on the CT protocol
itself, I do not have objections, but only wondering about the usage
scenarios..

Thanks,

-Rajeev

James Kempf wrote:

> Madjid,
>
> The additions look fine to me. I'll fold them into the proposed text. We
need to
> wait until Gary is back from vacation to see what he has to say.
>
>             jak
>
> ----- Original Message -----
> From: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
> To: "'James Kempf'" <[email-masked]>; <[email-masked]>
> Sent: Monday, July 22, 2002 3:55 PM
> Subject: RE: [Seamoby] New Section 5.8 - Requirements on Feature Context
> Specifications
>
> > James,
> >
> > thanks for making the effort you made on this section.
> > and thanks for trying to expedite this process.
> >  I like most of it except a few minor comments
> > based on the history of discussions.
> >
> > Please see below.
> >
> > BR,
> >
> > Madjid
> >
> > -----Original Message-----
> > From: James Kempf [mailto:[email-masked]]
> > Sent: Friday, July 19, 2002 8:26 PM
> > To: [email-masked]
> > Subject: [Seamoby] New Section 5.8 - Requirements on Feature Context
> > Specifications
> >
> >
> > requirements on feature context specifications. Note that this section
does
> not
> > the feature context is transferred using an IETF transport layer
protocol ,
> then
> > transport layer protocol is used.
> >
> > Madjid>> This would impose a little bit of vertical design and might
again
> lead to
> > heated debates on whether to use UDP/SCTP.... Don't know if the
following
> > addition within <> helps:
> >
> > Madjid>>
> > "If the feature context is transferred using an IETF transport layer
protocol
> ,
> > <and relying on specific mechanisms of the transport layer protocol,
such as
> > reliability or timing mechanisms>, then
> > transport layer protocol is used. <One must note that employing
different
> > transport mechanisms for different feature context might lead to limited
> > possibility of multiplexing various feature contexts>"
> >
> >
> >
> > If the feature context is transferred as an
> > transferred. If such changes are allowed, the feature context
specification
> MUST
> > container, and MUST include details of how the update is accomplished
<and
> triggered>.
> >
> > Madjid>> See the addition above. The external trigger might be needed.
> >

---

From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Date: Wed, 24 Jul 2002 18:20:15 -0500

Rajeev,

sorry for the delay. see below.

-----Original Message-----
From: Rajeev Koodli [mailto:[email-masked]]
Sent: Tuesday, July 23, 2002 4:24 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: James Kempf; [email-masked]
Subject: Re: [Seamoby] New Section 5.8 - Requirements on Feature Context
Specifications

Hello Madjid,

Nakhjiri Madjid-MNAKHJI1 wrote:

> and not from transport layer. If had just said use SCTP for reliability that

When you have to send an update, you do it whether or not SCTP failed to
get it through in the first case, right ? What SCTP or a reliable transport
protocol will offer you is the ability to send a message reliably. When you
have a new message or an update, I agree the feature code has to supply it
(and SCTP has to get to the destination reliably)!

Madjid>> True, furthermore, if you use a reliable protocol like
SCTP, you need to take extra care with CT, so the receiver doesn't mix up
updates from app. layer, with retx from transport.

I hope you are not indicating that each feature has to design its own reliable
transmission protocol. The way each feature uses SCTP or UDP is internal
to the feature, and is not a function of the CT protocol itself. The
CT protocol
should define a set of messages that can be carried over different transport
protocols.

Madjid>> No, No, however, If we add a set of minimal support (like
what I mentioned above) to the generic protocol, then provide the option
for the feature to use it or not we are covered. 
If we completely ignore reliability
completely, we will write off CT as a useful protocol, I think!

BR,

Madjid

Regards,

-Rajeev