Re: Draft for ROHC over DVB - comments on your text.

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

I have a few questions about the draft from the ULE perspective, please 
see below.

Gorry


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

1) ULE Type

There are two ways the Type field could be used, and I am not clear 
which you are proposing.

a) You could use a ULE Mandatory Extension Header. The value for this 
could be allocated by the IETF, if this were approved as an IETF RFC and 
that would certainly be one way to proceed that would allow you to embed 
ROHC functionality in the ULE/GSE Gateway and Receivers.

b) You could apply to the IEEE for an EtherType value from the IEEE 
Registry that would be applicable to all IEEE technologies (WiFi, 
wired-ethernet, etc) and which naturally could be used with ULE/GSE 
also, although you would still need to define how this was implemented, 
and how this interacted with ULE if you wanted to embed the compression 
and decompression in the ULE end-points rather than in the connected end 
host Ethernet drivers.

(it's a little wrong to speak of a "IANA assigned EtherType number" - 
since this mixes the two possibilities).

Comments and questions relating to this:

---
In section 3.1.2:

I don't understand the header format. The base-header has the type 
Ethernet - this means the encapsulated PDU must be an Ethernet Frame (as 
per RFC4326). A receiver should attempt to forward the PDU to the 
bridged LAN interface.

If you wanted a compressed ROHC payload in bridged mode, you'd probably 
need to define a new ULE-Type that denotes you are carrying a bridged 
ROHC PDU that needs to be decompressed prior to Receiver bridge 
processing - you probably also need to describe how this would work.

---

In Section 4.1:

"Since new EtherType is allocated, this
   protocol can be extended to asymmetrical link via Link-Layer
   Tunneling Mechanism [RFC3077]"

- UDLR uses IEEE EtherTypes, whereas ULE uses these, but includes its 
own extension formats. So this is only so, if you request an 
IEEE-allocated Ethertype, rather than a ULE-Type value from the IANA 
extensions registry.

---------------------------------------------------------------------
2) In Section 3.1.1:

"In the absence of multiple receivers, a transmitter can send an SNDU"...

I think this is only partially true, it may be safer to refer this to 
RFC4326, since this is also dependent on the way in which the ULE Stream 
is used.

---------------------------------------------------------------------
3) In section 3.2 (ROHC over MPEG2-TS):

- This format isn't clear to me, it seems you are trying to define a new 
types of Stream, which I guess is possible, but that would imply 
defining integrity checks, length, NPAs, etc - in much the same way as 
ULE was developed. This would perhaps at most save 2 bytes, but would be 
incompatible with the ULE framework. I'm not sure I understand the 
motivation here.

---------------------------------------------------------------------
4) In Section 4:

With the exclusion of section 3.2, this seems to apply to any ULE 
Stream (and probably a GSE stream) - independent of the physical layer 
(DVB, ATSC, or whatever).

In Section 4.1:

Again, with the exclusion of section 3.2, this could be applicable to GSE.
---------------------------------------------------------------------

Best wishes,

Gorry


I also have a few minor editorial comments (which may be helpful if you 
decide to prepare an updated draft):

---
Change
/ULE stream/
to
/ULE Stream
---

It would seem worthwhile drawing the diagrams in the same representation 
as other ULE Extensions, using the 32-bit wide format of:


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |D|        Length  (15b)        |         Type = 0x????         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

I'd suggest creating a two reference subsections, one
"Normative References"
and one
"Informative References"

I'd suggest replacing GSE with the ETSI Specification reference:

   [GSE] TS 102 606 "Digital Video Broadcasting (DVB); Generic Stream
   Encapsulation (GSE) Protocol, "European Telecommunication Standards,
   Institute (ETSI), 2007.

I'd suggesting a normative reference to:

   [RFC4326] Fairhurst, G. and B. Collini-Nocker, "Unidirectional
   Lightweight Encapsulation (ULE) for transmission of IP datagrams
   over an MPEG-2 Transport Stream", RFC 4326, December 2005.

I'd suggest placing the following as Informative references :

[DIX]
[ISO-MPEG2]
[ITU-H222]
[RFC3077]

You may like to provide an informational reference to the following for 
terminology and architecture:

   [RFC4259] Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-
   Nocker, B., and H. Linder, "A Framework for Transmission of IP
   Datagrams over MPEG-2 Networks", RFC 4259, November 2006.