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+ROHCTo 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+ROHCI 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 discoveryLLC 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/SNAPSNAP 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