[ovs-dev] Fwd: Where to add GTP tunnel headers in datapath flow table of open vSwitch

[Ajmer Singh]

---------- Forwarded message ----------
From: Ajmer Singh <ajmersingh.tu06 at gmail.com>
Date: Fri, Mar 11, 2016 at 3:16 PM
Subject: Re: [ovs-dev] Where to add GTP tunnel headers in datapath flow
table of open vSwitch
To: Jesse Gross <jesse at kernel.org>


Hi,


openflow1.3 specification supports below match fields.

enum oxm_ofb_match_fields {
OFPXMT_OFB_IN_PORT = 0, /* Switch input port. */
OFPXMT_OFB_IN_PHY_PORT = 1, /* Switch physical input port. */
OFPXMT_OFB_METADATA = 2, /* Metadata passed between tables. */
OFPXMT_OFB_ETH_DST = 3, /* Ethernet destination address. */
OFPXMT_OFB_ETH_SRC = 4, /* Ethernet source address. */
OFPXMT_OFB_ETH_TYPE = 5, /* Ethernet frame type. */
OFPXMT_OFB_VLAN_VID = 6, /* VLAN id. */
---------------------------------------
OFPXMT_OFB_IPV6_EXTHDR = 39, /* IPv6 Extension Header pseudo-field */
}
but open Vswitch2.4 does have different enum constants for match fields.

enum OVS_PACKED_ENUM mf_field_id{
    MFF_DP_HASH,
    MFF_RECIRC_ID,
    MFF_CONJ_ID,
    MFF_TUN_ID,
    MFF_TUN_SRC,
    MFF_TUN_DST,
    MFF_TUN_FLAGS,
    MFF_TUN_TTL,
    MFF_TUN_TOS,
    MFF_TUN_GBP_ID,
    MFF_TUN_GBP_FLAGS,
    MFF_METADATA,
    MFF_IN_PORT,
    MFF_IN_PORT_OXM,
    MFF_ACTSET_OUTPUT,
    MFF_SKB_PRIORITY,
    MFF_PKT_MARK,
    MFF_REG0,
    MFF_REG1,
    MFF_REG2,
    MFF_REG3,
    MFF_REG4,
    MFF_REG5,
    MFF_REG6,
    MFF_REG7,
#error "Need to update MFF_REG* to match FLOW_N_REGS"
    MFF_XREG0,
    MFF_XREG1,
    MFF_XREG2,
    MFF_XREG3,
#error "Need to update MFF_REG* to match FLOW_N_XREGS"
    MFF_ETH_SRC,
    MFF_ETH_DST,
    MFF_ETH_TYPE,
    MFF_VLAN_TCI,
    MFF_DL_VLAN,
    MFF_VLAN_VID,
    MFF_DL_VLAN_PCP,
    MFF_VLAN_PCP,
    MFF_MPLS_LABEL,
    MFF_MPLS_TC,
    MFF_MPLS_BOS,
/* Update mf_is_l3_or_higher() if MFF_IPV4_SRC is no longer the first
element
    MFF_IPV4_SRC,
    MFF_IPV4_DST,
    MFF_IPV6_SRC,
    MFF_IPV6_DST,
    MFF_IPV6_LABEL,
    MFF_IP_PROTO,
    MFF_IP_DSCP,
    MFF_IP_DSCP_SHIFTED,
    MFF_IP_ECN,
    MFF_IP_TTL,
    MFF_IP_FRAG,
    MFF_ARP_OP,
    MFF_ARP_SPA,
    MFF_ARP_TPA,
    MFF_ARP_SHA,
    MFF_ARP_THA,
    MFF_TCP_SRC,
    MFF_TCP_DST,
    MFF_TCP_FLAGS,
    MFF_UDP_SRC,
    MFF_UDP_DST,
    MFF_SCTP_SRC,
    MFF_SCTP_DST,
    MFF_ICMPV4_TYPE,
    MFF_ICMPV4_CODE,
    MFF_ICMPV6_TYPE,
    MFF_ICMPV6_CODE,
    MFF_ND_TARGET,
    MFF_ND_SLL,
    MFF_ND_TLL,
    MFF_N_IDS
}
Could you please guide how these maps to standard openflow specification
match fields?

Regards,
Ajmer

On Fri, Mar 11, 2016 at 3:10 PM, Ajmer Singh <ajmersingh.tu06 at gmail.com>
wrote:

> thanks for your response.
>
> On Wed, Mar 9, 2016 at 10:02 PM, Jesse Gross <jesse at kernel.org> wrote:
>
>> On Tue, Mar 8, 2016 at 9:24 PM, Ajmer Singh <ajmersingh.tu06 at gmail.com>
>> wrote:
>> > I have now question related to mapping of ofp_header->type (OFPT_) with
>> > OFPRAW_contants
>> >
>> > struct ofp_header {
>> >     uint8_t version;    /* An OpenFlow version number, e.g.
>> OFP10_VERSION.
>> > */
>> >     uint8_t type;       /* One of the OFPT_ constants. */
>> >     ovs_be16 length;    /* Length including this ofp_header. */
>> >     ovs_be32 xid;       /* Transaction id associated with this packet.
>> > Replies use the same id as was in the request to facilitate pairing. */
>> > };
>> > OFP_ASSERT(sizeof(struct ofp_header) == 8);
>> >
>> > ofphdrs_decode(): openVswitch/lib/ofp-msg.c
>> > this function assumes that openflow header type contains only below enum
>> > constants. My query is why it is not taking care of lot many openflow
>> > messages (PACKET_OUT, FLOW_MOD etc..). your response is much
>> appreciated.
>> > OFPT_VENDOR
>> > OFPT10_STATS_REQUEST
>> > OFPT10_STATS_REPLY
>> > OFPT11_STATS_REQUEST
>> > OFPT11_STATS_REQUEST
>>
>> The comment above struct ofphdrs describes what information is contained
>> in it:
>>
>> /* A thin abstraction of OpenFlow headers:
>>  *
>>  *   - 'version' and 'type' come straight from struct ofp_header, so
>> these are
>>  *     always present and meaningful.
>>  *
>>  *   - 'stat' comes from the 'type' member in statistics messages only.
>> It is
>>  *     meaningful, therefore, only if 'version' and 'type' taken together
>>  *     specify a statistics request or reply.  Otherwise it is 0.
>>  *
>>  *   - 'vendor' is meaningful only for vendor messages, that is, if
>> 'version'
>>  *     and 'type' specify a vendor message or if 'version' and 'type'
>> specify
>>  *     a statistics message and 'stat' specifies a vendor statistic type.
>>  *     Otherwise it is 0.
>>  *
>>  *   - 'subtype' is meaningful only for vendor messages and otherwise 0.
>> It
>>  *     specifies a vendor-defined subtype.  There is no standard format
>> for
>>  *     these but 32 bits seems like it should be enough. */
>>
>> It is not handling any message types, just extracting this
>> information. However, none of this needs to be modified to add a new
>> tunnel type.
>>
>
>