[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: New mailing list documents
Hi Fairhurst,
Further, I have few more clarifications, Don't we support ARP in
Satellite network with these encapsulation i.e. simple encapsulation and ULE.
I can see in Section 4.1 Bridged Payload, you have talked about ARP Message.
But i hope it is not clear, atleast to me.
Thanks in advance.
Best Regards,
William.
>===== Original Message From ip-dvb@erg.abdn.ac.uk =====
>>===== 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.t
x
>>> >> 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.