At a high level, the onePK architecture is composed of three major elements:
- the presentation layer
- the onePK API infrastructure
- the communication channel
These elements combine to provide a consistent and adaptable architecture that enables multiple languages and multiple deployment models for applications that work across the network.
Presentation Layer: What the Programmer Sees
The presentation layer consists of the API libraries that programmers can use within their applications. There are currently many separate APIs available for separate network tasks. With onePK, application programmers get a universal network programming toolkit. The onePK libraries are initially available in C and Java. But the architecture is extensible, so additional language bindings (such as Python) can and will be added. The presentation library was designed with very few dependencies, so it can be easily integrated with existing tooling and development requirements.
onePK API Infrastructure: One API for Many Devices
This provides access to functions that are internal to a router or switch. One of its primary values is that it abstracts underlying differences between operating systems and platforms. For example, if your application uses a onePK function call to read interface statistics, that same function call will work across all Cisco networking software platforms (Cisco IOS® Software, Cisco IOS XR Software, Cisco IOS XE Software, and Cisco NX-OS Software).
Communication Channel: Security and Flexibility
The communication model provides a fast, safe, extensible channel between the application and the network element. (Applications are required to authenticate before being allowed to access the functions of the network abstraction layer.)
By using a pluggable channel, the communication model enables flexible deployment models - a primary goal of the architecture.
A deployment model describes where the application will run. onePK applications can run on the router or switch itself, on a colocated processing blade (if the device supports one), or on an external server that resides anywhere in the network.
The choice of deployment model will be determined by the capabilities of the target device and the requirements of the applications.
onePK is designed so that application developers can deploy their applications in three different modes.
Each mode is designed to be source code portable. Each of the modes is discussed briefly below.
Applications are hosted in a Linux environment on the Network Element platform itself. Isolation is provided between onePK applications and the network processes running on the host processor. The isolation is provided through containers. Communication transport between the network services and the onePK applications are plugged in with platform-specific IPC.
This is a controlled hosting environment. Several levels of security are supported for installing and running applications on a onePK Network Element.
- Cisco or the OS vendor must sign all packages that are installed in the application container. This is supported through the RPM utility.
- All Network Elements running onePK must be licensed for onePK applications. Licensing is checked at application initialization. When the application creates the first connection, a license check is performed.
- The user of the application must be authenticated and authorized by the AAA infrastructure.
- Process hosting lets application developers install and run applications within a Network Element. This provides low latency communication and a single footprint for applications. All onePK applications are run in a process container. This ensures fair allocation of resources between applications and ensures that the hosted platform OS is allocated sufficient resources to perform its tasks.
Blade hosting lets applications run close to the control planes and data planes and have dedicated resources to perform tasks.
End-node hosting lets applications take advantage of industry platforms, ranging from large computational intensive devices such as multi-CPU/multicore servers running Linux or Windows, to compact mobile devices running Android or iOS.
In any of the above models:
For authentication, onePK uses the user (username and password) of the application-based authentication with AAA infrastructure.
For authorization, onePK uses application name and/or instanceID-based authorization with AAA infrastructure.
Services sets are used to organize the hundreds of onePK APIs into functional groups. The initial release includes support for the following base service sets.
The element service set consists of APIs to get and set network device and interface properties, state, and statistics.
The utilities service set provides access to syslog and AAA functions within the element.
The discovery service set provides a mechanism for an application to discover remote or local network elements, network topology, and the network elements providing onePK services.
The developer service set provides developers with a set of additional services to enable them to build applications that can be managed, deployed, and if necessary debugged.
The data path service set provides locations on the forwarding path to insert custom features. These locations allow developers to insert their own packet/flow processing logic into the forwarding path.
The policy service set allows applications to configure several features of the forwarding path, including filtering, ACLs, and QoS.
The routing service set provides read access to the routing information base (RIB) and enables a developer to safely modify the routing/switching logic of the network element.