Welcome back to part II of our blog on orchestration and control. In the previous part we have discussed differences between network controllers, SDN- and broadcast-controllers and why an orchestration platform on top is required.
To deploy a successful orchestration project, you need to cover multiple aspects:
- Onboard
- Plan
- Control
- Monitor
In this blog we are looking into step 1: Onboarding
What needs to be done?
Before you can use your equipment in production, it is most efficient to onboard all your resources in an automated and secured way.
First you need to discover switches, media edge devices, and any other physical and virtual infrastructure. This could be via network scan or by interfacing with third-party CMDB-databases, as well as with a NMOS IS-04 registry. Also make sure that your solution not only discovers your infrastructure, but also extracts network connectivity, for example via LLDP-protocol.
In a 2nd step an orchestrator applies initial base configurations and makes sure each resource has the right firmware and software running. This process can even perform a number of automatic checks, like for example, check whether the standard credentials of the data source have been updated.
As a result of the onboarding process, the orchestrator maintains a list of usable (“ready to use”) inventory. It is important to mention that many factors can impact the usability of a resource after a successful onboarding process. An orchestration platform has this context and constantly updates the status of each resource.
Here are a few examples of what can impact the “ready to use”-status:
- health state (e.g. faulty device)
- planned maintenance slots (e.g. planned firmware update)
- device connectivity state (e.g. connection lost)
- security breach (e.g. application vulnerability)
- rights (e.g. time restrictions for signals)
- license status (e.g. pay-per-use infrastructure)
- predicted alarms (e.g. via an AI forecasting engine)
- detected anomaly (e.g. via AI behavioral anomaly detection algorithms)
Why do you need this?
- get a single source of truth for all your inventory
- achieve consistency by automating the onboarding process
- automation adds security and leaves less room for human error
As you have seen in part I of our blog, an orchestration platform can cover many roles, sometimes this includes the role of an SDN-controller and / or broadcast-controller at the same time, or an orchestration platform can interface with other SDN- and BC-controllers. It will depend on your project and your needs which combination will fit best.
How to integrate with SDN- and BC-controllers?
First an orchestrator need to share the list of usable inventory and (optionally) the network topology via an API with the broadcast-controller and SDN-controller.
Second, you also need to take care of IP-addresses, your orchestrator should be able to manage ranges of IP-addresses and multicast IP-addresses and share those with the controllers, which allows the latter to use and apply those addresses to equipment managed directly by the SDN- or BC-controller (e.g. source devices which need an IP-multicast sender address).
In part III of this blog, we are going to look into step 2: PLAN
Such a wonderful article, thank you!
Nice continuation.