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
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) Bin Hu
Multiple Networking Backends
----------------------------
Description
^^^^^^^^^^^
Network Function Virtualization (NFV) brings the need of supporting multiple networking
back-ends in virtualized infrastructure environments.
First of all, a Service Providers' virtualized network infrastructure will consist of
multiple SDN Controllers from different vendors for obvious business reasons.
Those SDN Controllers may be managed within one cloud or multiple clouds.
Jointly, those VIMs (e.g. OpenStack instances) and SDN Controllers need to work
together in an interoperable framework to create NFV services in the Service
Providers' virtualized network infrastructure. It is needed that one VIM (e.g. OpenStack
instance) shall be able to support multiple SDN Controllers as back-end.
Secondly, a Service Providers' virtualized network infrastructure will serve multiple,
heterogeneous administrative domains, such as mobility domain, access networks,
edge domain, core networks, WAN, enterprise domain, etc. The architecture of
virtualized network infrastructure needs different types of SDN Controllers that are
specialized and targeted for specific features and requirements of those different domains.
The architectural design may also include global and local SDN Controllers.
Importantly, multiple local SDN Controllers may be managed by one VIM (e.g.
OpenStack instance).
Furthermore, even within one administrative domain, NFV services could also be quite diversified.
Specialized NFV services require specialized and dedicated SDN Controllers. Thus a Service
Provider needs to use multiple APIs and back-ends simultaneously in order to provide
users with diversified services at the same time. At the same time, for a particular NFV service,
the new networking APIs need to be agnostic of the back-ends.
Requirements
^^^^^^^^^^^^
Based on the use cases described above, we derive the following
requirements.
It is expected that in NFV networking service domain:
* One OpenStack instance shall support multiple SDN Controllers simultaneously
* New networking API shall be integrated flexibly and quickly
* New NFV Networking APIs shall be agnostic of back-ends
* Interoperability is needed among multi-vendor SDN Controllers at back-end
Current Implementation
^^^^^^^^^^^^^^^^^^^^^^
In the current implementation of OpenStack networking, SDN controllers are
hooked up to Neutron by means of dedicated plugins. A plugin translates
requests coming in through the Neutron northbound API, e.g. the creation of a
new network, into the appropriate northbound API calls of the corresponding SDN
controller.
There are multiple different plugin mechanisms currently available in Neutron,
each targeting a different purpose. In general, there are `core plugins`,
covering basic networking functionality and `service plugins`, providing layer 3
connectivity and advanced networking services such as FWaaS or LBaaS.
Core and ML2 Plugins
''''''''''''''''''''
The Neutron core plugins cover basic Neutron functionality, such as creating
networks and ports. Every core plugin implements the functionality needed to
cover the full range of the Neutron core API. A special instance of a core
plugin is the ML2 core plugin, which in turn allows for using sub-drivers -
separated again into type drivers (VLAN, VxLAN, GRE) or mechanism drivers (OVS,
OpenDaylight, etc.). This allows to using dedicated sub-drivers for dedicated
functionality.
In practice, different SDN controllers use both plugin mechanisms to integrate
with Neutron. For instance OpenDaylight uses a ML2 mechanism plugin driver
whereas OpenContrail integrated by means of a full core plugin.
In its current implementation, only one Neutron core plugin can be active at any
given time. This means that if a SDN controller utilizes a dedicated core
plugin, no other SDN controller can be used at the same time for the same type
of service.
In contrast, the ML2 plugin allows for using multiple mechanism drivers
simultaneously. In principle, this enables a parallel deployment of multiple SDN
controllers if and only if all SDN controllers integrate through a ML2 mechanism
driver.
Neutron Service Plugins
'''''''''''''''''''''''
Neutron service plugins target L3 services and advanced networking services,
such as BGPVPN or LBaaS. Typically, a service itself provides a driver plugin
mechanism which needs to be implemented for every SDN controller. As the
architecture of the driver mechanism is up to the community developing the
service plugin, it needs to be analyzed for every driver plugin mechanism
individually if and how multiple back-ends are supported.
Gaps in the current solution
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Given the use case description and the current implementation of OpenStack
Neutron, we identify the following gaps:
* **[MB-GAP1] Limited support for multiple back-ends**
As pointed out above, the Neutron core plugin mechanism only allows for one
active plugin at a time. The ML2 plugin allows for running multiple mechanism
drivers in parallel, however, successful inter-working strongly depends on the
individual driver.
Moreover, the ML2 plugin and its API is - by design - very layer 2 focused. For
NFV networking use cases beyond layer 2, for instance L3VPNs, a more flexible
API is required.
Conclusion
^^^^^^^^^^
We conclude that a complementary method of integrating multiple SDN controllers
into a single OpenStack deployment is needed to fulfill the needs of operators.
|
