[ovs-dev] [RFC PATCH v2 00/13] Add Network Service Header Support
Johnson Li
johnson.li at intel.com
Tue Jul 12 17:25:45 UTC 2016
IETF draft at:
https://tools.ietf.org/html/draft-ietf-sfc-nsh-01
defines a new protocol named Network Service Header (NSH) for
Service Function Chaining. The NSH format looks like below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver|O|C|R|R|R|R|R|R| Length | MD Type | Next Proto |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Path ID | Service Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Mandatory/Optional Context Header ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this patch set, we implement the NSH support for the OVS which
then can be used as Service Function Forwarder. NSH is transport
independent by design, and VxLAN-GPE and Ethernet are targeted
transports being supported by OVS initially.
The implementation for VxLAN-GPE is upstreamed by Jiri Benc at
Linux kernel tree commit <e1e5314de08ba6003b358125eafc9ad9e75a950c>
while adding VxLAN-GPE support, the Ethernet type of the VxLAN-GPE
tunneling port is set to ARPHRD_NONE, which breaks the assumption
that all frames communicated between OVS data plane and tunneling
ports should start from a Ethernet header. Hence Simon Horman
submitted a patch set to enable the raw protocol support at:
http://openvswitch.org/pipermail/dev/2016-June/072010.html
In order to support NSH without depending on Simon's patch, we
introduced new flow actions push_eth and pop_eth to support the
Ethernet as a NSH transport. The new actions append a new Ethenet
header to carry NSH frame or remove the Ethernet header from the
NSH frame. We reused Simon's code for the data path implementation
and added explicit flow actions in control plane.
Basic NSH steering test case:
172.168.60.101/24 172.168.60.102/24
+--------------+ +--------------+
| br-int | | br-int |
+--------------+ +--------------+
| vxlan0 | | vxlan0 |
+--------------+ +--------------+
| |
| |
| |
192.168.50.101/24 192.168.50.102/24
+--------------+ +---------------+
| br-eth1 | | br-eth1 |
+--------------+ +---------------+
| eth1 |----------------------| eth1 |
+--------------+ +---------------+
Node 1 with OVS. Node 2 with OVS.
Configure Node 1:
Step 1: Create VxLAN port
$ovs-vsctl add-port br-int vxlan0 -- set interface vxlan0 \
type=vxlan options:remote_ip=192.168.50.102 options:key=flow \
options:dst_port=4789
Step 2: Add flows for Egress
$ovs-ofctl add-flow br-int "table=0, priority=260, in_port=LOCAL \
actions=load:0x1->NXM_NX_NSP[],load:0xFF->NXM_NX_NSI[],\
load:1->NXM_NX_NSH_MDTYPE[],load:0x3->NXM_NX_NSH_NP[],\
load:0x11223344->NXM_NX_NSH_C1[],load:0x55667788->NXM_NX_NSH_C2[],\
load:0x99aabbcc->NXM_NX_NSH_C3[],load:0xddeeff00->NXM_NX_NSH_C4[],\
push_nsh,push_eth,output:1"
Step 3: Add flow for Ingress
$ovs-ofctl add-flow br-int "table=0, priority=260, in_port=1,\
nsh_mdtype=1, nsp=0x800001, nsi=0xFF, nshc1=0xddeeff00,\
nshc2=0x99aabbcc, nshc3=0x55667788, nshc4=0x11223344, \
actions=pop_eth,pop_nsh,output:LOCAL"
Configure Node 2:
Step 1: Create VxLAN port
$ovs-vsctl add-port br-int vxlan0 -- set interface vxlan0 \
type=vxlan options:remote_ip=192.168.50.101 options:key=flow \
options:dst_port=4789
Step 2: Add flows for Egress
$ovs-ofctl add-flow br-int "table=0, priority=260, in_port=LOCAL \
actions=load:0x800001->NXM_NX_NSP[],load:0xFF->NXM_NX_NSI[],\
load:1->NXM_NX_NSH_MDTYPE[],load:0x3->NXM_NX_NSH_NP[],\
load:0xddeeff00->NXM_NX_NSH_C1[],load:0x99aabbcc->NXM_NX_NSH_C2[],\
load:0x55667788->NXM_NX_NSH_C3[],load:0x11223344->NXM_NX_NSH_C4[],\
push_nsh,push_eth,output:1"
Step 3: Add flow for Ingress
$ovs-ofctl add-flow br-int "table=0, priority=260, in_port=1,\
nsh_mdtype=1, nsp=0x1, nsi=0xFF, nshc1=0x11223344,\
nshc2=0x55667788, nshc3=0x99aabbcc, nshc4=0xddeeff00, \
actions=pop_eth,pop_nsh,output:LOCAL"
---
Change Log:
V1->V2: 1. Add prototype for MD type 2 support. Since the MD type 2
uses the same TLV format of Geneve, so this patch set
implements a prototype for MD type 2 support by reusing
the TUN_METADATA APIs and data structures for Geneve. BTW,
all the Geneve specific APIs will be renamed to be more
generic in the following patch iterations if this approach
makes sense.
2. Add Ethernet transport support. To remove the dependency
on Simon' patches for raw protocol support, we enable
Ethernet as a supported NSH transport. Hence explicit flow
actions push_eth/pop_eth to push/pop Ethernet header are added.
Johnson Li (13):
Add NSH keys as match fields for user space flow table
Format NSH keys to readable strings
Add key attributes of Network Service Header
Add APIs to set NSH keys for match fields
Add Meta flow key for NSH header
Parse NSH header in function flow_extract in user space
Userspace: Parse NSH header in flow_extract
Add "pop_nsh/push_nsh" flow action for OVS control plane
commit control plane action to data plane
Add push_eth/pop_eth flow actions for kernel data path
Add control plane command push_eth and pop_eth
Commit push_eth/pop_eth flow action to data plane
Format ODP action for push_eth/pop_eth flow actions
datapath/linux/compat/include/linux/openvswitch.h | 44 +++
include/openvswitch/flow.h | 5 +-
include/openvswitch/match.h | 12 +
include/openvswitch/meta-flow.h | 126 +++++++
include/openvswitch/ofp-actions.h | 7 +
include/openvswitch/packets.h | 19 +
lib/dpif-netdev.c | 4 +
lib/dpif.c | 4 +
lib/flow.c | 85 +++++
lib/match.c | 48 +++
lib/meta-flow.c | 152 ++++++++
lib/nx-match.c | 18 +
lib/odp-execute.c | 12 +
lib/odp-util.c | 418 +++++++++++++++++++++-
lib/ofp-actions.c | 155 ++++++++
lib/packets.h | 48 +++
ofproto/ofproto-dpif-sflow.c | 5 +
ofproto/ofproto-dpif-xlate.c | 73 ++++
tests/ofproto.at | 10 +-
19 files changed, 1241 insertions(+), 4 deletions(-)
--
1.8.4.2
--------------------------------------------------------------
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
More information about the dev
mailing list