[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: AW: About dest MAC@
Bertrand,
one reason for using DVB-S are the costs of equipment, which is extremly cheap on the receiver side. Of course it is only cheap if DVB-S is used in an uni-directional way, that is the uplink happens in an other way, e.g. SCPC, narrow-band Internet, PSTN, ...
Anyhow, these scenarios exist, and they will be affected by the address resolution / filtering issues Gorry and Alain discussed on this list.
Wolfgang
>
>
> 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
> CANAL+modified.
>
>
>