Subject: Re: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW EXTENSION?

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 02 Feb 2005 19:47:30 +0000

So let me try to see if I can summarise the discussion:

One motive for the query about the LLC usage was linked to anticipated future 
support for ROHC. The important goal at this time for the ipdvb WG is to KNOW 
that we can extend ULE in the furture satisfy new needs - I see ROHC as one 
which is very desirable. The text below seems to indicate we could do this.

However, I am hessitant to introduce a new extension header for a possible 
use, which isn't quite decided yet, and where there may be other issues that 
come to light as the ROHC work progresses (some people would like to see 
multiple small packets per SNDU - but again this needs more thought, and there 
ARE issues, there may be others).

ULE has already completed one WGLC, and this was raised in the second one. I 
recommend that we publish ULE without this new specific optimisation, with the 
understanding that once the requirements are understood and optimisations 
considered, a separate short ID could be written defining how to do ROHC (or 
optimised LLC... etc) over ULE.

**BUT**, I want to know what others think: Is this a good plan for the WG, or 
should we look further at this now?

Gorry Fairhurst
(ipdvb WG Chair)

Gorry Fairhurst wrote:
> 
> 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
>>
>>
> 
>

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 2 Feb 2005 23:04:19 +0100

On Feb 02 2005, at 20:47 Uhr, Gorry Fairhurst wrote:

> I recommend that we publish ULE without this new specific 
> optimisation, with the understanding that once the requirements are 
> understood and optimisations considered, a separate short ID could be 
> written defining how to do ROHC (or optimised LLC... etc) over ULE.

That's certainly fine with me: the new extension header can be added at 
any time.
We just should consider whether it is good to have implementations out 
there that do ULE but don't do the compact LLC.

The protocol designer in me has the general feeling that the asymmetry 
(can choose to use/not use MAC addresses with ethertype, must use MAC 
with length) is wrong.
I can't point out the specific example that would validate that feeling 
now -- apart from ROHC, whose details haven't been decided.

Gruesse, Carsten