Re: AW: About dest MAC@

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

Dear Wolfgang,
I thank you very much for your explanation, and I have some additional questions to make sure I fully understand you explanation :
The example is based on small ISP's feeding their network over satellite link from a large teleport. For me, the link between the teleport and the small ISP looks like a B to B link allowing then the small ISP to provide B to C access to local customers. My question, is now the following : why would a teleport service to ISP providers use MPEG2 - DVB protocols (mostly designed for DTH TV services) for that B to B pure data link ?  I assume that this kind of data transmission is already used since years over dedicated telecom satellites with other more suited protocols ? This especially when your scenario requires a bi-directional and permanent satellite link ?
What do you think ?
Bertrand

> assume the following example operational scenario:
>
> A teleport service provider provides broadband Internet access via DVB-S to smaller ISPs located in regions without terrestrial broadband access. This teleport provider serves more customer on the same transponder. It assigns to each of them a global routable IP address space. Receiving traffic from the Internet destined to one of its customer's IP address space the teleport service provider will broadcast the traffic on the DVB-S link. As this link is shared by more customer, the traffic "physically" will be received by all of them. In order to allow efficient filtering, the teleport provider uses a specific PID for each customer as well as the MAC address of the customer's receiving equipment. This scenario could also include a "kind of manually configured and therefore static address resolution" (mapping of customer's IP address space to customer's PID / MAC address). Doing things like address resolution automatically is somewhat difficult if we're talking about uni-direc!
>  tional links.
>
> However this example operational scenario reflect many aspects Alain and Gorry discussed:
>
> - The connected minor ISP could use the teleport service provider as the only external access (leaf network with single access point)
> - The connected minor ISP could use also other teleport service providers / peering ISPs but do not transit traffic between them (leaf network with several access points)
> - The connected minor ISP could use also other teleport service providers / peering ISPs and do transit traffic between them (transit network with several access points)
>
> What I do not see so far as a common operational scenario is that one customer will receive for its IP address range traffic via several access router connected to the same DVB-S transponder. But also this could change in future if IPv6 brings more possibilities for multihoming and network renumbering.
>
> Cheers,
>
> Wolfgang
>
> >
> >
> > 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
> > CANAL+modified.
> >
> >
> >

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