[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: About dest MAC@
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-directional 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.
>
>
>