OpenFlow packet format defines the wire structure of packets exchanged between an OpenFlow switch and the controller. This standardized framing enables consistent programmability across multi vendor network devices.
Understanding the exact fields, bit ordering, and version specific differences is essential for developers building SDN controllers and for network operators tuning high performance forwarding planes.
| Version | Header Length | Key Fields | Use Case |
|---|---|---|---|
| OpenFlow 1.0 | 16 bytes | Type, Length, XID | Basic learning switch and matching |
| OpenFlow 1.2 | 16 bytes | Type, Length, XID, Experimenter ID | Multiple tables, metadata, counters |
| OpenFlow 1.3 | 16 bytes | Type, Length, XID, Version bitmap | Group tables, async packets, meter tables |
| OpenFlow 1.5 | 16 bytes | Type, Length, XID, Version bitmap | CT actions, resubmit with metadata |
| OpenFlow 1.6 | 16 bytes | Type, Length, XID, Version bitmap | Extended instructions, packet queue stats |
PacketIn and Controller Aspect
The PacketIn message carries observed frames from the data plane to the controller. Each PacketIn uses the openflow packet format with a header, fixed body, and optional TLV styled metadata depending on the OpenFlow version.
Controllers can set packet processing behavior through the Async Configuration message, which determines which packet types trigger PacketIn and at which severity level. This keeps controller logic clean and avoids unnecessary copies of unchanged frames.
Header and Message Structure
Every message in the protocol starts with a common header. This header uses a specific openflow packet format style where type fields map directly to message roles like handshake, configuration, or asynchronous events.
Length is a 16 bit unsigned integer indicating total message size in 8 octet units. XID, a 32 bit field, links request and reply pairs so the controller can track pending operations and handle timeouts reliably.
Experimenter Messages and Extensions
Experimenter messages allow vendors to inject custom logic without altering the core specification. These messages embed an experimenter ID followed by a vendor defined openflow packet format body that the controller must parse carefully.
Version bitmaps in hello and features reply messages enumerate supported capabilities. This mechanism reduces handshake chatter by allowing endpoints to agree on extensions such as NXT actions, multipath, and other experimenter defined optimizations.
Encoding, Wire Format, and Parsing Rules
All multi octet integer values use big endian network byte order. Fields occupy aligned boundaries, which simplifies hardware offload implementations and ensures deterministic parsing performance across platforms.
Modern pipelines may carry metadata in the form of a skip field or metadata registry that moves with the packet through tables. When translating between openflow wire format and hardware action lists, compilers must preserve exact semantics of resubmit, terminate, and metadata write operations.
Design Implications and Forward Compatibility
Designers should treat the openflow packet format as a stable backbone while allowing optional extensions through experimenter type and version bitmap negotiation. This balances interoperability with innovation.
Careful version detection and strict length validation protect deployments from malformed frames and support graceful degradation when newer features meet older line cards.
- Always validate the header length and total message length before parsing the body.
- Use the XID field to match requests with replies and handle timeouts cleanly.
- Check version bitmaps during handshake to negotiate supported extensions.
- Handle experimenter messages with a dispatch table keyed on the experimenter ID.
- Enforce big endian decoding on all platforms to avoid byte order bugs.
- Plan asynchronous PacketIn handling to avoid stalling the control pipeline.
- Reserve well defined error message formats for malformed or unexpected frames.
- Document custom experimenter formats and share them with controller applications.
FAQ
Reader questions
How does the length field help with framing in a streaming connection?
The length field tells the receiver where the current message ends, allowing the controller to split concatenated buffers correctly and to detect malformed or truncated frames before processing.
What happens if the controller ignores an unknown packet type?
The switch treats unrecognized message types as errors and may log the event, reply with an error message, or drop the connection depending on the switch implementation and configured fail safe behavior.
Can experimenter IDs collide across different vendors?
Each experimenter ID is a globally unique 32 bit value assigned by a standards body, preventing collisions and ensuring that controllers can distinguish vendor specific payloads within the openflow packet format.
Why is byte order always big endian in the specification?
Using big endian network byte order across the protocol removes ambiguity on mixed endian platforms, simplifies parser code, and ensures interoperability between controllers and switches from different manufacturers.