summaryrefslogtreecommitdiffstats
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
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>
-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