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
|
.. Licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. Copyright 2017 AT&T Intellectual Property. All rights reserved.
.. _ONAP Heat Networking:
ONAP Heat Networking
-----------------------
ONAP defines two types of networks: External Networks and Internal Networks.
External Networks
^^^^^^^^^^^^^^^^^^^^
An ONAP external network is created by using VID or by invoking SO directly
to instantiate the network.
External networks are orchestrated separately, independent of VNFs.
A network instantiated via VID or by invoking SO directly is managed by
ONAP and is inventoried in AAI.
An external network can be created by using one of the following
resources:
- ``OS::Neutron::Net``
- ``OS::Neutron::ProviderNet``
- ``OS::ContrailV2::VirtualNetwork``
An external network **MAY** be used to
- Connect a VM in a VNF to VMs in another VNF
- Connect a VM in a VNF to an external gateway or external router
- Connect a VM in a VNF to other VMs in the same VNF
An external network may be designed to perform
- All three functions listed above or
- Perform only two functions listed above or
- Perform only one function listed above
.. req::
:id: R-16968
:target: VNF
:keyword: MUST NOT
:validation_mode: static
:updated: frankfurt
A VNF's Heat Orchestration Templates **MUST NOT** include heat
resources to create an ONAP external network.
An ONAP external network **MUST** be instantiated by using VID
or by invoking SO directly.
.. req::
:id: R-00606
:target: VNF
:keyword: MAY
:updated: frankfurt
A VNF **MAY** be connected to zero, one or more than one ONAP external
network.
.. req::
:id: R-57424
:target: VNF
:keyword: MAY
:validation_mode: none
:updated: frankfurt
A VNF's port connected to an ONAP external network **MAY**
use the port for the purpose of
- Connecting a VM in the VNF to VMs in another VNF and/or
- Connecting a VM in the VNF to an external gateway or external router
and/or
- Connecting a VM in the VNF to other VMs in the same VNF
.. req::
:id: R-99794
:target: VNF
:keyword: MUST
:validation_mode: none
:updated: casablanca
An ONAP external network **MUST** have one subnet. An external network
**MAY** have more than one subnet.
ONAP enforces a naming convention for
resource IDs and resource property
parameters associated with
external networks. :ref:`ONAP Heat Resource ID and Parameter Naming Convention`
provides additional details.
Internal Networks
^^^^^^^^^^^^^^^^^^^^
An ONAP internal network is created by the VNF's Heat Orchestration Template.
That is, the VNF's Heat Orchestration Template contains the heat resources to
instantiate the network.
An ONAP internal network is not inventoried by AAI and can not be managed
independently of the VNF.
An ONAP internal network MUST only be used for connecting a VM in the
VNF to other VMs in the same VNF.
An ONAP internal network MUST NOT be used for connecting a VM in the VNF to
VMs in another VNF or connecting a VM in the VNF to an external gateway and/or
external router.
The reason for this is for operational simplicity. An ONAP internal network
will be deleted when the VNF that created the network (referred to as VNF A)
is deleted. If a different VNF (referred to as VNF B) attaches to the ONAP
internal network created by VNF A, then VNF B must be deleted prior VNF A.
In addition, if an ONAP internal network is used to connect two (or more) VNFs,
there is no record in AAI inventory. This could lead to additional
operational complications.
.. req::
:id: R-87096
:target: VNF
:keyword: MAY
:updated: frankfurt
A VNF **MAY** contain zero, one or more than one ONAP internal network.
.. req::
:id: R-35666
:target: VNF
:keyword: MUST
:validation_mode: static
:updated: frankfurt
If a VNF has an ONAP internal network, the VNF's Heat Orchestration
Template **MUST** include the heat resources to create the
ONAP internal network.
A VNF's ONAP internal network is created using Neutron Heat Resources
(e.g., ``OS::Neutron::Net``, ``OS::Neutron::Subnet``,
``OS::Neutron::ProviderNet``) and/or
Contrail Heat Resources (e.g., ``OS::ContrailV2::VirtualNetwork``,
``OS::ContrailV2::NetworkIpam``).
.. req::
:id: R-52425
:target: VNF
:keyword: MUST
:validation_mode: none
:updated: frankfurt
A VNF's port connected to an ONAP internal network **MUST**
use the port for the purpose of reaching VMs in the same VNF.
.. req::
:id: R-46461
:target: VNF
:keyword: MUST NOT
:validation_mode: none
:updated: frankfurt
A VNF's port connected to an ONAP internal network **MUST NOT**
use the port
for the purpose of reaching VMs in another VNF and/or an
external gateway and/or
external router.
.. req::
:id: R-16241
:target: VNF
:keyword: MUST
:validation_mode: static
:updated: frankfurt
A VNF's ONAP internal network **MUST** have one subnet.
A VNF's ONAP internal network **MAY** have more than one subnet.
.. req::
:id: R-86972
:target: VNF
:keyword: SHOULD
:updated: casablanca
A VNF **SHOULD** create the ONAP internal network in the VNF's Heat
Orchestration Template's Base Module.
.. req::
:id: R-22688
:target: VNF
:keyword: MUST
:validation_mode: static
:updated: frankfurt
When a VNF's Heat Orchestration Template creates an ONAP internal network
(per the ONAP definition, see Requirements R-52425 and R-46461
and R-35666) and the ONAP internal network needs to be shared between
modules within a VNF, the ONAP
internal network **MUST** be created either in the
* the base module
* a nested YAML file invoked by the base module
and the base module **MUST** contain an output parameter that provides
either the network UUID or network name.
* If the network UUID value is used to reference the network, the output
parameter name in the base module **MUST** follow the naming convention
``int_{network-role}_net_id``
* If the network name in is used to reference the network, the output
parameter name in the base template **MUST** follow the naming convention
``int_{network-role}_net_name``
The ``{network-role}`` **MUST** be the network-role of the ONAP
internal network created in the Base Module.
The Base Module Output Parameter MUST be declared in the ``parameters:``
section of the Incremental Module(s) where the ``OS::Neutron::Port``
resource(s) is attaching to the ONAP internal network.
ONAP does not programmatically enforce a naming convention for
parameters for internal network. However, a naming convention is
provided that must be followed.
:ref:`ONAP Heat Resource ID and Parameter Naming Convention`
provides additional details.
|
