Re: About dest MAC@

["Bertrand WENDLING" <wendling@canal-plus.fr>]

Dear Alain, dear Gorry,
I am a little puzzled by this discussion, you should not forget that in a broadcast
world (meaning DVB-MPEG2), it is very uncommon for the broadcaster to know the MAC and
even the IP address of a receiver (today nearly all of them don't even have one).
Receivers are bought in any kind of retail shop and are plug and play when connected to
a dish. In a broadcast mode the only thing you need to know on the receiver side is what
IP service I have to listen to in order to get access the expected service (the IP
address is here used as another filtering criteria to extract the relevant IP sections
in an IP stream). Regarding the broadcast technology (still meaning DVB-MPEG2), except
for specific B to B application, it is uncommon to do unicast, just because of the cost
of the bandwidth.
Now, the interesting point is when a receiver have a broadcast access (e.g. a dish to
get the MPEG2 signal), and a DSL access. In this case, the receiver will work in the
same way as a PC connected to the DSL network, but might access data from both network
(the MPEG 2 and the DSL one) for various application where two streams may be needed
(the common one broadcasted, and the user specific one streamed over DSL).
Now, assume that in case the broadcaster wants to send data to a specific user over the
DVB-MPEG2 network, based on a request coming through the DSL network (back channel), he
will have to give the receiver the DVB triplet (to locate the TS and PID) and an IP
address to filter on. In any case, the only way the receiver can be known by the
broadcaster is when he has a return channel (e.g. a DSL connection, and then, the IP
address is allocated by the ISP).
Could you perhaps explain a little more the concrete scenarios and operational
configurations you have in mind ?
Best regards
Bertrand

Dr G Fairhurst wrote:

> alain.ritoux@6wind.com wrote:
> >
> > Dr G Fairhurst wrote:
> >
> > >
> > >>- If the IRD is itself a router, there is still the case (that may be
> > >>of (most?) common usage ??) that the network behind it is a
> > >>leaf-network, and by no mean a transit network.
> > >
> > >
> > > OK, so specifically you mean a leaf network where routing protocols are
> > > not used to determine forwarding to the "leaf" network. One example is a
> > > network with one external receive interface (via the MPEG-2 port).
> >
> > Not exactly, in fact, the "leaf" network I had in mind could have
> > several point of access (i.e CPE), but does NOT provide transit, hence
> > only packets destined to the "leaf" network should be accepted.
> >
>
> OK, but what happens whene there are several places (networks)
> via which the "leaf: network may receive an Ip packet?
> - routers normally advertise that a site is reachable
> via an interface. Do routers do this on each network to which they
> are attached?
>
> If so, how do the routers connected to the MPEG-2 feed know whether
> to forward the packet from the MPEG-2 feed via the other network(s)
> to the destination end host, or to discard this packet because
> someone else will be forwarding? - This is usually the function of the
> IP routing protocol in combination with the link MAC address.
>
> In the case of just one receive interface, the above point is moot,
> and we don't have the same routing issues.
>
> > >
> > > That is, theer are no alternative delivery paths, and therefore no
> > > reachability via other routers that may also receive the packet. Specifically
> > > you must also require all other routers to silently drop packets with
> > > an unreachable network address. If you do all this, I agree - but
> > > although this would work, it seems a "tweak", and I'm not sure the
> > > latter
> > I admit this is tweaky, and I'm not definitly proud of it ;-)
> >
> > > is a robust recommendation (if one router returns an ICMP message to
> > > the source, what happens??)
> > Well, the source is informed that dest is unreachable, and may stop.
> > So indeed, it works only when ALL routers perform the same trick, which
> > is somehow fragile I admit.
> >
>
> Ok, so, you can do it this way if you have an operational need, but
> it's probably not a recommended solution.
>
> > >
> > > My thoughts are that we have some cases here that can use IP packets
> > > without MAC addresses, providing:
> > >
> > > (a) they can efficiently filter on IP level addresses
> > >
> > > AND
> > >
> > > (b) If they are routers they MUST also differentiate packets with
> > > a MAC dest address from those without a MAC address, and MUST discard
> > > packets with no MAC address that do not correspond to their own IP address
> > > (or with all the rules above to the prefix used for hosts on a leaf IP network.)
>
> > Definitely agree, the trick was only for the case where there's no MAC
> > addr. Of course, if there is a MAC addr, is MUST be used to reject or
> > accept packets whatever their dst IP addr is.
> >
> > Alain.
> > --
> > Alain RITOUX
> > Tel +33-1-39-30-92-32
> > Fax +33-1-39-30-92-11
> > visit our web http://www.6wind.com

--
This message and any attachments (the "message") is intended solely for the
addressees and is confidential. If you receive this message in error, please
delete it and immediately notify the sender.
Any use not in accordance with its purpose, any dissemination or disclosure,
either whole or partial, is prohibited except formal approval.
The E-Mail transmission can not guarantee the integrity of this message.
CANAL+TECHNOLOGIES will not therefore be liable for the message if modified.


begin:vcard 
n:Bertrand;WENDLING
tel;cell:+33 6 03 45 86 54
tel;fax:+33 1 71 71 50 51
tel;work:+33 1 71 71 53 57
x-mozilla-html:TRUE
url:www.canalplus-technologies.com
org:CANAL+ Technologies;Advanced Studies & Standardisation Department
adr:;;34 place Raoul Dautry;75738 PARIS Cedex 15;;;France
version:2.1
email;internet:wendling@canal-plus.fr
title:Standards Officer
fn:WENDLING Bertrand
end:vcard