From d5f19352721f170adaf0ae08ecc70ccad142d018 Mon Sep 17 00:00:00 2001 From: Justin Pettit Date: Wed, 4 Feb 2009 14:26:11 -0800 Subject: [PATCH] Changed control protocol name to OpenFlow Management Protocol. --- .../ofcp-spec.tex => ofmp-spec/ofmp-spec.tex} | 150 +++++++++--------- 1 file changed, 74 insertions(+), 76 deletions(-) rename doc/{ofcp-spec/ofcp-spec.tex => ofmp-spec/ofmp-spec.tex} (80%) diff --git a/doc/ofcp-spec/ofcp-spec.tex b/doc/ofmp-spec/ofmp-spec.tex similarity index 80% rename from doc/ofcp-spec/ofcp-spec.tex rename to doc/ofmp-spec/ofmp-spec.tex index db7be031..90a73ab6 100644 --- a/doc/ofcp-spec/ofcp-spec.tex +++ b/doc/ofmp-spec/ofmp-spec.tex @@ -7,9 +7,9 @@ \usepackage{hyperref} -\title{Remote Switch Control Protocol} -\author{Keith Amidon} -\date{02 February 2009} +\title{OpenFlow Management Protocol} +\author{Version 0.0.1 (Wire Protocol 0x80)} +\date{04 February 2009} \begin{document} @@ -63,7 +63,7 @@ section. \label{sec-2} - The remote switch control protocol is based on the OpenFlow + 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 @@ -88,7 +88,7 @@ section. 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 Remote Switch Control + 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 @@ -98,17 +98,17 @@ section. \label{sec-2.2} - The remote switch control protocol uses the same encryption + 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 remote - switch control protocol will use the same keys as 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 remote switch control protocol uses the same basic header as + 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 @@ -122,21 +122,21 @@ section. { \footnotesize \begin{verbatim} - enum rscp_type { - RSCP_HELLO, /* Message Types Shared with OpenFlow. */ - RSCP_ERROR, /* Message Types Shared with OpenFlow. */ - RSCP_ECHO_REQUEST, /* Message Types Shared with OpenFlow. */ - RSCP_ECHO_REPLY, /* Message Types Shared with OpenFlow. */ - RSCP_VENDOR, /* Message Types Shared with OpenFlow. */ - RSCP_RESERVED_0, /* Reserved Message Types. */ - RSCP_RESERVED_1, /* Reserved Message Types. */ - RSCP_EXTENDED_DATA, /* Extended Data Message */ - RSCP_CAPABILITY_REQUEST,/* Remote Control Protocol-specific. */ - RSCP_CAPABILITY_REPLY, /* Remote Control Protocol-specific. */ - RSCP_SWITCH_RESOURCES, /* Remote Control Protocol-specific. */ - RSCP_CONFIG_UPDATE, /* Remote Control Protocol-specific. */ - RSCP_CONFIG_UPDATE_ACK, /* Remote Control Protocol-specific. */ - RSCP_HOST_INFO /* Remote Control Protocol-specific. */ + 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} @@ -153,8 +153,8 @@ section. for flexibility and extensibility. When present, TLVs occur in sequence until a TLV is encountered - with type \verb|RSCPTLV_END|. This TLV must have a length of zero. A - single TLV of type \verb|RSCPTLV_END| would represent an empty list of + 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: @@ -162,11 +162,11 @@ section. { \footnotesize \begin{verbatim} - enum rscp_tlv_type { - RSCPTLV_END = 0, + enum ofmp_tlv_type { + OFMPTLV_END = 0, }, - struct rscp_tlv { + 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. */ @@ -188,17 +188,17 @@ section. Because of the use the same basic message framing, distinguishing - the remote switch control protocol from OpenFlow could be - difficult. The definition and required use of the remote switch - control protocol \hyperref[sec-2.6.1]{hello messsage} is intended to be compatible with + 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 remote switch control protocol. + 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 remote switch - control protocol connection, it must reply with an \hyperref[sec-2.6.5]{error message} + 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. @@ -206,8 +206,8 @@ section. \label{sec-2.6} - There are a few message types used by the remote switch control - protocol that are used for essentially the same purposes in it and + 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. @@ -218,7 +218,7 @@ section. 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 ``REMOTE SWITCH CONTROL PROTOCOL''. This + UTF-8 encoded string ``OPENFLOW MANAGEMENT PROTOCOL''. This simplifies debugging and allows automatic detection of the protocol. @@ -251,17 +251,16 @@ section. OpenFlow with the exception that all the meaning of the type and code fields are unique to each protocol. - For the remote switch control protocol, the type values are - defined by: + For the Management Protocol, the type values are defined by: { \footnotesize \begin{verbatim} - enum rscp_error_type { - RSCPET_HELLO_FAILED, /* Hello failed. */ - RSCPET_BAD_REQUEST, /* Request was not understood. */ - RSCPET_UNKNOWN_FORMAT, /* Format of typed data not understood. */ - RSCPET_CONFIG_ERROR /* Error processing configuration update. */ + 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} @@ -269,15 +268,15 @@ section. } - The \verb|RSCPET_HELLO_FAILED| type is exactly analogous to the + 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 rscp_hello_failed_code { - RSCPHFC_INCOMPATIBLE, /* Hello failed */ + enum ofmp_hello_failed_code { + OFMPHFC_INCOMPATIBLE, /* Hello failed */ }; \end{verbatim} @@ -285,19 +284,19 @@ section. } - The \verb|RSCPET_BAD_REQUEST| type is also similar to the + 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 rscp_bad_request_code { - RSCPBRC_BAD_VERSION, /* ofp_header.version not supported. */ - RSCPBRC_BAD_TYPE, /* ofp_header.type not supported. */ - RSCPBRC_RESERVED_0, /* For ID alignment w/compatible codes + 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 */ - RSCPBRC_BAD_VENDOR, /* Vendor not supported. */ - RSCPBRC_BAD_SUBTYPE /* Vendor subtype not supported. */ + OFMPBRC_BAD_VENDOR, /* Vendor not supported. */ + OFMPBRC_BAD_SUBTYPE /* Vendor subtype not supported. */ }; \end{verbatim} @@ -307,7 +306,7 @@ section. The \verb|data| field contains at least 64 bytes of the failed request. - The \verb|RSCPET_UNKNOWN_FORMAT| type is used when the format specified + 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 @@ -330,11 +329,11 @@ section. { \footnotesize \begin{verbatim} - enum rscped_flags { + enum ofmped_flags { MORE_DATA = 1 }; - struct rscp_extended_data { + 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 */ @@ -356,12 +355,11 @@ section. in extended data messages if they will fit in a single regular message. -\subsection{Remote Control Protocol-specific Messages} +\subsection{OpenFlow Management Protocol-specific Messages} \label{sec-2.8} - The remaining message types are specific to the remote - switch control protocol. + The remaining message types are specific to the Management Protocol. \subsubsection{Switch Resources} \label{sec-2.8.1} @@ -394,7 +392,7 @@ section. { \footnotesize \begin{verbatim} - struct rscp_capabilities_request { + struct ofmp_capabilities_request { uint32_t format; /* Format in which to send capabilities */ }; @@ -403,7 +401,7 @@ section. } - The only field in this message, \verb|format|, specifies tedhe format + 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}. @@ -423,7 +421,7 @@ section. { \footnotesize \begin{verbatim} - struct rscp_capabilities_reply { + struct ofmp_capabilities_reply { uint32_t format; /* Format of capabilities info */ uint8_t data[0]; /* Capabilities data */ }; @@ -451,7 +449,7 @@ section. \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 remote switch control protocol message + 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} @@ -471,7 +469,7 @@ section. { \footnotesize \begin{verbatim} - struct rscp_config_update { + struct ofmp_config_update { uint32_t format; /* Format of capabilities info */ uint8_t cookie[20]; /* Collision detect cookie */ uint8_t data[0]; /* Capabilities data */ @@ -529,7 +527,7 @@ section. { \footnotesize \begin{verbatim} - struct rscp_config_update_ack { + struct ofmp_config_update_ack { uint8_t cookie[20]; /* Collision detect cookie */ }; @@ -552,7 +550,7 @@ section. { \footnotesize \begin{verbatim} - struct rscp_host_info { + struct ofmp_host_info { uint64_t datapath_id; /* Referenced datapath. */ uint16_t port_id; /* Referenced port. */ data[0]; /* TLV encoded data about host. */ @@ -569,10 +567,10 @@ section. { \footnotesize \begin{verbatim} - enum rscp_host_info_tlv_type { - RSCPHITLV_END = 0, /* End of TLV records. */ - RSCPHITLV_HOST_DLADDR , /* Host MAC address. */ - RSCPHITLV_HOST_UUID /* Host unique identifier. */ + 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} @@ -580,8 +578,8 @@ section. } - The value for \verb|RSCPHITLV_HOST_DLADDR| is a six-byte MAC address. - The value for \verb|RSCPHITLV_HOST_UUID| is a variable length + 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} @@ -622,8 +620,8 @@ section. \label{sec-3.3} - The messaging requirements of OpenFlow and the remote control - protocol are similar in a few areas. Reusing the same messages in + 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} -- 2.30.2