On Thu, Jul 19, 2012 at 12:24:13AM -0700, Ben Pfaff wrote:
> Signed-off-by: Ben Pfaff <[email protected]>
> ---
> DESIGN | 106
> +++++++++++++++++++++++++++++++++++++++++++++++++
> tests/ovs-ofctl.at | 87 ++++++++++++++++++++++++++++++++++++++++
> utilities/ovs-ofctl.c | 76 +++++++++++++++++++++++++++++++++++
> 3 files changed, 269 insertions(+), 0 deletions(-)
>
> diff --git a/DESIGN b/DESIGN
> index b06751f..9c1ff55 100644
> --- a/DESIGN
> +++ b/DESIGN
> @@ -152,6 +152,112 @@ sends flow_removed message --- --- --- %
> %
> receive the generated messages.)
>
>
> +VLAN Matching
> +=============
> +
> +The 802.1Q VLAN header causes more trouble than any other 4 bytes in
> +networking. More specifically, three versions of OpenFlow and Open
> +vSwitch have among them four different ways to match the contents and
> +presence of the VLAN header. The following table describes how each
> +version works.
> +
> + Match NXM OF1.0 OF1.1 OF1.2
> + ----- --------- ----------- ----------- ------------
> + [1] 0000/0000 ????/1,??/? ????/1,??/? 0000/0000,--
> + [2] 0000/ffff ffff/0,??/? ffff/0,??/? 0000/ffff,--
> + [3] 1xxx/1fff 0xxx/0,??/1 0xxx/0,??/1 1xxx/ffff,--
For [2] and [3] should the mask in the OF1.2 column be 1fff,
that is the top three bits clear, as the PCP is not set?
> + [4] z000/f000 ????/1,0y/0 fffe/0,0y/0 1000/1000,0y
> + [5] zxxx/ffff 0xxx/0,0y/0 0xxx/0,0y/0 1xxx/ffff,0y
> + [6] 0000/0fff <none> <none> <none>
> + [7] 0000/f000 <none> <none> <none>
> + [8] 0000/efff <none> <none> <none>
> + [9] 1001/1001 <none> <none> 1001/1001,--
> + [10] 3000/3000 <none> <none> <none>
And in the same vain as my comment on [5],
I believe that [10] is invalid for OF1.2.
> +Each column is interpreted as follows.
> +
> + - Match: See the list below.
> +
> + - NXM: xxxx/yyyy means NXM_OF_VLAN_TCI_W with value xxxx and mask
> + yyyy. A mask of 0000 is equivalent to omitting
> + NXM_OF_VLAN_TCI(_W), a mask of ffff is equivalent to
> + NXM_OF_VLAN_TCI.
> +
> + - OF1.0 and OF1.1: wwww/x,yy/z means dl_vlan wwww, OFPFW_DL_VLAN
> + x, dl_vlan_pcp yy, and OFPFW_DL_VLAN_PCP z. ? means that the
> + given nibble is ignored (and conventionally 0 for wwww or z,
> + conventionally 1 for x or z). <none> means that the given match
> + is not supported.
> +
> + - OF1.2: xxxx/yyyy,zz means OXM_OF_VLAN_VID_W with value xxxx and
> + mask yyyy, and OXM_OF_VLAN_PCP (which is not maskable) with
> + value zz. A mask of 0000 is equivalent to omitting
> + OXM_OF_VLAN_VID(_W), a mask of ffff is equivalent to
> + OXM_OF_VLAN_VID. -- means that OXM_OF_VLAN_PCP is omitted.
> + <none> means that the given match is not supported.
> +
> +The matches are:
> +
> + [1] Matches any packet, that is, one without an 802.1Q header or with
> + an 802.1Q header with any TCI value.
> +
> + [2] Matches only packets without an 802.1Q header.
> +
> + NXM: Any match with (vlan_tci == 0) and (vlan_tci_mask & 0x1000)
> + != 0 is equivalent to the one listed in the table.
> +
> + OF1.0: The spec doesn't define behavior if dl_vlan is set to
> + 0xffff and OFPFW_DL_VLAN_PCP is not set.
> +
> + OF1.1: The spec says explicitly to ignore dl_vlan_pcp when
> + dl_vlan is set to 0xffff.
> +
> + OF1.2: The spec doesn't say what should happen if (vlan_vid == 0)
> + and (vlan_vid_mask & 0x1000) != 0 but (vlan_vid_mask != 0x1000),
> + but it would be straightforward to also interpret as [2].
My reading is that the requirement for [2] is that the mask is
absent and vlan_vid == 0x0000, or in language that might be
understood outside of the spec: the CFI bit is clear and VID =
0x000.
I would lean towards extending that logic to allow any mask,
though as mentioned below I would prefer that there was a general
restriction that the top three bits of masks are clear.
> + [3] Matches only packets that have an 802.1Q header with VID xxx (and
> + any PCP).
> +
> + [4] Matches only packets that have an 802.1Q header with PCP y (and
> + any VID).
> +
> + NXM: z is ((y << 1) | 1).
> +
> + OF1.0: The spec isn't very clear, but OVS implements it this way.
> +
> + OF1.2: Presumably other masks such that (vlan_vid_mask & 0x1fff)
> + == 0x1000 would also work, but the spec doesn't define their
> + behavior.
Yes, I agree.
I think that its ok to accept other masks because,
for example:
1000 & 1000 == 1000 & 1fff
> +
> + [5] Matches only packets that have an 802.1Q header with VID xxx and
> + PCP y.
> +
> + NXM: z is ((y << 1) | 1).
> +
> + OF1.2: Presumably other masks such that (vlan_vid_mask & 0x1fff)
> + == 0x1fff would also work.
For OF1.2 I think its best to either require the top 3 bits of
the mask to be clear or ignore them. Perdonally I prefer the first
option.
> + [6] Matches packets with no 802.1Q header or with an 802.1Q header
> + with a VID of 0. Only possible with NXM.
> +
> + [7] Matches packets with no 802.1Q header or with an 802.1Q header
> + with a PCP of 0. Only possible with NXM.
> +
> + [8] Matches packets with no 802.1Q header or with an 802.1Q header
> + with both VID and PCP of 0. Only possible with NXM.
> +
> + [9] Matches only packets that have an 802.1Q header with an
> + odd-numbered VID (and any PCP). Only possible with NXM and
> + OF1.2. (This is just an example; one can match on any desired
> + VID bit pattern.)
For OF1.2 my feeling is that as all of these
have OFPVID_NONE as the VID that they are all equivalent to [2].
Either that or all masks should be rejected if
the VID is OFPVID_NONE.
> +
> +[10] Matches only packets that have an 802.1Q header with an
> + odd-numbered PCP (and any VID). Only possible with NXM. (This
> + is just an example; one can match on any desired VID bit
> + pattern.)
> +
> +
I concur that this is not valid for OF1.2.
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev
