This is kind of a part 1.1 or what you wanna call it. Before starting on the technical side of 2110 I would just share my thoughts and experience so far on 2110 in a IP Core.
For now I have a full 2110 network up and running, its not yet in production, but it will be soon. To be simple here in the end it’s just multicast traffic that I need to transport, but there are som challenges here that we need to address.
I am not a broadcast engineer, I am a Network Engineer, so the broadcast side I am still a noob compare to many other I work with. I try to learn the broadcast side, but this would take som time. There are a lot of pieces that are put together to make this puzzle work.
One of the challenges to move forward to IP here is the broadcast vendors does not understand network on that level they should. Same goes for the network vendors, they are not understanding or have the knowledge on have end customers are using the broadcast equipment in a production. Many relays on the standards that are out there, in the network world we think about this as multicast streams that we need to handle. The challenge here is that PIM is not bandwidth aware, so we relays on ECMP to load balance for us. This is not a perfect solution, but it does work.
Another thing that scares me is that many vendor and broadcast people are designing this as layer 2 network. As I wrote in part 1, that is a big NO NO! Yes, it’s simple to understand and maybe to setup, but handling it when the network grows is pain, just handling Spanning-tree here and control it can be huge task and in some cases impossible..
There are solution out there that have made som control software to handle this, but I am not a fan of taking the control plane out of the hardware. If that controller goes down you loose control or in some cases the network and a control plane on the switch is usual faster then when its running on a server or another hardware somewhere. I know some vendor or persons are not agree with me on this, but this is just my experience. Another thing here also is that you can loose feature that are in the software on the network equipment because the control software does not supports it yet and you can not manually configure the switch through CLI because the control software does not like this.
So a solution in between here I think is great, a broadcast software that can do some manual multicast stuff and handling the endpoints is fine and don’t touch the routing. We still have the issue on the network side then, bandwidth ! In this case ECMP is only option, Cisco have NBM (None Blocking Multicast) that uses Policy map to handle load sharing between links and it’s the local switch that handles this. This address the bandwidth issue somehow, but it’s not that smart. I have not tested it my self, so will be careful to say anything about it. I would test it soon.
After some more experience I would write more of this thought post.
The list can go on, but I think I leave it there for now. Maybe add some more thoughts in the future. This is just my thoughts I wrote down on a late night after I put my 4 months baby to bed and hade som time to spare. Sorry for any abbreviations. I would also like to here anyone else opinion on this, I have not enable comments here yet, but soon. In meanwhile contact me on LinkedIn or comment on the post where I linked this article.