Re: Remarks concerning IP-over-DVB : Future MAC Support

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

Thanks, 

Could I ask some questions to probe on other alternatives to the way
in which IP is sent over MPE?

Patrick Cipiere wrote:
> 
> Patrick Cipiere wrote:
> 
> >> I am also using cards that do not hardware filter the PIDs, but leave
> >> this task to the driver. With these  cards it is easier to deal with the
> >> whole 8191 PIDs, but cost more cpu cycles.
> >>
> 
> Gorry wrote:
> 
> > Yes - I also presume this offers a way to modify the IP protocol
> > processing with some existing cards. How much experience do you
> > have of this?
> 
> Emmanuel Duros <Emmanuel.Duros@UDcast.com> and I already wrote 6
> drivers for different DVB-S cards and manufacturers running with
> FreeBSD. And we are currently coding a new one.

Useful experience.

> We try to make them as simple as usual ethernet drivers.
> In fact we consider the driver as an ethernet layer 2 driver, and we
> consider that RF/mpeg2/mpe are in layer 1.
> By doing so, the DVB-S NIC card/driver fits nicely in the stack, with
> standard ethernet interface with layer 3.
> 
> This might explain my previous remark about layering.
> 
> I strongly believe that we need a source MAC address, and this can be
> solved today with LLC_SNAP and RFC1483.

Agreed, can be solved in this way in current MPE.

The use of LLC/SNAP adds to the payload overhead, it doesn't seem to
add significantly to the capability - although, like in Ethernet,
you're perfectly entitled to use it, if you wish. Have I missed
something?

If we are contemplating redefining the IP service over DVB, though we
may not necessarily choose to do it this way.

> This need is reinforced when using RFC3077 on this interface, because
> you transform a unidirectional simplex interface into a duplex
> interface.
> The interface needs to be able to reject its own packets (received
> 250ms later).

This, I think is based on the UDLR approach, which is essentially a 
LAN solution rather than native IP solution. It is well-suited to 
some important application scenarios, but not all.

Some people have another view of how such networks should operate.
There are various flavours - those doing backbone routing, those with
two-way DVB services. 

Two alternative viewpoints: 

(i) Some people have argued for a full MAC 
	- source and destination IP address with EtherType.
(ii) Others could manage quite well with no MAC address, and will 
use IP routing (or some other scheme to address DVB end points).

I believe most networks will benefit from an EtherType - this doesn't
preclude the use of this to denote LLC/SNAP if you so desire, it also
provides a good access point for differentiating IPv4 and IPv6
datagrams, support for a flavour of arp (how that works without
MAC addresses, and how it relates to PIDs and MPEG-multiplexes is 
at the moment an open issue?)

How important is the EtherType field in compression schemes like ROHC?

> 
> Patrick.
> --
> UDcast: Full IP over Broadcast Media
> 
> Phone:  (+33) (0)4 93 00 16 99
> Mobile: (+33) (0)6 14 21 55 98
> Fax:    (+33) (0)4 93 00 16 61                 http://www.UDcast.com