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
246
247
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) OPNFV, Huawei
===========================
OPNFV Platform Architecture
===========================
.. ==> Add reference links from https://wiki.opnfv.org/releases/brahmaputra/releasedocs
.. ==> All links should point to release docs, not to OPNFV-Wiki or artifacts.
OPNFV Lab Infrastructure
========================
The `Pharos Project <https://www.opnfv.org/developers/pharos>`_ provides a lab infrastructure
that is geographically and technically diverse.
Labs instantiate **bare-metal** and **virtual** environments that are accessed remotely by the
community and used for OPNFV platform and feature development, builds, deploys and testing.
This will greatly assist in developing a highly robust and stable OPNFV platform
with well understood performance characteristics.
Community labs are hosted by OPNFV member companies on a voluntary basis.
The Linux Foundation also hosts an OPNFV lab that provides centralised CI
and other production resources which are linked to community labs.
Future lab capabilities will include the ability easily automate deploy and test of any
OPNFV install scenario in any lab environemnt as well as a *Virtual Lab* for
developer on-boarding with minimal effort.
.. ==> I am not sure this is the best place to include this.
Software architecture
=====================
This section will provide information which upstream projects, versions and components are
integrated in the release to implement OPNFV requirement. You can find a requirement list
`here <http://artifacts.opnfv.org/genesisreq/docs/requirements.pdf>`_.
OpenStack
---------
.. ==> didn't understand Chris' suggestion about reducing the heading level for these sub-topics
OPNFV uses OpenStack as cloud management system.
Brahmaputra is based on OpenStack Liberty Release.
The set of sub-projects varies slightly depending on the installer.
.. ==> If possible replace the list of OpenStack components here by a link to an
.. appropriate document
.. (http://artifacts.opnfv.org/genesisreq/review/10155/requirements/component-support.html
.. was suggested, but this is different infomation.)
The following table shows which components are deployed.
+------------+----------------+-----------+-----------+-----------+-----------+
| services | type | Apex | Compass | Fuel | Joid |
+============+================+===========+===========+===========+===========+
| ceilometer | metering | Available | Available | Available | Available |
+------------+----------------+-----------+-----------+-----------+-----------+
| cinder | volume | Available | Available | Available | Available |
+------------+----------------+-----------+-----------+-----------+-----------+
| cloud | cloudformation | --- | Available | Available | Available |
+------------+----------------+-----------+-----------+-----------+-----------+
| glance | image | Available | Available | Available | Available |
+------------+----------------+-----------+-----------+-----------+-----------+
| heat | orchestration | Available | Available | Available | Available |
+------------+----------------+-----------+-----------+-----------+-----------+
| keystone | identity | Available | Available | Available | Available |
+------------+----------------+-----------+-----------+-----------+-----------+
| neutron | network | Available | Available | Available | Available |
+------------+----------------+-----------+-----------+-----------+-----------+
| nova | compute | Available | Available | Available | Available |
+------------+----------------+-----------+-----------+-----------+-----------+
| swift | object-store | Available | --- | Available | Available |
+------------+----------------+-----------+-----------+-----------+-----------+
.. This table is created by outputs from jenkins functest log, components registering at keystone
.. would prefer a table per scenario.
Some of the sub-projects are not deployed in all scenarios.
.. end of the part to be replaced by link if possible.
Note that additional components of OpenStack are used as part of deployment tools and test frameworks
(Fuel, Tempest, Rally).
For more information about the OpenStack features and usage refer to the
`official OpenStack documentation page <http://docs.openstack.org/>`_.
Please ensure that you have the Liberty release selected at the
``More Releases & Languages`` drop down menu.
Operating System
----------------
OPNFV uses Linux on all target machines. Depending on the installers, different
distributions are supported.
Ubuntu 14 supported by Fuel, Compass and Joid installers
CentOS 7 supported by Apex and Compass
SDN Controllers
---------------
OPNFV Brahmaputra release supports different SDN controllers.
Some scenarios don't use an SDN controller but rely just on **Neutron** networking capabilities.
Depending on the SDN controller you are using, the featureset will vary.
Brahmaputra also provides scenarios without an SDN controller, just using OpenStack Neutron.
The OpenDaylight project is a collaborative open source project that aims to accelerate
adoption of Software-Defined Networking (SDN) and Network Functions Virtualization
(NFV) with a transparent approach that fosters new innovation.
**OpenDaylight** is an SDN controller that aims to accelerate
adoption of Software-Defined Networking (SDN) and Network Functions Virtualization
(NFV) with a transparent approach that fosters new innovation.
OpenDaylight runs within a JVM and is installed in OPNFV within a container and integrated with OpenStack
using the ODL device driver. The Brahmaputra release of OPNFV integrates the Beryllium release.
You can find more information about OpenDaylight among the release artifacts at the
`Downloads page <https://www.opendaylight.org/downloads>`_.
Please ensure you are using the Beryllium documentation.
**ONOS** is an SDN controller written in Java with a distributed architecture with special focus to
support scalability, fault tolerance and hardware and software upgrades without
interrupting network traffic.
More information on the internal design of ONOS may be found in
`User's Guide <https://wiki.onosproject.org/display/ONOS/User's+Guide>`_ and
`Architecture+Guide <https://wiki.onosproject.org/display/ONOS/Architecture+Guide>`_ on the
`wiki of the ONOS project <https://wiki.onosproject.org>`_.
ONOS is integrated to OPNFV using a framework ONOSFW and Neutron plugins. Details can be found in the
ONOS specific OPNFV documents,
`Design guide <http://artifacts.opnfv.org/onosfw/brahmaputra/docs/design/design.pdf>`_,
`User guide <http://artifacts.opnfv.org/onosfw/brahmaputra/docs/userguide/index.html>`_ and
`Config guide <http://artifacts.opnfv.org/onosfw/brahmaputra/docs/configguide/index.html>`_.
.. **OpenContrail** SDN controller will be supported in the next drop of the Brahmaputra release.
Data Plane
----------
OPNFV extends Linux's virtual networking capabilies by using virtual switch
and router components including improving those components by requirements
specific to telco use cases.
For instance some scenarios use **OpenVSwich**
to replace Linux bridges as it offers advantages in terms of mobility, hardware
integration and use by network controllers. OPNFV leverages these by upgrade
to a specific installation using user-space datapath. This includes changes to
other dataplane components, including libvirt, qemu, DPDK etc.
Please find more information in
`OVSNFV User's Guide <http://artifacts.opnfv.org/ovsnfv/docs/userguides/userguides.pdf>`_
.. ==> need input, if we mention other components
Other Components
----------------
**KVM**
NFV infrastructure has special requirements on hypervisors with respect of
interrupt latency (timing correctness and packet latency in data plane) and
live migration.
Besides additional software changes, this requires
some adjustments to system configuration
information, like hardware, BIOS, OS, etc.
.. KVM4NFV is one implementation, we have three implementations of the OS virtualization layer
.. to capture here.
.. ==> need more input
Please find more information at
`KVM4NFV project documentation <http://artifacts.opnfv.org/kvmfornfv/docs/all/all.pdf>`_
.. As it is a platform overview I think if we mention KVM as hypervisor we should focus on which version we are using and how as opposed to the OPNFV project that deals with KVM itself.
Deployment Architecture
=======================
OPNFV starts with a typical configuration with 3 controller nodes running
OpenStack, SDN, etc. and a minimum of 2 compute nodes for deployment of VNFs.
A detailed description of this 5 node configuration can be found in pharos documentation.
The 3 controller nodes allow to provide an HA configuration. The number of compute
nodes can be increased dynamically after the initial deployment.
OPNFV can be deployed on bare metal or in a virtual environment, where each of the hosts
is a virtual machine and provides the virtual resources using nested virtualization.
The initial deployment is done using a so-called "jumphost". This server (either bare metal
or virtual) is first installed with the installer program that then installs OpenStack
and other components on the controller nodes and compute nodes. See the
`OPNFV user guide <http://artifacts.opnfv.org/opnfvdocs/brahmaputra/docs/userguide/userguide.pdf>`_
for more details.
.. Editors note:
.. In a second level of detail, describe how software is distributed over the 3 controller
.. nodes, compute nodes and other hardware.
In Brahmaputra, different scenarios can be deployed to provide the different feature sets, e.g.
HA, IPV6, BGPVPN, KVM, or select the different implementations, e.g. SDN controllers.
.. ==> Is it described somewhere what we mean by scenarios? If yes, then the original text is better.
.. If not, I would give a brief overview here to describe the term.
The following scenarios are supported, some of them can be deployed using different installers.
* nosdn-nofeature
* odl_l2-ha
* odl_l3-ha
* odl_l2-bgpvpn-noha
* onos-ha
* nosdn-ovs-ha
* nosdn-kvm-ha
* nosdn-ovs_kvm-ha
Please find more information at
`<https://wiki.opnfv.org/functextnexttaks>`_
.. ==> As soon as better information is available, the list can be replaced by a link to e.g.
.. http://artifacts.opnfv.org/opnfvdocs/brahmaputra/docs/configguide/configoptions.html#opnfv-scenario-s.
.. Dynamic View
.. ============
.. Editors note: we might skip this section completely for Brahmaputra.
.. Or we provide rather short statements. In later versions, we have to describe which
.. software is involved in which way during:
.. * VNF Life Cycle (onboarding, instantiate, scaling): we can reference to other documents
.. * Hardware Life Cycle (mainly how to add compute nodes, but also other cases)
.. * ...
|
