Re: LLC support in DVB , ATSC, MPEG-2?

[Carsten Bormann <cabo@tzi.org>]

> (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