[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW EXTENSION?
I guess ROHC over ULE/Enet would be a great topic for Minneapolis?
Gorry could that lead to another draft maybe?
Marie-Jose
> -------- Original Message --------
> Subject: Re: LLC support in DVB , ATSC, MPEG-2? - DO WE NEED A NEW
> EXTENSION?
> From: "Gorry Fairhurst" <gorry@erg.abdn.ac.uk>
> Date: Wed, February 02, 2005 2:47 pm
> To: ipdvb@erg.abdn.ac.uk
> Cc: "Carsten Bormann" <cabo@tzi.org>
>
> 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
> >>
> >>
> >
> >