HP HP2-Z31 - Questions & Answers

Q: What is HP's SDN strategy?
A: Virtual Application Networks represent HP's software-defined network vision. By leveraging SDN-enabled infrastructure, control plane, applications and integrated management systems HP is creating an open ecosystem to drive new innovation in networking.

Q: What is the HP Virtual Application Networks SDN Controller?
A: The HP Virtual Application Networks SDN controller is an integral part of HP's Virtual Application Networks offering. The controller acts as the central building block for an abstracted control plane in the
SDN architecture.

References:
Virtual Application Networks Overview (http://h20195.www2.hp.com/V2/GetPDF.aspx/4AA4-4714ENW.pdf?jumpid=em_r1165_ww/en/large/eg/RelatedLink/Virtual_Application_Networks_Overview_FAQs/resourcefinder/Jan_2013)

Explanation: A team requires one IP address for each controller, plus one IP address assigned to the team. If the current team manager goes down, the failover process includes keeping the team IP address active on the new team manager.
References:
HP VAN SDN Controller Administrator Guide (http://h20566.www2.hp.com/portal/site/hpsc/template.BINARYPORTLET/public/kb/docDisplay/resource.process/?spf_p.tpst=kbDocDisplay_ws_BI&spf_p.rid_kbDocDisplay=docDisplayResURL&javax.portlet.begCacheTok=com.vignette.cachetoken&spf_p.rst_kbDocDisplay=wsrp-resourceState%3DdocId%253Demr_na-)
(page 54) c04003114-2%257CdocLocale%253D&javax.portlet.endCacheTok=com.vignette.cachetoken

Software-defined networking (SDN) is an architecture purporting to be dynamic, manageable, cost-effective, and adaptable, seeking to be suitable for the high-bandwidth, dynamic nature of today's applications.

The SDN architecture is:

Directly programmable: Network control is directly programmable because it is decoupled from forwarding functions.
Agile: Abstracting control from forwarding lets administrators dynamically adjust network-wide traffic flow to meet changing needs.

References:
Wikipedia, Software-defined networking

Openflow 1.3.1: Support for multiple flow tables is introduced Reference: Open Flow 1.3.1 Support:

Controller View
https://wiki.opendaylight.org/images/d/dc/Openflow1.3_Support_for_Opendaylight.pdf

The Openflow controller component relies on PKI to establish mutual trust (2-way SSL) between itself and the Openflow switches that it manages.

Please note that both the Controller and Device certificates must be signed by the same CA, so that the TLS connection will be established.

References:
HP VAN SDN Controller Administrator Guide

{base uri}/{api}
This is an unauthenticated API
Use https not http.
Example:
https://15.255.121.2:8443/api

Response codes
- Normal: OK (200)
- Error: Not Found (404), Service Unavailable (503) Reference: HP VAN SDN Controller 2.2 REST AP

The first capability that's implemented is the ability of the Lync server (or any communications server, potentially) to dynamically provide to the network controller the IP addresses/ports of the paired endpoints of a real time flow. This enables the network to mark, without deep packet inspection, those flows with a CoS/QoS tag that will give them the proper treatment in the network. This becomes a positive identification of "authorized" real-time flows; any device/flow trying to use that tagging that is not "authorized" through
the API can automatically be re-tagged to a best effort service class.

This technique has a number of critical advantages over current techniques. When compared to the typical VLAN, it enables positive tagging of a variety of devices, including BYOD and potentially other systems that might have multiple traffic types (e.g., a PC running a soft client or a tablet).

In addition, when compared to deep packet inspection at each access element, it reduces cost as well as eliminating the errors and complexity that encryption of the packet stream can introduce.

References:
HP and Microsoft Demo OpenFlow-Lync Applications-optimized Network