Subject: ULE Extension Headers

From: "Allison, Art" <[email-masked]>
Date: Wed, 10 Mar 2004 11:34:35 -0500

Taking one....
(1) ULE Extension Headers - We have described a number of ways we can
encode extra headers associated with a specific SNDU, that a receiver
may optionally ignore without having to discard a PDU. However, we
have yet to agree if this is needed and which way is best. The most
promising seem to be:
    (a) use a 16-bit type field to indicate "extension header follows"
    (b) use a 1-bit flag to indicate "extension header follows"
    (c) the assignment of type field values to identify each
        individual extension header.

I recommend we add only a "place holder note" in the next revision of
the ULE draft (to be released in about one-two weeks) which says the WG
could possibly consider future extension headers (if needed), and
continue this discussion for the next revision (this can happen quickly
if the WG gets consensus, at the moment I see too many options
and unclear concrete examples).

----
I thought discussion faded to silence after I <effectively> acknowledged (b)
was ok with me. (And I thought some wanted to define the following structure
when the bit is set - an activity to which I do not think there were
objections.)
So maybe we have acceptance of an approach for this item?

Art
::{)>
Art Allison
Director Advanced Engineering
NAB
1771 N St NW
Washington DC 20036
202 429 5418

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]]
Sent: Monday, March 08, 2004 10:51 AM
To: [email-masked]
Subject: ULE : Encryption Support, FEC, and Extension headers.

There's been a lot of discussion on the list about three related topics:
    (i) The (potential/actual) need for FEC and Encryption
    (ii) How to implement headers in ULE to support Encryption
    (iii) Whether ULE should support optional extension headers.

I don't wnat to stop any of this debate, but I would like to try and put
a marker in the email threads so that those not following the detail
of the various discussions, have a picture of where the group seems
to have consensus.
   
So here's my recommendation as WG Chair:

(1) ULE Extension Headers - We have described a number of ways we can
encode extra headers associated with a specific SNDU, that a receiver
may optionaly ignore without having to discard a PDU. However, we
have yet to agree if this is needed and which way is best. The most
promising seem to be:
    (a) use a 16-bit type field to indicate "extension header follows"
    (b) use a 1-bit flag to indicate "extension header follows"
    (c) the assignment of type field values to identify each
        individual extension header.

I recommend we add only a "place holder note" in the next revision of
the ULE draft (to be released in about one-two weeks) which says the WG
could possibly consider future extension headers (if needed), and
continue this discussion for the next revision (this can happen quickly
if the WG gets consensus, at the moment I see too many options
and unclear concrete examples).

(2) FEC and Encryption, the requirements for these must be clearly
defined in an Internet Draft (reference could be made to other, e.g.
ETSI documents). This could be one or more individual drafts -
or by contribution of IETF-style text for the "ipdvb requirements" ID. 
This will assure, we have a common basis for discussion, either on the
mailing list or (if issues do prove hard to resolve in this way) at the
San Diego IETF. I'm anxious ULE collects only *useful* options.
Note: These individual ID's could be very short (a few pages) and
could finally be "combined" into the ULE (and/or requirements) text,
should they be accepted by the group.

(3) After production of a WG ULE ID, I'd like the WG to progress the
charter item of adopting a requirements WG Internet Draft. This document
must provide background, identify use-cases, and implementation options;
leading to appropriate recommendations.  We can either start from the
existing (somewhat imperfect/incomplete) requirements draft:

http://www.ietf.org/internet-drafts/draft-fair-ipdvb-req-04.txt

....or make one (or more) new ones. Thoughts?

Gorry Fairhurst
(ipdvb WG Chair)

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Wed, 10 Mar 2004 12:17:29 -0500

I disagree with the "if needed" and would like to see the extension headers
as part of the new revision even if the actual mechanism is TBD. We can come
up with a series of concrete use cases. I think extension headers are
essential to support future services (security being one) and ensure
extensibility.

Marie-Jose

---

From: Alain RITOUX <[email-masked]>
Date: Wed, 10 Mar 2004 18:32:29 +0100

> when the bit is set - an activity to which I do not think there were

I also am in favour of b) A structure was proposed for the case where
the bit is set. I didn't feel any strong objection against the proposed
definition, neither a great support ;-) but we were just 3 or 4 to
discuss about it, I don't know the feeling of the WG about this stuff.
How to proceed any further ?

> So maybe we have acceptance of an approach for this item?
maybe.

Cheers.
Alain.
-- 
Alain RITOUX
Tel +33-1-39-30-92-32
Fax +33-1-39-30-92-11
visit our web http://www.6wind.com

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 11 Mar 2004 16:28:05 +0000

Let's see if I can help steer this discussion.

* I note there is some enthusiasm to consider the idea of a ULE extension
header. That is useful to know, but I don't see a consensus YET.

* As I said earlier, I am against holding-up the publishing of the first rev
of the ULE WG draft.  I believe we should publish the draft as soon as
possible (next week), to make sure the rest of the text is acceptable to the
WG. We CAN issue a new revision of the ID soon after with this new
functionality (if we are ready) - there's no minimum time between
revisions!!!

Here is my suggestion to progress the extension header topic:

* We need first to at least find a list of examples of likely/potential
use...  Let us do this in the context of setting some (potential/actual)
requirements/architecture - this also is a WG charter item!  Any volunteers
of 1-3 paragraphs of ID text describing for each of the ideas for use:
Security; FEC; QoS; priority; Multiple-SNDU-Payload; anything else?

* I'm not yet clear of the relative costs of (a,b,c) in terms of
implementation, registry management, transmission efficiency - one thing
that would be very useful would be to write a short ID with a proposed
solution, to have something concrete to compare the design options with.

Any volunteers for either of the above?

Gorry

P.S. I didn't mean to ask for a vote (a,b,c) - I was trying to summarise the
options I had seen... Sorry if that caused some confusion.

---

From: "Marie-Jose Montpetit" <[email-masked]>
Date: Thu, 11 Mar 2004 12:38:19 -0500

I volunteer for some examples.

Marie-Jose