Reference Guide

Figure 18 Packet-In Processing
The Roles provide three broad bands of participation with the processing of PACKET_IN messages:
•
An ADVISOR may analyze and provide additional metadata about the packet (attached as
“hints” for listeners further downstream), but does not contribute directly to the formation of
the PACKET_OUT message.
•
A DIRECTOR may contribute to the formation of the associated PACKET_OUT message by
adding actions to it; DIRECTORs may also determine that the PACKET_OUT message is ready
to be sent back to the datapath, and can instruct the Sequencer to send it on its way.
•
An OBSERVER passively monitors the PACKET_IN/PACKET_OUT interactions.
•
Within each role, SPLs are processed in order of decreasing “altitude”. The altitude is specified
when the SPL registers with the controller. Between them, the role and altitude provide a
deterministic ordering of the “processing chain”.
•
When a PACKET_IN message event occurs, the PACKET_IN is wrapped in a MessageContext
which provides the context for the packet being processed. The packet is also decoded to the
extent where the network protocols present in the packet are identified; this information is attached
to the context.
•
The message context is passed from SPL to SPL (via the event() callback) in the predetermined
order, but only to those SPLs where at least one of the network protocols present in the packet is
also defined in the SPL’s “interest” set:
•
During an ADVISOR’s event() callback, hints might be attached to the context with a call to
addHint(Hint).
•
During a DIRECTOR’s event() callback, the PacketOut API may be utilized to:
 Add an action to the PACKET_OUT message under construction.
 Clear all the actions from the PACKET_OUT message under construction.
 Indicate to the sequencer that the packet should be blocked (i.e. not sent back to the
source datapath).
40