Subject: Call for the ipdvb WG to adopt: draft-fairhurst-ipdvb-ule-ext-01.txt

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 17 Jan 2007 17:43:55 +0000

As WG Chair, I request the ipdvb list to consider whether the WG is 
ready to adopt the following individual ID (Internet Draft) as a working 
group ID, with an intention to develop this into a RFC.

This particular draft was introduced to support a standard in 
preparation by the DVB Forum. The aim is to make the 2nd Generation 
Physical Layer present an interface via the Generic Stream Encapsulation 
that is consistent with ULE (e.g. uses the IANA registry), so that both 
can benefit from common extension modules: header compression, etc 
(should these be defined).

PLEASE DO read the draft below and offer email comments on the 
suitability or progression to an RFC and the technical content. ALL 
comments are welcome. Email received before the 25th January 2007 will 
be used to inform the decision about whether to make this a WG Draft.

WG documents should no longer be regarded as the property of the 
individuals who originally authored them - the working group as a whole 
must decide how they are shaped, and to see the document to
a successful conclusion. If adopted, the Internet Draft will be renamed 
to start with the filename draft-ietf-ipdvb..., and will be listed on 
the IETF web page for this WG.

  Best wishes,

  Gorry Fairhurst
  (ipdvb WG Chair)

----

     Title        : Extension Formats for Unidirectional Link 
Encapsulation (ULE) and the Generic Stream Encapsulation (GSE)
     Author(s)    : B. Collini-Nocker, G. Fairhurst
     Filename    : draft-fairhurst-ipdvb-ule-ext-01.txt
     Date        : 2007-1-11

    This document describes a set of Extension Headers for the
    Unidirectional Lightweight Encapsulation (ULE). The Extension Header
    formats defined in this document provide new extensions that are
    common extensions to both ULE and the Generic Stream Encapsulation
    (GSE) defined by the second generation framing structure DVB-S2
    standard (Channel coding and modulation systems for Broadcasting,
    Interactive Services, News Gathering and other broadband satellite
    applications).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-fairhurst-ipdvb-ule-ext-01.txt

---

From: Georgios Gardikis <[email-masked]>
Date: Thu, 18 Jan 2007 13:36:41 +0200

Dear Gorry,

thanks for your initiative.
I read your draft carefully and found it very interesting.
However, I have the feeling that MPEG-2 TS is gradually abandoned and we 
are paving towards an "all-IP" environment.
The introduction of "generic stream" shows exactly this tendency, and I 
believe that the same philosophy is to be followed in the 2nd generation 
terrestrial specs also (DVB-T2).
Surely, providing a support for TS packets encapsulation within GSE or 
ULE might provide a backwards-compatibility, but IMHO it is of 
questionable usability. MPEG-2 TS packets can be directly mapped in a S2 
BBframe, without the use of extra overhead.

At NCSR "Demokritos", we have a strong experience in IP/DVB and are 
currently leading a European research activity which is to investigate 
DVB-T2. In the latter, our team is devoted to research regarding 
baseband formatting and upper-layer issues.

My proposal: we can go on with your draft, since it strengthens the role 
of GSE and ULE, making them more flexible. Indeed, the feature of 
grouping data belonging to the same NPA is quite attractive.
But I believe it is also important to look into how the ipdvb WG can 
benefit from the advance of next-generation terrestrial standards. 
Looking towards the "shutoff" of the MPEG-2 TS, possible issues for 
research could be:

- the full migration of the MPEG signalling (PSI) to IP/GSE level
- the transfer of the DVB-H Time Slicing feature in IP/GSE level
- the transfer of the transport-layer FEC (MPE-FEC) in IP/GSE level.
and generally any issue which may stem from the use of Next-gen DVB as a 
"transmission system for broadcasting IP datagrams"

I would be more than willing to participate in any activity covering 
such issues.

Thanks and best regards to all,

George

---------------
Dr. Georgios J. Gardikis
Associate Researcher
Digital Telecommunications Lab
NCSR "Demokritos", Institute of Informatics and Telecommunications
Ag.Paraskevi, Athens, Greece
Tel: +30 210 6503108
Fax: +30 210 6532175
Web: http://aias.iit.demokritos.gr/~gardikis
Email: [email-masked]

O/H Gorry Fairhurst έγραψε:

> ready to adopt the following individual ID (Internet Draft) as a 
> working group ID, with an intention to develop this into a RFC.
>
> Physical Layer present an interface via the Generic Stream 
> Encapsulation that is consistent with ULE (e.g. uses the IANA 
> registry), so that both can benefit from common extension modules: 
> header compression, etc (should these be defined).
>
> individuals who originally authored them - the working group as a 
> whole must decide how they are shaped, and to see the document to
> a successful conclusion. If adopted, the Internet Draft will be 
> renamed to start with the filename draft-ietf-ipdvb..., and will be 
> listed on the IETF web page for this WG.
>
>
> Best wishes,
>
> Gorry Fairhurst
> (ipdvb WG Chair)
>
>
> ----
>
>
> Title : Extension Formats for Unidirectional Link Encapsulation (ULE) 
> and the Generic Stream Encapsulation (GSE)

---

From: Christian Praehauser <[email-masked]>
Date: Fri, 19 Jan 2007 10:56:27 +0100

Hello together.

I strongly believe that the ipdvb WG should adopt this draft.

I also have a few comments(C)/suggestions(S) (see below).

===
(S.1) Regarding the PDU-Concat Extension:
Maybe we can somehow use the (currently unused) most-significant bit in the first byte of they PDU-Length field?
Of course, as nothing comes for free, every possible use of it will complicate the receiver processing.
Nevertheless, we should consider it. My suggestions are:

	(a) It could be used to selectively enable a type field for each concatenated PDU, i.e. sort of "Type Field present indicator" (denoted by T). Of course it could also be an "absent indicator" ;-). From now on, I'll denote the PDU-Length field along with the optional type field as "concat header". The first concat header must have T=1 to indicate the type of the payload. After that one, if in subsequent concat headers T=0 then the the type field is omitted and the type is the same as indicated in the last concat header which had a type field (T=1).
This also gives us the option to use extension headers in concatenated PDUs. The question is if we should allow them.
I might add that using the T-bit would make the CONCAT-PDU-Type of the current draft version unnecessary.

I also discussed this point with Gorry. It would be glad if we could get some comments on this one.

	(b) We could also use the MSbit for padding purposes, i.e. to achieve alignment (e.g. 2- or 4-byte) for the concatenated PDUs.
The bit (P) would then control the presence of a padding control byte right after the PDU-Length field. The content of this padding control byte (PDU-Pad)
is interpreted as the number of (additional) padding bytes (containing the hexadecimal value 0xff) preceding the start of the concatenated PDU.
Example:
If P=1 and the PDU-Pad field has a value of 2, this means that 2 bytes of padding follow the padding control field. This means that in total the PDU is padded by 3 bytes (including PDU-Pad).

If PDU-Pad=0, then we've a 1-byte of padding.

(S.2) Regarding the TS-Concat Extension
In section 3.1 it might be more clear to refer to the number of TS packets contained in the SNDU by name, e.g. TS-Count, defined as
	TS-Count := (Length-10+D*6) / 188

(S.3) The figures on page 9 and 10 may suggest that the concatenated PDUs are aligned, but in fact they're not.

(C.4) Regarding the "Summary" section (4)
I never heard the term "Next_Header options" before.

(C.5) Typos

Page 3:

> to this document. GSE maintains a design philosophy that presents a 
> common network interface to that of ULE and uses a similar 
> construction for SNDUs 
                        ^--- A dot is missing

Page 8:
> The base header contains the Length of the entire SNDU. This carries 
> the value of the combined length of all PDUs to be encapsulated, 
> including each set of encapsulation headers. The base header also 
> caries a 16-bit ULE Type field.
     ^--- Don't remember me on my next visit to the dentist ;-)
===

Looking forward to hear from you.

Best regards,
Christian.
-- 
Christian Praehauser <[email-masked]>
Department of Computer Sciences, University of Salzburg