From 065fba5bef236f992bd5e4122e635bb21d525af9 Mon Sep 17 00:00:00 2001 From: Brady Johnson Date: Fri, 10 Feb 2017 13:01:52 +0100 Subject: Migrate docs to the new Danube dir structure Change-Id: I6bdfd21add4d04f0fee988f83888c1edcc488951 Signed-off-by: Brady Johnson --- docs/configguide/featureconfig.rst | 24 -- docs/configguide/postinstall.rst | 26 --- docs/design/architecture.rst | 129 ----------- docs/design/definitions.rst | 64 ------ ...PNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg | Bin 81908 -> 0 bytes .../OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg | Bin 85995 -> 0 bytes .../images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg | Bin 52507 -> 0 bytes .../images/OPNFV_SFC_Brahmaputra_SfCreation.jpg | Bin 59088 -> 0 bytes .../images/OPNFV_SFC_Brahmaputra_UseCase.jpg | Bin 52526 -> 0 bytes docs/design/index.rst | 16 -- docs/design/introduction.rst | 10 - docs/design/requirements.rst | 40 ---- docs/design/usecases.rst | 16 -- docs/development/design/architecture.rst | 129 +++++++++++ docs/development/design/definitions.rst | 64 ++++++ ...PNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg | Bin 0 -> 81908 bytes .../OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg | Bin 0 -> 85995 bytes .../images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg | Bin 0 -> 52507 bytes .../images/OPNFV_SFC_Brahmaputra_SfCreation.jpg | Bin 0 -> 59088 bytes .../images/OPNFV_SFC_Brahmaputra_UseCase.jpg | Bin 0 -> 52526 bytes docs/development/design/index.rst | 16 ++ docs/development/design/introduction.rst | 10 + docs/development/design/requirements.rst | 40 ++++ docs/development/design/usecases.rst | 16 ++ .../feature.configuration.rst | 256 --------------------- docs/installationprocedure/index.rst | 13 -- docs/release/configguide/featureconfig.rst | 24 ++ docs/release/configguide/postinstall.rst | 26 +++ .../release/installation/feature.configuration.rst | 256 +++++++++++++++++++++ docs/release/installation/index.rst | 13 ++ docs/release/release-notes/index.rst | 13 ++ docs/release/release-notes/releasenotes.rst | 204 ++++++++++++++++ docs/release/scenarios/os-odl_l2-sfc-ha/index.rst | 16 ++ .../os-odl_l2-sfc-ha/scenario.description.rst | 118 ++++++++++ .../release/scenarios/os-odl_l2-sfc-noha/index.rst | 16 ++ .../os-odl_l2-sfc-noha/scenario.description.rst | 118 ++++++++++ docs/release/userguide/feature.userguide.rst | 50 ++++ docs/release/userguide/index.rst | 13 ++ docs/releasenotes/index.rst | 13 -- docs/releasenotes/releasenotes.rst | 204 ---------------- docs/scenarios/os-odl_l2-sfc-ha/index.rst | 16 -- .../os-odl_l2-sfc-ha/scenario.description.rst | 118 ---------- docs/scenarios/os-odl_l2-sfc-noha/index.rst | 16 -- .../os-odl_l2-sfc-noha/scenario.description.rst | 118 ---------- docs/userguide/feature.userguide.rst | 50 ---- docs/userguide/index.rst | 13 -- 46 files changed, 1142 insertions(+), 1142 deletions(-) delete mode 100644 docs/configguide/featureconfig.rst delete mode 100644 docs/configguide/postinstall.rst delete mode 100644 docs/design/architecture.rst delete mode 100644 docs/design/definitions.rst delete mode 100644 docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg delete mode 100644 docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg delete mode 100644 docs/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg delete mode 100644 docs/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg delete mode 100644 docs/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg delete mode 100644 docs/design/index.rst delete mode 100644 docs/design/introduction.rst delete mode 100644 docs/design/requirements.rst delete mode 100644 docs/design/usecases.rst create mode 100644 docs/development/design/architecture.rst create mode 100644 docs/development/design/definitions.rst create mode 100644 docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg create mode 100644 docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg create mode 100644 docs/development/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg create mode 100644 docs/development/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg create mode 100644 docs/development/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg create mode 100644 docs/development/design/index.rst create mode 100644 docs/development/design/introduction.rst create mode 100644 docs/development/design/requirements.rst create mode 100644 docs/development/design/usecases.rst delete mode 100644 docs/installationprocedure/feature.configuration.rst delete mode 100644 docs/installationprocedure/index.rst create mode 100644 docs/release/configguide/featureconfig.rst create mode 100644 docs/release/configguide/postinstall.rst create mode 100644 docs/release/installation/feature.configuration.rst create mode 100644 docs/release/installation/index.rst create mode 100644 docs/release/release-notes/index.rst create mode 100644 docs/release/release-notes/releasenotes.rst create mode 100644 docs/release/scenarios/os-odl_l2-sfc-ha/index.rst create mode 100644 docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst create mode 100644 docs/release/scenarios/os-odl_l2-sfc-noha/index.rst create mode 100644 docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst create mode 100644 docs/release/userguide/feature.userguide.rst create mode 100644 docs/release/userguide/index.rst delete mode 100644 docs/releasenotes/index.rst delete mode 100644 docs/releasenotes/releasenotes.rst delete mode 100644 docs/scenarios/os-odl_l2-sfc-ha/index.rst delete mode 100644 docs/scenarios/os-odl_l2-sfc-ha/scenario.description.rst delete mode 100644 docs/scenarios/os-odl_l2-sfc-noha/index.rst delete mode 100644 docs/scenarios/os-odl_l2-sfc-noha/scenario.description.rst delete mode 100644 docs/userguide/feature.userguide.rst delete mode 100644 docs/userguide/index.rst (limited to 'docs') diff --git a/docs/configguide/featureconfig.rst b/docs/configguide/featureconfig.rst deleted file mode 100644 index 9189902c..00000000 --- a/docs/configguide/featureconfig.rst +++ /dev/null @@ -1,24 +0,0 @@ - configuration -======================= -Add a brief introduction to configure OPNFV with this specific feature including -dependancies on platform components, this description should be at a level that -will apply to any installer providing the pre-requisite components. - -Pre-configuration activities ----------------------------- -Describe specific pre-configuration activities. This should include ensuring the -right components are installed by the installation tools as required for your -feature to function. Refer to the previous installer configuration chapters, -installations guide and release notes - -Hardware configuration ----------------------- -Describe the hardware configuration needed for this specific feature - -Feature configuration ---------------------- -Describe the procedures to configure your feature on the platform in order -that it is ready to use according to the feature instructions in the platform -user guide. Where applicable you should add content in the postinstall.rst -to validate the feature is configured for use. -(checking components are installed correctly etc...) diff --git a/docs/configguide/postinstall.rst b/docs/configguide/postinstall.rst deleted file mode 100644 index 1702cea5..00000000 --- a/docs/configguide/postinstall.rst +++ /dev/null @@ -1,26 +0,0 @@ - post installation procedures -====================================== -Add a brief introduction to the methods of validating the installation -according to this specific installer or feature. - -Automated post installation activities --------------------------------------- -Describe specific post installation activities performed by the OPNFV -deployment pipeline including testing activities and reports. Refer to -the relevant testing guides, results, and release notes. - -note: this section should be singular and derived from the test projects -once we have one test suite to run for all deploy tools. This is not the -case yet so each deploy tool will need to provide (hopefully very simillar) -documentation of this. - - post configuration procedures --------------------------------------- -Describe any deploy tool or feature specific scripts, tests or procedures -that should be carried out on the deployment post install and configuration -in this section. - -Platform components validation ---------------------------------- -Describe any component specific validation procedures necessary for your -deployment tool in this section. diff --git a/docs/design/architecture.rst b/docs/design/architecture.rst deleted file mode 100644 index 679bb2f9..00000000 --- a/docs/design/architecture.rst +++ /dev/null @@ -1,129 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - -Architecture ------------- - -This section describes the architectural approach to incorporating the upstream -OpenDaylight (ODL) SFC project into the OPNFV Colorado platform. - -Service Functions -+++++++++++++++++ - -A Service Function (SF) is a Function that provides services to flows traversing -a Service Chain. Examples of typical SFs include: Firewall, NAT, QoS, and DPI. -In the context of OPNFV, the SF will be a Virtual Network Function. The SFs -receive data packets from a Service Function Forwarder. - -Service Function Forwarders -+++++++++++++++++++++++++++ - -The Service Function Forwarder (SFF) is the core element used in Service -Chaining. It is an OpenFlow switch that, in the context of OPNFV, is hosted -in an OVS bridge. In OPNFV there will be one SFF per Compute Node that will -be hosted in the "br-int" OpenStack OVS bridge. - -The responsibility of the SFF is to steer incoming packets to the corresponding -Service Function, or to the SFF in the next compute node. The flows in the SFF -are programmed by the OpenDaylight SFC SDN Controller. - -Service Chains -++++++++++++++ - -Service Chains are defined in the OpenDaylight SFC Controller using the -following constructs: - -SFC - A Service Function Chain (SFC) is an ordered list of abstract SF types. - -SFP - A Service Function Path (SFP) references an SFC, and optionally provides - concrete information about the SFC, like concrete SF instances. If SF - instances are not supplied, then the RSP will choose them. - -RSP - A Rendered Service Path (RSP) is the actual Service Chain. An RSP references - an SFP, and effectively merges the information from the SFP and SFC to create - the Service Chain. If concrete SF details were not provided in the SFP, then - SF selection algorithms are used to choose one. When the RSP is created, the - OpenFlows will be programmed and written to the SFF(s). - -Service Chaining Encapsulation -++++++++++++++++++++++++++++++ - -Service Chaining Encapsulation encapsulates traffic sent through the Service -Chaining domain to facilitate easier steering of packets through Service Chains. -If no Service Chaining Encapsulation is used, then packets much be classified -at every hop of the chain, which would be slow and would not scale well. - -In ODL SFC, Network Service Headers (NSH) is used for Service Chaining -encapsulation. NSH is an IETF specification that uses 2 main header -fields to facilitate packet steering, namely: - -NSP (NSH Path) - The NSP is the Service Path ID. - -NSI (NSH Index) - The NSI is the Hop in the Service Chain. The NSI starts at 255 and is - decremented by every SF. If the NSI reaches 0, then the packet is dropped - which avoids loop detections. - -NSH also has metadata fields, but that's beyond the scope of this architecture. - -In ODL SFC, NSH packets are encapsulated in VXLAN-GPE. - -Classifiers -+++++++++++ - -A classifier is the entry point into Service Chaining. The role of the -classifier is to map incoming traffic to Service Chains. In ODL SFC, this -mapping is performed by matching the packets and encapsulating the packets in -a VXLAN-GPE NSH tunnel. - -The packet matching is specific to the classifier implementation, but can be -as simple as an ACL, or can be more complex by using PCRF information or DPI. - -VNF Manager -+++++++++++ - -In OPNFV SFC, a VNF Manager is needed to spin-up VMs for Service Functions. -It has been decided to use the OpenStack Tacker VNF Mgr to spin-up and manage -the life cylcle of the SFs. Tacker will receive the ODL SFC configuration, -manage the SF VMs, and forward the configuration to ODL SFC. The following -sequence diagram details the interactions with the VNF Mgr: - -.. image:: ./images/OPNFV_SFC_Brahmaputra_SfCreation.jpg - -OPNFV SFC Network Topology -++++++++++++++++++++++++++ - -The following image details the Network Topology used in OPNFV Colorado SFC: - -.. image:: ./images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg - - -OVS NSH patch workaround -++++++++++++++++++++++++ - -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 VM, but in the "br-int" OVS -bridge. There is work ongoing in the upstream OVS community to implemement NSH -encapsulation. To get around the way OpenStack handles VXLAN tunnels, the OVS -work will also include the ability to encapsulate/decapsulate VXLAN tunnels from -OpenFlow rules, instead of relying on the Vtep ports. The ongoing upstream OVS -work will not be finished by the time OPNFV Colorado is released, so -a work-around has been created. This work-around will use a private branch of -OVS that has a preliminary version of NSH implemented. - -The following diagram illustrates how packets will be sent to an SF, when the -SFF has processed the packet and wants to send it to the SF: - -.. image:: ./images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg - -The following diagram illustrates how packets will sent from an SF to an SFF, -once the SF has processed a packet: - -.. image:: ./images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg - diff --git a/docs/design/definitions.rst b/docs/design/definitions.rst deleted file mode 100644 index 85416fb8..00000000 --- a/docs/design/definitions.rst +++ /dev/null @@ -1,64 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - -Definitions ------------ - -Definitions of most terms used here are provided in the `IETF SFC Architecture RFC `_. -Additional terms specific to the OPNFV SFC project are defined below. - - -Abbreviations -------------- - -.. list-table:: Abbreviations - :widths: 15 85 - :header-rows: 1 - - * - Abbreviation - - Term - - * - NS - - Network Service - - * - NFVO - - Network Function Virtualization Orchestrator - - * - NF - - Network Function - - * - NSH - - Network Services Header (Service chaining encapsulation) - - * - ODL - - OpenDaylight SDN Controller - - * - RSP - - Rendered Service Path - - * - SDN - - Software Defined Networking - - * - SF - - Service Function - - * - SFC - - Service Function Chain(ing) - - * - SFF - - Service Function Forwarder - - * - SFP - - Service Function Path - - * - VNF - - Virtual Network Function - - * - VNFM - - Virtual Network Function Manager - - * - VNF-FG - - Virtual Network Function Forwarding Graph - - * - VIM - - Virtual Infrastructure Manager diff --git a/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg b/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg deleted file mode 100644 index 1b542888..00000000 Binary files a/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg and /dev/null differ diff --git a/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg b/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg deleted file mode 100644 index 11eaf87b..00000000 Binary files a/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg and /dev/null differ diff --git a/docs/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg b/docs/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg deleted file mode 100644 index c183486e..00000000 Binary files a/docs/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg and /dev/null differ diff --git a/docs/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg b/docs/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg deleted file mode 100644 index 345317dd..00000000 Binary files a/docs/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg and /dev/null differ diff --git a/docs/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg b/docs/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg deleted file mode 100644 index efc0df33..00000000 Binary files a/docs/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg and /dev/null differ diff --git a/docs/design/index.rst b/docs/design/index.rst deleted file mode 100644 index f13d575b..00000000 --- a/docs/design/index.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - -******************************* -Service Function Chaining (SFC) -******************************* - -.. toctree:: - :numbered: - :maxdepth: 2 - - introduction.rst - definitions.rst - usecases.rst - architecture.rst - requirements.rst diff --git a/docs/design/introduction.rst b/docs/design/introduction.rst deleted file mode 100644 index f7b7df76..00000000 --- a/docs/design/introduction.rst +++ /dev/null @@ -1,10 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - -Introduction ------------- - -The `OPNFV Service Function Chaining (SFC) `_ -project aims to provide the ability to define an ordered list of a network services (e.g. firewalls, NAT, QoS). -These service are then "stitched" together in the network to create a service chain. -This project provides the infrastructure to install the upstream ODL SFC implementation project in an NFV environment. diff --git a/docs/design/requirements.rst b/docs/design/requirements.rst deleted file mode 100644 index 1c15a9b9..00000000 --- a/docs/design/requirements.rst +++ /dev/null @@ -1,40 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - -Requirements ------------- - -This section defines requirements for the initial OPNFV SFC implementation, -including those requirements driving upstream project enhancements. - -Minimal Viable Requirement -++++++++++++++++++++++++++ - -Deploy a complete SFC solution by integrating OpenDaylight SFC with OpenStack -in an OPNFV environment. - -Detailed Requirements -+++++++++++++++++++++ - -These are the Colorado specific requirements: - -1 The supported Service Chaining encapsulation will be NSH VXLAN-GPE. - -2 The version of OVS used must support NSH. - -3 The SF VM life cycle will be managed by the Tacker VNF Mgr. - -4 The supported classifiers will be either ODL Netvirt or ODL GBP. - -5 ODL will be the OpenStack Neutron backend and will handle all networking - on the compute nodes. - -Long Term Requirements -++++++++++++++++++++++ - -These requirements are out of the scope of the Colorado release. - -1 Dynamic movement of SFs across multiple Compute nodes. - -2 Load Balancing across multiple SFs - diff --git a/docs/design/usecases.rst b/docs/design/usecases.rst deleted file mode 100644 index 23e94417..00000000 --- a/docs/design/usecases.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - -Use Cases ---------- - -This section outlines the Colorado use cases driving the initial OPNFV -SFC implementation. - -The use cases targeted in the OPNFV SFC Colorado release focus on creating -simple Service Chains using Firewall Service Functions. As can be seen in the -following diagram, 2 service chains are created, each through a different -Service Function Firewall. Service Chain 1 will block HTTP, while Service -Chain 2 will block SSH. - -.. image:: ./images/OPNFV_SFC_Brahmaputra_UseCase.jpg diff --git a/docs/development/design/architecture.rst b/docs/development/design/architecture.rst new file mode 100644 index 00000000..679bb2f9 --- /dev/null +++ b/docs/development/design/architecture.rst @@ -0,0 +1,129 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +Architecture +------------ + +This section describes the architectural approach to incorporating the upstream +OpenDaylight (ODL) SFC project into the OPNFV Colorado platform. + +Service Functions ++++++++++++++++++ + +A Service Function (SF) is a Function that provides services to flows traversing +a Service Chain. Examples of typical SFs include: Firewall, NAT, QoS, and DPI. +In the context of OPNFV, the SF will be a Virtual Network Function. The SFs +receive data packets from a Service Function Forwarder. + +Service Function Forwarders ++++++++++++++++++++++++++++ + +The Service Function Forwarder (SFF) is the core element used in Service +Chaining. It is an OpenFlow switch that, in the context of OPNFV, is hosted +in an OVS bridge. In OPNFV there will be one SFF per Compute Node that will +be hosted in the "br-int" OpenStack OVS bridge. + +The responsibility of the SFF is to steer incoming packets to the corresponding +Service Function, or to the SFF in the next compute node. The flows in the SFF +are programmed by the OpenDaylight SFC SDN Controller. + +Service Chains +++++++++++++++ + +Service Chains are defined in the OpenDaylight SFC Controller using the +following constructs: + +SFC + A Service Function Chain (SFC) is an ordered list of abstract SF types. + +SFP + A Service Function Path (SFP) references an SFC, and optionally provides + concrete information about the SFC, like concrete SF instances. If SF + instances are not supplied, then the RSP will choose them. + +RSP + A Rendered Service Path (RSP) is the actual Service Chain. An RSP references + an SFP, and effectively merges the information from the SFP and SFC to create + the Service Chain. If concrete SF details were not provided in the SFP, then + SF selection algorithms are used to choose one. When the RSP is created, the + OpenFlows will be programmed and written to the SFF(s). + +Service Chaining Encapsulation +++++++++++++++++++++++++++++++ + +Service Chaining Encapsulation encapsulates traffic sent through the Service +Chaining domain to facilitate easier steering of packets through Service Chains. +If no Service Chaining Encapsulation is used, then packets much be classified +at every hop of the chain, which would be slow and would not scale well. + +In ODL SFC, Network Service Headers (NSH) is used for Service Chaining +encapsulation. NSH is an IETF specification that uses 2 main header +fields to facilitate packet steering, namely: + +NSP (NSH Path) + The NSP is the Service Path ID. + +NSI (NSH Index) + The NSI is the Hop in the Service Chain. The NSI starts at 255 and is + decremented by every SF. If the NSI reaches 0, then the packet is dropped + which avoids loop detections. + +NSH also has metadata fields, but that's beyond the scope of this architecture. + +In ODL SFC, NSH packets are encapsulated in VXLAN-GPE. + +Classifiers ++++++++++++ + +A classifier is the entry point into Service Chaining. The role of the +classifier is to map incoming traffic to Service Chains. In ODL SFC, this +mapping is performed by matching the packets and encapsulating the packets in +a VXLAN-GPE NSH tunnel. + +The packet matching is specific to the classifier implementation, but can be +as simple as an ACL, or can be more complex by using PCRF information or DPI. + +VNF Manager ++++++++++++ + +In OPNFV SFC, a VNF Manager is needed to spin-up VMs for Service Functions. +It has been decided to use the OpenStack Tacker VNF Mgr to spin-up and manage +the life cylcle of the SFs. Tacker will receive the ODL SFC configuration, +manage the SF VMs, and forward the configuration to ODL SFC. The following +sequence diagram details the interactions with the VNF Mgr: + +.. image:: ./images/OPNFV_SFC_Brahmaputra_SfCreation.jpg + +OPNFV SFC Network Topology +++++++++++++++++++++++++++ + +The following image details the Network Topology used in OPNFV Colorado SFC: + +.. image:: ./images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg + + +OVS NSH patch workaround +++++++++++++++++++++++++ + +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 VM, but in the "br-int" OVS +bridge. There is work ongoing in the upstream OVS community to implemement NSH +encapsulation. To get around the way OpenStack handles VXLAN tunnels, the OVS +work will also include the ability to encapsulate/decapsulate VXLAN tunnels from +OpenFlow rules, instead of relying on the Vtep ports. The ongoing upstream OVS +work will not be finished by the time OPNFV Colorado is released, so +a work-around has been created. This work-around will use a private branch of +OVS that has a preliminary version of NSH implemented. + +The following diagram illustrates how packets will be sent to an SF, when the +SFF has processed the packet and wants to send it to the SF: + +.. image:: ./images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg + +The following diagram illustrates how packets will sent from an SF to an SFF, +once the SF has processed a packet: + +.. image:: ./images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg + diff --git a/docs/development/design/definitions.rst b/docs/development/design/definitions.rst new file mode 100644 index 00000000..85416fb8 --- /dev/null +++ b/docs/development/design/definitions.rst @@ -0,0 +1,64 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +Definitions +----------- + +Definitions of most terms used here are provided in the `IETF SFC Architecture RFC `_. +Additional terms specific to the OPNFV SFC project are defined below. + + +Abbreviations +------------- + +.. list-table:: Abbreviations + :widths: 15 85 + :header-rows: 1 + + * - Abbreviation + - Term + + * - NS + - Network Service + + * - NFVO + - Network Function Virtualization Orchestrator + + * - NF + - Network Function + + * - NSH + - Network Services Header (Service chaining encapsulation) + + * - ODL + - OpenDaylight SDN Controller + + * - RSP + - Rendered Service Path + + * - SDN + - Software Defined Networking + + * - SF + - Service Function + + * - SFC + - Service Function Chain(ing) + + * - SFF + - Service Function Forwarder + + * - SFP + - Service Function Path + + * - VNF + - Virtual Network Function + + * - VNFM + - Virtual Network Function Manager + + * - VNF-FG + - Virtual Network Function Forwarding Graph + + * - VIM + - Virtual Infrastructure Manager diff --git a/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg b/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg new file mode 100644 index 00000000..1b542888 Binary files /dev/null and b/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg differ diff --git a/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg b/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg new file mode 100644 index 00000000..11eaf87b Binary files /dev/null and b/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg differ diff --git a/docs/development/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg b/docs/development/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg new file mode 100644 index 00000000..c183486e Binary files /dev/null and b/docs/development/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg differ diff --git a/docs/development/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg b/docs/development/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg new file mode 100644 index 00000000..345317dd Binary files /dev/null and b/docs/development/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg differ diff --git a/docs/development/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg b/docs/development/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg new file mode 100644 index 00000000..efc0df33 Binary files /dev/null and b/docs/development/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg differ diff --git a/docs/development/design/index.rst b/docs/development/design/index.rst new file mode 100644 index 00000000..f13d575b --- /dev/null +++ b/docs/development/design/index.rst @@ -0,0 +1,16 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +******************************* +Service Function Chaining (SFC) +******************************* + +.. toctree:: + :numbered: + :maxdepth: 2 + + introduction.rst + definitions.rst + usecases.rst + architecture.rst + requirements.rst diff --git a/docs/development/design/introduction.rst b/docs/development/design/introduction.rst new file mode 100644 index 00000000..f7b7df76 --- /dev/null +++ b/docs/development/design/introduction.rst @@ -0,0 +1,10 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +Introduction +------------ + +The `OPNFV Service Function Chaining (SFC) `_ +project aims to provide the ability to define an ordered list of a network services (e.g. firewalls, NAT, QoS). +These service are then "stitched" together in the network to create a service chain. +This project provides the infrastructure to install the upstream ODL SFC implementation project in an NFV environment. diff --git a/docs/development/design/requirements.rst b/docs/development/design/requirements.rst new file mode 100644 index 00000000..1c15a9b9 --- /dev/null +++ b/docs/development/design/requirements.rst @@ -0,0 +1,40 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +Requirements +------------ + +This section defines requirements for the initial OPNFV SFC implementation, +including those requirements driving upstream project enhancements. + +Minimal Viable Requirement +++++++++++++++++++++++++++ + +Deploy a complete SFC solution by integrating OpenDaylight SFC with OpenStack +in an OPNFV environment. + +Detailed Requirements ++++++++++++++++++++++ + +These are the Colorado specific requirements: + +1 The supported Service Chaining encapsulation will be NSH VXLAN-GPE. + +2 The version of OVS used must support NSH. + +3 The SF VM life cycle will be managed by the Tacker VNF Mgr. + +4 The supported classifiers will be either ODL Netvirt or ODL GBP. + +5 ODL will be the OpenStack Neutron backend and will handle all networking + on the compute nodes. + +Long Term Requirements +++++++++++++++++++++++ + +These requirements are out of the scope of the Colorado release. + +1 Dynamic movement of SFs across multiple Compute nodes. + +2 Load Balancing across multiple SFs + diff --git a/docs/development/design/usecases.rst b/docs/development/design/usecases.rst new file mode 100644 index 00000000..23e94417 --- /dev/null +++ b/docs/development/design/usecases.rst @@ -0,0 +1,16 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + +Use Cases +--------- + +This section outlines the Colorado use cases driving the initial OPNFV +SFC implementation. + +The use cases targeted in the OPNFV SFC Colorado release focus on creating +simple Service Chains using Firewall Service Functions. As can be seen in the +following diagram, 2 service chains are created, each through a different +Service Function Firewall. Service Chain 1 will block HTTP, while Service +Chain 2 will block SSH. + +.. image:: ./images/OPNFV_SFC_Brahmaputra_UseCase.jpg diff --git a/docs/installationprocedure/feature.configuration.rst b/docs/installationprocedure/feature.configuration.rst deleted file mode 100644 index e2fcbbb0..00000000 --- a/docs/installationprocedure/feature.configuration.rst +++ /dev/null @@ -1,256 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) Ferenc Cserepkei, Brady Allen Johnson, Manuel Buil and others - -Abstract -======== -This document provides information on how to install the OpenDayLigh SFC -features in OPNFV with the use of os_odl-l2_sfc-(no)ha scenario. - -SFC feature desciription -======================== -For details of the scenarios and their provided capabilities refer to -the scenario description documents: - -- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-ha/index.html - -- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-noha/index.html - - -The SFC feature enables creation of Service Fuction Chains - an ordered list -of chained network funcions (e.g. firewalls, NAT, QoS) - -The SFC feature in OPNFV is implemented by 3 major components: - -- OpenDayLight SDN controller - -- Tacker: Generic VNF Manager (VNFM) and a NFV Orchestrator (NFVO) - -- OpenvSwitch: The Service Function Forwarder(s) - -Hardware requirements -===================== - -The SFC scenarios can be deployed on a bare-metal OPNFV cluster or on a -virtual environment on a single host. - -Bare metal deployment on (OPNFV) Pharos lab -------------------------------------------- -Hardware requirements for bare-metal deployments of the OPNFV infrastructure -are given by the Pharos project. The Pharos project provides an OPNFV -hardware specification for configuring your hardware: -http://artifacts.opnfv.org/pharos/docs/pharos-spec.html - - -Virtual deployment ------------------- -To perform a virtual deployment of an OPNFV SFC scenario on a single host, -that host has to meet the following hardware requirements: - -- SandyBridge compatible CPU with virtualization support - -- capable to host 5 virtual cores (5 physical ones at least) - -- 8-12 GBytes RAM for virtual hosts (controller, compute), 48GByte at least - -- 128 GiBiBytes room on disk for each virtual host (controller, compute) + - 64GiBiBytes for fuel master, 576 GiBiBytes at least - -- Ubuntu Trusty Tahr - 14.04(.5) server operating system with at least ssh - service selected at installation. - -- Internet Connection (preferably http proxyless) - - -Pre-configuration activites - Preparing the host to install Fuel by script -========================================================================== -.. Not all of these options are relevant for all scenario's. I advise following the -.. instructions applicable to the deploy tool used in the scenario. - -Before starting the installation of the SFC scenarios some preparation of the -machine that will host the Colorado Fuel cluster must be done. - -Installation of required packages ---------------------------------- -To be able to run the installation of the basic OPNFV fuel installation the -Jumphost (or the host which serves the VMs for the virtual deployment) needs to -install the following packages: -:: - - sudo apt-get install -y git make curl libvirt-bin libpq-dev qemu-kvm \ - qemu-system tightvncserver virt-manager sshpass \ - fuseiso genisoimage blackbox xterm python-pip \ - python-git python-dev python-oslo.config \ - python-pip python-dev libffi-dev libxml2-dev \ - libxslt1-dev libffi-dev libxml2-dev libxslt1-dev \ - expect curl python-netaddr p7zip-full - - sudo pip install GitPython pyyaml netaddr paramiko lxml scp \ - scp pycrypto ecdsa debtcollector netifaces enum - -During libvirt install the user is added to the libvirtd group, so you have to -logout then login back again - - -Download the installer source code and artifact ------------------------------------------------ -To be able to install the scenario os_odl-l2_sfc-(no)ha one can follow the way -CI is deploying the scenario. -First of all the opnfv-fuel repository needs to be cloned: -:: - - git clone -b 'stable/colorado' ssh://@gerrit.opnfv.org:29418/fuel - -This command copies the whole colorado branch of repository fuel. - -Now download the appropriate OPNFV Fuel ISO into an appropriate folder: -:: - - wget http://artifacts.opnfv.org/fuel/colorado/opnfv-colorado.1.0.iso - -The exact name of the ISO image may change. -Check https://www.opnfv.org/opnfv-colorado-fuel-users to get the latest ISO. - -Simplified scenario deployment procedure using Fuel -=================================================== - -This section describes the installation of the os-odl-l2_sfc or -os-odl-l2_sfc-noha OPNFV reference platform stack across a server cluster -or a single host as a virtual deployment. - -Scenario Preparation --------------------- -dea.yaml and dha.yaml need to be copied and changed according to the -lab-name/host where you deploy. -Copy the full lab config from: -:: - - cp -r /deploy/config/labs/devel-pipeline/elx \ - /deploy/config/labs/devel-pipeline/ - -Add at the bottom of dha.yaml -:: - - disks: - fuel: 64G - controller: 128G - compute: 128G - - define_vms: - controller: - vcpu: - value: 2 - memory: - attribute_equlas: - unit: KiB - value: 12521472 - currentMemory: - attribute_equlas: - unit: KiB - value: 12521472 - compute: - vcpu: - value: 2 - memory: - attribute_equlas: - unit: KiB - value: 8388608 - currentMemory: - attribute_equlas: - unit: KiB - value: 8388608 - fuel: - vcpu: - value: 2 - memory: - attribute_equlas: - unit: KiB - value: 2097152 - currentMemory: - attribute_equlas: - unit: KiB - value: 2097152 - -Check if the default settings in dea.yaml are in line with your intentions -and make changes as required. - -Installation procedures ------------------------ - -We state here several alternatives. -First, we describe methods that are based on the use of the deploy.sh script, -what is used by the OPNFV CI system and can be found in the Fuel repository. - -In addition, the SFC feature can also be configured manually in the Fuel GUI -what we will show in the last subsection. - -Before starting any of the following procedures, go to -:: - - cd /ci - -Full automatic virtual deployment, High Availablity mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -This example will deploy the high-availability flavor of SFC scenario -os_odl-l2_sfc-ha in a fully automatic way, i.e. all installation steps -(Fuel server installation, configuration, node discovery and platform -deployment) will take place without any further prompt for user input. -:: - - sudo bash ./deploy.sh -b file:///config/ -l devel-pipeline -p - -s os_odl-l2_sfc-ha -i file:// - -Full automatic virtual deployment, non HIGH Availablity mode -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The following command will deploy the SFC scenario with non-high-availability -flavor (note the different scenario name for the -s switch). Otherwise it -does the same as described above. -:: - - sudo bash ./deploy.sh -b file:///config/ -l devel-pipeline -p - -s os_odl-l2_sfc-noha -i file:// - -Automatic Fuel installation and manual scenario deployment -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -A useful alternative to the full automatic procedure is to only deploy the Fuel host and to run host selection, role assignment and SFC scenario configuration manually. -:: - - sudo bash ./deploy.sh -b file:///config/ -l devel-pipeline -p -s os_odl-l2_sfc-ha -i file:// -e - -With -e option the installer will skip environment deployment, so an user -can do some modification before the scenario is really deployed. Another -useful option is the -f option which deploys the scenario using an existing -Fuel host. - -The result of this installation is a well configured Fuel sever. The use of -the deploy button on Fuel dashboard can initiate the deployment. A user may -perform manual post-configuration as well. - -Feature configuration on existing Fuel -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -If a Fuel server is already provisioned but the fuel plugins for Opendaylight, -Openvswitch are not provided install them by: -:: - - cd /opt/opnfv/ - fuel plugins --install fuel-plugin-ovs-*.noarch.rpm - fuel plugins --install opendaylight-*.noarch.rpm - -If plugins are installed and you want to update them use --force flag. - -Note that One may inject other - Colorado compatible - plugins to the Fuel -Master host using the command scp: - -scp .rpm root@10.20.0.2:.rpm - -Now the feature can be configured. Create a new environment with -Networking Setup:"OpenDayLight with tunneling segmentation". Then go to -settings/other and check "OpenDaylight plugin, SFC enabled", -"Install Openvswitch with NSH/DPDK, with NSH enabled". During node provision -remember assign the OpenDayLight role to the (primary)controller - -Now the deploy button on fuel dashboard can be used to deploy the environment. diff --git a/docs/installationprocedure/index.rst b/docs/installationprocedure/index.rst deleted file mode 100644 index 53279035..00000000 --- a/docs/installationprocedure/index.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - .. (c) - -********************************************** -SFC installation and configuration instruction -********************************************** - -.. toctree:: - :numbered: - :maxdepth: 2 - - feature.configuration.rst diff --git a/docs/release/configguide/featureconfig.rst b/docs/release/configguide/featureconfig.rst new file mode 100644 index 00000000..9189902c --- /dev/null +++ b/docs/release/configguide/featureconfig.rst @@ -0,0 +1,24 @@ + configuration +======================= +Add a brief introduction to configure OPNFV with this specific feature including +dependancies on platform components, this description should be at a level that +will apply to any installer providing the pre-requisite components. + +Pre-configuration activities +---------------------------- +Describe specific pre-configuration activities. This should include ensuring the +right components are installed by the installation tools as required for your +feature to function. Refer to the previous installer configuration chapters, +installations guide and release notes + +Hardware configuration +---------------------- +Describe the hardware configuration needed for this specific feature + +Feature configuration +--------------------- +Describe the procedures to configure your feature on the platform in order +that it is ready to use according to the feature instructions in the platform +user guide. Where applicable you should add content in the postinstall.rst +to validate the feature is configured for use. +(checking components are installed correctly etc...) diff --git a/docs/release/configguide/postinstall.rst b/docs/release/configguide/postinstall.rst new file mode 100644 index 00000000..1702cea5 --- /dev/null +++ b/docs/release/configguide/postinstall.rst @@ -0,0 +1,26 @@ + post installation procedures +====================================== +Add a brief introduction to the methods of validating the installation +according to this specific installer or feature. + +Automated post installation activities +-------------------------------------- +Describe specific post installation activities performed by the OPNFV +deployment pipeline including testing activities and reports. Refer to +the relevant testing guides, results, and release notes. + +note: this section should be singular and derived from the test projects +once we have one test suite to run for all deploy tools. This is not the +case yet so each deploy tool will need to provide (hopefully very simillar) +documentation of this. + + post configuration procedures +-------------------------------------- +Describe any deploy tool or feature specific scripts, tests or procedures +that should be carried out on the deployment post install and configuration +in this section. + +Platform components validation +--------------------------------- +Describe any component specific validation procedures necessary for your +deployment tool in this section. diff --git a/docs/release/installation/feature.configuration.rst b/docs/release/installation/feature.configuration.rst new file mode 100644 index 00000000..e2fcbbb0 --- /dev/null +++ b/docs/release/installation/feature.configuration.rst @@ -0,0 +1,256 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Ferenc Cserepkei, Brady Allen Johnson, Manuel Buil and others + +Abstract +======== +This document provides information on how to install the OpenDayLigh SFC +features in OPNFV with the use of os_odl-l2_sfc-(no)ha scenario. + +SFC feature desciription +======================== +For details of the scenarios and their provided capabilities refer to +the scenario description documents: + +- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-ha/index.html + +- http://artifacts.opnfv.org/sfc/colorado/docs/scenarios_os-odl_l2-sfc-noha/index.html + + +The SFC feature enables creation of Service Fuction Chains - an ordered list +of chained network funcions (e.g. firewalls, NAT, QoS) + +The SFC feature in OPNFV is implemented by 3 major components: + +- OpenDayLight SDN controller + +- Tacker: Generic VNF Manager (VNFM) and a NFV Orchestrator (NFVO) + +- OpenvSwitch: The Service Function Forwarder(s) + +Hardware requirements +===================== + +The SFC scenarios can be deployed on a bare-metal OPNFV cluster or on a +virtual environment on a single host. + +Bare metal deployment on (OPNFV) Pharos lab +------------------------------------------- +Hardware requirements for bare-metal deployments of the OPNFV infrastructure +are given by the Pharos project. The Pharos project provides an OPNFV +hardware specification for configuring your hardware: +http://artifacts.opnfv.org/pharos/docs/pharos-spec.html + + +Virtual deployment +------------------ +To perform a virtual deployment of an OPNFV SFC scenario on a single host, +that host has to meet the following hardware requirements: + +- SandyBridge compatible CPU with virtualization support + +- capable to host 5 virtual cores (5 physical ones at least) + +- 8-12 GBytes RAM for virtual hosts (controller, compute), 48GByte at least + +- 128 GiBiBytes room on disk for each virtual host (controller, compute) + + 64GiBiBytes for fuel master, 576 GiBiBytes at least + +- Ubuntu Trusty Tahr - 14.04(.5) server operating system with at least ssh + service selected at installation. + +- Internet Connection (preferably http proxyless) + + +Pre-configuration activites - Preparing the host to install Fuel by script +========================================================================== +.. Not all of these options are relevant for all scenario's. I advise following the +.. instructions applicable to the deploy tool used in the scenario. + +Before starting the installation of the SFC scenarios some preparation of the +machine that will host the Colorado Fuel cluster must be done. + +Installation of required packages +--------------------------------- +To be able to run the installation of the basic OPNFV fuel installation the +Jumphost (or the host which serves the VMs for the virtual deployment) needs to +install the following packages: +:: + + sudo apt-get install -y git make curl libvirt-bin libpq-dev qemu-kvm \ + qemu-system tightvncserver virt-manager sshpass \ + fuseiso genisoimage blackbox xterm python-pip \ + python-git python-dev python-oslo.config \ + python-pip python-dev libffi-dev libxml2-dev \ + libxslt1-dev libffi-dev libxml2-dev libxslt1-dev \ + expect curl python-netaddr p7zip-full + + sudo pip install GitPython pyyaml netaddr paramiko lxml scp \ + scp pycrypto ecdsa debtcollector netifaces enum + +During libvirt install the user is added to the libvirtd group, so you have to +logout then login back again + + +Download the installer source code and artifact +----------------------------------------------- +To be able to install the scenario os_odl-l2_sfc-(no)ha one can follow the way +CI is deploying the scenario. +First of all the opnfv-fuel repository needs to be cloned: +:: + + git clone -b 'stable/colorado' ssh://@gerrit.opnfv.org:29418/fuel + +This command copies the whole colorado branch of repository fuel. + +Now download the appropriate OPNFV Fuel ISO into an appropriate folder: +:: + + wget http://artifacts.opnfv.org/fuel/colorado/opnfv-colorado.1.0.iso + +The exact name of the ISO image may change. +Check https://www.opnfv.org/opnfv-colorado-fuel-users to get the latest ISO. + +Simplified scenario deployment procedure using Fuel +=================================================== + +This section describes the installation of the os-odl-l2_sfc or +os-odl-l2_sfc-noha OPNFV reference platform stack across a server cluster +or a single host as a virtual deployment. + +Scenario Preparation +-------------------- +dea.yaml and dha.yaml need to be copied and changed according to the +lab-name/host where you deploy. +Copy the full lab config from: +:: + + cp -r /deploy/config/labs/devel-pipeline/elx \ + /deploy/config/labs/devel-pipeline/ + +Add at the bottom of dha.yaml +:: + + disks: + fuel: 64G + controller: 128G + compute: 128G + + define_vms: + controller: + vcpu: + value: 2 + memory: + attribute_equlas: + unit: KiB + value: 12521472 + currentMemory: + attribute_equlas: + unit: KiB + value: 12521472 + compute: + vcpu: + value: 2 + memory: + attribute_equlas: + unit: KiB + value: 8388608 + currentMemory: + attribute_equlas: + unit: KiB + value: 8388608 + fuel: + vcpu: + value: 2 + memory: + attribute_equlas: + unit: KiB + value: 2097152 + currentMemory: + attribute_equlas: + unit: KiB + value: 2097152 + +Check if the default settings in dea.yaml are in line with your intentions +and make changes as required. + +Installation procedures +----------------------- + +We state here several alternatives. +First, we describe methods that are based on the use of the deploy.sh script, +what is used by the OPNFV CI system and can be found in the Fuel repository. + +In addition, the SFC feature can also be configured manually in the Fuel GUI +what we will show in the last subsection. + +Before starting any of the following procedures, go to +:: + + cd /ci + +Full automatic virtual deployment, High Availablity mode +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This example will deploy the high-availability flavor of SFC scenario +os_odl-l2_sfc-ha in a fully automatic way, i.e. all installation steps +(Fuel server installation, configuration, node discovery and platform +deployment) will take place without any further prompt for user input. +:: + + sudo bash ./deploy.sh -b file:///config/ -l devel-pipeline -p + -s os_odl-l2_sfc-ha -i file:// + +Full automatic virtual deployment, non HIGH Availablity mode +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The following command will deploy the SFC scenario with non-high-availability +flavor (note the different scenario name for the -s switch). Otherwise it +does the same as described above. +:: + + sudo bash ./deploy.sh -b file:///config/ -l devel-pipeline -p + -s os_odl-l2_sfc-noha -i file:// + +Automatic Fuel installation and manual scenario deployment +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A useful alternative to the full automatic procedure is to only deploy the Fuel host and to run host selection, role assignment and SFC scenario configuration manually. +:: + + sudo bash ./deploy.sh -b file:///config/ -l devel-pipeline -p -s os_odl-l2_sfc-ha -i file:// -e + +With -e option the installer will skip environment deployment, so an user +can do some modification before the scenario is really deployed. Another +useful option is the -f option which deploys the scenario using an existing +Fuel host. + +The result of this installation is a well configured Fuel sever. The use of +the deploy button on Fuel dashboard can initiate the deployment. A user may +perform manual post-configuration as well. + +Feature configuration on existing Fuel +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +If a Fuel server is already provisioned but the fuel plugins for Opendaylight, +Openvswitch are not provided install them by: +:: + + cd /opt/opnfv/ + fuel plugins --install fuel-plugin-ovs-*.noarch.rpm + fuel plugins --install opendaylight-*.noarch.rpm + +If plugins are installed and you want to update them use --force flag. + +Note that One may inject other - Colorado compatible - plugins to the Fuel +Master host using the command scp: + +scp .rpm root@10.20.0.2:.rpm + +Now the feature can be configured. Create a new environment with +Networking Setup:"OpenDayLight with tunneling segmentation". Then go to +settings/other and check "OpenDaylight plugin, SFC enabled", +"Install Openvswitch with NSH/DPDK, with NSH enabled". During node provision +remember assign the OpenDayLight role to the (primary)controller + +Now the deploy button on fuel dashboard can be used to deploy the environment. diff --git a/docs/release/installation/index.rst b/docs/release/installation/index.rst new file mode 100644 index 00000000..53279035 --- /dev/null +++ b/docs/release/installation/index.rst @@ -0,0 +1,13 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + .. (c) + +********************************************** +SFC installation and configuration instruction +********************************************** + +.. toctree:: + :numbered: + :maxdepth: 2 + + feature.configuration.rst diff --git a/docs/release/release-notes/index.rst b/docs/release/release-notes/index.rst new file mode 100644 index 00000000..e5e1dc60 --- /dev/null +++ b/docs/release/release-notes/index.rst @@ -0,0 +1,13 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + .. (c) + +***************** +SFC Release Notes +***************** + +.. toctree:: + :numbered: + :maxdepth: 2 + + releasenotes.rst diff --git a/docs/release/release-notes/releasenotes.rst b/docs/release/release-notes/releasenotes.rst new file mode 100644 index 00000000..bf07e59a --- /dev/null +++ b/docs/release/release-notes/releasenotes.rst @@ -0,0 +1,204 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) Brady Johnson (Ericsson Inc.) and others + +Abstract +======== + +This document compiles the release notes for the Colorado release of +OPNFV SFC. + +Important notes +=============== + +These notes provide release information for the use of SFC with the Fuel +and Apex installer tools for the Colorado release of OPNFV. + +Summary +======= + +The goal of the SFC Colorado release is to integrate the OpenDaylight +SFC project into an OPNFV environment, with either the Fuel or Apex +installer. In subsequent releases, other OPNFV installers will be +considered. + +More information about OpenDaylight and SFC can be found here. + +- `OpenDaylight `_ version "Boron" + +- `Service function chaining `_ + + +- Documentation built by Jenkins + + - Overall OPNFV documentation + + - `Design document `_ + + - `User Guide `_ + + - `Installation Instructions `_ + + - Release Notes (this document) + + +Release Data +============ + ++--------------------------------------+--------------------------------------+ +| **Project** | sfc | +| | | ++--------------------------------------+--------------------------------------+ +| **Repo/tag** | colorado.2.0 | +| | | ++--------------------------------------+--------------------------------------+ +| **Release designation** | Colorado base release | +| | | ++--------------------------------------+--------------------------------------+ +| **Release date** | November 10 2016 | +| | | ++--------------------------------------+--------------------------------------+ +| **Purpose of the delivery** | Improve functionality provided in | +| | Brahmaputra release. Increased test | +| | coverage with new Funtest cases. | +| | Make SFC/Tacker work on multiple | +| | compute nodes | +| | | ++--------------------------------------+--------------------------------------+ + +Version change +-------------- + +Module version changes +~~~~~~~~~~~~~~~~~~~~~~ +This is the second tracked release of OPNFV sfc. It is based on +following upstream versions: + +- OpenStack Mitaka release + +- OpenDaylight Boron release + +- Open vSwitch 2.5.90 with Yi Yang NSH patch + +Document changes +~~~~~~~~~~~~~~~~ +This is the second tracked version of OPNFV SFC. It comes with +the following documentation: + +- `Design document `_ + +- `User Guide `_ + +- `Installation Instructions `_ + +- Release notes (This document) + +Reason for version +------------------ + +Feature additions +~~~~~~~~~~~~~~~~~ + +**JIRA TICKETS:** + +`JIRA EPIC with the new features in SFC Colorado `_ + +Bug corrections +~~~~~~~~~~~~~~~ + +**JIRA TICKETS:** + +`Bug-fixes `_ + +Deliverables +------------ + +Software deliverables +~~~~~~~~~~~~~~~~~~~~~ + +No specific deliverables are created, as SFC is included with Apex and Fuel. + +Documentation deliverables +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- `Design document `_ + +- `User Guide `_ + +- `Installation Instructions `_ + +- Release notes (This document) + +Known Limitations, Issues and Workarounds +========================================= + +System Limitations +------------------ + +The Colorado 2.0 release has several limitations: + +1 - OPNFV SFC only works in non-HA environments with the Fuel installer. +There is a bug in ODL which is fixed in ODL Boron SR1 and will be part +of Colorado 3.0 + +2 - Any VM (e.g. SFs) must have only one security group. +There is a bug in ODL Boron which only one security group is read. +The rest are silently ignored. This issue will be fixed in ODL +Boron SR1, which will be included in Colorado 3.0. + +Known issues +------------ + +OpenDaylight SFC relies on a version of Open vSwitch (OVS) with +Network Service Headers (NSH). A version of OVS with NSH currently +exists, but it is in a branched version of OVS. Extensive upstream +work has been done to merge the NSH patches into mainstream OVS, +but the work is still not complete. More information about this +can be found in the OPNFV SFC design document (link provided above). + +Workarounds +----------- + +The way OpenStack handles VXLAN-GPE tunnels doesnt work well with +SFC, since OpenStack terminates the VXLAN tunnels in the br-int +bridge instead of the SF VM. Ideally, the tunnel should be terminated +in the VM so the SF has access to the NSH header carried in the tunnel. +A workaround was created to send the packets to the SF VM with the +VXLAN-GPE headers intact and can be found in the OPNFV SFC design +document (link provided above). + +Test results +============ +The Colorado release of SFC has undergone QA test runs +with Functest tests on the Fuel and Apex installers. + +References +========== +For more information on the OPNFV Colorado release, please see: + +OPNFV +----- + +1) `OPNFV Home Page `_ + +2) `OPNFV documentation- and software downloads `_ + +3) `OPNFV Colorado release `_ + +OpenStack +--------- + +4) `OpenStack Mitaka Release artifacts `_ + +5) `OpenStack documentation `_ + +OpenDaylight +------------ + +6) `OpenDaylight artifacts `_ + +Open vSwitch with NSH +--------------------- + +7) https://github.com/yyang13/ovs_nsh_patches + diff --git a/docs/release/scenarios/os-odl_l2-sfc-ha/index.rst b/docs/release/scenarios/os-odl_l2-sfc-ha/index.rst new file mode 100644 index 00000000..d72e657c --- /dev/null +++ b/docs/release/scenarios/os-odl_l2-sfc-ha/index.rst @@ -0,0 +1,16 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +========================================= +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 new file mode 100644 index 00000000..cb918002 --- /dev/null +++ b/docs/release/scenarios/os-odl_l2-sfc-ha/scenario.description.rst @@ -0,0 +1,118 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +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 Colorado release uses the OpenDaylight Boron 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. +This scenario is not working in Colorado 1.0 with the Fuel installer, since Tacker is not +registered in the HA Proxy and calls to Tacker fail. This will be fixed in Colorado 2.0. + +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 release, SFC was +changed to use a newer, branched version of OVS based on 2.5.90, 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/brahmaputra/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 Colorado release, please visit: + +http://www.opnfv.org/colorado + diff --git a/docs/release/scenarios/os-odl_l2-sfc-noha/index.rst b/docs/release/scenarios/os-odl_l2-sfc-noha/index.rst new file mode 100644 index 00000000..ef3e4fbe --- /dev/null +++ b/docs/release/scenarios/os-odl_l2-sfc-noha/index.rst @@ -0,0 +1,16 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +=========================================== +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 new file mode 100644 index 00000000..b5d41044 --- /dev/null +++ b/docs/release/scenarios/os-odl_l2-sfc-noha/scenario.description.rst @@ -0,0 +1,118 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +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 Colorado release uses the OpenDaylight +Boron 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. + +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 release, SFC was +changed to use a newer, branched version of OVS based on 2.5.90, 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/brahmaputra/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 Colorado release, please visit: + +http://www.opnfv.org/colorado + diff --git a/docs/release/userguide/feature.userguide.rst b/docs/release/userguide/feature.userguide.rst new file mode 100644 index 00000000..6e80a391 --- /dev/null +++ b/docs/release/userguide/feature.userguide.rst @@ -0,0 +1,50 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. (c) + +SFC description +===================== +.. Describe the specific features and how it is realised in the scenario in a brief manner +.. to ensure the user understand the context for the user guide instructions to follow. + +The OPNFV SFC feature will create service chains, classifiers, and create VMs for Service +Functions, allowing for client traffic intended to be sent to a server to first traverse +the provisioned service chain. + +The Service Chain creation consists of configuring the OpenDaylight SFC feature. This +configuration will in-turn configure Service Function Forwarders to route traffic to +Service Functions. A Service Function Forwarder in the context of OPNFV SFC is the +"br-int" OVS bridge on an Open Stack compute node. + +The classifier(s) consist of configuring the OpenDaylight Netvirt feature. Netvirt is +a Neutron backend which handles the networking for VMs. Netvirt can also create simple +classification rules (5-tuples) to send specific traffic to a pre-configured Service +Chain. A common example of a classification rule would be to send all HTTP traffic +(tcp port 80) to a pre-configured Service Chain. + +Service Function VM creation is performed via a VNF Manager. Currently, OPNFV SFC +is integrated with OpenStack Tacker, which in addition to being a VNF Manager, also +orchestrates the SFC configuration. In OPNFV SFC Tacker creates service chains, +classification rules, creates VMs in OpenStack for Service Functions, and then +communicates the relevant configuration to OpenDaylight SFC. + +SFC capabilities and usage +================================ +.. Describe the specific capabilities and usage for feature. +.. Provide enough information that a user will be able to operate the feature on a deployed scenario. + +The OPNFV SFC feature can be deployed with either the "os-odl_l2-sfc-ha" or the +"os-odl_l2-sfc-noha" scenario. SFC usage for both of these scenarios is the same. + +As previously mentioned, Tacker is used as a VNF Manager and SFC Orchestrator. All +the configuration necessary to create working service chains and classifiers can +be performed using the Tacker command line. Refer to the `Tacker walkthrough `_ +(step 3 and onwards) for more information. + +SFC API usage guidelines and example +----------------------------------------------- +.. Describe with examples how to use specific features, provide API examples and details required to +.. operate the feature on the platform. + +Refer to the `Tacker walkthrough `_ +for Tacker usage guidelines and examples. diff --git a/docs/release/userguide/index.rst b/docs/release/userguide/index.rst new file mode 100644 index 00000000..9bfd2433 --- /dev/null +++ b/docs/release/userguide/index.rst @@ -0,0 +1,13 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 + .. (c) + +************** +SFC User Guide +************** + +.. toctree:: + :numbered: + :maxdepth: 2 + + feature.userguide.rst diff --git a/docs/releasenotes/index.rst b/docs/releasenotes/index.rst deleted file mode 100644 index e5e1dc60..00000000 --- a/docs/releasenotes/index.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - .. (c) - -***************** -SFC Release Notes -***************** - -.. toctree:: - :numbered: - :maxdepth: 2 - - releasenotes.rst diff --git a/docs/releasenotes/releasenotes.rst b/docs/releasenotes/releasenotes.rst deleted file mode 100644 index bf07e59a..00000000 --- a/docs/releasenotes/releasenotes.rst +++ /dev/null @@ -1,204 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) Brady Johnson (Ericsson Inc.) and others - -Abstract -======== - -This document compiles the release notes for the Colorado release of -OPNFV SFC. - -Important notes -=============== - -These notes provide release information for the use of SFC with the Fuel -and Apex installer tools for the Colorado release of OPNFV. - -Summary -======= - -The goal of the SFC Colorado release is to integrate the OpenDaylight -SFC project into an OPNFV environment, with either the Fuel or Apex -installer. In subsequent releases, other OPNFV installers will be -considered. - -More information about OpenDaylight and SFC can be found here. - -- `OpenDaylight `_ version "Boron" - -- `Service function chaining `_ - - -- Documentation built by Jenkins - - - Overall OPNFV documentation - - - `Design document `_ - - - `User Guide `_ - - - `Installation Instructions `_ - - - Release Notes (this document) - - -Release Data -============ - -+--------------------------------------+--------------------------------------+ -| **Project** | sfc | -| | | -+--------------------------------------+--------------------------------------+ -| **Repo/tag** | colorado.2.0 | -| | | -+--------------------------------------+--------------------------------------+ -| **Release designation** | Colorado base release | -| | | -+--------------------------------------+--------------------------------------+ -| **Release date** | November 10 2016 | -| | | -+--------------------------------------+--------------------------------------+ -| **Purpose of the delivery** | Improve functionality provided in | -| | Brahmaputra release. Increased test | -| | coverage with new Funtest cases. | -| | Make SFC/Tacker work on multiple | -| | compute nodes | -| | | -+--------------------------------------+--------------------------------------+ - -Version change --------------- - -Module version changes -~~~~~~~~~~~~~~~~~~~~~~ -This is the second tracked release of OPNFV sfc. It is based on -following upstream versions: - -- OpenStack Mitaka release - -- OpenDaylight Boron release - -- Open vSwitch 2.5.90 with Yi Yang NSH patch - -Document changes -~~~~~~~~~~~~~~~~ -This is the second tracked version of OPNFV SFC. It comes with -the following documentation: - -- `Design document `_ - -- `User Guide `_ - -- `Installation Instructions `_ - -- Release notes (This document) - -Reason for version ------------------- - -Feature additions -~~~~~~~~~~~~~~~~~ - -**JIRA TICKETS:** - -`JIRA EPIC with the new features in SFC Colorado `_ - -Bug corrections -~~~~~~~~~~~~~~~ - -**JIRA TICKETS:** - -`Bug-fixes `_ - -Deliverables ------------- - -Software deliverables -~~~~~~~~~~~~~~~~~~~~~ - -No specific deliverables are created, as SFC is included with Apex and Fuel. - -Documentation deliverables -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -- `Design document `_ - -- `User Guide `_ - -- `Installation Instructions `_ - -- Release notes (This document) - -Known Limitations, Issues and Workarounds -========================================= - -System Limitations ------------------- - -The Colorado 2.0 release has several limitations: - -1 - OPNFV SFC only works in non-HA environments with the Fuel installer. -There is a bug in ODL which is fixed in ODL Boron SR1 and will be part -of Colorado 3.0 - -2 - Any VM (e.g. SFs) must have only one security group. -There is a bug in ODL Boron which only one security group is read. -The rest are silently ignored. This issue will be fixed in ODL -Boron SR1, which will be included in Colorado 3.0. - -Known issues ------------- - -OpenDaylight SFC relies on a version of Open vSwitch (OVS) with -Network Service Headers (NSH). A version of OVS with NSH currently -exists, but it is in a branched version of OVS. Extensive upstream -work has been done to merge the NSH patches into mainstream OVS, -but the work is still not complete. More information about this -can be found in the OPNFV SFC design document (link provided above). - -Workarounds ------------ - -The way OpenStack handles VXLAN-GPE tunnels doesnt work well with -SFC, since OpenStack terminates the VXLAN tunnels in the br-int -bridge instead of the SF VM. Ideally, the tunnel should be terminated -in the VM so the SF has access to the NSH header carried in the tunnel. -A workaround was created to send the packets to the SF VM with the -VXLAN-GPE headers intact and can be found in the OPNFV SFC design -document (link provided above). - -Test results -============ -The Colorado release of SFC has undergone QA test runs -with Functest tests on the Fuel and Apex installers. - -References -========== -For more information on the OPNFV Colorado release, please see: - -OPNFV ------ - -1) `OPNFV Home Page `_ - -2) `OPNFV documentation- and software downloads `_ - -3) `OPNFV Colorado release `_ - -OpenStack ---------- - -4) `OpenStack Mitaka Release artifacts `_ - -5) `OpenStack documentation `_ - -OpenDaylight ------------- - -6) `OpenDaylight artifacts `_ - -Open vSwitch with NSH ---------------------- - -7) https://github.com/yyang13/ovs_nsh_patches - diff --git a/docs/scenarios/os-odl_l2-sfc-ha/index.rst b/docs/scenarios/os-odl_l2-sfc-ha/index.rst deleted file mode 100644 index d72e657c..00000000 --- a/docs/scenarios/os-odl_l2-sfc-ha/index.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) - -========================================= -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/scenarios/os-odl_l2-sfc-ha/scenario.description.rst b/docs/scenarios/os-odl_l2-sfc-ha/scenario.description.rst deleted file mode 100644 index cb918002..00000000 --- a/docs/scenarios/os-odl_l2-sfc-ha/scenario.description.rst +++ /dev/null @@ -1,118 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) - -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 Colorado release uses the OpenDaylight Boron 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. -This scenario is not working in Colorado 1.0 with the Fuel installer, since Tacker is not -registered in the HA Proxy and calls to Tacker fail. This will be fixed in Colorado 2.0. - -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 release, SFC was -changed to use a newer, branched version of OVS based on 2.5.90, 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/brahmaputra/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 Colorado release, please visit: - -http://www.opnfv.org/colorado - diff --git a/docs/scenarios/os-odl_l2-sfc-noha/index.rst b/docs/scenarios/os-odl_l2-sfc-noha/index.rst deleted file mode 100644 index ef3e4fbe..00000000 --- a/docs/scenarios/os-odl_l2-sfc-noha/index.rst +++ /dev/null @@ -1,16 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) - -=========================================== -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/scenarios/os-odl_l2-sfc-noha/scenario.description.rst b/docs/scenarios/os-odl_l2-sfc-noha/scenario.description.rst deleted file mode 100644 index b5d41044..00000000 --- a/docs/scenarios/os-odl_l2-sfc-noha/scenario.description.rst +++ /dev/null @@ -1,118 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) - -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 Colorado release uses the OpenDaylight -Boron 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. - -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 release, SFC was -changed to use a newer, branched version of OVS based on 2.5.90, 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/brahmaputra/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 Colorado release, please visit: - -http://www.opnfv.org/colorado - diff --git a/docs/userguide/feature.userguide.rst b/docs/userguide/feature.userguide.rst deleted file mode 100644 index 6e80a391..00000000 --- a/docs/userguide/feature.userguide.rst +++ /dev/null @@ -1,50 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 -.. (c) - -SFC description -===================== -.. Describe the specific features and how it is realised in the scenario in a brief manner -.. to ensure the user understand the context for the user guide instructions to follow. - -The OPNFV SFC feature will create service chains, classifiers, and create VMs for Service -Functions, allowing for client traffic intended to be sent to a server to first traverse -the provisioned service chain. - -The Service Chain creation consists of configuring the OpenDaylight SFC feature. This -configuration will in-turn configure Service Function Forwarders to route traffic to -Service Functions. A Service Function Forwarder in the context of OPNFV SFC is the -"br-int" OVS bridge on an Open Stack compute node. - -The classifier(s) consist of configuring the OpenDaylight Netvirt feature. Netvirt is -a Neutron backend which handles the networking for VMs. Netvirt can also create simple -classification rules (5-tuples) to send specific traffic to a pre-configured Service -Chain. A common example of a classification rule would be to send all HTTP traffic -(tcp port 80) to a pre-configured Service Chain. - -Service Function VM creation is performed via a VNF Manager. Currently, OPNFV SFC -is integrated with OpenStack Tacker, which in addition to being a VNF Manager, also -orchestrates the SFC configuration. In OPNFV SFC Tacker creates service chains, -classification rules, creates VMs in OpenStack for Service Functions, and then -communicates the relevant configuration to OpenDaylight SFC. - -SFC capabilities and usage -================================ -.. Describe the specific capabilities and usage for feature. -.. Provide enough information that a user will be able to operate the feature on a deployed scenario. - -The OPNFV SFC feature can be deployed with either the "os-odl_l2-sfc-ha" or the -"os-odl_l2-sfc-noha" scenario. SFC usage for both of these scenarios is the same. - -As previously mentioned, Tacker is used as a VNF Manager and SFC Orchestrator. All -the configuration necessary to create working service chains and classifiers can -be performed using the Tacker command line. Refer to the `Tacker walkthrough `_ -(step 3 and onwards) for more information. - -SFC API usage guidelines and example ------------------------------------------------ -.. Describe with examples how to use specific features, provide API examples and details required to -.. operate the feature on the platform. - -Refer to the `Tacker walkthrough `_ -for Tacker usage guidelines and examples. diff --git a/docs/userguide/index.rst b/docs/userguide/index.rst deleted file mode 100644 index 9bfd2433..00000000 --- a/docs/userguide/index.rst +++ /dev/null @@ -1,13 +0,0 @@ -.. This work is licensed under a Creative Commons Attribution 4.0 International License. -.. http://creativecommons.org/licenses/by/4.0 - .. (c) - -************** -SFC User Guide -************** - -.. toctree:: - :numbered: - :maxdepth: 2 - - feature.userguide.rst -- cgit 1.2.3-korg