[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?
Currently I'm doing a research on ROHC over ULE also. I can foreseeing that
it got some issues might need to be discuss for ROHC in ULE such as does it
support broadcast, extension header...etc
So if Mr.Gorry can lead to another draft on ROHC, I would be happy to join
the discussion and sharing the idea.
Best Regards,
Simon Teh
Universiti Sains Malaysia
-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
Behalf Of Marie-Jose Montpetit
Sent: 03 February 2005 04:36
To: ipdvb@erg.abdn.ac.uk
Cc: Carsten Bormann; ipdvb@erg.abdn.ac.uk
Subject: 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
> >>
> >>
> >
> >