1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
|
..
Copyright 2015 Futurewei. All rights reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
Convention for heading levels in Neutron devref:
======= Heading 0 (reserved for the title in a document)
------- Heading 1
~~~~~~~ Heading 2
+++++++ Heading 3
''''''' Heading 4
(Avoid deeper levels because they do not render well.)
==========================
System Design and Workflow
==========================
Problem Description
===================
The `Service Chaining API specification <http://docs.openstack.org/developer/networking-sfc/api.html>`_ proposes a Neutron port based solution for setting up a service chain. A specification on the system architecture and related API work flow is needed to guide the code design.
System Architecture
============================
The following figure shows the generic architecture of the Port Chain
Plugin. As shown in the diagram, Port Chain Plugin can be backed by
different service providers such as OVS Driver and/or different types of
SDN Controller Drivers. Through the "Common Driver API", these
different drivers can provide different implementations for the service
chain path rendering. In the first release and deployment based on this
release, we will only deliver codes for the OVS driver. In the next release,
we can add codes to support multiple active drivers::
Port Chain Plugin With Different Types of Drivers
+-----------------------------------------------------------------+
| +-----------------------------------------------------------+ |
| | Port Chain API | |
| +-----------------------------------------------------------+ |
| | Port Chain Database | |
| +-----------------------------------------------------------+ |
| | Driver Manager | |
| +-----------------------------------------------------------+ |
| | Common Driver API | |
| +-----------------------------------------------------------+ |
| | |
| +------------+------------------------+---------------------+ |
| | OVS Driver | Controller Driver1 | Controller Driver2 | |
| +------------+------------------------+---------------------+ |
+-------|------------------|-------------------------|------------+
| | |
+-----------+ +-----------------+ +-----------------+
| OVS Agent | | SDN Controller1 | | SDN Controller2 |
+-----------+ +-----------------+ +-----------------+
The second figure below shows the reference implementation architecture,
which is through the OVS Driver path. The figure shows the components
that will be added on the Neutron Server and the compute nodes to
support this Neutron Based SFC functionality. As shown in the diagram,
a new Port Chain Plugin will be added to the Neutron Server.
The existing "OVS Driver" and "OVS Agent" will be extended to support
the service chain functionality. The OVS Driver will communicate with
each OVS Agent to program its OVS forwarding table properly so that a
tenant's traffic flow can be steered through the user defined sequence
of Neutron ports to get the desired service treatment from the Service
Function running on the VMs.
A separate `OVS Driver and Agent specification <http://docs.openstack.org/developer/networking-sfc/portchain-ovs-driver-agent.html>`_ will describe in more
detail on the design consideration of the Driver, Agent, and how to set up the
classification rules on the OVS to identify different flows and how to
set up the OVS forwarding table. In the reference implementation, the OVS Driver
communicates with OVS Agent through RPC to program the OVS. The communication
between the OVS Agent and the OVS is through OVSDB/Openflow::
Port Chain Plugin With OVS Driver
+-------------------------------+
| +-------------------------+ |
| | Port Chain API | |
| +-------------------------+ |
| | Port Chain Database | |
| +-------------------------+ |
| | Driver Manager | |
| +-------------------------+ |
| | Common Driver API | |
| +-------------------------+ |
| | |
| +-------------------------+ |
| | OVS Driver | |
| +-------------------------+ |
+-------|----------------|------+
| |
+-----------+ +-----------+
| OVS Agent | | OVS Agent |
+-----------+ +-----------+
Port Chain Creation Workflow
============================
The following example shows how the Neutron CLI commands may be used to
create a port-chain consisting of a service VM vm1 and a service VM
vm2. The user can be an Admin/Tenant or an Application built on top.
Traffic flow into the Port Chain will be from source IP address
22.1.20.1 TCP port 23 to destination IP address 171.4.5.6 TCP port 100.
The flow needs to be treated by SF1 running on VM1 identified by
Neutron port pair [p1, p2] and SF2 running on VM2 identified by Neutron
port pair [p3, p4].
The net1 should be created before creating Neutron port using existing
Neutron API. The design has no restriction on the type of net1, i.e. it
can be any type of Neutron network since SFC traffic will be tunneled
transparently through the type of communication channels of net1.
If the transport between vSwitches is VXLAN, then we will use that VXLAN
tunnel (and NOT create another new tunnel) to transport the SFC traffic
through. If the transport between vSwitches is Ethernet, then the SFC
traffic will be transported through Ethernet. In other words, the SFC
traffic will be carried over existing transport channel between vSwitches
and the external transport channel between vSwitches is set up for net1
through existing Neutron API and ML2. The built-in OVS backend
implements tunneling the original flow packets over VXLAN tunnel. The detailed
outer VXLAN tunnel transport format and inner SFC flow format including
how to leverage existing OVS's support for MPLS label to carry chain ID
will be described in the `Port Chain OVS Driver and Agent specification <http://docs.openstack.org/developer/networking-sfc/portchain-ovs-driver-agent.html>`_.
In the future we can add implementation of tunneling the SFC flow packets over
flat L2 Ethernet or L3 IP network or GRE tunnel etc.
Boot service VMs and attach ports
---------------------------------
Create Neutron ports on network net1::
neutron port-create --name p1 net1
neutron port-create --name p2 net1
neutron port-create --name p3 net1
neutron port-create --name p4 net1
Boot VM1 from Nova with ports p1 and p2 using two --nic options::
nova boot --image xxx --nic port-id=p1 --nic port-id=p2 vm1
Boot VM2 from Nova with ports p3 and p4 using two --nic options::
nova boot --image yyy --nic port-id=p3 --nic port-id=p4 vm2
Alternatively, the user can create each VM with one VNIC and then
attach another Neutron port to the VM::
nova boot --image xxx --nic port-id=p1 vm1
nova interface-attach --port-id p2 vm1
nova boot --image yyy --nic port-id=p3 vm2
nova interface-attach --port-id p4 vm2
Once the Neutron ports p1 - p4 exist, the Port Chain is created using
the steps described below.
Create Flow Classifier
----------------------
Create flow-classifier FC1 that matches on source IP address 22.1.20.1
(ingress direction) and destination IP address 171.4.5.6 (egress
direction) with TCP connection, source port 23 and destination port
100::
neutron flow-classifier-create
--ip-version ipv4
--source-ip-prefix 22.1.20.1/32
--destination-ip-prefix 172.4.5.6/32
--protocol tcp
--source-port 23:23
--destination-port 100:100 FC1
Create Port Pair
-----------------
Create port-pair PP1 with ports p1 and p2, port-pair PP2 with
ports p3 and p4, port-pair PP3 with ports P5 and P6::
neutron port-pair-create
--ingress=p1
--egress=p2 PP1
neutron port-pair-create
--ingress=p3
--egress=p4 PP2
neutron port-pair-create
--ingress=p5
--egress=p6 PP3
Create Port Group
-----------------
Create port-pair-group PG1 with port-pair PP1 and PP2, and
port-pair-group PG2 with port-pair PP3::
neutron port-pair-group-create
--port-pair PP1 --port-pair PP2 PG1
neutron port-pair-group-create
--port-pair PP3 PG2
Create Port Chain
-----------------
Create port-chain PC1 with port-group PG1 and PG2, and flow
classifier FC1::
neutron port-chain-create
--port-pair-group PG1 --port-pair-group PG2 --flow-classifier FC1 PC1
This will result in the Port chain driver being invoked to create the
Port Chain.
The following diagram illustrates the code execution flow (not the
exact codes) for the port chain creation::
PortChainAPIParsingAndValidation: create_port_chain
|
V
PortChainPlugin: create_port_chain
|
V
PortChainDbPlugin: create_port_chain
|
V
DriverManager: create_port_chain
|
V
portchain.drivers.OVSDriver: create_port_chain
The vSwitch Driver needs to figure out which switch VM1 is connecting
with and which switch VM2 is connecting with (for OVS case, the OVS
driver has that information given the VMs' port info). As to the
connection setup between the two vSwitches, it should be done through
existing ML2 plugin mechanism. The connection between these two
vSwitches should already be set up before the user initiates the SFC
request. The service chain flow packets will be tunneled through the
connecting type/technology (e.g. VXLAN or GRE) between the two
vSwitches. For our reference code implementation, we will use VXLAN to
show a complete data path setup. Please refer to the `OVS Driver and OVS
Agent specification <http://docs.openstack.org/developer/networking-sfc/portchain-ovs-driver-agent.html>`_ for more detail info.
|
