To Those Who Do DOCSIS3.0, 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. Thanks for any direction you have.
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. This tutorial may help some: http://www.nanog.org/meetings/nanog48/presentations/Sunday/Riddel_VDOC_N48.p... Scott Helms Vice President of Technology ZCorum (678) 507-5000 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Nov 29, 2013 at 9:32 AM, mr. s <sigasecure@gmail.com> wrote:
To Those Who Do DOCSIS3.0,
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.
Thanks for any direction you have.
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. Phil On 11/29/13, 9:32 AM, "mr. s" <sigasecure@gmail.com> wrote:
To Those Who Do DOCSIS3.0,
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.
Thanks for any direction you have.
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. Regards, Frank -----Original Message----- From: Phil Karn [mailto:karn@philkarn.net] Sent: Friday, November 29, 2013 11:10 AM To: nanog@nanog.org Subject: Re: DOCSIS 3.0 and Multicast 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.
On 11/29/2013 10:03 AM, Frank Bulk wrote:
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.
Phil, 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 -------------------------------- http://twitter.com/kscotthelms -------------------------------- On Fri, Nov 29, 2013 at 1:47 PM, Phil Karn <karn@philkarn.net> wrote:
On 11/29/2013 10:03 AM, Frank Bulk wrote:
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.
On 11/29/2013 11:38 AM, Scott Helms wrote:
Phil,
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).
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).
----- Original Message -----
From: "Phil Karn" <karn@philkarn.net>
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... Cheers, -- jra -- Make Election Day a federal holiday: http://wh.gov/lBm94 100k sigs by 12/14 Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274
On 11/29/2013 01:11 PM, Jay Ashworth wrote:
----- Original Message -----
From: "Phil Karn" <karn@philkarn.net>
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.
Phil, 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). regards, Victor K On Fri, Nov 29, 2013 at 1:47 PM, Phil Karn <karn@philkarn.net> wrote:
On 11/29/2013 10:03 AM, Frank Bulk wrote:
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.
participants (7)
-
Frank Bulk -
Jay Ashworth -
mr. s -
Phil Bedard -
Phil Karn -
Scott Helms -
Victor Kuarsingh