The Cisco Extensible Network Controller (XNC) is a software platform that serves as an interface between the network hardware in one direction (southbound) and third-party applications (northbound). The Cisco XNC, which is a Java Virtual Machine (JVM), can run on any hardware platform that provides the Java runtime environment (please refer to Get Started tab for system requirements). The Cisco XNC is based on a highly available, scalable, and extensible architecture that supports a network comprised of heterogeneous network devices. To accommodate devices of varied capabilities and speaking different protocols the Controller is built for multi-protocol support. The Cisco XNC is built for extensibility using the OSGi (Open Services Gateway initiative) framework, which allows new functionality to be added. OSGi also provides you with built-in ISSU (In Service Software Upgrade) and ability to run modules with different versions.
The Cisco XNC provides the following:
- Multiprotocol Southbound support including OpenFlow 1.0.
- Functionality to support network visibility and programmability, such as network topology discovery, network device management, forwarding rules programming, and access to detailed network statistics.
- A Service Abstraction Layer (SAL) that enables modular southbound interface support, such as OpenFlow 1.0.
- Consistent management access.
- Security features, such as role-based access control (RBAC), and integration with an external Active Directory or TACACS for authentication and authorization functions.
- Troubleshooting tools, such as analytics gathering and diagnostic packet injection.
As a developer, you can use the REST APIs to program the northbound interface.
The following example shows how APIs are used on the Cisco XNC . The APIs are described from the southbound to northbound. Refer to the diagram to see where the APIs are in relation to the structure.
- On the Southbound as stated earlier we support OpenFlow 1.0 Support for other protocols like OnePK and OpenFlow 1.3 will be added soon. These modules are linked dynamically into a Service Abstraction Layer (SAL).
- The SAL exposes services to which the modules north of it are written. The SAL figures out how to fulfill the requested service irrespective of the underlying protocol used between the Controller and the network devices. This provides investment protection to the Applications as the OpenFlow and other protocols evolve over time.
- For the Controller to control devices in its domain it needs to know about the devices, their capabilities, reachability, etc. This information is stored and managed by the Topology Manager.
- The other components like ARP handler, Host Tracker, Device Manager and Switch Manager help in generating the topology database for the Topology Manager.
- Topology Independent Forwarding (TIF) and Slice Manager are two applications that are fundamental. Other Applications can leverage the services of any other application or module using the API.
- TIF and Slice Manger generate rules which get programmed to the various devices via the Forwarding Rules Manager.
- The Controller exposes open Northbound APIs which are used by Applications. We support the OSGI framework and bidirectional REST for the Northbound API. The business logic and algorithms reside in the Apps. These Apps use the Controller to gather network intelligence, runs its algorithm to do analytics and then use the Controller to orchestrate the new rules throughout the network.
- The Controller has a built in GUI for management.
The product documentation is available under the APIs and Docs tab.