[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: LLC support in DVB , ATSC, MPEG-2?
Right, I (personally) do think it would be good to explore ROHC requirements for ipdvb. Perhaps we should point this list to the ROHC draft? 


1) MPE+LLC/SNAP+ROHC
To support ROHC over MPE would need LLC/SNAP - which has overhead/processing drawbacks. This mitigates the benefit from performing ROHC in this case. 


2) ULE+Bridging+LLC+ROHC
I can see why an LLC-based method could serve ROHC well when ROHC may have to cross a L2 Ethernet subnetwork - especially when some of the L2 devices act as bridges (such as Wireless APs). To support ROHC over ULE using LLC would currently also require the Bridging Extension. If the ULE gateway is operating in a Bridging mode, this seems rather like the case for an 802.11 AP. So I'd have expected it to work with LLC bridging - but there is an overhead. 


3) Other Options?
If the ULE-capable device is a router, you could have saved bytes by suppressing some fields. If you intend to use a L2 code point (LLC-Type), but at the same time do not need the L2 end point identifier (MAC Addresses), I think I need to understand more.
Clearly it would be posisble to define a header of this sort - but then it creates more Receiver de-multiplexing options...
One thought: If the WG envisages only one or a small number of uses for an LLC without MAC mode, would it make sense to think of a separate IANA assignment(s) for a Mndatory Type value from the ULE Registry? And what would the protocol dependices be on ROHC --- would the same ROHC methods still work? 

Gorry

Carsten Bormann wrote:


(i) Do we need LLC?
Yes (discussed at both ipdvb BoF as well as at other times), we should supportLLC, because of it use/potential use for OSPF; 
Bridging; L2 Management/devcice discovery



LLC is also the basis for SNAP.


(ii) Non-issues for ULE.
LLC is also used:
 - To raise the ETnerenet frame size above that of traditional Ethernet
 - To provide a Type field (not present in basic MPE header).
Both of these are supported natively within ULE without the need for LLC/SNAP 


SNAP can be used for protocols other than those that have an ethertype.
Again, I don't know all protocols...


Is the assumption that all LLC protocols need full MAC addresses?



So, yes that was it.
- My understanding was that because this was an IEEE protocol, and much of the use of LLC reflected use in a bridged network, then it was best to include both a source and destination MAC address. 


I'd say leave this for the encapsulator to decide.
Assuming that ROHC over 802 goes the LLC route, it is not a given to me that we always need MAC addresses.
It would be easy to introduce a mandatory extension header 2, which is like 1 (i.e., does not allow chaining) but leaves out the 14 bytes of (DA, SA, Type -- the latter is redundant with the LLC length), leading to: 
       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|        Length  (15b)        |         Type = 0x0002         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      =                           LLC payload                         =
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             (CRC-32)                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(and the obvious equivalent for D=0).



I'm keen to understand first the intended usage....



This would be used for compressed voice in a ROHC/RTP scenario.
The LLC payload would contain the necessary glue, a ROHC header (which has a context ID useful for demultiplexing), and the voice payload (say, 10 bytes). Adding MAC addresses and another (redundant) type/length field makes this SNDU significantly larger. 
An NPA may or may not be necessary, depending on the specific use.

Gruesse, Carsten