Subject: LCT Header Extensions

From: Justin Chapweske <[email-masked]>
Date: Wed, 10 Oct 2001 17:31:40 -0500

From LCT:

"If present, Header Extensions MUST be processed to ensure that they are
recognized before performing any congestion control procedure or
otherwise accepting an LCT packet. LCT packets with unrecognised Header
Extensions MUST be discarded by the receiving agent, hence the expected
use of extensions SHOULD be signaled out-of-band before session startup."

This concerns me because it means there is no mechanism for forward 
compatibility between implementations/versions.  I would like to request 
that a Header Extension be specified for vendor-specific headers, 
perhaps as follows:

EXT_VEND = 3    Vendor-specific Extension

This extension allows vendors to add their own extensions in a backwords 
compatible fashion.  
Recievers MUST ignore any vender-specific extensions that they don't 
understand.

A suggested format is as follows:

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |L| HET = 3     |       HEL     |          VEND_CODE            |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 .                                                               .
 .              Vender-specific Extension Content                .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Vendor Code (VEND_CODE): 16 bits

Identifies which vendor this extension is from.  The Vendor code 
determines how
the vendor-specific extension content will be parsed.  It is RECOMMENDED 
that
vendors use an extensible format for their own extensions so that they 
only need a
single vendor code.

Thanks,

--
Justin Chapweske, Onion Networks
http://onionnetworks.com/

---

From: "Michael Luby" <[email-masked]>
Date: Wed, 10 Oct 2001 17:42:16 -0700

Justin,

I agree that it is not as clearly written as it should have been, and the
writing needs to be changed.  My proposal is written below.  Before getting
to that, the problems that I see with your proposal are that:
(1) Your suggested format is quite complicated (embedding fields within
fields), and wastes a lot of precious packet space.
(2) It would most likely require vendors to register their vender code with
IANA, and the IANA registry would have to be set up for this, etc., and this
is an extra complication.

The solution I propose is to leave everything the way it is right now
(although I do think it is good to get rid of the header extension bit X in
the first word of the header, and to get rid of the L in each header
extension, as you suggested in an earlier email), but to change the language
you called out to the following:

"The expected use of Header Extensions, the list of Header Extension Types
and
how to process the corresponding Header Extension SHOULD be signaled
out-of-band
before session startup.  If out-of-band signaling is used to communicate the
possible Header Extensions Types to be used in the session, then
Header Extension Types that are not crucial to the behavior of the receiving
agent
MAY be designated as optional.
If the receiving agent does not recognize a Header Extension Type,
or if the receiving agent does not know how to process a Header Extension
with a recognized Header Extension Type that has not been designated as
optional,
then the LCT packet MUST be discarded without further processing.
The receiving agent MUST process a Header Extension unless its Header
Extension Type is designated as optional."

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Justin
Chapweske
Sent: Wednesday, October 10, 2001 3:32 PM
To: [email-masked]
Subject: LCT Header Extensions

 From LCT:

  0                   1                   2                   3

Thanks,

---

From: Lorenzo Vicisano <[email-masked]>
Date: Wed, 10 Oct 2001 19:40:24 -0700

Mike, Justin,

Given that here we are defining a packet format (or at least
a piece of it), I think we should be able to interpret all
its fields, and define some sort of behavior for them, 
at least as far as LCT is concerned. If nothing else,
this would allow us to debug the content of the LCT header
(I'm thinking of tools like "tcpdump").

For this reason I don't like the idea of signaling Header Extension
Types out of band. On the other hand it is nice to be able
to add backward-compatible extensions, to refine the protocol without
changing the version number.

My proposal is:

"All header extensions that are not understood can be safely
ignored by the receiver. This allows to introduce backward-compatible
enhancement to the protocol without changing the version number.
Non backward-compatible header extensions CANNOT be introduced without
changing the protocol version number."

	Lorenzo

Note that in multicast, unlike unicast, the sender may not want/be able
to negotiate protocol capabilities, either because the receiver
population is heterogeneous or because there is no feedback channel. 

My proposal is to use the 1st bit of the header extension (the one
that we were using for "L") to signal whether the header extention can
be safely ignored, if not understood.

As now we have 8 bits for the type (we got rid of "L"),
we reserve types 128 through 254 for backward-compatible
header extension, i.e. extension that will be ignored if
not understood.

Note that LCVv2 can narrow the subset of backward-compatible
extension, if it needs to and if it hasn't used all of it already

In message <[email-masked]>,

---

From: "Michael Luby" <[email-masked]>
Date: Wed, 10 Oct 2001 19:50:39 -0700

I like this suggestion.  Justin?

-----Original Message-----
From: Lorenzo Vicisano [mailto:[email-masked]]
Sent: Wednesday, October 10, 2001 7:40 PM
To: Michael Luby
Cc: Justin Chapweske; [email-masked]
Subject: Re: LCT Header Extensions

Mike, Justin,

My proposal is:

	Lorenzo

---

From: Justin Chapweske <[email-masked]>
Date: Wed, 10 Oct 2001 23:37:02 -0500

I like it too.  There will of course have to be clarification as to 
which ranges are for fixed and variable length headers.

Michael Luby wrote:

>>writing needs to be changed.  My proposal is written below.  Before
>>
>getting
>
>>(2) It would most likely require vendors to register their vender code
>>
>with
>
>>IANA, and the IANA registry would have to be set up for this, etc., and
>>
>this
>
>>(although I do think it is good to get rid of the header extension bit X
>>
>in
>
>>extension, as you suggested in an earlier email), but to change the
>>
>language
>
>>before session startup.  If out-of-band signaling is used to communicate
>>
>the
>
>>Header Extension Types that are not crucial to the behavior of the
>>
>receiving
>
>>agent