The OpenFlow Switch specification 1.0.0, Section 5.3.3 ("Modify
State Messages"), states that
"[the] cookie field is an opaque data value that is set by the
controller. It is not used in any matching functions, and thus
does not need to reside in hardware. The value -1
(0xffffffffffffffff) is reserved and must not be used. It is
required that when command is OFPC_MODIFY or OFPC_MODIFY_STRICT
that matched flows have their cookie field updated appropriately."
while section 5.4.2 ("Flow Removed Message") states that
"[the] match, cookie, and priority fields [of the ofp_flow_removed
struct] are the same as those used in the flow setup request"
where the latter are presumably the values from the corresponding
ofp_flow_mod struct with a command value of OFPFC_ADD, OFPFC_MODIFY,
or OFPFC_MODIFY_STRICT. Although section 5.3.3 states that "the
cookie field [...] does not need to reside in hardware" (I interpret
"hardware" to mean "OpenFlow switch"), the content of Flow Removed
Message seems to contradict this.
Basically, my interpretation is that the cookie is a unique but
opaque flow identifier (cf., ofp_header.xid, which is a
Controller/Switch transaction identifier; also note that dpctl prints
the cookie, and not the xid identifier, when dump-flows is invoked).
However, nox never sets this field to any value but 0 (zero). Is this
an implementation oversight in nox?
Thanks!
...Martin Fong
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ nox-dev mailing list nox-dev@noxrepo.org http://noxrepo.org/mailman/listinfo/nox-dev
