From 0a9106c39f131a1d2952e1187ee1d1924d84e1f6 Mon Sep 17 00:00:00 2001 From: Manuel Buil <mbuil@suse.com> Date: Mon, 21 Aug 2017 15:54:29 +0200 Subject: Added new fdio scenarios descriptions As part of MS6 we must have an updated directory structure. I added the two new scenarios using fdio Change-Id: If74dade8c75c59d452b034b98fff5dc0791b2191 Signed-off-by: Manuel Buil <mbuil@suse.com> --- docs/release/scenarios/os-odl-sfc-ha/index.rst | 18 +++ .../os-odl-sfc-ha/scenario.description.rst | 120 ++++++++++++++++++++ docs/release/scenarios/os-odl-sfc-noha/index.rst | 18 +++ .../os-odl-sfc-noha/scenario.description.rst | 123 +++++++++++++++++++++ .../release/scenarios/os-odl-sfc_fdio-ha/index.rst | 18 +++ .../os-odl-sfc_fdio-ha/scenario.description.rst | 97 ++++++++++++++++ .../scenarios/os-odl-sfc_fdio-noha/index.rst | 18 +++ .../os-odl-sfc_fdio-noha/scenario.description.rst | 101 +++++++++++++++++ docs/release/scenarios/os-odl_l2-sfc-ha/index.rst | 18 --- .../os-odl_l2-sfc-ha/scenario.description.rst | 121 -------------------- .../release/scenarios/os-odl_l2-sfc-noha/index.rst | 18 --- .../os-odl_l2-sfc-noha/scenario.description.rst | 123 --------------------- 12 files changed, 513 insertions(+), 280 deletions(-) create mode 100644 docs/release/scenarios/os-odl-sfc-ha/index.rst create mode 100644 docs/release/scenarios/os-odl-sfc-ha/scenario.description.rst create mode 100644 docs/release/scenarios/os-odl-sfc-noha/index.rst create mode 100644 docs/release/scenarios/os-odl-sfc-noha/scenario.description.rst create mode 100644 docs/release/scenarios/os-odl-sfc_fdio-ha/index.rst create mode 100644 docs/release/scenarios/os-odl-sfc_fdio-ha/scenario.description.rst create mode 100644 docs/release/scenarios/os-odl-sfc_fdio-noha/index.rst create mode 100644 docs/release/scenarios/os-odl-sfc_fdio-noha/scenario.description.rst delete mode 100644 docs/release/scenarios/os-odl_l2-sfc-ha/index.rst delete mode 100644 docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst delete mode 100644 docs/release/scenarios/os-odl_l2-sfc-noha/index.rst delete mode 100644 docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst (limited to 'docs') diff --git a/docs/release/scenarios/os-odl-sfc-ha/index.rst b/docs/release/scenarios/os-odl-sfc-ha/index.rst new file mode 100644 index 00000000..d979a95c --- /dev/null +++ b/docs/release/scenarios/os-odl-sfc-ha/index.rst @@ -0,0 +1,18 @@ +.. _os-odl-sfc-ha: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) <optionally add copywriters name> + +========================================= +os-odl-sfc-ha overview and description +========================================= +.. This document will be used to provide a description of the scenario for an end user. +.. You should explain the purpose of the scenario, the types of capabilities provided and +.. the unique components that make up the scenario including how they are used. + +.. toctree:: + :maxdepth: 3 + + ./scenario.description.rst + diff --git a/docs/release/scenarios/os-odl-sfc-ha/scenario.description.rst b/docs/release/scenarios/os-odl-sfc-ha/scenario.description.rst new file mode 100644 index 00000000..249b0bd7 --- /dev/null +++ b/docs/release/scenarios/os-odl-sfc-ha/scenario.description.rst @@ -0,0 +1,120 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) <optionally add copywriters name> + +Introduction +============ +.. In this section explain the purpose of the scenario and the types of capabilities provided + +The os-odl-sfc-ha is intended to be used to install the OPNFV SFC project in a standard +OPNFV High Availability mode. The OPNFV SFC project integrates the OpenDaylight SFC project +into the OPNFV environment. The OPNFV SFC Euphrates release uses the OpenDaylight Nitrogen SR1 release. + +Scenario components and composition +=================================== +.. In this section describe the unique components that make up the scenario, +.. what each component provides and why it has been included in order +.. to communicate to the user the capabilities available in this scenario. + +This scenario installs everything needed to use the SFC OpenDaylight project in an OPNFV +environment. The classifier used in this scenario is implemented by the Netvirt OpenDaylight +project. + +Following is a detailed list of what is included with this scenario: + +OpenDaylight features installed +------------------------------- + +The OpenDaylight SDN controller is installed in the controller node. + +The following are the SFC features that get installed: + +- odl-sfc-model +- odl-sfc-provider +- odl-sfc-provider-rest +- odl-sfc-ovs +- odl-sfc-openflow-renderer + +The following are the Netvirt features that get installed: + +- odl-netvirt-openstack +- odl-sfc-genius +- odl-neutron-service +- odl-neutron-northbound-api +- odl-neutron-spi +- odl-neutron-transcriber +- odl-ovsdb-southbound-impl-api +- odl-ovsdb-southbound-impl-impl +- odl-ovsdb-library + +By simply installing the odl-netvirt-sfc feature, all the dependant features +will automatically be installed. + +The VNF Manager +--------------- + +In order to create a VM for each Service Function, a VNF Manager is needed. The OPNFV +SFC project currently uses the Tacker OpenStack project as a VNF Manager. Tacker is +installed on the controller node and manages VNF life cycle, and coordinates VM creation +and SFC configuration with OpenStack and OpenDaylight SFC project. + +Scenario usage overview +======================= +.. Provide a brief overview on how to use the scenario and the features available to the +.. user. This should be an "introduction" to the userguide document, and explicitly link to it, +.. where the specifics of the features are covered including examples and API's + +Once this scenario is installed, it will be possible to create Service Chains and +classification entries to map tenant traffic to individual, pre-defined Service Chains. +All configuration can be performed using the Tacker CLI. + +Limitations, Issues and Workarounds +=================================== +.. Explain scenario limitations here, this should be at a design level rather than discussing +.. faults or bugs. If the system design only provide some expected functionality then provide +.. some insight at this point. + +The *client* virtual machine needs to be located in a compute node where at least +one of the service functions (SFs) is placed. This is due to a limitation in OpenDaylight, +Nitrogen, which only installs the traffic classifier in the compute nodes where the SFs are. + +Specific version of OVS +----------------------- + +SFC needs changes in OVS to include the Network Service Headers (NSH) Service Chaining +encapsulation. This OVS patch has been ongoing for quite a while (2 years+), and still +has not been officially merged. Previously, SFC used NSH from a branched version of OVS +based on 2.3.90, called the "Pritesh Patch". In the OpenDaylight Nitrogen SR1 release, SFC was +changed to use a newer, branched version of OVS based on 2.6.1, called the "Yi Yang +Patch". + +The older version of OVS only supported VXLAN-GPE + NSH encapsulation, but the newer +version supports both ETH + NSH and VXLAN-GPE + ETH + NSH. Currently SFC is only +implemented with VXLAN-GPE + ETH + NSH. + +Workaround for VXLAN and OpenStack +---------------------------------- + +When using NSH with VXLAN tunnels, its important that the VXLAN tunnel is terminated +in the SF VM. This allows the SF to see the NSH header, allowing it to decrement the +NSI and also to use the NSH metadata. When using VXLAN with OpenStack, the tunnels +are not terminated in the SF VM, but in the “br-int” OVS bridge. A work-around has +been created to address this issue, which can be found here: + +http://artifacts.opnfv.org/sfc/danube/docs/design/architecture.html#ovs-nsh-patch-workaround + +In subsequent versions of SFC, we will change the SFF-SF transport to be ETH + NSH, +which will obviate this work around. + +References +========== + +For more information about SFC, please visit: + +https://wiki.opnfv.org/display/sfc/Service+Function+Chaining+Home + +https://wiki.opendaylight.org/view/Service_Function_Chaining:Main + +For more information on the OPNFV Euphrates release, please visit: + +http://www.opnfv.org/euphrates diff --git a/docs/release/scenarios/os-odl-sfc-noha/index.rst b/docs/release/scenarios/os-odl-sfc-noha/index.rst new file mode 100644 index 00000000..e416ca86 --- /dev/null +++ b/docs/release/scenarios/os-odl-sfc-noha/index.rst @@ -0,0 +1,18 @@ +.. _os-odl-sfc-noha: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) <optionally add copywriters name> + +=========================================== +os-odl-sfc-noha overview and description +=========================================== +.. This document will be used to provide a description of the scenario for an end user. +.. You should explain the purpose of the scenario, the types of capabilities provided and +.. the unique components that make up the scenario including how they are used. + +.. toctree:: + :maxdepth: 3 + + ./scenario.description.rst + diff --git a/docs/release/scenarios/os-odl-sfc-noha/scenario.description.rst b/docs/release/scenarios/os-odl-sfc-noha/scenario.description.rst new file mode 100644 index 00000000..691c0931 --- /dev/null +++ b/docs/release/scenarios/os-odl-sfc-noha/scenario.description.rst @@ -0,0 +1,123 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) <optionally add copywriters name> + +Introduction +============ +.. In this section explain the purpose of the scenario and the types of capabilities provided + +The os-odl-sfc-noha is intended to be used to install the OPNFV SFC project in a standard +OPNFV Non-High Availability mode. The OPNFV SFC project integrates the OpenDaylight SFC +project into the OPNFV environment. The OPNFV SFC Euphrates release uses the OpenDaylight +Nitrogen SR1 release. + +Scenario components and composition +=================================== +.. In this section describe the unique components that make up the scenario, +.. what each component provides and why it has been included in order +.. to communicate to the user the capabilities available in this scenario. + +This scenario installs everything needed to use the SFC OpenDaylight project in an OPNFV +environment. Since this scenario is Non-High Availability, then only one controller and +one compute node will be deployed. The classifier used in this scenario is implemented +by the Netvirt OpenDaylight project. + +Following is a detailed list of what is included with this scenario: + +OpenDaylight features installed +------------------------------- + +The OpenDaylight SDN controller is installed in the controller node. + +The following are the SFC features that get installed: + +- odl-sfc-model +- odl-sfc-provider +- odl-sfc-provider-rest +- odl-sfc-ovs +- odl-sfc-openflow-renderer + +The following are the Netvirt features that get installed: + +- odl-netvirt-openstack +- odl-sfc-genius +- odl-neutron-service +- odl-neutron-northbound-api +- odl-neutron-spi +- odl-neutron-transcriber +- odl-ovsdb-southbound-impl-api +- odl-ovsdb-southbound-impl-impl +- odl-ovsdb-library + +By simply installing the odl-netvirt-sfc feature, all the dependant features +will automatically be installed. + +The VNF Manager +--------------- + +In order to create a VM for each Service Function, a VNF Manager is needed. The OPNFV +SFC project currently uses the Tacker OpenStack project as a VNF Manager. Tacker is +installed on the controller node and manages VNF life cycle, and coordinates VM creation +with the OpenDaylight SFC project. + +Scenario usage overview +======================= +.. Provide a brief overview on how to use the scenario and the features available to the +.. user. This should be an "introduction" to the userguide document, and explicitly link to it, +.. where the specifics of the features are covered including examples and API's + +Once this scenario is installed, it will be possible to create Service Chains and +classification entries to map tenant traffic to individual, pre-defined Service Chains. +All configuration can be performed using the Tacker CLI. + +Limitations, Issues and Workarounds +=================================== +.. Explain scenario limitations here, this should be at a design level rather than discussing +.. faults or bugs. If the system design only provide some expected functionality then provide +.. some insight at this point. + +The *client* virtual machine needs to be located in a compute node where at least +one of the service functions (SFs) is placed. This is due to a limitation in OpenDaylight, +Nitrogen, which only installs the traffic classifier in the compute nodes where the SFs are. + +Specific version of OVS +----------------------- + +SFC needs changes in OVS to include the Network Service Headers (NSH) Service Chaining +encapsulation. This OVS patch has been ongoing for quite a while (2 years+), and still +has not been officially merged. Previously, SFC used NSH from a branched version of OVS +based on 2.3.90, called the "Pritesh Patch". In the OpenDaylight Nitrogen SR1 release, SFC was +changed to use a newer, branched version of OVS based on 2.6.1, called the "Yi Yang +Patch". + +The older version of OVS only supported VXLAN-GPE + NSH encapsulation, but the newer +version supports both ETH + NSH and VXLAN-GPE + ETH + NSH. Currently SFC is only +implemented with VXLAN-GPE + ETH + NSH. + +Workaround for VXLAN and OpenStack +---------------------------------- + +When using NSH with VXLAN tunnels, its important that the VXLAN tunnel is terminated +in the SF VM. This allows the SF to see the NSH header, allowing it to decrement the +NSI and also to use the NSH metadata. When using VXLAN with OpenStack, the tunnels +are not terminated in the SF VM, but in the “br-int” OVS bridge. A work-around has +been created to address this issue, which can be found here: + +http://artifacts.opnfv.org/sfc/danube/docs/design/architecture.html#ovs-nsh-patch-workaround + +In subsequent versions of SFC, we will change the SFF-SF transport to be ETH + NSH, +which will obviate this work around. + +References +========== + +For more information about SFC, please visit: + +https://wiki.opnfv.org/display/sfc/Service+Function+Chaining+Home + +https://wiki.opendaylight.org/view/Service_Function_Chaining:Main + +For more information on the OPNFV Euphrates release, please visit: + +http://www.opnfv.org/euphrates + diff --git a/docs/release/scenarios/os-odl-sfc_fdio-ha/index.rst b/docs/release/scenarios/os-odl-sfc_fdio-ha/index.rst new file mode 100644 index 00000000..28413b2e --- /dev/null +++ b/docs/release/scenarios/os-odl-sfc_fdio-ha/index.rst @@ -0,0 +1,18 @@ +.. _os-odl-sfc_fdio-ha: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) <optionally add copywriters name> + +========================================= +os-odl-sfc_fdio-ha overview and description +========================================= +.. This document will be used to provide a description of the scenario for an end user. +.. You should explain the purpose of the scenario, the types of capabilities provided and +.. the unique components that make up the scenario including how they are used. + +.. toctree:: + :maxdepth: 3 + + ./scenario.description.rst + diff --git a/docs/release/scenarios/os-odl-sfc_fdio-ha/scenario.description.rst b/docs/release/scenarios/os-odl-sfc_fdio-ha/scenario.description.rst new file mode 100644 index 00000000..39efcacd --- /dev/null +++ b/docs/release/scenarios/os-odl-sfc_fdio-ha/scenario.description.rst @@ -0,0 +1,97 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) <optionally add copywriters name> + +Introduction +============ +.. In this section explain the purpose of the scenario and the types of capabilities provided + +The os-odl-sfc_fdio-ha is intended to be used to install the OPNFV SFC project in a standard +OPNFV High Availability mode. The OPNFV SFC project integrates the OpenDaylight SFC project +into the OPNFV environment. The OPNFV SFC Euphrates release uses the OpenDaylight Nitrogen SR1 release. + +Scenario components and composition +=================================== +.. In this section describe the unique components that make up the scenario, +.. what each component provides and why it has been included in order +.. to communicate to the user the capabilities available in this scenario. + +This scenario installs everything needed to use the SFC OpenDaylight project in an OPNFV +environment. The classifier used in this scenario is implemented by the Netvirt OpenDaylight +project. + +Following is a detailed list of what is included with this scenario: + +OpenDaylight features installed +------------------------------- + +The OpenDaylight SDN controller is installed in the controller node. + +The following are the SFC features that get installed: + +- odl-sfc-model +- odl-sfc-provider +- odl-sfc-provider-rest +- odl-sfc-ovs +- odl-sfc-openflow-renderer + +The following are the Netvirt features that get installed: + +- odl-netvirt-openstack +- odl-sfc-genius +- odl-neutron-service +- odl-neutron-northbound-api +- odl-neutron-spi +- odl-neutron-transcriber +- odl-ovsdb-southbound-impl-api +- odl-ovsdb-southbound-impl-impl +- odl-ovsdb-library + +By simply installing the odl-netvirt-sfc feature, all the dependant features +will automatically be installed. + +The VNF Manager +--------------- + +In order to create a VM for each Service Function, a VNF Manager is needed. The OPNFV +SFC project currently uses the Tacker OpenStack project as a VNF Manager. Tacker is +installed on the controller node and manages VNF life cycle, and coordinates VM creation +and SFC configuration with OpenStack and OpenDaylight SFC project. + +Scenario usage overview +======================= +.. Provide a brief overview on how to use the scenario and the features available to the +.. user. This should be an "introduction" to the userguide document, and explicitly link to it, +.. where the specifics of the features are covered including examples and API's + +Once this scenario is installed, it will be possible to create Service Chains and +classification entries to map tenant traffic to individual, pre-defined Service Chains. +All configuration can be performed using the Tacker CLI. + +Limitations, Issues and Workarounds +=================================== +.. Explain scenario limitations here, this should be at a design level rather than discussing +.. faults or bugs. If the system design only provide some expected functionality then provide +.. some insight at this point. + +The *client* virtual machine needs to be located in a compute node where at least +one of the service functions (SFs) is placed. This is due to a limitation in OpenDaylight, +Nitrogen, which only installs the traffic classifier in the compute nodes where the SFs are. + +Specific version of FD.IO +----------------------- + +TO BE ADDED + +References +========== + +For more information about SFC, please visit: + +https://wiki.opnfv.org/display/sfc/Service+Function+Chaining+Home + +https://wiki.opendaylight.org/view/Service_Function_Chaining:Main + +For more information on the OPNFV Euphrates release, please visit: + +http://www.opnfv.org/euphrates diff --git a/docs/release/scenarios/os-odl-sfc_fdio-noha/index.rst b/docs/release/scenarios/os-odl-sfc_fdio-noha/index.rst new file mode 100644 index 00000000..a77bc4c5 --- /dev/null +++ b/docs/release/scenarios/os-odl-sfc_fdio-noha/index.rst @@ -0,0 +1,18 @@ +.. _os-odl-sfc_fdio-noha: + +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) <optionally add copywriters name> + +=========================================== +os-odl-sfc_fdio-noha overview and description +=========================================== +.. This document will be used to provide a description of the scenario for an end user. +.. You should explain the purpose of the scenario, the types of capabilities provided and +.. the unique components that make up the scenario including how they are used. + +.. toctree:: + :maxdepth: 3 + + ./scenario.description.rst + diff --git a/docs/release/scenarios/os-odl-sfc_fdio-noha/scenario.description.rst b/docs/release/scenarios/os-odl-sfc_fdio-noha/scenario.description.rst new file mode 100644 index 00000000..6ef8c4ba --- /dev/null +++ b/docs/release/scenarios/os-odl-sfc_fdio-noha/scenario.description.rst @@ -0,0 +1,101 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) <optionally add copywriters name> + +Introduction +============ +.. In this section explain the purpose of the scenario and the types of capabilities provided + +The os-odl-sfc_fdio-noha is intended to be used to install the OPNFV SFC project in a standard +OPNFV Non-High Availability mode. The OPNFV SFC project integrates the OpenDaylight SFC +project into the OPNFV environment. The OPNFV SFC Euphrates release uses the OpenDaylight +Nitrogen SR1 release. + +Scenario components and composition +=================================== +.. In this section describe the unique components that make up the scenario, +.. what each component provides and why it has been included in order +.. to communicate to the user the capabilities available in this scenario. + +This scenario installs everything needed to use the SFC OpenDaylight project in an OPNFV +environment. Since this scenario is Non-High Availability, then only one controller and +one compute node will be deployed. The classifier used in this scenario is implemented +by the Netvirt OpenDaylight project. + +Following is a detailed list of what is included with this scenario: + +OpenDaylight features installed +------------------------------- + +The OpenDaylight SDN controller is installed in the controller node. + +The following are the SFC features that get installed: + +- odl-sfc-model +- odl-sfc-provider +- odl-sfc-provider-rest +- odl-sfc-ovs +- odl-sfc-openflow-renderer + +The following are the Netvirt features that get installed: + +- odl-netvirt-openstack +- odl-sfc-genius +- odl-neutron-service +- odl-neutron-northbound-api +- odl-neutron-spi +- odl-neutron-transcriber +- odl-ovsdb-southbound-impl-api +- odl-ovsdb-southbound-impl-impl +- odl-ovsdb-library + +By simply installing the odl-netvirt-sfc feature, all the dependant features +will automatically be installed. + +The VNF Manager +--------------- + +In order to create a VM for each Service Function, a VNF Manager is needed. The OPNFV +SFC project currently uses the Tacker OpenStack project as a VNF Manager. Tacker is +installed on the controller node and manages VNF life cycle, and coordinates VM creation +with the OpenDaylight SFC project. + +Scenario usage overview +======================= +.. Provide a brief overview on how to use the scenario and the features available to the +.. user. This should be an "introduction" to the userguide document, and explicitly link to it, +.. where the specifics of the features are covered including examples and API's + +Once this scenario is installed, it will be possible to create Service Chains and +classification entries to map tenant traffic to individual, pre-defined Service Chains. +All configuration can be performed using the Tacker CLI. + +Limitations, Issues and Workarounds +=================================== +.. Explain scenario limitations here, this should be at a design level rather than discussing +.. faults or bugs. If the system design only provide some expected functionality then provide +.. some insight at this point. + +The *client* virtual machine needs to be located in a compute node where at least +one of the service functions (SFs) is placed. This is due to a limitation in OpenDaylight, +Nitrogen, which only installs the traffic classifier in the compute nodes where the SFs are. + +Specific version of FD.IO +----------------------- + +TO BE ADDED + + +References +========== + +For more information about SFC, please visit: + +https://wiki.opnfv.org/display/sfc/Service+Function+Chaining+Home + +https://wiki.opendaylight.org/view/Service_Function_Chaining:Main + +For more information on the OPNFV Euphrates release, please visit: + +http://www.opnfv.org/euphrates + diff --git a/docs/release/scenarios/os-odl_l2-sfc-ha/index.rst b/docs/release/scenarios/os-odl_l2-sfc-ha/index.rst deleted file mode 100644 index 00d414a6..00000000 --- a/docs/release/scenarios/os-odl_l2-sfc-ha/index.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. _os-odl_l2-sfc-ha: - -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) <optionally add copywriters name> - -========================================= -os-odl_l2-sfc-ha overview and description -========================================= -.. This document will be used to provide a description of the scenario for an end user. -.. You should explain the purpose of the scenario, the types of capabilities provided and -.. the unique components that make up the scenario including how they are used. - -.. toctree:: - :maxdepth: 3 - - ./scenario.description.rst - diff --git a/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst b/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst deleted file mode 100644 index 881ca967..00000000 --- a/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst +++ /dev/null @@ -1,121 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) <optionally add copywriters name> - -Introduction -============ -.. In this section explain the purpose of the scenario and the types of capabilities provided - -The os-odl_l2-sfc-ha is intended to be used to install the OPNFV SFC project in a standard -OPNFV High Availability mode. The OPNFV SFC project integrates the OpenDaylight SFC project -into the OPNFV environment. The OPNFV SFC Danube release uses the OpenDaylight Boron SR2 release. - -Scenario components and composition -=================================== -.. In this section describe the unique components that make up the scenario, -.. what each component provides and why it has been included in order -.. to communicate to the user the capabilities available in this scenario. - -This scenario installs everything needed to use the SFC OpenDaylight project in an OPNFV -environment. The classifier used in this scenario is implemented by the Netvirt OpenDaylight -project. - -Following is a detailed list of what is included with this scenario: - -OpenDaylight features installed -------------------------------- - -The OpenDaylight SDN controller is installed in the controller node. - -The following are the SFC features that get installed: - -- odl-sfc-model -- odl-sfc-provider -- odl-sfc-provider-rest -- odl-sfc-ovs -- odl-sfc-openflow-renderer - -The following are the Netvirt features that get installed: - -- odl-ovsdb-openstack -- odl-mdsal-xsql -- odl-neutron-service -- odl-neutron-northbound-api -- odl-neutron-spi -- odl-neutron-transcriber -- odl-mdsal-apidocs -- odl-ovsdb-southbound-impl-rest -- odl-ovsdb-southbound-impl-ui - -By simply installing the odl-ovsdb-openstack feature, all the dependant features -will automatically be installed. - -The VNF Manager ---------------- - -In order to create a VM for each Service Function, a VNF Manager is needed. The OPNFV -SFC project currently uses the Tacker OpenStack project as a VNF Manager. Tacker is -installed on the controller node and manages VNF life cycle, and coordinates VM creation -with the OpenDaylight SFC project. - -Scenario usage overview -======================= -.. Provide a brief overview on how to use the scenario and the features available to the -.. user. This should be an "introduction" to the userguide document, and explicitly link to it, -.. where the specifics of the features are covered including examples and API's - -Once this scenario is installed, it will be possible to create Service Chains and -classification entries to map tenant traffic to individual, pre-defined Service Chains. -All configuration can be performed using the Tacker CLI. - -Limitations, Issues and Workarounds -=================================== -.. Explain scenario limitations here, this should be at a design level rather than discussing -.. faults or bugs. If the system design only provide some expected functionality then provide -.. some insight at this point. - -The *client* virtual machine needs to be located in a compute node where at least -one of the service functions (SFs) is placed. This is due to a limitation in OpenDaylight, -Boron, which only installs the traffic classifier in the compute nodes where the SFs are. - -Specific version of OVS ------------------------ - -SFC needs changes in OVS to include the Network Service Headers (NSH) Service Chaining -encapsulation. This OVS patch has been ongoing for quite a while (2 years+), and still -has not been officially merged. Previously, SFC used NSH from a branched version of OVS -based on 2.3.90, called the "Pritesh Patch". In the OpenDaylight Boron SR2 release, SFC was -changed to use a newer, branched version of OVS based on 2.6.1, called the "Yi Yang -Patch". - -The older version of OVS only supported VXLAN-GPE + NSH encapsulation, but the newer -version supports both ETH + NSH and VXLAN-GPE + ETH + NSH. Currently SFC is only -implemented with VXLAN-GPE + ETH + NSH. - -Workaround for VXLAN and OpenStack ----------------------------------- - -When using NSH with VXLAN tunnels, its important that the VXLAN tunnel is terminated -in the SF VM. This allows the SF to see the NSH header, allowing it to decrement the -NSI and also to use the NSH metadata. When using VXLAN with OpenStack, the tunnels -are not terminated in the SF VM, but in the “br-int” OVS bridge. A work-around has -been created to address this issue, which can be found here: - -http://artifacts.opnfv.org/sfc/danube/docs/design/architecture.html#ovs-nsh-patch-workaround - -In subsequent versions of SFC, we will change the SFF-SF transport to be ETH + NSH, -which will obviate this work around. - -References -========== - -For more information about SFC, please visit: - -https://wiki.opnfv.org/display/sfc/Service+Function+Chaining+Home - -https://wiki.opendaylight.org/view/Service_Function_Chaining:Main - -For more information on the OPNFV Danube release, please visit: - -http://www.opnfv.org/danube - diff --git a/docs/release/scenarios/os-odl_l2-sfc-noha/index.rst b/docs/release/scenarios/os-odl_l2-sfc-noha/index.rst deleted file mode 100644 index ba55ab5f..00000000 --- a/docs/release/scenarios/os-odl_l2-sfc-noha/index.rst +++ /dev/null @@ -1,18 +0,0 @@ -.. _os-odl_l2-sfc-noha: - -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) <optionally add copywriters name> - -=========================================== -os-odl_l2-sfc-noha overview and description -=========================================== -.. This document will be used to provide a description of the scenario for an end user. -.. You should explain the purpose of the scenario, the types of capabilities provided and -.. the unique components that make up the scenario including how they are used. - -.. toctree:: - :maxdepth: 3 - - ./scenario.description.rst - diff --git a/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst b/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst deleted file mode 100644 index 74d386b0..00000000 --- a/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst +++ /dev/null @@ -1,123 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) <optionally add copywriters name> - -Introduction -============ -.. In this section explain the purpose of the scenario and the types of capabilities provided - -The os-odl_l2-sfc-noha is intended to be used to install the OPNFV SFC project in a standard -OPNFV Non-High Availability mode. The OPNFV SFC project integrates the OpenDaylight SFC -project into the OPNFV environment. The OPNFV SFC Danube release uses the OpenDaylight -Boron SR2 release. - -Scenario components and composition -=================================== -.. In this section describe the unique components that make up the scenario, -.. what each component provides and why it has been included in order -.. to communicate to the user the capabilities available in this scenario. - -This scenario installs everything needed to use the SFC OpenDaylight project in an OPNFV -environment. Since this scenario is Non-High Availability, then only one controller and -one compute node will be deployed. The classifier used in this scenario is implemented -by the Netvirt OpenDaylight project. - -Following is a detailed list of what is included with this scenario: - -OpenDaylight features installed -------------------------------- - -The OpenDaylight SDN controller is installed in the controller node. - -The following are the SFC features that get installed: - -- odl-sfc-model -- odl-sfc-provider -- odl-sfc-provider-rest -- odl-sfc-ovs -- odl-sfc-openflow-renderer - -The following are the Netvirt features that get installed: - -- odl-ovsdb-openstack -- odl-mdsal-xsql -- odl-neutron-service -- odl-neutron-northbound-api -- odl-neutron-spi -- odl-neutron-transcriber -- odl-mdsal-apidocs -- odl-ovsdb-southbound-impl-rest -- odl-ovsdb-southbound-impl-ui - -By simply installing the odl-ovsdb-openstack feature, all the dependant features -will automatically be installed. - -The VNF Manager ---------------- - -In order to create a VM for each Service Function, a VNF Manager is needed. The OPNFV -SFC project currently uses the Tacker OpenStack project as a VNF Manager. Tacker is -installed on the controller node and manages VNF life cycle, and coordinates VM creation -with the OpenDaylight SFC project. - -Scenario usage overview -======================= -.. Provide a brief overview on how to use the scenario and the features available to the -.. user. This should be an "introduction" to the userguide document, and explicitly link to it, -.. where the specifics of the features are covered including examples and API's - -Once this scenario is installed, it will be possible to create Service Chains and -classification entries to map tenant traffic to individual, pre-defined Service Chains. -All configuration can be performed using the Tacker CLI. - -Limitations, Issues and Workarounds -=================================== -.. Explain scenario limitations here, this should be at a design level rather than discussing -.. faults or bugs. If the system design only provide some expected functionality then provide -.. some insight at this point. - -The *client* virtual machine needs to be located in a compute node where at least -one of the service functions (SFs) is placed. This is due to a limitation in OpenDaylight, -Boron, which only installs the traffic classifier in the compute nodes where the SFs are. - -Specific version of OVS ------------------------ - -SFC needs changes in OVS to include the Network Service Headers (NSH) Service Chaining -encapsulation. This OVS patch has been ongoing for quite a while (2 years+), and still -has not been officially merged. Previously, SFC used NSH from a branched version of OVS -based on 2.3.90, called the "Pritesh Patch". In the OpenDaylight Boron SR2 release, SFC was -changed to use a newer, branched version of OVS based on 2.6.1, called the "Yi Yang -Patch". - -The older version of OVS only supported VXLAN-GPE + NSH encapsulation, but the newer -version supports both ETH + NSH and VXLAN-GPE + ETH + NSH. Currently SFC is only -implemented with VXLAN-GPE + ETH + NSH. - -Workaround for VXLAN and OpenStack ----------------------------------- - -When using NSH with VXLAN tunnels, its important that the VXLAN tunnel is terminated -in the SF VM. This allows the SF to see the NSH header, allowing it to decrement the -NSI and also to use the NSH metadata. When using VXLAN with OpenStack, the tunnels -are not terminated in the SF VM, but in the “br-int” OVS bridge. A work-around has -been created to address this issue, which can be found here: - -http://artifacts.opnfv.org/sfc/danube/docs/design/architecture.html#ovs-nsh-patch-workaround - -In subsequent versions of SFC, we will change the SFF-SF transport to be ETH + NSH, -which will obviate this work around. - -References -========== - -For more information about SFC, please visit: - -https://wiki.opnfv.org/display/sfc/Service+Function+Chaining+Home - -https://wiki.opendaylight.org/view/Service_Function_Chaining:Main - -For more information on the OPNFV Danube release, please visit: - -http://www.opnfv.org/danube - -- cgit