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
|
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) <optionally add copywriters name>
=======================
OPNFV os-odl-gluon-noha
=======================
This document provides scenario level details for the Danube release of Gluon.
.. contents::
:depth: 3
:local:
Introduction
------------
.. In this section explain the purpose of the scenario and the types of capabilities provided
This scenario integrates the Gluon framework into the OPNFV platform and makes
it available for testing and development. Gluon is a model-driven networking
framework that extends OpenStack Neutron with the ability to generate new
networking APIs from YAML models. Additionally, Gluon provides a mechanism for
integrating multiple networking backends (SDN controllers) in parallel.
Scenario components and composition
-----------------------------------
.. In this section describe the unique components that make up the scenario,
.. what each component provides and why it has been included in order
.. to communicate to the user the capabilities available in this scenario.
The scenario contains Gluon 1.0.2 which was released in conjunction with
OpenStack Ocata. However, Gluon 1.0.2 is fully compatible with OpenStack Newton
which is used in the Danube release of OPNFV and hence also in this scenario.
The Gluon framework consists of five software components:
* **Gluon core plugin:** Gluon integrates into OpenStack Neutron as an extended
version of the existing ML2 core plugin. It hence runs in the context of the
Neutron server process on the OpenStack controller nodes.
* **Proton server:** The proton server runs one or more Protons which expose
service-specific REST APIs. This scenario currently only contains a single
Proton, exposing a L3VPN service API.
* **Proton client:** For every API model, the protonclient tool generates
the corresponding command line options for creating, deleting and updating
the API objects exposed by a Proton.
* **etcd:** Gluon and all Protons maintain their state in the distributed
key-value store etcd.
* **Shim layer for OpenDaylight:** This shim layer is notified about changes
in the configuration state of a Proton and translates these changes into API
calls to the OpenDaylight SDN controller. This scenario contains a shim layer
for the L3VPN Proton API.
In addition to these scenario-specific components, the scenario contains
OpenStack Newton and OpenDaylight Boron.
Scenario usage overview
-----------------------
.. Provide a brief overview on how to use the scenario and the features available to the
.. user. This should be an "introduction" to the user guide document, and explicitly link to it,
.. where the specifics of the features are covered including examples and API's
The Gluon framework extends existing Neutron functionality by exposing an
alternative L3VPN API through a corresponding Proton. As a result, the existing
Neutron functionality remains available as for any other scenario with
OpenDaylight.
The configuration of the L3VPN service is done throught the RESTful API exposed
by the L3VPN proton or by means of the protonclient. The high-level workflow
for configuring the L3VPN service Proton is as follows:
i) create a new port
ii) create a new vpn object
iii) bind the port to the vpn object
More detailed information can be found in the :ref:`Gluon feature guide <netready-userguide>`.
Scenario-specific test cases
----------------------------
A Gluon-specific test case is run against this scenario to verify the
functionality provided by Gluon. This section briefly describes the test case.
The test case verifies that Gluon can be used to provision a L3VPN which
provides layer 3 connectivity between two virtual machines connected to two
different networks. Specifically, the test case performs the following steps:
i) create two Gluon ports
ii) create a L3VPN
iii) create service bindings between the Gluon ports and the L3VPN
iv) boot two VMs - each using one of the previously created ports
v) send a single ping (ICMP) packet from VM1 to VM2 and vice versa
vi) verify that both pings succeeded
All calls to the REST API of the L3VPN Proton are done by means of the
protonclient command line tool.
Limitations, Issues and Workarounds
-----------------------------------
.. Explain scenario limitations here, this should be at a design level rather than discussing
.. faults or bugs. If the system design only provide some expected functionality then provide
.. some insight at this point.
The following limitations apply:
* The OpenDaylight shim layer currently supports only a single L3VPN.
* The DHCP service is not enabled for VMs connecting to a L3VPN created through
Gluon. Hence, VMs need to be configured with static IP addresses.
|
