March 16, 2016
It bears repeating that RIFT.io’s mission as a company is to accelerate the pace of innovation for next-generating network technologies such as NFV and promote wider adoption by making the technologies easier to deploy. One surefire way we have been delivering on our mission is to collaborate openly, even with companies with competing technologies and approaches. A prime example of this collaboration was our work with both Canonical and OpenMANO on an elegant design to connect resource orchestration and configuration management using our open-source RIFT.ware platform.
We did this because orchestrating network services in the cloud requires both elements to work together in an integrated way. Resource orchestration is responsible for creating network and computes resources, and interconnecting virtual network functions (VNFs) either through logical connections or forwarding graphs. This requires the VNFs to be configured, which is not a one-time task.
In fact, configuration management may span the entire life cycle of the VNF. Typically configuration management can be split into three phases day-0, day-1 and day-2. Day-0 configuration refers to the configuration required for boot strapping the VNF and is done once, at the VNF startup. Day-1 configuration refers to early-phase configuration such as configuring the VNF with license server information. Day-2 configuration is typically responsible for enabling and managing the functions offered by the VNF with modifications to the configuration possible during the entire VNF lifecycles.
RIFT.ware provides two distinct mechanisms to facilitate configuration management – management using the native Configuration Management (CM) tasklet and management using Canonical Juju. RIFT.ware uses plugin architecture to enable both configuration management options simultaneously. In addition, RIFT.ware supports the concept of Configuration Agent Account. This enables specifying multiple configuration modes. Figure 1 shows screenshot for adding a Juju configuration agent account.
RIFT.ware also supports primitives for configuration management at both VNF and NS, or configuration primitives and service primitives respectively. Configuration primitives typically refers to the configuration of a single VNF, while service primitives may impact multiple VNFs. However, both primitive types are model-driven with RIFT.ware WebUI providing a simple interface for configuration management based on the model. Each primitive is also associated with a list of parameters expresses as a name and value pairs and supports the following attributes:
- Default: A default value may be associated with the parameter
- Mandatory: Implies that the parameter is mandatory
- Hidden: Implies that this parameter is hidden in the UI from the user
- Read-only: Implies that user will not be able to edit this field in the UI.
The parameters can also grouped for clarity and through a mandatory flag at the group level entire group may be made optional. RIFT.ware provides an RPC mechanism to invoke primitives. For each primitive the user may specify a path to a custom script to be executed when the primitive is invoked. The WebUI provides the ability to view the job status of each executed primitive. Figure 2 shows the screenshot of an example NS level primitive:
For leveraging Canonical Juju to implement the configuration primitives for the VNFs, RIFT.ware enables the use of Juju Charms. Since the VNFs are already launched from the resource orchestrator, “manual provisioning” feature of the Juju is used to deploy Charms to existing systems. The architecture for RIFT.ware integrating with Juju in the context of Open Source MANO (OSM) project is illustrated in Figure 3:
In this design configuration, RIFT.ware Launchpad is serving as the Network Service Orchestrator (NSO), Telefonica’s OpenMANO as the Resource Orchestrator (RO) while Canonical Juju fulfills the role of the configuration manager. The proxy charms responsible for configuring each VNF are deployed in independent containers on Juju server. Figure 4 shows the call flow for configuration management using Juju with RIFT.ware deploying a proxy Charm for each VNF in the NS. After the Charm is deployed initial configuration primitives are applied.
RIFT.io simplifies this detailed, multi-solution integration by employing a plug-in architecture for configuration management. Currently, we support two different types of plugins, Canonical Juju and RIFT.ware native. Figure 5 illustrates how this plug-in architecture works in RIFT.ware.
In conclusion, we and other industry watchers expect the pace of NFV innovation and adoption to pick up this year as new customer use cases emerge. Our goal is to catalyze this further by working with leading companies and organizations in building new tools and solutions that drive down complexity and increase utility. Our progress in integrating resource orchestration and configuration management illustrates our commitment toward this goal. Look for more updates from us in this key area of our company’s focus.