Cisco XNC Definition

Cisco XNC (Extensible Network Controller) is a software platform that acts as an interface between one-way (southbound) network hardware and third-party applications (northbound).

It runs on a Java Virtual Machine (JVM) runs on any hardware platform that provides a Java runtime environment (see the Deployment Steps tab for system requirements).

Cisco XNC is based on a comprehensive, highly available architecture that supports networks of heterogeneous network devices.

The design of the controller is to support multiple protocols to support devices with different functions and to handle different protocols.

Cisco XNC builts on the Open Services Gateway initiative (OSGi) framework for greater extensibility, so new features can be added. OSGi also has built-in ISSU (In-Service Software Upgrade) and the ability to run different versions of modules.

Features

Cisco XNC has the following features:

  • Multiprotocol southbound support such as OpenFlow 1.0.
  • The features that support network visibility and programmability, including network topology discovery, network device management, forwarding rule programming, and also access to detailed network statistics.
  • A service abstraction layer that enables modular southbound interface support, such as OpenFlow 1.0.
  • Consistent administrative access.
  • The Security features like role-based access control and integration with external Active Directory or TACACS for authentication and authorization.
  • Troubleshooting tools such as analysis collection and diagnostic packet injection.

Developers can program the northbound interface using the REST API.

Feature module

As mentioned earlier, Southbound supports OpenFlow 1.0 support. Support for other protocols such as OnePK and OpenFlow 1.3 will be added soon. The dynamic link of these modules is to the service abstraction layer (SAL).

SAL provides services to higher modules. It also resolves how to satisfy service requests regardless of the underlying protocol used between the controller and the network device. As OpenFlow and other protocols evolve, this protects your application investment.

  • In order for a controller to control a device in its domain, it needs to know about the device itself, its capabilities, reachability, and so on. This information is stored and managed by the Topology Manager.
  • Other components such as ARP Handler, Host Tracker, Device Manager, and Switch Manager can help generate a topology database for Topology Manager.
  • The two underlying applications are Topology Independent Forwarding (TIF) and Slice Manager. Other applications can use the services of any other form or module using the API.
  • TIF and Slice Manager generate rules that program into various devices through the Forwarding Rules Manager.
  • The controller exposes an open northbound API used by the application. And also it supports the OSGi framework and bidirectional REST for Northbound API. Business logic and algorithms are in the application.

These applications use the controller to gather network intelligence, execute and analyze the algorithm, and then use the controller to orchestrate new rules across the network.

The controller has a GUI for management.