Re: AW: AW: AW: About dest MAC@

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

Fritsche Wolfgang wrote:
> 
> Bertrand,
> 
> I don't agree with your point of usual DVB-S receiver are handling 
> only 2Mbit/s max, there are many (also cheap ones) with go far beyond 
> this. And it's not only an issue of the receiver, it's also issue 
> where the receiver is located in the satellite's footprint, and how 
> big is the dish on the receiver side.
> 
Sure, the technology is scalable, from a few Mbps, to 100 Mbps, or so.
The RF intreface (antenna, LNB, etc) vary depending on the link/satellite
configuration, but these don't impact the MPEG-2 transmission format.

> However, my intention has only been to show you that there are 
> operational scenarios in this areas, and from my point of view it's 
> important to have this kind of discussion about address resolution 
> / filtering / ... on this list.
> 

The draft charter at http://www.erg.abdn.ac.uk/ip-dvb/ said 

"The MPEG-2 Transport Stream provides a transmission network that has
become widely use to support digital TV broadcast, including: DVB, DAB, 
ATSC, ISDB-T. These and related standards define a set of commercially 
available components that are increasingly being used to provide a 
general-purpose packet transmission network. MPEG-2 Transport networks 
are being used to build IP networks to supplement broadcast TV/audio 
services and also to provide one-way and two-way IP-only subnetworks."

If that helps to clarify the scope - i.e. the focus should be on the
IP services, but is not restricted to data-only IP services, it COULD
also apply to digital TV broadcast applications that wish to also
support IP services.  

I suggest that where existing standards already exist, such as for 
ATSC, and DVB digital TV broadcast applications, there may be a need
to recommend how the IPv4/IPv6 service binds to these standards, and
it may be desirable to recommend how to use such existing techniques, if
these are applicable. Where there are no techniques, or the techniques
are not well-suited to IP networks, then new techniques will need to
be found.

Either way, we need to set up some scenarios, so we know the various
topologies and use-cases we are looking at. All inputs welcome!!!

Gorry


> Cheers,
> 
> Wolfgang
> 
> >
> >
> > Ok, I have a better understanding on the application you have
> > in mind. Just two remarks for information (again), usual DVB
> > receiver are effectively cheap, but can handle only a limited
> > bitrate dedicated to data streams (usually 2 Mbits/s max),
> > DVB receivers are designed in a way the audio and video
> > stream are processed in a specific and dedicated way at high
> > bitrate where data are demuxed and filtered in a much less
> > efficient way introducing this kind of limitation. When
> > speaking about uplink over SCPC, PSTN etc... You may have to
> > take into account the fact that this asymmetric way of
> > processing is used also at the server uplink side regarding
> > the size of the data to be send (for large amount of data,
> > the satellite like is used, for small ones, the PSTN, narrow
> > band internet return channel is used. This to avoid the
> > satellite transmission delay for small amount of data as well
> > as to make the best use of the bandwidth / transmission cost
> > between satellite / PSNT..... Bertrand
> >
> > Fritsche Wolfgang wrote:
> >
> > > 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.
> > > >
> > > >
> > > >
> >
> > --
> > 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.
> >
> >
> >