+++ /dev/null
-% Created 2009-02-02 Mon 17:09
-\documentclass[11pt,a4paper]{article}
-\usepackage[utf8]{inputenc}
-\usepackage[T1]{fontenc}
-\usepackage{graphicx}
-\usepackage{longtable}
-\usepackage{hyperref}
-
-
-\title{OpenFlow Management Protocol}
-\author{Version 0.0.1 (Wire Protocol 0x80)}
-\date{04 February 2009}
-
-\begin{document}
-
-\maketitle
-
-\setcounter{tocdepth}{3}
-\tableofcontents
-\vspace*{1cm}
-
-\section{Goals}
-\label{sec-1}
-
-
-The high-level design goals for the protocol are described in this
-section.
-
-\begin{itemize}
-\item Rapid implementation
-
- Most importantly, Nicira must implement the protocol quickly to
- meet current business objectives. However, the ability to implement
- the protocol rapidly should be a benefit to anyone implementing the
- protocol.
-\item Support ``all'' switch features
-
- The controller should be able to learn about all available switch
- features and retrieve and modify their values through the protocol.
-\item ``Multi-master''
-
- It must be possible to make changes at both the controller and the
- switch. When changes are made and connectivity exists between the
- switch and the controller, both sides should be resynchronized
- within a short period of time (< 1 sec??).
-\item Extensible
-
- To support future enhancements, the protocol must be capable of
- accommodating additional configuration settings and
- upgrading/downgrading configuration appropriately.
-\item Scalable
-
- The protocol should be able to handle any size switch, from a few
- ports to hundreds of ports.
-\item Minimal cost of implementation on the switch
-
- One of the selling points of OpenFlow is the ability to take cost
- out of switches by implementing complex network-wide functionality
- in the controller. It is thus preferable to minimize the cost of
- implementation on the switch.
-\end{itemize}
-\section{Specification}
-\label{sec-2}
-
-
- The OpenFlow Management Protocol is based on the OpenFlow
- protocol, with which it is often expected to be used. It augments
- the flow table management provided by the OpenFlow protocol with
- more general switch management functions required in a full-featured
- switch.
-
-\subsection{Connection Maintenance}
-\label{sec-2.1}
-
-
- As with OpenFlow, the switch is responsible for initiating the
- connection to the controller at a user configurable IP address and
- TCP port. The default destination port for the connection is 6632,
- one less than the default OpenFlow destination port 6633. The IP
- address of the controller may be discovered through the same
- discovery protocol defined for OpenFlow.
-
- The switch must attempt to maintain an open connection to the
- controller at all times while in an operational state, although the
- exact details for detecting connection failure and opening a new
- connection are left to individual implementations.
-
- After connection establishment, both sides must send \hyperref[sec-2.6.1]{hello messages}
- to each other before any other messages are sent.
-
- While the default ports for OpenFlow and the OpenFlow Management
- Protocol are different, the latter is deliberately designed to be
- able to coexist on the same port, in which case the appropriate
- connection type can be determined by examining the initial hello
- message sent after connection establishment.
-
-\subsection{Encryption}
-\label{sec-2.2}
-
-
- The OpenFlow Management Protocol uses the same encryption
- mechanism defined in the analogous section of the OpenFlow
- specification. It is expected, but not required, that the
- Management Protocol will use the same keys as the OpenFlow
- protocol for authentication of either end of the connection.
-
-\subsection{Framing}
-\label{sec-2.3}
-
-
- The Management Protocol uses the same basic header as
- the OpenFlow protocol, defined as \verb|ofp_header| in the OpenFlow
- specification. The fields of this header are used in the same way
- as they are in the OpenFlow protocol except that the type IDs
- generally have different meanings. However, a few message types
- are shared among the two protocols, in which case they have the
- same message type code in both protocols.
-
- Each message type is further described in subsequent sections of
- this document. The message types IDs are defined by:
-
-{ \footnotesize
-
-\begin{verbatim}
- enum ofmp_type {
- OFMP_HELLO, /* Message Types Shared with OpenFlow. */
- OFMP_ERROR, /* Message Types Shared with OpenFlow. */
- OFMP_ECHO_REQUEST, /* Message Types Shared with OpenFlow. */
- OFMP_ECHO_REPLY, /* Message Types Shared with OpenFlow. */
- OFMP_VENDOR, /* Message Types Shared with OpenFlow. */
- OFMP_RESERVED_0, /* Reserved Message Types. */
- OFMP_RESERVED_1, /* Reserved Message Types. */
- OFMP_EXTENDED_DATA, /* Extended Data Message */
- OFMP_CAPABILITY_REQUEST,/* Management Protocol-specific. */
- OFMP_CAPABILITY_REPLY, /* Management Protocol-specific. */
- OFMP_SWITCH_RESOURCES, /* Management Protocol-specific. */
- OFMP_CONFIG_UPDATE, /* Management Protocol-specific. */
- OFMP_CONFIG_UPDATE_ACK, /* Management Protocol-specific. */
- OFMP_HOST_INFO /* Management Protocol-specific. */
- };
-
-\end{verbatim}
-
-
-}
-
-\subsection{Type/Length/Value Encoding in Messages}
-\label{sec-2.4}
-
-
- Some messages use a type/length/value (TLV) encoding scheme for
- data transferred in the message body. This is done for primarily
- for flexibility and extensibility.
-
- When present, TLVs occur in sequence until a TLV is encountered
- with type \verb|OFMPTLV_END|. This TLV must have a length of zero. A
- single TLV of type \verb|OFMPTLV_END| would represent an empty list of
- TLVs.
-
- The TLV message format is defined by:
-
-{ \footnotesize
-
-\begin{verbatim}
- enum ofmp_tlv_type {
- OFMPTLV_END = 0,
- },
-
- struct ofmp_tlv {
- uint16_t type; /* Type of value. */
- uint16_t len; /* Length of value (excluding type & len). */
- data[0]; /* Value data as defined by type & len. */
- };
-
-\end{verbatim}
-
-
-}
-
- The meaning of the \verb|type| field is unique to each message type
- that uses the TLV encoding except that type code 0 must always
- indicate the end of the TLV encoded data. Implementations must
- skip unknown type values and continue processing to enhance
- forward compatibility.
-
-\subsection{Reserved Message Types}
-\label{sec-2.5}
-
-
- Because of the use the same basic message framing, distinguishing
- the OpenFlow Management Protocol from OpenFlow could be
- difficult. The definition and required use of the Management
- Protocol \hyperref[sec-2.6.1]{hello message} is intended to be compatible with
- OpenFlow while facilitating this differentiation.
-
- To further assist in differentiation, the message type IDs for the
- feature request and feature reply messages defined in the OpenFlow
- specification are reserved in the Management Protocol.
- If either the switch or the controller receives one of these
- message type IDs on a connection expected to be a Management
- Protocol connection, it must reply with an \hyperref[sec-2.6.5]{error message}
- specifying reserved message type code and then terminate the
- connection.
-
-\subsection{Messages Types Shared with OpenFlow}
-\label{sec-2.6}
-
-
- There are a few message types used by the Management
- Protocol that are used for essentially the same purposes in it and
- the OpenFlow protocol and have identical or compatible message
- formats. These message types use the same message type ID in both
- protocols.
-
-\subsubsection{Hello}
-\label{sec-2.6.1}
-
-
- This message is the same as the OpenFlow message except that
- after the OpenFlow header the data of the message includes the
- UTF-8 encoded string ``OPENFLOW MANAGEMENT PROTOCOL''. This
- simplifies debugging and allows automatic detection of the
- protocol.
-
-\subsubsection{Echo Request}
-\label{sec-2.6.2}
-
-
- This message works exactly as the corresponding message in
- OpenFlow.
-
-\subsubsection{Echo Reply}
-\label{sec-2.6.3}
-
-
- This message works exactly as the corresponding message in
- OpenFlow.
-
-\subsubsection{Vendor}
-\label{sec-2.6.4}
-
-
- This message works exactly as the corresponding message in
- OpenFlow.
-
-\subsubsection{Error}
-\label{sec-2.6.5}
-
-
- This message works the same as the corresponding message in
- OpenFlow with the exception that all the meaning of the type and
- code fields are unique to each protocol.
-
- For the Management Protocol, the type values are defined by:
-
-{ \footnotesize
-
-\begin{verbatim}
- enum ofmp_error_type {
- OFMPET_HELLO_FAILED, /* Hello failed. */
- OFMPET_BAD_REQUEST, /* Request was not understood. */
- OFMPET_UNKNOWN_FORMAT, /* Format of typed data not understood. */
- OFMPET_CONFIG_ERROR /* Error processing configuration update. */
- };
-
-\end{verbatim}
-
-
-}
-
- The \verb|OFMPET_HELLO_FAILED| type is exactly analogous to the
- \verb|OFPET_HELLO_FAILED| type in OpenFlow. A single code is currently
- defined:
-
-{ \footnotesize
-
-\begin{verbatim}
- enum ofmp_hello_failed_code {
- OFMPHFC_INCOMPATIBLE, /* Hello failed */
- };
-
-\end{verbatim}
-
-
-}
-
- The \verb|OFMPET_BAD_REQUEST| type is also similar to the
- \verb|OFPET_HELLO_FAILED| type in OpenFlow. The subtypes are:
-
-{ \footnotesize
-
-\begin{verbatim}
- enum ofmp_bad_request_code {
- OFMPBRC_BAD_VERSION, /* ofp_header.version not supported. */
- OFMPBRC_BAD_TYPE, /* ofp_header.type not supported. */
- OFMPBRC_RESERVED_0, /* For ID alignment w/compatible codes
- * in OpenFlow */
- OFMPBRC_BAD_VENDOR, /* Vendor not supported. */
- OFMPBRC_BAD_SUBTYPE /* Vendor subtype not supported. */
- };
-
-\end{verbatim}
-
-
-}
-
- The \verb|data| field contains at least 64 bytes of the failed request.
-
- The \verb|OFMPET_UNKNOWN_FORMAT| type is used when the format specified
- for a message such as \hyperref[sec-2.8.2]{capabilities request} or
- \hyperref[sec-2.8.4]{configuration update} is unknown. The \verb|code| field is not used in
- this error. The \verb|data| field contains a sequence of 32-bit
- unsigned integers representing acceptable format types in order
- from most preferred to least.
-
-\subsection{Extended Data Message}
-\label{sec-2.7}
-
-
- Because the OpenFlow message header only has a 16-bit length field,
- the largest possible message size is 64kB. This may be
- insufficient for some message types such as the configuration
- update message. The extended data message removes this restriction
- by encapsulating the message body of the original message (without
- the base OpenFlow header) in more than one extended data messages.
-
- The extended data message format is:
-
-{ \footnotesize
-
-\begin{verbatim}
- enum ofmped_flags {
- MORE_DATA = 1
- };
-
- struct ofmp_extended_data {
- uint8_t type, /* Type code of the encapsulated message */
- uint8_t flags,
- uint8_t pad[6], /* Maintain same alignment as regular body */
- uint8_t data[0]; /* Message body fragment */
- };
-
-\end{verbatim}
-
-
-}
-
- The MORE\_{}DATA flag must be set in every extended data message
- sequence encapsulating a message body too long to fit in a single
- standard message except the last message, in which the it must be
- cleared. All but the final messages should typically be maximum
- length, although this is not required.
-
- To simplify implementations, messages MUST NOT be sent encapsulated
- in extended data messages if they will fit in a single regular
- message.
-
-\subsection{OpenFlow Management Protocol-specific Messages}
-\label{sec-2.8}
-
-
- The remaining message types are specific to the Management Protocol.
-
-\subsubsection{Switch Resources}
-\label{sec-2.8.1}
-
-\begin{itemize}
-\item TODO Describe reply in detail
-\end{itemize}
- The switch resources message describes the resources available on
- the switch. It must be sent by the switch to the controller
- immediately after the initial hello exchange at connection
- establishment and any time thereafter when resources change on the
- switch.
-
-\subsubsection{Capabilities Request}
-\label{sec-2.8.2}
-
-
- The capabilities request message is sent from the controller to
- the switch, which replies with a \hyperref[sec-2.8.3]{capabilities reply} message.
- While not required, the controller will typically send a
- capabilities request message after receiving the hello message on
- connection establishment to determine switch capabilities. In
- this way, it is very similar to the feature request and reply
- messages in the OpenFlow specification. However, because the
- encoding of the capabilities is different, the messages have
- different names.
-
- The capabilities request message format is:
-
-{ \footnotesize
-
-\begin{verbatim}
- struct ofmp_capabilities_request {
- uint32_t format; /* Format in which to send capabilities */
- };
-
-\end{verbatim}
-
-
-}
-
- The only field in this message, \verb|format|, specifies the format
- the controller expects for the reply. The only capabilities
- format current specified is the \hyperref[*==Simple==Capabilities==Format]{Simple Capabilities Format}.
-
- On receipt of a capabilities request message, the switch must
- send a capabilities reply in the specified format to the
- controller or an \hyperref[*==Unknown==capabilities==format]{unknown capabilities format error message} in
- reply.
-
-\subsubsection{Capabilities Reply}
-\label{sec-2.8.3}
-
-
- The capabilities reply message is sent from the switch to the
- controller in response to a \hyperref[sec-2.8.2]{capabilities request} message from the
- controller. The capabilities reply message format is:
-
-{ \footnotesize
-
-\begin{verbatim}
- struct ofmp_capabilities_reply {
- uint32_t format; /* Format of capabilities info */
- uint8_t data[0]; /* Capabilities data */
- };
-
-\end{verbatim}
-
-
-}
-
- The \verb|format| specifies the format of the capabilities data. It
- must be the same as the \verb|format| field in the
- \hyperref[sec-2.8.2]{capabilities request}.
-
-\paragraph{Simple Capability Format}
-\label{sec-2.8.3.1}
-
-\begin{itemize}
-\item Basically, same as vswitchd configuration syntax
-\item Each key/value pair is contained on a single line. The line
- separator is a single newline character.
-\item Keys have hierarchy based on controlling entities domain
- name. Initially all keys will be `com.nicira'\ldots{}
-\item Values can just be true/false to indicate the presence/absence
- of a feature (or just not present for the absences).
-\item Values can also be strings and/or numbers indicating limits on
- specific capabilities, etc.
-\item It should be possible to use a capabilities reply to determine
- whether additional OpenFlow Management Protocol message
- types are supported or not to minimize the need to change the
- protocol version in the framing header.
-\end{itemize}
-\subsubsection{Configuration Update}
-\label{sec-2.8.4}
-
-
- The configuration update message can be sent asynchronously in
- either direction. It's purpose is to inform the peer that a
- configuration value has changed. On receipt of a configuration
- update message, the message must be processed and a corresponding
- configuration update reply message describing the results of that
- processing sent back to the peer.
-
- The format of the configuration update message is:
-
-{ \footnotesize
-
-\begin{verbatim}
- struct ofmp_config_update {
- uint32_t format; /* Format of capabilities info */
- uint8_t cookie[20]; /* Collision detect cookie */
- uint8_t data[0]; /* Capabilities data */
- };
-
-\end{verbatim}
-
-
-}
-
- The \verb|format| field specifies the format in which the
- configuration data is presented. The only format currently
- supported is the \hyperref[sec-2.8.4.1]{Simple Configuration Format}.
-
- The \verb|cookie| field is used to detect simultaneous configuration
- changes on both peers. The use of the field is described in the
- \hyperref[sec-2.8.4.2]{detection of simultaneous changes section}.
-
- On receipt of a configuration update message the message must be
- processed and either a \hyperref[*==Configuration==Update==Reply]{configuration update reply} or an
- \hyperref[sec-2.6.5]{error message}.
-
-\paragraph{Simple Configuration Format}
-\label{sec-2.8.4.1}
-
-\begin{itemize}
-\item TODO complete this section more fully.
-\item Basically, the current vswitchd configuration file format
-\item Keys in ``fully specified form'' (no sections)
-\item Keys sorted as by implementation now
-\end{itemize}
-\paragraph{Detection of simultaneous changes}
-\label{sec-2.8.4.2}
-
-\begin{itemize}
-\item TODO Describe simultaneous change detection more completely.
-\item Collision detect cookie values are a SHA-1 hash of last
- configuration accepted from peer, over sorted keys \& values in
- memory.
-\item To prevent inadvertent overwriting of data, the switch is
- treated as the master for all updates. It should refuse
- updates with an incorrect cookie. Controller is responsible
- for dealing with recovering from simultaneous changes by
- merging configurations or whatever other means necessary.
-\end{itemize}
-\subsubsection{Configuration Update Acknowledgment}
-\label{sec-2.8.5}
-
-
- The configuration update acknowledgment is sent in response to a
- \hyperref[sec-2.8.4]{configuration update} message. It indicates the update has been
- successfully accepted and processed. The message body consists
- of an updated collision detect cookie:
-
-{ \footnotesize
-
-\begin{verbatim}
- struct ofmp_config_update_ack {
- uint8_t cookie[20]; /* Collision detect cookie */
- };
-
-\end{verbatim}
-
-
-}
-
-\subsubsection{Host Info}
-\label{sec-2.8.6}
-
-
- In some cases, the switch may definitively know additional
- information about one or more hosts present on a given datapath
- and port. In these cases the switch may send the host info
- message to the controller to provide this information.
-
- The format of the host info message is:
-
-{ \footnotesize
-
-\begin{verbatim}
- struct ofmp_host_info {
- uint64_t datapath_id; /* Referenced datapath. */
- uint16_t port_id; /* Referenced port. */
- data[0]; /* TLV encoded data about host. */
- };
-
-\end{verbatim}
-
-
-}
-
- The data in the message is encoded as described in the
- \hyperref[sec-2.4]{Type/Length/Value Encoding in Messages} section.
-
-{ \footnotesize
-
-\begin{verbatim}
- enum ofmp_host_info_tlv_type {
- OFMPHITLV_END = 0, /* End of TLV records. */
- OFMPHITLV_HOST_DLADDR , /* Host MAC address. */
- OFMPHITLV_HOST_UUID /* Host unique identifier. */
- };
-
-\end{verbatim}
-
-
-}
-
- The value for \verb|OFMPHITLV_HOST_DLADDR| is a six-byte MAC address.
- The value for \verb|OFMPHITLV_HOST_UUID| is a variable length
- universally unique identifier for the host.
-
-\section{Design Rationale}
-\label{sec-3}
-
-
-\subsection{Why specify an additional protocol}
-\label{sec-3.1}
-
-
- The core purpose of OpenFlow is to manage the flow table in the
- switch. There are many other activities required to fully manage a
- switch, configuring ports, updating stats, etc. Some of these
- require significant data transfer that could interfere with the
- primary purpose of OpenFlow.
-
- Switches from existing vendors typically already have their own
- methods for accomplishing these tasks. A vendor considering
- adopting OpenFlow may not wish to re-implement this support. If
- the core OpenFlow specification required such a reimplementation,
- it could likely reduce the adoption of OpenFlow or considerably
- slow the process of standardization of new protocol messages to
- accomplish these tasks, extending the time before implementations
- appeared on the market.
-
-\subsection{Use of a non-standard protocol}
-\label{sec-3.2}
-
-
- The requirements for the protocol, including bidirectional
- asynchronous messaging are not well supported by any widely
- implemented protocol used for similar purposes. It is expected
- most implementers of the remote switch protocol will also be
- implementers of the OpenFlow protocol and thus specifying a similar
- protocol will increase code reuse.
-
-\subsection{Reuse of some OpenFlow messages}
-\label{sec-3.3}
-
-
- The messaging requirements of OpenFlow and the OpenFlow Management
- Protocol are similar in a few areas. Reusing the same messages in
- those areas should further contribute to code reuse.
-
-\subsection{Connection direction from switch to controller}
-\label{sec-3.4}
-
-
-\subsection{Use of vswitchd configuration file format for config documents}
-\label{sec-3.5}
-
-
- Simply put, it is available to Nicira already and matches the
- initial requirements for switch configuration management.
-
-
-\end{document}
-
projects / openvswitch / commitdiff