Reference Guide
Table Of Contents
- 1 Introduction
- 2 Establishing Your Test and Development Environments
- 3 Developing Applications
- Introduction
- Authentication
- REST API
- Audit Logging
- Alert Logging
- Configuration
- High Availability
- OpenFlow
- Metrics Framework
- GUI
- SKI Framework - Overview
- SKI Framework - Navigation Tree
- SKI Framework - Hash Navigation
- SKI Framework - View Life-Cycle
- SKI Framework - Live Reference Application
- UI Extension
- Introduction
- Controller Teaming
- Distributed Coordination Service
- Persistence
- Backup and Restore
- Device Driver Framework
- 4 Application Security
- 5 Including Debian Packages with Applications
- 6 Sample Application
- Application Description
- Creating Application Development Workspace
- Application Generator (Automatic Workspace Creation)
- Creating Eclipse Projects
- Updating Project Dependencies
- Building the Application
- Installing the Application
- Application Code
- 7 Testing Applications
- 8 Built-In Applications
- Appendix A
- Appendix B
- Bibliography
The Message Library is a Java implementation of the OpenFlow specification, providing facilities for
encoding and decoding OpenFlow messages from and to Java rich data types.
The controller handles the connections from OpenFlow switches and provides the means for upper
layers of software to interact with those switches via the ControllerService API.
The following figure illustrates this:
Figure 14 OpenFlow Controller
Message Library
The Message Library is a Java implementation of the OpenFlow specification, providing facilities for
encoding and decoding OpenFlow messages from and to Java rich data types.
Design Goals
The following are the overall design goals of the library:
•
To span all OpenFlow protocol versions
However, actively supporting just 1.0.0 and 1.3.2
•
To be extensible
Easily accommodating future versions
•
To provide an elegant, yet simple, API for handling with OpenFlow messages
•
To reduce the burden on application developers
Insulating developers from differences across protocol versions, as much as possible
•
To expose the semantics but hide the syntax details
Developers will not be required to encode and decode bitmasks, calculate message
lengths, insert padding, etc.
•
To be robust and type-safe
Working with Java enumerations and types
27