OpenFlow messages larger than 64KB are not allowed by the protocol specification. Therefore, a MULTIPART_REPLY message (which sends a switch's "flow stats" to the controller) can not carry more than 64KB of data.
In such cases, the data are broken into more that one MULTIPART_REPLY messages. The existence of subsequent MULTIPART_REPLY messages is indicated by setting the OFPMPF_REPLY_MORE
flag in a MULTIPART_REPLY message to 1.
Problem
The CPQD switch does not implement the OpenFlow protocol correctly. It creates MULTIPART_REPLY messages with sizes greater than 64K instead of breaking the data into many MULTIPART_REPLY messages and using the OFPMPF_REPLY_MORE flag.
The OFPMPF_REPLY_MORE handling is present in the code ( in udatapath/pipeline.c) but it is not implemented correctly. There is a limit on the number of tables that can be 'pipelined' into a single MULTIPART_REPLY message, but the size of each table is not taken into account.
A "flow stats" entry contained in a MULTIPART_REPLY message is 96 bytes long. So when the switch (incorrectly) tries to pack more than 680 "flow stats" into a single message, the message size exceeds 64KB and the message is sent to the controller malformed. As a result, the CPQD switch may not work correctly when more that 680 flows are installed on it, if for example they are all part of the same table. In this case a malformed OpenFlow message is created.
Background
OpenFlow messages larger than 64KB are not allowed by the protocol specification. Therefore, a MULTIPART_REPLY message (which sends a switch's "flow stats" to the controller) can not carry more than 64KB of data.
In such cases, the data are broken into more that one MULTIPART_REPLY messages. The existence of subsequent MULTIPART_REPLY messages is indicated by setting the OFPMPF_REPLY_MORE flag in a MULTIPART_REPLY message to 1.
Problem
The CPQD switch does not implement the OpenFlow protocol correctly. It creates MULTIPART_REPLY messages with sizes greater than 64K instead of breaking the data into many MULTIPART_REPLY messages and using the OFPMPF_REPLY_MORE flag.
The OFPMPF_REPLY_MORE handling is present in the code ( in
udatapath/pipeline.c) but it is not implemented correctly. There is a limit on the number of tables that can be 'pipelined' into a single MULTIPART_REPLY message, but the size of each table is not taken into account.A "flow stats" entry contained in a MULTIPART_REPLY message is 96 bytes long. So when the switch (incorrectly) tries to pack more than 680 "flow stats" into a single message, the message size exceeds 64KB and the message is sent to the controller malformed. As a result, the CPQD switch may not work correctly when more that 680 flows are installed on it, if for example they are all part of the same table. In this case a malformed OpenFlow message is created.