summaryrefslogtreecommitdiffstats
path: root/docs
diff options
context:
space:
mode:
authorGeorg Kunz <georg.kunz@ericsson.com>2016-06-06 22:33:19 +0200
committerGerrit Code Review <gerrit@172.30.200.206>2016-06-17 15:11:47 +0000
commita6bdd13709870b864d57454200798a3a028012fa (patch)
tree3b6d007d2e77972cc7518123b55ee678a1e5672c /docs
parent673bf398bf6bf74f40aa8a41d8aa25e265fab9de (diff)
Data model and NB API for shared service function use case
The use case has been renamed from "shared service functions" to "port abstraction" Change-Id: I1b5ec4b97af434814b88b824d02e98d46fd1979f Signed-off-by: Georg Kunz <georg.kunz@ericsson.com>
Diffstat (limited to 'docs')
-rw-r--r--docs/requirements/use_cases.rst2
-rw-r--r--docs/requirements/use_cases/port_abstraction.rst140
-rw-r--r--docs/requirements/use_cases/shared_service_functions.rst83
3 files changed, 141 insertions, 84 deletions
diff --git a/docs/requirements/use_cases.rst b/docs/requirements/use_cases.rst
index e4fc7d7..0488d69 100644
--- a/docs/requirements/use_cases.rst
+++ b/docs/requirements/use_cases.rst
@@ -8,7 +8,7 @@ The following sections address networking use cases that have been identified to
.. toctree::
use_cases/l3vpn.rst
- use_cases/shared_service_functions.rst
+ use_cases/port_abstraction.rst
use_cases/programmable_provisioning.rst
use_cases/georedundancy_cells.rst
use_cases/georedundancy_regions_insances.rst
diff --git a/docs/requirements/use_cases/port_abstraction.rst b/docs/requirements/use_cases/port_abstraction.rst
new file mode 100644
index 0000000..8f6e791
--- /dev/null
+++ b/docs/requirements/use_cases/port_abstraction.rst
@@ -0,0 +1,140 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) Georg Kunz
+
+
+Port Abstraction
+----------------
+
+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 networks of
+ a tenant by means of a single vNIC.
+
+ Typically, a vNIC is bound to a single network. Hence, in order to directly
+ connect a service function to multiple 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, IPAM, 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
+^^^^^^^^^^^^
+
+Data model
+""""""""""
+
+The envisioned data model of the port abstraction model is as follows:
+
+* ``instance-port``
+
+ An instance port object represents a vNIC which is bindable to an OpenStack
+ instance by the compute service (Nova).
+
+ *Attributes:* Since an instance-port is a layer 2 device, its attributes
+ include the MAC address, MTU and others (TBD).
+
+
+* ``interface``
+
+ An interface object is a logical abstraction of an instance-port. It allows to
+ build hierachies of interfaces by means of a reference to a parent interface.
+ Each interface represents a subset of the packets traversing a given port or
+ parent interface after applying a layer 2 segmentation mechanism specific to the
+ interface type.
+
+ *Attributes:* The attributes are specific to the type of interface.
+
+ *Examples:* trunk interface, VLAN interface, VxLAN interface, MPLS interface
+
+
+* ``service``
+
+ A service object represents a specific networking service.
+
+ *Attributes:* The attributes of the service objects are service specific and
+ valid for given service instance.
+
+ *Examples:* L2, L3VPN, SFC
+
+
+* ``service-port``
+
+ A service port object binds an interface to a service.
+
+ *Attributes:* The attributes of a service-port are specific for the bound
+ service.
+
+ *Examples:* port services (IPAM, DHCP, security), L2 interfaces, L3VPN
+ interfaces, SFC interfaces.
+
+
+
+Northbound API
+""""""""""""""
+
+The API for manipulating the data model is as follows:
+
+* ``instance-port-{create,delete} <name>``
+
+ Creates or deletes an instance port object that represents a vNIC in a VM.
+
+
+* ``interface-{create,delete} <name> [interface type specific parameters]``
+
+ Creates or deletes an interface object.
+
+
+* ``service-{create,delete} <name> [service specific parameters]``
+
+ Create a specific service object, for instance a L3VPN, a SFC domain, or a L2 network.
+
+
+* ``service-port-{create,delete} <service-id> <interface-id> [service specific parameters]``
+
+ Creates a service port object, thereby binding an interface to a given service.
+
+
+
+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
diff --git a/docs/requirements/use_cases/shared_service_functions.rst b/docs/requirements/use_cases/shared_service_functions.rst
deleted file mode 100644
index 3d370c0..0000000
--- a/docs/requirements/use_cases/shared_service_functions.rst
+++ /dev/null
@@ -1,83 +0,0 @@
-.. 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