RE: New mailing list documents

[William StanisLaus <williams77@mailandnews.com>]

>===== Original Message From gorry@erg.abdn.ac.uk =====
>William StanisLaus wrote:
>>
>> >===== 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.
>>
>
>That's a signalling issue - currently using SI Tables.
>
>> >>      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.
>>
>
>Not so, there's an address format that carries MAC addresses, you just don't
>need them when you are communicating to end hosts.
>

Can you suggest me some addressing formats which carries MAC addresses in 
Simple Encapsulation and ULE.

>> >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.
>>
>
>Not so. Learning bridges need both, but you could assume the source if
>you know the identity of the encapsualtor

Yeah I agree with Learning bridges which require Both Source and Destinatin 
MAC address for bridging.. rather updating its bridging route table. But for 
satellite networks is more like a static network and whenver a new Terminals 
comes into picture there is always an authentication and based on that we can 
configure the new comer MAC address in other existing Terminals. Most of the 
case, i see as Star Network in DVB-RCS, and now we are experimenting Mesh 
network.

>
>> >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.
>
>Yes - so you must use LLC/SNAP - which is kind of strange.
>
>>   Also when you say Bridged Payload did you mean, tunneling Layer2 packet,
>> something like L2TP.
>>
>
>I mean connecting to ethernet LANS at both ends - i.e. were receiver is NOT
> an IP router.
>

   Do you mean receiver is always a bridge in this case for forwarding/routing 
and act as a host for Network management. Then is that packets gets discarded 
if the Payload type is different from 0x6558 i.e. bridged ethernet frame.

Thanks and Regards,
William.


>> >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.