Cisco Blogs
Share

What’s in the Cisco Evolved Services Platform’s Orchestration Engine?


October 17, 2014 - 0 Comments

We created the Evolved Services Platform (ESP) to help our customers increase service revenue while driving down costs. In doing so, we needed to make it expansive to include the breadth of technologies and solutions that would apply to many domains (such as access, Wide Area Network (WAN), and data center) and technologies (such as cloud, security, and video).

And we addressed the fact that a virtualized network function (VNF) is only as good as the automation of orchestration capabilities that are used spin it up and expand it to fit the required job. Given all the VNFs (greater than 40, just counting our own) that we could conceivably be orchestrating, we had to ensure that the Cisco ESP was sufficiently broad and inclusive of multivendor technologies.

The following diagram shows the big picture—the applications and network services made possible by an open, elastic, and application-centric architecture. It includes the applications themselves, the Cisco ESP, and the Cisco Evolved Programmable Network (EPN). Looking inside the Cisco ESP, you can see that the orchestration engine is the centerpiece.

Orcheastration Engine

The Orchestration Engine takes instructions from, and provides feedback to, the Service Broker (which provides the business intent and customer facing portal) and programs the multivendor infrastructure (compute, storage, and network) to enable the applications. It takes into account the provider’s service profiles and catalog of individual functions.

Before looking at the individual orchestration engine components, let’s recap its main functions from the Cisco ESP solution overview:

  1. Automates the creation, monitoring, and assurance of all required physical and virtual infrastructure
  2. Connects applications to infrastructure using open APIs
    • These applications may be accessed via a Service Broker (with a northbound RESTful interface)
    • The infrastructure will typically be accessed via NETCONF programming and YANG data models
  3. Enables operators to dynamically deliver personalized services

Thus, at its base, the orchestration engine performs configuration, automation, and provisioning operations across multiple domains, accounting for customers, services, and infrastructure.

Now let’s double-click on the orchestration engine to view some of its components.

Orchestration Engine 10.17 2

The above diagram actually shows four layers; the top 3 are the ESP and the bottom is the EPN:

  • The Service Broker (top layer) handles customer facing services (CFS)
  • The Orchestration Engine (middle two layers), handles resource-facing services (RFS)
  • The EPN (bottom layer) is the multivendor physical and virtual infrastructure

This gives you a sense of what the orchestration engine might contain in different scenarios. It is further subdivided into cross-domain and single-domain layers.

In our recent virtualized business services announcement, we announced the Cisco Network Services Orchestrator (leveraging technologies from Tail-f) to enable cross-domain orchestration and multi-vendor provisioning capabilities of both physical and virtual network functions. The individual domains are many, as required for an end-to-end architecture; shown above are CPE, WAN, and Data Center:

  • CPE: Connecting business customers to cloud based network and applications services – e.g. Cloud VPN leveraging Cisco Meraki technology
  • WAN: Multivendor WAN resources are managed through Cisco’s WAN Automation Engine, which utilizes Cisco’s MATE portfolio
  • Data Center: Enables profitable cloud delivery of applications and network services to customers as outlined in the business case for Virtual Managed Services

These may talk to each other and work in concert; for instance, the WAN and data center domains may work together for optimal placement of applications or network services based on end user experience (response time) requirements. The main point is that there’s at least one orchestration engine component for every domain, and all may be automated cross-domain by the Cisco Network Services Orchestrator.

And that’s our peek into the Orchestration Engine, under the hood of the flexible, open, and modular Cisco Evolved Services Platform.

Have questions or comments? Tweet us @CiscoSP360 



In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.