summaryrefslogtreecommitdiffstats
path: root/docs/requirements/use_cases/shared_service_functions.rst
blob: 3d370c00d4beb31329bfab6de6595b6dcee84907 (plain)
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
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. http://creativecommons.org/licenses/by/4.0
.. (c) Georg Kunz


Shared Service Functions
------------------------

Description
^^^^^^^^^^^

This use case aims at binding multiple networks or network services to a single
vNIC (port) of a given VM. There are several specific application scenarios for
this use case:

* Shared Service Functions: A service function connects to multiple (tenant)
  networks by means of a single vNIC.

  Typically, a vNIC is bound to a single (tenant) network. Hence, in order to
  directly connect a service function to multiple (tenant) networks at the same
  time, multiple vNICs are needed - each vNIC binding the service function to a
  separate network. For service functions requiring connectivity to a large
  number of networks, this approach does not scale as the number of vNICs per VM
  is limited and additional vNICs occupy additional resources on the hypervisor.

  A more scalable approach is to bind multiple networks to a single vNIC
  and let the service function, which is now shared among multiple networks,
  handle the separation of traffic itself.


* Multiple network services: A service function connects to multiple different
  network types such as a L2 network, a L3(-VPN) network, a SFC domain or
  services such as DHCP, IPv6 NDP, firewall/security, etc.


In order to achieve a flexible binding of multiple services to vNICs, a logical
separation between a vNIC (instance port) - that is, the entity that is used by
the compute service as hand-off point between the network and the VM - and a
service interface - that is, the interface a service binds to - is needed.

Furthermore, binding network services to service interfaces instead of to the
vNIC directly enables a more dynamic management of the network connectivity of
network functions as there is no need to add or remove vNICs.


Requirements
^^^^^^^^^^^^

Northbound API
""""""""""""""

The API has to cover the following functionality:

* management of instance ports

* management of service ports

* binding of services to service ports


Data models
"""""""""""

TBD


Orchestration
"""""""""""""

None.


Dependencies on other resources
"""""""""""""""""""""""""""""""

The compute service needs to be enabled to consume instance ports instead of
classic Neutron ports.


Implementation Proposal
^^^^^^^^^^^^^^^^^^^^^^^

TBD