RE: New mailing list documents

[William StanisLaus <williams77@mailandnews.com>]

>===== Original Message From ip-dvb@erg.abdn.ac.uk =====
>William StanisLaus wrote:
>>
>> Hi Fairhurst,
>>      Thanks for the drafts.. I am a new bee.. and have a basic question, 
Does
>> these Encapsulations is to replace DSM-CC... in MPE ??.
>
>Yes - for those networks that are able to change. There is a large
>deployed
>base of MPE in broadcast TV service networks - it is unlikely these
>deployed
>networks will move away from MPE for the foreseeable future. So co-existance
>of the two schemes is important to me. New networks may choose.
>
>There are also a large number of IP-based networks that could take
>advantage of
>the new encapsulation by a change of driver software. Existing networks may
>upgrdae at some time. Again, new networks will have the chance to choose.
>

 Is there any differentiator BITs in MPEG2-TS to figure out which MPE is USED 
(i.e. DSM-CC, ULE or Simple Encapsulation). Atleast DSM-CC should be 
interpreted seperately.

>>      How do we do MAC filtering in DVB Receivers,  If MPE doesn't have
>> information about Destination MAC address ??
>>
>
>MPE has only a ***destination*** Mac address.
>
  Yeah i agree only Destination MAC present in case of DSM-CC. But i wonder 
even Destination MAC is not present in Simple encapsulation and ULE. Is that 
because, it is used only in Broadcast medium, I mean always Link Layer 
Boardcast is done even for Network Unicast packets.

>It does not have a source address - which can present issues with LAN 
bridges,
>IPv6 autoconfiguration, and some other scenarios.
>

   Sorry i am not very sure about IPv6 :(, but for LAN Bridges, we need to 
know only the Destination MAC address to forward the packet. Packet 
forwarding/routing is done based on the destination address.

>It doesn't carry a protocol Type field - which requires use of further 
headers
>to support IPv6 efficiently and other protocols, such as arp.
>

  protocol type field in Simple encap and ULE, it also resembles the LLC-SNAP 
flag in DSM-CC, in which you can define your payload type. By default it is 
IPv4, atleast that is in our configuration.

  Also when you say Bridged Payload did you mean, tunneling Layer2 packet, 
something like L2TP.

>The requirements draft speaks of such issues - and will be re-issued in
>an
>updated format within  a week.
>
>More questions, comments welcome !
>
>Gorry

Thanks for your clarifications...

Best Regards,
William.

>
>> Thanks in advance.
>>
>> Best Regards,
>> William.
>>
>> >===== Original Message From Dr G Fairhurst <gorry@erg.abdn.ac.uk> =====
>> >Two new "draft" Internet Drafts are now available for comments.
>> >
>> >Lightweight Encapsulation rev 01
>>
>http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/ids/draft-unisal-ipdvb-enc-01.tx
>> t
>> >
>> >Ultra Lightweight Encapsulation (ULE) rev 00
>>
>http://www.erg.abdn.ac.uk/users/gorry/ip-dvb/ids/draft-fair-ipdvb-ule-00.txt
>> >
>> >
>> >
>> >These two drafts capture the comments the authors have received on the
>> encapsulation.
>> >In answering the comments from people concerning how to implement, we
>> discovered
>> >there were in fact two varients of the protocol.
>> >
>> >* One was oriented to a wide range of transport services and was based
>> >on PES
>> >  packets - it thus could be used in a very flexible way. It employs the 
AFC
>> >  bits and an adaptation field for framing.
>> >
>> >*  The other approach (ULE)  is based solely on "raw" transport streams.
>> >   This does NOT use the adaptation field, and it can NOT be used for
>> >PES streams.
>> >   It uses a pointer signalled by the PUSI to synchronise framing.
>> >
>> >To get the best possible feedback, and to avoid confusion when we
>> >discuss these,
>> >the authors agreed to split the protocols into the two separate drafts.
>> >That's why
>> >you suddenly see two ID's in place of the one. So, let's debate the
>> pros/cons!
>> >
>> >We can go forward with one of these, both of these in a combined
>> encapsulation,
>> >or some other scheme - if there are comments, suggestions, please do say
>> soon!
>> >
>> >Gorry & Bernhard.