- Community Home
- >
- Networking
- >
- Software Defined Networking
- >
- Re: HP OpenFlow APIs vs. Beacon/Floodlight/OpenFlo...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-15-2013 11:47 AM
10-15-2013 11:47 AM
HP OpenFlow APIs vs Beacon/Floodlight/OpenFlowJ APIs?
Hi Folks,
I'm wondering if anybody can answer a question regarding the OpenFlow APIs that are available for Java developers with the HP SDN Controller. I notice that they are similar to what is available with the other Java APIs, which evolved originally from OpenFlowJ, and which are present now in Beacon, Floodlight, OpenDaylight, etc. However they are different enough to require re-work, for those of us who have used those other controllers.
I'm sure there are good reasons - perhaps resolving threading issues, perhaps related to the different application roles (Director, Observer, Advisor), perhaps related to teaming support. I just have not seen the official rationale anywhere so I want to make sure I understand it correctly, rather than surmising.
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2013 08:13 AM
10-16-2013 08:13 AM
Re: HP OpenFlow APIs vs. Beacon/Floodlight/OpenFlowJ APIs?
The HP SDN Controller Team deliberately chose to depart from OpenFlowJ in order to get OF 1.3 support in a manner that will allow applications to use nearly identical constructs whether they are speaking with an OF 1.0/1.1/1.2 or 1.3 switch. What follows is a set of design objectives for the OpenFlow Controller and Library:
- Span all protocol versions
- Extensible – easily accommodate future versions
- Reduce the burden on application developers
- Insulate application developers from differences across protocol versions as much as possible
- Expose semantics & hide syntax details
- Developers not required to encode / decode bitmasks and other structures
- Developers not required to calculate message lengths, insert paddings, etc.
- Robust & type-safe
- Work with Java enumerations and types
- Protect controller & applications from each other – multiple queues, immutable objects, etc.
- Facilitate performance, scalability and parallel processing
Thanks for your question!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-16-2013 11:05 AM
10-16-2013 11:05 AM
Re: HP OpenFlow APIs vs. Beacon/Floodlight/OpenFlowJ APIs?
Thanks for the great explanation! I understand the design goal, and also have a clarification question regarding one item:
- Protect controller & applications from each other – multiple queues, immutable objects, etc.
I wondered if it would be possible to give a couple concrete examples of these. Do these refer to different queues for different applications, or for different roles, or perhaps related to other types of queues?
Also, regarding immutable objects, I do notice all of the 'Mutable*' objects available in the openflow implementation classes. Are there specific concurrency situations that are possible with the non-mutable objects (either in the HP controller or in the others), that are protected by this, that you could describe? I don't see anything specific listed in the Programmer's Guide, so I'm curious.
Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
10-17-2013 11:58 PM
10-17-2013 11:58 PM
Re: HP OpenFlow APIs vs. Beacon/Floodlight/OpenFlowJ APIs?
Protect controller & applications from each other – multiple queues
--------------------------------------------------------------------------------
HP SDN Controller will decouple incoming connection events and message events from the consumption of those events by DataPathListeners and MessageListeners, using bounded event queues. Each listener will have a separate queue (An application can have multiple listeners). This will provide some level of protection for the controller and for other listeners, from an ill-performing listener implementation. It is up to each listener to consume the events fast enough to keep pace with the rate of arrival. In the event that the listener is unable to do so, an out-of-band "queue-full" event will be posted, and event queuing for that listener will be suspended.
Protect controller & applications from each other – immutable objects
----------------------------------------------------------------------------------
All OpenFlow messages and structures passed into and out of the HP SDN Controller must be immutable. An application using the controller should take care of synchronizing mutable objects if it is shared between multiple threads.