If you recall from my earlier posts here and here, RISE is the new protocol in the Nexus 7000 and 7000 Series switch that allows integration of a remote service appliance like NAM or an application delivery controller with the same functional capability as if it was attached to the switch backplane like an embedded services blade. Devices can actually be connected over any layer 2 network, and not necessarily directly connected to the Nexus switch ports, although that is the usual configuration. RISE-enabled ports are configured on the Nexus 7000 and up to 4 dedicated ports per appliance can be configured for maximum throughput to connected devices.
It’s a great benefit for appliance vendors to not have to develop specific network-embedded modules of their products to install inside the chassis, as well as saving valuable slots while providing the same degree of traffic visibility and optimization for the appliance. In this video, I had a chance to sit down with Praveen Chandra, Director of NAM Engineering at Cisco, to talk about the first Cisco service appliance to support RISE and what it means for Prime NAM customers:
If anything is certain about the video business, it’s this: the volume of change is daunting and every change tends to make life more complicated, not less.
This is certainly true at the sharp end of the business -- digital video processing – where “multiscreen” video, new video formats and new video technologies are together creating a perfect storm of complexity. Once there was SD over MPEG2 delivered to TVs. Now there is SD, various flavors of HD and, soon, 4K; and MPEG2, AVC and now HEVC; plus a wealth of encapsulation schemes and DRMs; And even more screen sizes and resolutions as the number of device to be supported grows ever larger.
The number of permutations of all these options is truly dizzying. Every permutation is a potential video “workflow” to be implemented – and the number of permutations is expanding rapidly, apparently endlessly and it’s exponential. Today Cisco deals with some media companies that have over 80 video workflows for their content. One more video format – for instance 4K – and this potentially doubles to 160. Another compression scheme – HEVC perhaps -- and now we have 320. And so on.
Keeping track of all these “workflows” is one thing, but Read More »
There’s a reason the superlative term “broadcast quality” is the measuring stick and euphemism for “highest possible video quality” — and the people that make it happen are all here this week for the annual National Association of Broadcasters convention.
If you’re reading this, chances are high that you’re on your way or already here, perhaps for the second or third time this year — and it’s only April. We’re there too, not surprisingly, with a lot to share with our colleagues in broadcasting.
By “a lot to share,” I mean the new Videoscape Virtualized Video Processing solution, for handling the massive array of inputs, outputs, and related workflows; solutions for 4K/UltraHD video; advanced HEVC compression; new advancements enabling greater compression with no loss of video quality for MP2 and AVC; and a clear path for our broadcast television colleagues to swiftly transition to IP video, from production to ad insertion to delivery.
The notion of combining enterprise-grade routing with broadcast television isn’t a new one, especially at a National Association of Broadcasters convention. Like everything else, the intersections between Internet Protocol-based technologies and just about everything — video included — have been building momentum for the last several years.
But! This year is different, and milestone-grade, if you ask us. Why? At this year’s NAB, Cisco and Snell, a long-time leader in broadcast television infrastructure, will demonstrate what we believe to be a first-ever integration of real-time, IP-based signaling — from production to the viewing screen.
In essence, the demonstration makes it possible for broadcasters to use off-the-shelf, enterprise-class IP routers to distribute video — in the same way they now ship SDI (serial digital interface) signals through the television ecosystem. If we were to Read More »
One of the great challenges of SDN – that many in my view underplay – is the change in paradigm from having a vendor deliver your network (hardware + software), to having (potentially) an ecosystem deliver your network – and this ecosystem may require you to develop software to perform network tasks or to integrate various SDN components together. This was recognized quite astutely by consultant Jim Metzler, which I discussed in one of my earlier blogs. “Applications can dynamically request services from the network” is what the SDN evangelists will tell you. Jim astutely asked “How exactly do they do that?”. Well ….. the true answer is that either (i) you need to buy [new] apps that do this off the shelf, as it were, or [more likely today] (ii) you need to modify your apps or develop new apps to do this.
Coding -- the New Networking?
So are you ready for procuring apps and/or developing software in your network design team now? Don’t worry if you say “no”. Let me first tell you a few customer reactions to this topic, and then let me update you on Cisco Services can help you develop new SDN apps that solve your specific network challenges.