Welcome back to part III of our blog on orchestration and control. In the previous part we have discussed everything around onboarding infrastructure like switches and media edge devices and how an orchestration platform can build and maintain a list of usable inventory which can then be shared with a broadcast- or SDN-controller.
In this blog we are looking into step 2: Plan
What needs to be done?
Once your resources & equipment are ready-to-use, you can start planning your event or production ahead of time and therefore you need to reserve resources.
Instead of specifying dedicated equipment, you could work with resource pools. These combine similar resource types which don’t have to be exactly identical, for example CCUs. Each CCU can have different capabilities. In your pool of 10 CCUs only 3 might be UHD-capable, they might be from different vendors and one of them might have a limitation as it can only be used in a certain studio.
The sum of all resources you need for your event is stored in templates, also known as service definitions. Those templates define the amount of resources and their characteristics you need per resource type, without pinpointing to a specific resource yet.
Remember, the orchestrator maintains the list of usable inventory. In the next step you pick one of your templates, define a start and stop time for your event, and based on that the orchestration platform will make reservations on specific resources that are available at the requested time, are capable and have the capacity to fulfill the requirements for your upcoming event.
With the move to software- and cloud-based systems, an important new aspect comes into play. You also want to be able to reserve resources which do not exist permanently. Consequently, an orchestration platform must be capable to deploy and spin up the resource on demand, often right before the event starts, for example a cloud-based transcoder or a virtual machine to host a video server.
Making reservations on physical on-premises resources is also not always straight forward. Imagine you want to reserve two decoder channels on a 6-channel video server: being able to virtualize physical resources into elementary (virtual) functions is another key requirement for an orchestration platform to manage those elementary virtual functions efficiently.
Here are a few examples of different resources and their characteristics:
- Resource types
- on-premises physical resources (e.g. monitors, multiviewers, CCUs, control panels, …)
- virtual resources (e.g. pools of multicast-addresses, studios, people, …)
- cloud-based resources (e.g. microservices, transcoders, packagers,…)
- Capabilities
- technical (e.g. HD or UHD, …)
- locations (e.g. remote studio, stadium, …)
- administrative (e.g. rights associated with a device)
- Capacity
- network capacity (e.g. 10Gig-link or 100Gig-link)
- device capacity (e.g. encoder that supports four parallel encodings in SD, but only two encodings in HD)
- Availability
- resource has not been reserved for another event yet.
- and is not impacted by the factors mentioned in part II of our blog (e.g. in planned maintenance, in alarm, etc.)
Once the reservations for your equipment have been made, the orchestration platform guarantees that all required resources will be available for your event by constantly tracking the reservation state and the availability of each resource.
In case a resource goes into alarm before the event starts or during the event, the orchestrator must apply an alternative resource from the resource pool for your production. Resource management is a dynamic process which constantly needs to adapt to changing circumstances.
Managing resources is a must for an orchestration platform. Depending on your use case the orchestrator must also be aware of the network topology and know where all resources & media end points are connected in the network. Only with that the orchestrator can guarantee that the reserved resources can be connected together. Being able to reserve network capacity is mandatory whenever the network infrastructure has been designed in a way that the network can potentially be oversubscribed.
Why do you need this?
- no more resource overbooking, resources are available at the requested time
- resource utilization ratio and network utilization will be optimized
- cost per resource and per event can be tracked easily
In short, this way of working allows you to do more with fewer resources, as they are always automatically allocated in the most efficient way.
How to integrate with SDN- and BC-controllers?
If the orchestrator does not also fulfill the role of an SDN- and broadcast-controller , those separated systems need to work together.
The orchestration platform shares the reservation state of each resource including the event, which the resources have been booked for, with the broadcast- and SDN-controller.
With that, a broadcast controller can for example make exactly those resources on its user interface available, that have been reserved by the orchestrator before.
The SDN-controller can limit the sources and destinations which are made available to an operator to only those, that are required for the production, especially useful in blocking network infrastructures to avoid operators switching signals (and consuming bandwidth) which are not required for the production.
It is important to mention that for blocking networks, the orchestration platform needs to ask the SDN-controller if there is enough network capacity available for an event that is getting planned in the future.
No matter which combination of controllers and orchestrators you chose, make sure they can interface with each other.
In the upcoming part IV of this blog series, we will look into step 3: CONTROL
Great summary of what network orchestration can bring to the table. One thing that would also be interesting to discuss in future parts of this “controllers and orchestration” series is how orchestration facilitates the monitoring and management of intra- and inter-domain networks (with special focus on the inter-domain).
Thanks Flavio for your feedback! We will certainly pick up your idea in one of our upcoming blogs! In the meanwhile we have posted part IV of this blog series, which is about dynamic service-aware monitoring in general.