HP VAN SDN Controller Administrator Guide

7
The HP VAN SDN Controller is an extensible platform supporting native applications (sometimes
referred to as modules) and external applications. Native applications are authored in Java or a
byte-code compatible language and are deployed on the controller as collections of OSGi bundles.
Native applications use the Java services exported and advertised by the controller platform and
by other applications. Native applications can dynamically extend the controller REST API surface,
extend the controller’s GUI, and integrate with the controller authentication and authorization
framework. Native application are well suited when the application needs frequent and low
latency interactions with network devices.
External applications can be developed in any language and are deployed on a platform outside
the controller platform or on the same platform as the controller. External applications interact
with the controller using the REST API services exported and advertised by the controller platform,
and by native applications deployed on the controller. Because external applications are deployed
outside the controller platform they cannot extend the REST API or GUI surface of the controller.
External applications are suitable for applications that have relatively infrequent and high latency
control interactions with network devices, and when deploying on a different platform is required.
Supported Switches and OpenFlow
Compatibility
At the time of this publication, the HP VAN controller supports the following:
 Versions 1.0 and 1.3 of OpenFlow on HPN ProVision and Comware switches
 HPN switches that have different OpenFlow pipeline capabilities in the same version
The controller negotiates with each OpenFlow switch for the highest common OpenFlow version
between the switch and controller. The Controller supports multiple OpenFlow versions at the
same time.
Notes
Once a specific OpenFlow version is identified for a given switch, the controller continues
to operate with that version as long as the switch is connected to the controller. Rebooting
the switch for a software update or other reason breaks the connection and results in a
new negotiation between the switch and the controller for the highest common OpenFlow
version.
Including a switch that does not support OpenFlow in a controller domain creates two
separate clusters.
Caution
OpenFlow switches in a controller domain should not be connected in a loop topology
with switches outside the domain. Allowing such connections can create broadcast loops
inside the OpenFlow network.