I can't seem to find a simple answer to this, possibly because it is self
evident to those actually using Multicast over DOCSIS. Which we are not
currently.
Multicast over DOCSIS 3.0, to 3.0 CM, can the CM share the same media
stream on their node?
In example, 2 Cable Modems in the same node (no splitting, same US/DS
channels/ports, CMTS..), each have a customer watching ESPN.
Is there one or two media streams worth of content on the plant, channels,
node?
We now how this operates in other worlds, GPON, xDSL and AE. Just haven't
seen it specifically mentioned out right in DOCSIS literature.
Keep in mind that in the cable world the node itself is a layer 1 device,
basically it converts between fiber and coax signaling, and so it doesn't
take part in any IP transactions. Now, if your CMTS supports multicast and
the modems on the same node are on the same downstream AND multicast is
enabled on the CMTS then the devices behind the modem (which is a bridge)
can use the same stream. A device behind the modem could actually be an
embedded device on the modem, but in the DOCSIS world the modem itself
(usually) has its own MAC address and each integrated device will have its
own so a home gateway product (video, MOCA, voice, router, and WIFI) will
often have 5+ MAC addresses, one for each of the devices and often each one
has its own configuration.
I would take a look at the presentation in the other post, there are
multitude of ways it can be accomplished and some of those are spelled out
in the DOCSIS 3.0 specs.
Like the other poster said, HFC architectures are very centralized and
controlled at the head-end and the components in the field such as the
fiber node and even the CM are not active in making decisions about where
traffic goes, they just receive what has been sent to them and pass it
along. Ultimately any multicast streams will go to a set-top box (or some
other video device) and in the case of dynamic multicast it would be the
STB generating the IGMP joins.
But to answer your question, the answer is yes, the same stream can be
sent to two different receivers in the same service group. By the time it
gets to the fiber node, it's just RF and if the CM is tuned to the right
frequencies, either a specific one for video, or a shared one, it can be
used.
Most providers aren't doing IP video over DOCSIS, they are still using QAM
based delivery via dedicated video spectrum.
Do any cable companies actually use the hardware multicast capability in
DOCSIS cable modems?
I can think of some potentially neat uses, but it seems highly unlikely
that the cable companies would enable their use to compete against their
own TV programming services.
It's been tried in Iowa (Butler-Bremmer Communications) and elsewhere, but
last I heard, there were bugs in the multicast implementation of the CMs and
the middleware vendor didn't have a very large marketshare. GoBackTV was
more focused on the LATAM market and the company is now owned by Aurora.
They used Asian STBs, not the Motorola/Scientific Atlanta/Amino/Entone STBs
that you may be familiar with. So the end-product looks somewhat cobbled
together.
It looks like Cisco is doing something in the IP Video over DOCSIS area, and
so if you're serious about this, you could reach out to them.
It's not video over IP multicast that interests me so much as the
opportunity to thwart NSA-style bulk traffic analysis by multicasting
unicast messages with encrypted destination addresses so an eavesdropper
can't tell who it's for.
Arbitrarily turning uni-cast traffic into multi-cast won't do much in that
regard. If the end points that didn't orginally ask for the data NAK the
incoming stream then they'll get kicked out of the IGMP group, further the
requesting end point will be confused by the fact that the traffic is
coming in as multi-cast. You could put up some fake hosts that will take
any multi-cast data, but they'd be pretty easy to spot over time and making
all of your home gateways accept multi-cast traffic they didn't ask for
would be a bad thing (think trivial DDoS of your system).
Scott Helms
Vice President of Technology
ZCorum
(678) 507-5000
Oh, sorry, I meant to explain that this would be part of a new system
with user software explicitly written to join a multicast group,
passively listen to all incoming traffic, decrypt whatever's addressed
to it and ignore the rest.
If the destination addresses are hashed or encrypted so that only the
recipient can recognize them, then passive eavesdropping would not
reveal to whom they were being sent and the system would be no less
efficient than an existing cable modem network with the same set of users.
I've been trying to think of ways to thwart large scale traffic
analysis, and in a unicast network it's really not easy without a lot of
extra traffic (think TOR).
Well, in a story in MIT Tech Review this week, it's mentioned that IETF is
considering baking TOR into the base level of the Internet, so if (like me)
you think that's a pretty unmanageable, inefficient approach, you might want
to chime in now...
Well, it's inefficient compared to direct unicasting but I can't think
of a much better way to do it. And if you really want security against
dragnet surveillance, and I think we do, we'll find a way to manage it.
Hey, it's not like fiber bandwidth and CPU cycles are hard to find these
days.
Been watching this conversation and had a few comments.
First, one of the concerns is exposure to wire monitoring on the HFC
(Hybrid-Fiber Coax) plant while using DOCSIS, then I think folks should be
aware that there is encryption applied to the traffic between the CMTS and
Cable Modem (CM). This was traditionally BPI (Baseline Privacy Inspection)
and DOCSIS 3.0 supports SEC (which then allows use of AES). I may have
missed the point along this email train, but folks may not be aware that
putting an RF capturing device on the plant, or sitting behind a CM on the
does not gain you gratuitous access to neighbouring people's data. So if
application/network flows are also encrypted, you would not necessarily be
able to know who it's for as all payload traffic should already be
encrypted on the [DOCSIS] wire. This however does not change eavesdropping
on the outside of the DOCSIS plan (after CM, or before CMTS).
If one did come up with a way of sending normal traffic over a DOCSIS
Multicast pipe, then there are a number of resource issues which need to be
considered (as they have operator and vendor impact). Multicast is managed
very differently (signalling and payload) in DOCSIS vs. Unicast traffic,
and therefore resources will be an issue (i.e. IDs used to direct traffic
for Unicast are not the same as those used for Multicast). To add, forcing
a bunch of (or all) traffic down a Multicast pipe would impact an
operator's ability to managed QoS for customers (which is already complex
enough in the DOCSIS world) and may impact CM operation (which will be
keeping track what multicast groups/packets will be forwarded for a given
service endpoint).