From e3448d10dcd973e60b6b2819bbc2dba8455b9c11 Mon Sep 17 00:00:00 2001 From: Georg Kunz Date: Fri, 22 Jul 2016 17:38:22 +0200 Subject: Incorporating further review comments Change-Id: I65fa2036f32c018c3d9cda46a82c6f1e2d4e6323 Signed-off-by: Georg Kunz --- docs/requirements/index.rst | 2 +- docs/requirements/introduction.rst | 19 +- docs/requirements/use_cases.rst | 2 +- docs/requirements/use_cases/l3vpn_ecmp.rst | 7 +- .../requirements/use_cases/l3vpn_hub_and_spoke.rst | 12 +- .../use_cases/programmable_provisioning.rst | 28 +-- .../use_cases/service-binding-pattern.rst | 199 --------------------- .../use_cases/service_binding_pattern.rst | 198 ++++++++++++++++++++ 8 files changed, 237 insertions(+), 230 deletions(-) delete mode 100644 docs/requirements/use_cases/service-binding-pattern.rst create mode 100644 docs/requirements/use_cases/service_binding_pattern.rst (limited to 'docs') diff --git a/docs/requirements/index.rst b/docs/requirements/index.rst index db6fb4a..f375bd7 100644 --- a/docs/requirements/index.rst +++ b/docs/requirements/index.rst @@ -12,7 +12,7 @@ NetReady: Network Readiness :Abstract: OPNFV provides an infrastructure with different SDN controller options to realize NFV functionality on the platform it builds. As - OPNFV uses OpenStack as VIM, we need to analyze the capabilities this + OPNFV uses OpenStack as a VIM, we need to analyze the capabilities this component offers us. The networking functionality is provided by a single component called Neutron, which hides the controller under it, let it be Neutron itself or any supported SDN controller. As NFV diff --git a/docs/requirements/introduction.rst b/docs/requirements/introduction.rst index f502a70..0593e07 100644 --- a/docs/requirements/introduction.rst +++ b/docs/requirements/introduction.rst @@ -6,10 +6,10 @@ Introduction This document represents and describes the results of the OPNFV NetReady (Network Readiness) project. Specifically, the document comprises a selection of -NFV-related networking use cases and their networking requirements, a -corresponding gap analysis of the aforementioned requirements with respect to -the current OpenStack networking architecture and a description of potential -solutions and improvements. +NFV-related networking use cases and their networking requirements. For every +use case, it furthermore presents a gap analysis of the aforementioned +requirements with respect to the current OpenStack networking architecture. +Finally it provides a description of potential solutions and improvements. Scope @@ -29,11 +29,12 @@ solutions. Problem Description ------------------- -Telco ecosystem's movement toward cloud domain results in Network Function Virtualization -that is discussed and specified in ETSI NFV. This movement opens up many green field -areas which are full of potentials of growth in both business and technology. This new -NFV domain brings new business opportunities and new market segments as well as emerging -technologies that are exploratory and experimental in nature, especially in NFV networking. +Telco ecosystem's movement towards the cloud domain results in Network Function +Virtualization that is discussed and specified in ETSI NFV. This movement opens +up many green field areas which are full of potential growth in both business +and technology. This new NFV domain brings new business opportunities and new +market segments as well as emerging technologies that are exploratory and +experimental in nature, especially in NFV networking. It is often stated that NFV imposes additional requirements on the networking architecture and feature set of the underlying NFVI beyond those of data center diff --git a/docs/requirements/use_cases.rst b/docs/requirements/use_cases.rst index a8356ea..d31bbd3 100644 --- a/docs/requirements/use_cases.rst +++ b/docs/requirements/use_cases.rst @@ -9,6 +9,6 @@ The following sections address networking use cases that have been identified to .. toctree:: use_cases/multiple_backends.rst use_cases/l3vpn.rst - use_cases/service-binding-pattern.rst + use_cases/service_binding_pattern.rst use_cases/programmable_provisioning.rst use_cases/georedundancy.rst diff --git a/docs/requirements/use_cases/l3vpn_ecmp.rst b/docs/requirements/use_cases/l3vpn_ecmp.rst index b3d5b63..7bcb64f 100644 --- a/docs/requirements/use_cases/l3vpn_ecmp.rst +++ b/docs/requirements/use_cases/l3vpn_ecmp.rst @@ -31,15 +31,16 @@ subnet 10.1.1.0/24 and assigned the same IP addresses 10.1.1.5. VNF 2 and VNF 3 on host A and B respectively, attached to subnet 10.1.1.0/24, and assigned different IP addresses 10.1.1.6 and 10.1.1.3 respectively. -Here, the Network VRF Policy Resource is ``ECMP/AnyCast``. Traffic to **Anycast 10.1.1.5** -can be load split from either WAN GW or another VM like G5. +Here, the Network VRF Policy Resource is ``ECMP/AnyCast``. Traffic to the +anycast IP **10.1.1.5** can be load split from either WAN GW or another VM like +G5. Current implementation ~~~~~~~~~~~~~~~~~~~~~~ -Support for creating and managing L3VPNs is in general available in OpenStack +Support for creating and managing L3VPNs is, in general, available in OpenStack Neutron by means of the BGPVPN project [BGPVPN]_. However, the BGPVPN project does not yet fully support ECMP as described in the following. diff --git a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst index 07004ef..17459b6 100644 --- a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst +++ b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst @@ -8,12 +8,12 @@ Hub and Spoke Case Description ~~~~~~~~~~~ -A Hub-and-spoke topology comprises two types of network entities: a central hub -and multiple spokes. The corresponding VRFs of the hub and the spokes are -configured to import and export routes such that all traffic is routed through -the hub. As a result, spokes cannot communicate with each other directly, but -only indirectly via the central hub. Hence, the hub typically hosts central network -functions such firewalls. +In a traditional Hub-and-spoke topology there are two types of network entities: +a central hub and multiple spokes. The corresponding VRFs of the hub and the +spokes are configured to import and export routes such that all traffic is +directed through the hub. As a result, spokes cannot communicate with each other +directly, but only indirectly via the central hub. Hence, the hub typically +hosts central network functions such firewalls. Furthermore, there is no layer 2 connectivity between the VNFs. diff --git a/docs/requirements/use_cases/programmable_provisioning.rst b/docs/requirements/use_cases/programmable_provisioning.rst index 8d143f3..d66a54c 100644 --- a/docs/requirements/use_cases/programmable_provisioning.rst +++ b/docs/requirements/use_cases/programmable_provisioning.rst @@ -1,24 +1,27 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 -Programmable Provisioning of Provider networks +Programmable Provisioning of Provider Networks ---------------------------------------------- Description ~~~~~~~~~~~ -In NFV environment the VNFM (consumer of OpenStack IaaS API) have no -administrative rights, however in the telco domain provider networks are used in -some cases. When a provider network is created administrative rights are needed -what in the case of a VNFM without administrative rights needs manual work. -It shall be possible to configure provider networks without administrative rights. -It should be possible to assign the capability to create provider networks to -any roles. + +In a NFV environment the VNFMs (Virtual Network Function Manager) are consumers +of the OpenStack IaaS API. They are often deployed without administrative rights +on top of the NFVI platform. Furthermore, in the telco domain provider networks +are often used. However, when a provider network is created administrative +rights are needed what in the case of a VNFM without administrative rights +requires additional manual configuration work. It shall be possible to +configure provider networks without administrative rights. It should be +possible to assign the capability to create provider networks to any roles. + Derived Requirements ~~~~~~~~~~~~~~~~~~~~~ - Authorize the possibility of provider network creation based on policy - There should be a new entry in :code:`policy.json` which controls the provider network creation - Default policy of this new entry should be :code:`rule:admin_or_owner`. - - This policy should be respected by neutron API + - This policy should be respected by the Neutron API Northbound API / Workflow +++++++++++++++++++++++++ @@ -34,5 +37,8 @@ Only admin users can manage provider networks [OS-NETWORKING-GUIDE-ML2]_. Potential implementation ~~~~~~~~~~~~~~~~~~~~~~~~ - - Policy engine shall be able to handle a new provider network creation and modification related policy - - When a provider network is created or modified neutron should check the authority with the policy engine instead of requesting administrative rights + - Policy engine shall be able to handle a new provider network creation and + modification related policy. + - When a provider network is created or modified neutron should check the + authority with the policy engine instead of requesting administrative + rights. diff --git a/docs/requirements/use_cases/service-binding-pattern.rst b/docs/requirements/use_cases/service-binding-pattern.rst deleted file mode 100644 index a5088a3..0000000 --- a/docs/requirements/use_cases/service-binding-pattern.rst +++ /dev/null @@ -1,199 +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 - - -Service Binding Design Pattern ------------------------------- - -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 -"""""""""" - -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`` - - 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. - - -* ``interface`` - - An interface object is a logical abstraction of an instance-port. It allows to - 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. - - *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 -"""""""""""""" - -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} `` - - Creates or deletes an instance port object that represents a vNIC in a VM. - - -* ``interface-{create,delete} [interface type specific parameters]`` - - Creates or deletes an interface object. - - -* ``service-{create,delete} [service specific parameters]`` - - Create a specific service object, for instance a L3VPN, a SFC domain, or a L2 network. - - -* ``service-port-{create,delete} [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. - - -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. - diff --git a/docs/requirements/use_cases/service_binding_pattern.rst b/docs/requirements/use_cases/service_binding_pattern.rst new file mode 100644 index 0000000..8abcf7a --- /dev/null +++ b/docs/requirements/use_cases/service_binding_pattern.rst @@ -0,0 +1,198 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Georg Kunz + + +Service Binding Design Pattern +------------------------------ + +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 binds 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 +"""""""""" + +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`` + + 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. + + +* ``interface`` + + An interface object is a logical abstraction of an instance-port. It allows to + 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. + + *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 +"""""""""""""" + +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} `` + + Creates or deletes an instance port object that represents a vNIC in a VM. + + +* ``interface-{create,delete} [interface type specific parameters]`` + + Creates or deletes an interface object. + + +* ``service-{create,delete} [service specific parameters]`` + + Create a specific service object, for instance a L3VPN, a SFC domain, or a L2 network. + + +* ``service-port-{create,delete} [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. + + +Current Implementation +^^^^^^^^^^^^^^^^^^^^^^ + +The core Neutron API 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. + -- cgit 1.2.3-korg