SDN控制器如何获取交换机已安装流表？flow_mod消息确认方法咨询

1. How does an SDN controller retrieve installed flow tables from a switch? #

The core mechanism for controllers to get installed flow tables relies on OpenFlow's Statistics Request messages. Here's the practical breakdown:

• The controller sends an OFPT_STATS_REQUEST message to the switch, specifying the stats type as OFPST_FLOW (flow statistics). You can filter this request to fetch all flows, flows from a specific table, or even flows matching particular criteria (like a specific match field).
• The switch responds with an OFPT_STATS_RESPONSE message, which includes granular details for each installed flow: match fields, actions, priority, idle/hard timeouts, packet/byte counts, and more.

For popular controllers, this translates to concrete implementations:

• POX: Use the flow_stats_request method from the openflow component. You can trigger a request for a specific switch, then handle the FlowStatsReceived event to process the returned flow data.
• OpenDaylight (ODL): Query flow tables via the RESTCONF API (endpoints like /restconf/config/opendaylight-inventory:nodes/node/{node-id}/table/{table-id}/flow) or use the MD-SAL (Model-Driven Service Abstraction Layer) to programmatically fetch flow stats through Yang models.

2. Can controllers like POX or ODL confirm flow installation success or retrieve installed flows, even though FlowMod messages aren't confirmable? #

You’re correct that the OpenFlow spec doesn’t define a dedicated acknowledgment for flow_mod messages—but controllers have reliable workarounds and built-in mechanisms to verify flow installation:

Two key approaches: #

1. Switch error feedback
   If a flow_mod is invalid (e.g., bad match fields, insufficient resources, or permission issues), the switch sends an OFPT_ERROR message back to the controller. Controllers listen for these events to detect failed installations:

   • In POX, register a listener for the ErrorIn event to catch failures.
   • In ODL, the OpenFlow plugin propagates these error events to the MD-SAL, so applications can subscribe to notifications to handle installation issues.

2. Active flow table querying
   The most foolproof way to confirm a flow is installed is to explicitly query the switch’s flow table (using the same stats request mechanism from the first question) right after sending the flow_mod:

   • In POX, after sending a flow_mod, trigger a flow_stats_request and check if the new flow appears in the response.
   • In ODL, send a post-installation GET request via RESTCONF, or use the MD-SAL to compare the desired flow state (from your application) with the actual state reported by the switch.

Some controllers add extra layers: ODL, for example, maintains a local copy of the switch’s flow state, so it can sync desired vs. actual states to confirm successful installation automatically.

内容的提问来源于stack exchange，提问作者Daniel