|author||Brady Johnson <firstname.lastname@example.org>||2016-01-20 11:33:16 +0100|
|committer||Brady Johnson <email@example.com>||2016-01-21 19:32:13 +0100|
|-rw-r--r--||docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg||bin||0 -> 81908 bytes|
|-rw-r--r--||docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg||bin||0 -> 85995 bytes|
|-rw-r--r--||docs/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg||bin||0 -> 52507 bytes|
|-rw-r--r--||docs/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg||bin||0 -> 59088 bytes|
|-rw-r--r--||docs/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg||bin||0 -> 52526 bytes|
diff --git a/.gitignore b/.gitignore
new file mode 100644
@@ -0,0 +1,3 @@
diff --git a/docs/design/architecture.rst b/docs/design/architecture.rst
index 24be167..d2a1bb4 100644
@@ -1,4 +1,126 @@
+This section describes the architectural approach to incorporating the upstream
+OpenDaylight (ODL) SFC project into the OPNFV Brahmaputra platform.
+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 are defined in the OpenDaylight SFC Controller using the
+ A Service Function Chain (SFC) is an ordered list of abstract SF types.
+ 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.
+ 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.
+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.
+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 Brahmaputra 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 probably not be finished by the time OPNFV Brahmaputra 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
-This section will describe the architectural approach to incorporating SFC into the OPNFV platform. \ No newline at end of file
diff --git a/docs/design/definitions.rst b/docs/design/definitions.rst
index effaf0e..3826304 100644
@@ -1,20 +1,13 @@
-Definitions of most terms used here are provided in the `IETF SFC Architecture draft <https://datatracker.ietf.org/doc/draft-ietf-sfc-architecture/>`_. Additional terms specific to the OPNFV SFC project are defined below.
+Definitions of most terms used here are provided in the `IETF SFC Architecture RFC <https://datatracker.ietf.org/doc/rfc7665/>`_.
+Additional terms specific to the OPNFV SFC project are defined below.
-.. list-table:: Definitions
- :widths: 15 85
- :header-rows: 1
- * - Term
- - Meaning
- * - ...
- - ...
.. list-table:: Abbreviations
:widths: 15 85
@@ -31,9 +24,18 @@ Abbreviations
* - 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
diff --git a/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg b/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpgBinary files differ
new file mode 100644
diff --git a/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg b/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpgBinary files differ
new file mode 100644
diff --git a/docs/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg b/docs/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpgBinary files differ
new file mode 100644
diff --git a/docs/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg b/docs/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpgBinary files differ
new file mode 100644
diff --git a/docs/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg b/docs/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpgBinary files differ
new file mode 100644
diff --git a/docs/design/index.rst b/docs/design/index.rst
index c878b87..138a181 100644
@@ -26,7 +26,3 @@ Indices and tables
-Build date: |today|
diff --git a/docs/design/introduction.rst b/docs/design/introduction.rst
index 746ba05..441ed99 100644
@@ -1,5 +1,5 @@
.. two dots create a comment. please leave this logo at the top of each of your rst files.
-.. image:: ../etc/opnfv-logo.png
+.. image:: ../etc/opnfv-logo.png
@@ -8,13 +8,13 @@
This work is licensed under a Creative Commons Attribution 3.0 Unported License.
This is the working documentation for the SFC project.
diff --git a/docs/design/requirements.rst b/docs/design/requirements.rst
index dbedc6f..3a71635 100644
@@ -1,4 +1,41 @@
+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.
+These are the Brahmaputra specific requirements:
+1 Placement of SFs on only one Compute node will be supported.
+2 The supported Service Chaining encapsulation will be NSH VXLAN-GPE.
+3 The version of OVS used must support NSH.
+4 The SF VM life cycle will be managed by the Tacker VNF Mgr.
+5 The supported classifiers will be either ODL Netvirt or ODL GBP.
+6 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 Brahmaputra release.
+1 Placing SFs on multiple Compute nodes.
+2 Dynamic movement of SFs across multiple Compute nodes.
+3 Load Balancing across multiple SFs
-This section will define requirements for the initial OPNFV SFC implementation, including those requirements driving upstream project enhancements.
diff --git a/docs/design/usecases.rst b/docs/design/usecases.rst
index 9b88698..b42fcbd 100644
@@ -1,4 +1,14 @@
-This section will outline use cases driving the initial OPNFV SFC implementation. \ No newline at end of file
+This section outlines the Brahmaputra use cases driving the initial OPNFV
+The use cases targeted in the OPNFV SFC Brahmaputra 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