[pox-dev] Dealing with buffer ID = -1, i.e. no buffered packet
Murphy McCauley
murphy.mccauley at gmail.com
Mon Oct 8 20:13:54 PDT 2012
Just one more note to anyone who is interested here...
On Oct 8, 2012, at 7:09 PM, Murphy McCauley wrote:
> l2_learning hasn't been updated for this, but check out l2_pairs in the betta branch, which uses the fact that packet_out and flow_mod can now be passed a packet_in as "data", and they should both "do the right thing".
"do the right thing" is tricky here in the case of flow_mods, as they can resend a buffer, but can't send raw data, which is what you have if the switch didn't buffer it. What actually happens in this case is that pack()ing a flow_mod will actually return the wire representation of a flow_mod, a barrier, and a packet_out sent to TABLE. The assumption is that the packet you're sending will hit the flow you just installed.
Another thought would be to write an assert that checks that the packet going out would actually match the flow you're installing, but this isn't guaranteed to be right since there might be a higher-priority rule that it matches first.
Yet a different possible approach would be to just send a flow_mod followed by a packet_out with the same actions as the flow_mod. This is PROBABLY most similar in behavior to what happens when a buffer ID is specified (?). You'd have to do a little extra work: if the flow you're installing has output-to-controller actions, you'd have to strip those (I can't think of any other examples of things you'd have to change off the top of my head, though there might be some in the spec or some that are vendor actions).
I'd welcome input on this if anyone had any . :)
-- Murphy
More information about the pox-dev
mailing list