Wikis > SDN Federation/Operability > White Paper | SDN Federation/Operability Orchestration


TOP 10 requirements

  • Controller functions must provide northbound interfaces to orchestration functions.
  • Orchestration functions must provide east-west interfaces between different orchestrators.
  • Controller must support southbound heterogeneous (open & proprietary) interfaces.
  • The framework must support multiple administrative domains.
  • A controller can get configuration demands or request from multiple orchestrators.
  • The orchestration function provides northbound interfaces to the service catalogues.
  • All APIs must be opened & published such as REST.
  • The controller must provide a discovery function.
  • Common APIs for most standard functions.
  • Must scale to “n” number orchestrators and controllers.

Executive summary / current state, / out of scope,

— STEFAN SUGGESTED TEXT —

While network protocols have been converging and are basically standardized on TCP/IP for practically all networks, management of network devices is still highly vendor specific. While “open” approaches are trying to replace network equipment with commodity hardware, this can only be a long term approach. In the short- to mid-term, we need standardization of network device management.

The most difficult issue with network device management is that changes need be “orchestrated”, meaning, there is a certain order in which changes have to be applied to ensure that the network remains operational. With more and more functionality per end-device, this has become complex. Vendors have been responding by introducing “controllers” that can manage many of their devices, and orchestrate changes between them. However, also controllers are highly vendor specific, with proprietary communication both north- and sound-bound.

What is needed is an open API for controllers that is standardized between vendors, allowing to issue network management instructions that are deployed over that vendors infrastructure consistently.

Eventually, there could be controllers of controllers, where a master controller takes control of all other controllers to consistently manage a network. For example, the master controller would conifigure controllers from vendor X and vendor Y which themselves communicate to infrastructure layer elements of vendor Z. However, eventually, we expect that hardware devices will adapt open standard APIs themselves, so eventually the mechanics of network orchestration will be standardized, intermediate controllers will be eliminated or reduced, and the master controller takes on much higher-level architectural control functions to ensure overall performance and reliability of complex networks.

Today, we are concentrating our effort in the north south communication and not the east-west.

Current-Federated-Controllers

— STEFAN SUGGESTED TEXT END —

—– OLD TEXT BELOW —-

Today, the vendors are releasing more and more controllers. Unfortunately, it is too often that they work in an island.

  • The communication to and from could be proprietary.
  • An open source API and full interoperability should be the end goal but baby steps would need to be taken.
  • We could envision that controllers are non-vendor dependent. In other word orchestrator from vendor X could configure a controller from vendor Y that will configure an infrastructure layer element from vendor Z.

 

Today, we are concentrating our effort in the north south communication and not the east-west.

— OLD TEXT END

Problems/challenges

 

1st there is the communication between the Orchestrator and the controllers. Too often, the Orchestrator is a human being and the configuration is done through CLI. The interaction should be through a WEB interface that then will configure the controllers through APIs.

 

2nd there is the communication between the controllers and the infrastructure layer elements. Again we should move away from the CLI configuration. The configuration should be done through programmable interfaces such as HTTP, SNMP, NETCONF, CAPWAP… defined by the opendaillight organization.

 

3rd there is the legacy equipment. In this case, there is a lack of controllers. We acknowledge for legacy equipment it could be best to use CLI for the time being.

 

==============================================================

Use Case Number 1
Use Case Name Description: Multiple Controller Coordination To Configure Workload Dependence Map 

In this Use Case, the multiple controllers are orchestrated to configure their respective devices/components to establish a work load’s dependency map.  The dependency map may be wide area communications or WAN devices, firewalls, IPS, switches, routers etc, that is all hardware devices and/or software components that an application dependents upon to deliver its service at a high experience level.  This use case seeks to automate workload dependency map configuration to decrease the time of IT delivery.   Based upon ONUG community data, the time to install a physical server is approximately 200 days starting at the time the order is sent to procurement and 42 days to configure a workload’s dependency map after the physical service has been installed.  Assuming that a Virtual Machine can support the workload, then its configuration time is less than 15 minutes and x number of minutes to configure the dependency maps.

Actors:  Data Center, WAN et al Orchestrators

Pre-Conditions:  The workload and supporting services must be identified and provisioned.

The network controllers and resources participating in the service chain must be identified and deployed and activated.

Post-Conditions: The orchestrator has necessary information for dependency map authorization, creation, and configuration.

Alternative Paths TBD

Assumptions Orchestrators are connected and communicating to controllers, while controllers have full authority to act upon their supporting devices on behalf of orchestrator directives.  The full dependency map is know to orchestrators.

Reference TBD

Field  Description 

==============================================================

Use Case Number 2
Use Case Name Description: SD-N and SD-WAN Controller Collaboration

Currently, data center orchestration and controllers are disjoint from wide area networking initiatives. This use case seeks to connect these software-defined infrastructure islands to establish network connectivity and network services for applications/workload that spans both local and wide area networking.   In this use case, a workload is configured to span both data center and wide area network infrastructure.  Specific SD-WAN and SD-N virtualized networking/overlay connectivity require coordination and tunnel establishment.   In addition,  to support workload, network services resident in branch offices and data center require configuration.

Actors:  Virtualized Networks/Overlay Data Center Controllers and SD-WAN Controllers

Pre-Conditions:  The controllers much be configured and operationally supporting their respective devices while controllers are under the direction of their associated orchestrators.

Network controllers and resources participating in a service chain, if any, must be identified and deployed and activated.

Post-Conditions: The orchestrator, controllers and devices has authorized and necessary information for connectivity establishment plus network service configuration.  Application/workload is provided with connectivity and required network services to service uses in both branch offices and corporate facilities serviced by data centers.

Alternative Paths TBD

Assumptions Orchestrators are connected and communicating to controllers, while controllers have full authority to act upon their supporting devices on behalf of orchestrator directives.

Reference TBD

Benefits

The benefits will be able to have automatic configuration, a simpler repeatable process less prone to user errors, faster provisioning. The investment will be in software that has a depreciation of 3 years instead of hardware that is 5 years.

==============================================================

Use case number Alpha

Use case name Leverage orchestration to fail-over application.

Description

In this Use Case, an application is running in a data center A and it is in a dormant state in data center B. If the application starts misbehaving or the application stops running, the orchestrator will reconfigure the environment to isolate the application in data center A and to activate the application in data center B.

Pre-conditions

There is a process that will detect the application failing and notify appropriate parties. The business decided to automate the fail-over or to have a manual intervention.

The orchestrator has all information to reconfigure the environment.

Post-conditions

N/A

Assumption

Orchestrators are connected and communicating to controllers, while controllers have full authority to act upon their supporting devices on behalf of orchestrator directives.

Benefits

  • Automatic fail-over: For the cases of high cost and complex high-availability (HA) architecture, this could help to contain the cost and simplify the architecture with having almost the same benefits as HA.
  • Manual fail-over: Once the business to invoke a BCP condition, it will take milliseconds to execute.

==============================================================

Use case number Beta

Use case name Enterprise network reconfiguration

Description

In this Use Case, a new application is provisioned or an update is pushed to an application that will bring new services. The network needs to be reconfigured to prioritize the traffic of that application based on specific parameters. The orchestrator will direct the different controllers to reconfigure the network components in the field (routers, firewalls, switches, access points, WAN optimization…).

Pre-conditions

Network parameters of the applications are known.

Post-conditions

The traffic of the application has the correct prioritization across throughout the enterprise.

Assumption

Orchestrators are connected and communicating to controllers, while controllers have full authority to act upon their supporting devices on behalf of orchestrator directives.

Benefits

It will take seconds to reconfigure the network to accommodate the needs of new services.

==============================================================

Use case number Gamma

Use case: “Automated workload provisioning”

Description

In this Use Case, an application spans between 2 data centers. We would envision that the orchestrator will configure the different equipment to provision virtual servers, databases,…, network equipment, bandwidth between data centers.

Pre-conditions

There is enough spare capacity in the data center and the overall infrastructure to accommodate the need of that new applications.

Post-conditions

The application is fully operational between 2 data centers.

Assumption

Orchestrators are connected and communicating to controllers, while controllers have full authority to act upon their supporting devices on behalf of orchestrator directives.

Benefits

The application is deployed quickly with minimal human intervention. The application could be redeployed exactly the same way between 2 other data centers.

Federated-Controllers Federated-Controllers-Detailed

Tags: