summaryrefslogtreecommitdiffstats
path: root/docs/requirements/use_cases
diff options
context:
space:
mode:
authorGeorg Kunz <georg.kunz@ericsson.com>2016-07-12 15:50:32 +0200
committerGerrit Code Review <gerrit@172.30.200.206>2016-07-14 15:11:20 +0000
commitb71d64b9375bea76cc07b4cb24d22b94a9bc9da0 (patch)
tree7f21a0b4d9d06d7939ea8ffdf142a67bfc9d207f /docs/requirements/use_cases
parent44e1e451cfe474e628bba4c470c54c2de33e5732 (diff)
Renamed and extended port abstraction model
The former port abstraction use case has been rename (again) to better highlight that it represents a design pattern for APIs and data models. In line with this, the text has been extended. Change-Id: I49c3f153dc7b75b000acacd8436b41d9d1219e2a Signed-off-by: Georg Kunz <georg.kunz@ericsson.com>
Diffstat (limited to 'docs/requirements/use_cases')
-rw-r--r--docs/requirements/use_cases/service-binding-pattern.rst (renamed from docs/requirements/use_cases/port_abstraction.rst)75
1 files changed, 67 insertions, 8 deletions
diff --git a/docs/requirements/use_cases/port_abstraction.rst b/docs/requirements/use_cases/service-binding-pattern.rst
index 8f6e791..5b288bd 100644
--- a/docs/requirements/use_cases/port_abstraction.rst
+++ b/docs/requirements/use_cases/service-binding-pattern.rst
@@ -3,8 +3,8 @@
.. (c) Georg Kunz
-Port Abstraction
-----------------
+Service Binding Design Pattern
+------------------------------
Description
^^^^^^^^^^^
@@ -49,7 +49,13 @@ Requirements
Data model
""""""""""
-The envisioned data model of the port abstraction model is as follows:
+This section describes a general concept for a data model and a corresponding
+API. It is not intended that these entities are to be implemented exactly as
+described. Instead, they are meant to show a design pattern for future network
+service models and their corresponding APIs. For example, the "service" entity
+should hold all required attributes for a specific service, for instance a given
+L3VPN service. Hence, there would be no entity "service" but rather "L3VPN".
+
* ``instance-port``
@@ -63,7 +69,7 @@ The envisioned data model of the port abstraction model is as follows:
* ``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.
+ build hierarchies 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.
@@ -98,7 +104,10 @@ The envisioned data model of the port abstraction model is as follows:
Northbound API
""""""""""""""
-The API for manipulating the data model is as follows:
+An exemplary API for manipulating the data model is described below. As for the
+data model, this API is not intended to be a concrete API, but rather an example
+for a design pattern that clearly separates ports from services and service
+bindings.
* ``instance-port-{create,delete} <name>``
@@ -134,7 +143,57 @@ The compute service needs to be enabled to consume instance ports instead of
classic Neutron ports.
-Implementation Proposal
-^^^^^^^^^^^^^^^^^^^^^^^
+Current Implementation
+^^^^^^^^^^^^^^^^^^^^^^
+
+The core Neutron API [**describe what is meant by that**] does not follow the
+service binding design pattern. For example, a port has to exist in a Neutron
+network - specifically it has to be created for a particular Neutron network. It
+is not possible to create just a port and assign it to a network later on as
+needed. As a result, a port cannot be moved from one network to another, for
+instance.
+
+Regarding the shared service function use case outlined above, there is an
+ongoing activity in Neutron [VLAN-AWARE-VMs]_. The solution proposed by this
+activity allows for creating a trunk-port and multiple sub-ports per Neutron
+port which can be bound to multiple networks (one network per sub-port). This
+allows for binding a single VNIC to multiple networks and allow the
+corresponding VMs to handle the network segmentation (VLAN tagged traffic)
+itself. While this is a step in the direction of binding multiple services
+(networks) to a port, it is limited by the fundamental assumption of Neutron
+that a port has to exist on a given network.
+
+There are extensions of Neutron that follow the service binding design pattern
+more closely. An example is the BGPVPN project. A rough mapping of the service
+binding design pattern to the data model of the BGPVPN project is as follows:
+
+* instance-port -> Neutron port
+
+* service -> VPN
+
+* service-port -> network association
+
+This example shows that extensions of Neutron can in fact follow the described
+design pattern in their respective data model and APIs.
+
+
+
+Conclusions
+^^^^^^^^^^^
+
+In conclusion, the design decisions taken for the core Neutron API and data
+model do not follow the service binding model. As a result, it is hard to
+implement certain use cases which rely on a flexible binding of services to
+ports. Due to the backwards compatibility to the large amount of existing
+Neutron code, it is unlikely that the core Neutron API will adapt to this design
+pattern.
+
+New extension to Neutron however are relatively free to choose their data model
+and API - within the architectural boundaries of Neutron of course. In order to
+provide the flexibility needed, extensions shall aim for following the service
+binding design pattern if possible.
+
+For the same reason, new networking frameworks complementing Neutron, such as
+Gluon, shall follow this design pattern and create the foundation for
+implementing networking services accordingly.
-TBD