Re: [EFM] RE: [EFM-P2MP] Point-to-Point plus Shared Media
John (& the PON people),
I hope you will forgive me for "crossing the tracks" once again.
I suggest that we could look at an "Ethernet like" solution for this: If we assume that
some form of PHY-layer ONU identifier is being used, then we could over-provision the
number of bits used for that identifier. For example, if we use 8 bits for a PON that
supports 64:1 maximum split, then we have 192 "spare" ONU id's.
>From the PHY perspective we could define that each PHY must recognize more than one ONU
id (say 4 or 8). Now we can allow the concept of a system implementation that would use
64 + n "virtual MACs" - where n is the number of PON multicast groups that it supports.
(note that we all know that smart system designers will implement many "virtual MACs"
as one real MAC with multiple queues and state - the extra multicast queues are no
different to bridge implementations which support IGMP now)
Our task within 802.3ah would not define the use of these "extra ONU ids" - or even
which ones are extra or otherwise. We would allow someone else to define the use of
multicast groups - perhaps there would be a PON Multicast Group Protocol defined.
Default operation would be strict "multiple point-point emulation," the first (and most
obvious) system level enhancement would be to map downstream broadcast to one ONU id,
smarter system implementers will allow mapping of broadcasts according to VLANs or
multicast group membership.
If the system vendor "gets it wrong" with respect to .1d or general LMSC architectural
compatibility, the PON will still operate in basic mode as multiple point-point. The
only overhead (from our point of view) is a couple of extra bits in the ONU id.
Finally, from the point of view of TV broadcasts - the "IP philosophy" of broadcast TV
is much more scaleable than the "old-fashioned" methods. Instead of sending all
channels to everybody all the time, channels are sent according to multicast group
membership. This means that the number of channels available may scale orders of
magnitude higher than with plain old broadcast. Plus of course the security is
implemented further back in the network (authentication for group membership) instead
of in the client. Security in the client must be fixed for the life of the system
(unless the client is constantly updated) and once broken, is lost forever (pirate TV
decoders anyone?). Security back in the network is invisible to the client and can be
upgraded as technology improves.
Does any of this make sense?
Hugh.
John Limb wrote:
> John,
> You raise an interesting and important challenge. However, if a system only
> supports one view then I think one could make a case that the single copy
> broadcast view is more important than the point-to-point view, at least for
> the residential market. The reasoning is as follows: let us say that we are
> able to do a 64 way split in a year or two. With a point-to-point service
> (not emmulation) we would be limited to providing a maximum of 1000/64 = 16
> Mb/s of broadcast capacity before we would run out of bandwidth. It would be
> even less in practice as we would need to leave some capacity open for data
> and administration. 16 Mb/s is not even enough to broadcast one HDTV channel
> and no capacity for NVOD. If we ever get to a split of 128 the situation
> gets worse.
> Am I right in assuming that the worst inefficiency that would happen by
> reflecting all upstream traffic on the downstream is 50%? This seems like a
> much smaller penalty to make than the drastic limitation that would occur
> with not permiting true broadcast.
> Of course we could allocate a separate wavelength for video broadcast, but
> that would be a severe restriction on how service could be deployed. Even
> then, there are data broadcast services that would very rapidly eat into
> downstream channel capacity.
>