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

["Allison, Art" <AAllison@nab.org>]

Although I do not speak for ATSC as an organization; in response to this
query, I asked <around> among those knowledgeable about ATSC implementations
of IP traffic in broadcast if they are using LLCSNAP. I have not found
anyone who is using LLCSNAP today and no plans to do so were exposed. The
ATSC Standard A/90 supports the DSMCC LLCSNAP flag, and specifies which
protocol encapsulation is used based on that flag setting. All IP
implementations of which I am aware use encapsulation 0x04, which indicated
Asynchronous IP datagrams in Addressable Sections. 

So, my judgment is that use of LLC is likely to be small in those Regions of
the World that use ATSC Transport Standards.  

As there is a defined standard method for those that wish to employ LLC in
MPEG-2 TS (DSMCC), I suggest that developing another one is not a good
investment of resources to handle this <apparently> corner case.

Art Allison
Director, Advanced Engineering
NAB Science & Technology
1771 N St NW, Washington Dc 20036
202 429 5418 
-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
Behalf Of Gorry Fairhurst
Sent: Monday, January 31, 2005 8:17 AM
To: ipdvb@erg.abdn.ac.uk
Cc: Carsten Bormann
Subject: LLC support in DVB , ATSC, MPEG-2?


So, I'd like to ask the group as a whole, what they see as the usage of LLC
within DVB, ATSC, or any MPEG-2 based transmission network?

Carsten Bormann wrote:

<snip - see response in separate email>
> 
> One question though: Why is it that ethertype frames can be sent 
> without MAC but length (LLC) frames can't?

So the WG did discuss this, but it seems worthwhile checking again that we
have got this correct.

The history as I recall is:

(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

(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


> 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 don't know all existing LLC protocols,

Nor me --- can anyone else on this list help?

 > but I know at least one
> proposal for one that probably doesn't.

Aha - Do tell more...



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

<snip - see response in separate email>


> Gruesse, Carsten
> 
> 


Best wishes,

Gorry Fairhurst