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
Design Choices
Some specific design choices were made to establish the underlying principles of the
implementation, to help meet the goals specified above.
•
All OpenFlow messages are fully creatable/encodable/decodable, making the library
completely symmetrical in this respect.
The controller (or app) never creates certain messages (such as PortStatus, FlowRemoved,
MultipartReply, etc.) as these are only ever generated by the switch. Technically, we
would only need to decode those messages, never encode them.
However, providing a complete solution allows us to emulate OpenFlow switches in Java
code. This facilitates the writing of automated tests to verify switch/controller interactions
in a deterministic manner.
•
Message instances, for the most part, are immutable.
This means a single instance can be shared safely across multiple applications (and
multiple threads) without synchronization.
This implies that the structures that make up the message (ports, instructions, actions, etc.)
must also be immutable.
Where possible, “Data Types” will be used to encourage API type-safety – see the
Javadocs for com.hp.util.ip and com.hp.of.lib.dt.
•
Where bitmasks are defined in the protocol, Java enumerations are defined with a constant
for each bit.
A specific bitmask value is represented by a Set of the appropriate enumeration
constants.
For example: Set<PortConfig>
•
A message instance is mutable only while the message is under construction (for example, an
application composing a FlowMod message). To be sent through the system it must be
converted to its immutable form first.
•
To create and send a message, an application will:
Use the Message Factory to create a mutable message of the required type
Set the state (payload) of the message
Make the message immutable
Send the message via the ControllerService API.
•
The Core Controller will use the Message Factory to encode the message into its byte-stream
form, for transmitting to the switch.
•
The Core Controller will use the Message Factory to decode incoming messages from their
byte-stream form into their (immutable) rich data type form.
28