From c43b4b3554b695ba7c32afceb8d34ee57472680d Mon Sep 17 00:00:00 2001 From: Georg Kunz Date: Thu, 5 May 2016 23:48:39 +0200 Subject: Added use case Shared service functions Change-Id: Id06570995c112bda391689f80265d596c4ac43fa Signed-off-by: Georg Kunz --- .../use_cases/shared-service-functions.rst | 48 +++++++++++++++++++--- 1 file changed, 42 insertions(+), 6 deletions(-) (limited to 'docs/requirements/use_cases') diff --git a/docs/requirements/use_cases/shared-service-functions.rst b/docs/requirements/use_cases/shared-service-functions.rst index 12b2f5c..3d370c0 100644 --- a/docs/requirements/use_cases/shared-service-functions.rst +++ b/docs/requirements/use_cases/shared-service-functions.rst @@ -6,21 +6,56 @@ Shared Service Functions ------------------------ - Description ^^^^^^^^^^^ -TBD +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 """""""""""""" -TBD +The API has to cover the following functionality: + +* management of instance ports + +* management of service ports + +* binding of services to service ports Data models @@ -32,13 +67,14 @@ TBD Orchestration """"""""""""" -TBD +None. Dependencies on other resources """"""""""""""""""""""""""""""" -TBD +The compute service needs to be enabled to consume instance ports instead of +classic Neutron ports. Implementation Proposal -- cgit 1.2.3-korg