RE: [EFM] T.V. broadcast / unicast
Roy,
Sorry, I don't quite understand the cost differences between
a) what I described, and
b) your conception of Ethernet systems.
Let me try to be more clear as to what I am after, and please come back and tell me how my system differs from yours; again, I think this comparison could be of interest to many EFM interessees.
Bob, thanks for your referring to my previous lengthy contribution.
What I have in mind is indeed an Ethernet system, and more specifically, an 802.1D switched full duplex point-to-point Ethernet public access network, built with fiber optic links [can also use Cat5 for short length final drop].
These are something like pre-standard EFM networks that are being built today, using Enterprise-grade standard L2 Ethernet switches with optical (e.g. 1000Base-LX and 100Base-FX) interfaces.
Several companies do this today, and the pioneers that I know of back in Europe started to build Ethernet access networks like this back in 1996-97, as limited field trials. No need to say there are operators (both new entrants and incumbents) investing in & operating these networks.
Expensive? -- Maybe, it depends on what they are compared to, and, perhaps more importantly, what are the business cases [out of scope here though].
If it is the DVB/MPEG2/IP/Ethernet content packaging you see as costly, I might agree; these Head Ends are still fairly expensive and to some extent still at a prototype stage.
If it is the IP TV CPE (Set-Top Box) that worries you, I also partly agree; these are not yet mature enough technically & have not yet reached the volumes leading to economies of scale.
However, I tend to see both of these devices as parts of a service offering, very remotely tied to subscribers' access connectivity, and I don't really think these were the components you had in mind when talking about high cost.
Just a few more words on the L3 (IP) multicast support assumed in my setup:
It is currently very common for switch makers to include a feature called 'IGMP snooping' (an L3 filtering mechanism with proprietary implementation), to realize the limited broadcast/multicast distribution mechanism desired for the IP TV application. But this is probably old news to all of you.
Finally, all, please note that what I attempted to describe above is only one of the many possible types of EFM-like Ethernet access networks; the active point-to-point topology based on new physical infrastructure.
When taking on an overall system view, capacity distribution & features usage will certainly vary between topologies, active or passive networks, etc.
Thank you,
Ingvar Froroth
> -----Original Message-----
> From: Roy Bynum [mailto:rabynum@xxxxxxxxxxxxxx]
> Sent: Friday, November 23, 2001 2:40 PM
> To: bob.barrett@xxxxxxxxxxxxxxx; John Pickens;
> carlosal@xxxxxxxxxxxxxxxxxx
> Cc: stds-802-3-efm-p2mp@ieee.org; stds-802-3-efm@ieee.org; Norman Finn
> Subject: RE: [EFM] T.V. broadcast / unicast
>
>
>
> Bob,
>
> The problem that I have with Ingvar's e-mail was that he described
> functionality that exists on systems that cost much more than
> Ethernet
> systems do, starting at about 10X per megabit. There are
> fully loaded
> SONET ADMS that cost less per megabit than those systems do.
> I do not
> believe that the EFM TF would consider that to be cost
> effective or have
> the "broad market potential" that is part of the 802.3 requirements.
>
> Thank you,
> Roy Bynum
>
>
> At 02:33 PM 11/21/2001 +0000, Bob Barrett wrote:
>
> >I think a lot of this depends on how the relative cost of CWDM optics
> >develops over the next two-three years. It would be far
> simpler technically
> >to put b'cast TV (and / or user selected TV channels) on a
> separate lambda
> >(may be not using an 802 protocol). I thought that was why
> we are proposing
> >to leave some of the lambda bands vacant.
> >
> >I thought that the email from Ingvar was very informative.
> >
> >'Broadcasting' only the channels selected by users (probably from a
> >selection system at the POP, not at the CO) is a change of system
> >architecture from the traditional cable T.V. model. It also
> requires powered
> >POPs. Powered POPs map well into the star / fan-out p2p
> systems (which maps
> >into my positioning well, so I am in favour of it).
> >
> >Best regards
> >
> >Bob
> >
> >-----Original Message-----
> >From: owner-stds-802-3-efm@majordomo.ieee.org
> >[mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of
> >carlosal@xxxxxxxxxxxxxxxxxx
> >Sent: 20 November 2001 19:55
> >To: John Pickens
> >Cc: Norman Finn; stds-802-3-efm@ieee.org;
> stds-802-3-efm-p2mp@ieee.org
> >Subject: [EFM] Re: [EFM-P2MP] Point-to-Point plus Shared Media
> >
> >
> >
> >
> >Two comments:
> >
> >1) John Pickens said:
> >
> > > I know there is a contingent within the working group
> that does not
> > > consider it a requirement to access the
> single-copy-broadcast attribute
> >of
> > > the media, so probably we should poll this question at some point.
> >
> >Although I'm the first to acknowledge that my opinion is *not*
> >representative of all carriers (far from it :-), I can say that the
> >single-copy-broadcast is one of the *great* potential
> advantages of using
> >Ethernet PON in the access network. Of course, it all
> depends on whether
> >will we be able to provide broadcast-based services such as
> digital video.
> >
> >I believe that many carriers will be of the same opinion.
> >
> >So my vote is already cast - single-copy-broadcasts are a
> requirement.
> >
> >2) Norman Finn's idea is really neat from a technical *and* political
> >standpoint, as it sounds as a reasonable compromise between
> the two fields;
> >however, I'm not sure that it's actually feasible in practice due to
> >administrative reasons, as John pointed out. It is highly
> probable that
> >most carriers will end up using only one of the modes.
> >
> >[For instance, this already happened with DSL; almost nobody
> uses the two
> >transmission modes of DMT modems (interleaved and fast).
> Although it is
> >technically possible to use the two at the same time, almost
> everybody uses
> >only the interleaved one, mainly because of the complexity, and also
> >because of potential compatibility issues]
> >
> >Anyway, just to explore the alternatives, we could deploy completely
> >separate IP networks, each over a separate MAC address (of
> course this
> >assume that we are going to run IP over Ethernet, but who
> bets otherwise?).
> >Each IP network could 'opt' for some particular mode of operation.
> >
> >p.s. There are also some security issues that we should
> analyze in this
> >case; the two kinds of traffic would be received at every
> node, and this is
> >could pose a different security problem. Not sure about it,
> just wondering.
> >
> >
> >Carlos Ribeiro
> >CTBC Telecom
>