SDN Controller Programming Guide

4
Jersey [2] is a JAX-RS (JSR 311) reference Implementation for building RESTful Web services. In
Representational State Transfer (REST) architectural style, data and functionality are considered
resources, and these resources are accessed using Uniform Resource Identifiers (URIs), typically
links on the web. REST-style architectures conventionally consist of clients and servers and it is
designed to use a stateless communication protocol, typically HTTP. Clients initiate requests to
servers; servers process requests and return appropriate responses. Requests and responses are
built around the transfer of representations of resources. Clients and servers exchange
representations of resources using a standardized interface and protocol. These principles
encourage RESTful applications to be simple, lightweight, and have high performance.
The HP VAN SDN Controller also offers a framework to develop Web User Interfaces - HP SKI. The
SKI Framework provides a foundation on which developers can create a browser-based web
application.
The HP VAN SDN Controller makes use of external services providing APIs that allow SDN
applications to make use of them.
Keystone [9] external service provides authentication and high level authorization services. It
supports token-based authentication scheme which is used to secure the RESTful web services (Or
REST APIs) and the web user interfaces.
ZooKeeper [10] is a coordination service for distributed applications. It is a centralized service for
maintaining configuration information, naming, providing distributed synchronization, and
providing group services.
Apache Cassandra [11] is a high performance, extremely scalable, fault tolerant (no single point
of failure), distributed post-relational database solution. Cassandra combines all the benefits of
Google Bigtable and Amazon Dynamo to handle the types of database management needs that
traditional RDBMS vendors cannot support.
Figure 5 illustrates with more detail the tiers that compose the HP VAN SDN Controller. It shows
the principal interfaces and their roles in connecting components within each tier, the tiers to each
other and the entire system to the external world. The approach aims to achieve connectivity in a
controlled manner and without creating undue dependencies on specifics of component
implementations. The separate tiers are expected to interact over well-defined mutual interfaces,
with decreasing coarseness from top to bottom. This means that on the way down, high-level
policy communicated as part of the deployment interaction over the external APIs is digested and
broken down by the upper tier into something akin to a specific plan, which gets in turn
communicated over the inter-tier API to the lower controller tier. The controller then turns this plan
into detailed instructions which are either pre-emptively disseminated to the network infrastructure
or are used to prime the RADIUS or OpenFlow [12] [13] controllers so that they are able to answer
future switch (other network infrastructure device) queries. Similarly, on the way up, the various
data sensed by the controller from the network infrastructure, regarding its state, health and
performance, gets aggregated at administrator tier. Only the administrator tier interfaces with the
user or other external applications. Conversely, only the controller tier interfaces with the network
infrastructure devices and other supporting controller entities, such as RADIUS, OpenFlow [12]
[13], MSM controller software, and so on.