This is an old revision of the document!
This project provides a framework for automatic and rapid deployment of end-to-end VNF services through VNFFG, which is one of the NFV components documented in the ETSI NFV Management and Orchestration (MANO) specification [NFVMAN001]. ETSI GS NFV specification also dedicates a specific section (section 6) to VNFFG based network services. VNFs and VNFFGs are also known by the terms Service Function (SF) and Service Function Chain (SFC) respectively.
This project proposal will bring in ongoing OpenStack work on VNFFG and ONF OpenFlow work on service chaining. It also includes integrating OpenStack SFC related components with different vendors’ VNFs instantiated on virtual machines. This project will create a link between OpenStack, ONF OpenFlow, and OPNFV. The diagram below shows an end-to-end service provided by a VNFFG consisting of a number of VNFs.
 === Components ====
^ Plane      ^ Components ^
| Management | VNFFG Manager, VNF Instance Manager  |
| Control    | SDN Controller |
| Data       | Classifier, SF Forwarder(Proxy), VNF Nodes |
 
== VNFFG Manager ==
The OpenStack based VNFFG Manager provides an interface for the VNFFG Service Admin to specify a high-level service policy intent for a tenant’s flow from the source to the destination (such as the sequence of service function flavors and the flow classification criteria). The Admin’ requirement should be network topology agnostic.  The VNFFG Manager’s role is to translate the Admin’s high-level abstract policy-based VNF service requirements into flow classification constructs as well as the sequence of detail L4~L7 VNF instance constructs. 
== VNF Manager ==
The VNF (Service Function) Manager manages the life cycle of the VNFs that are hosted on the Service VMs or on external devices. The VNF Manager registers its VNF instances with VNFFG Manager via VNF Registration API. VNFFG Manager imports the VNF instances into its VNF Catalog which is used to create the VNFFGs. 
== SDN Controller ==
The SDN Controller manages a data-plane service domain that consists of Classifiers, Service Function Forwarders, VNFs and Proxy Devices. The SDN controller is responsible for installing flow rules in the classifiers, SFFs and Proxy Devices to direct the flows to the VNFs. The SDN Controller receives the location information for the VNFs to be included in VNFFGs from the VNFFG Manager.
== Service Function Forwarder (OpenFlow Switch/Router) ==
Each SFF is responsible for forwarding the traffic to their designated local VNFs and for forwarding the traffic to the next hop SFF after the local VNF processing. A SFF may also perform a chain termination function where it removes a Service Chain Header before delivering the packet to its final destination using normal routing. The SFFs uses an overlay transport network such as VXLAN to forward the traffic in the service domain. The Service Function Forwarder can be a virtual/physical switch or router.
== VNF ==
The VNF (Service Function) performs the actual service function treatment on the traffic flows. It can be a virtual device that runs on a VM or a physical device. 
== Traffic Classifier ==
An ingress Traffic Classifier is used to classify packet flows to different VNFFGs at the entry point of the VNFFG. The Classifier performs packet inspection and maps flows to VNFFGs by adding a Service Chain Header encapsulation [SFC-SCH] to the packet. 
== Proxy Device ==
The Proxy Device is used to interface with a non SFC Header-aware VNF.
=== Interfaces ===
== Management Interfaces ==
The management interfaces include:
  - Management interface M1 is between the VNFFG Application/Admin and the VNFFG Manager. This allows the Application/Admin to express a high-level intent for the creation of VNFs and VNFFGs, but does not specify their actual realization. This includes the OpenStack Policy APIs and Advanced Services APIs for specification of user’s requirement/intention for service chaining. 
  - Management interface M2 is between the VNF Manager and the VNFFG Manager. The VNF Manager uses this API to register (on-board) VNF Instances and VNF Templates with the VNFFG Manager.
== Control Plane Interfaces ==
The control plane interfaces include:
  - Control plane interface C1 is between the VNFFG Plugin and different vendors’ SDN Controller drivers. This interface allows communication of VNF instance connectivity and flavor details as well as a VNFFG’s service function ordering information.  The interface information can be passed through transparently to the SDN Controller to become the NBI of the SDN Controller.  
  - Control plane interface C2 is between the SDN Controller and the OpenFlow vSwitches. This interface allows communication of OpenFlow commands between the Controller and the vSwitches so that vSwitches can be programmed to correctly steer different flows to different VNFFG paths.   
== Data-plane Interfaces ==
A data-plane VNFFG starts at the ingress Classifier and traverses Service Function Forwarders, SCH-aware VNFs, Proxy Devices and legacy non SCH-aware VNFs through to a terminating SFF at the end of the VNFFG are shown in the diagram below.
 
=== Components ====
^ Plane      ^ Components ^
| Management | VNFFG Manager, VNF Instance Manager  |
| Control    | SDN Controller |
| Data       | Classifier, SF Forwarder(Proxy), VNF Nodes |
 
== VNFFG Manager ==
The OpenStack based VNFFG Manager provides an interface for the VNFFG Service Admin to specify a high-level service policy intent for a tenant’s flow from the source to the destination (such as the sequence of service function flavors and the flow classification criteria). The Admin’ requirement should be network topology agnostic.  The VNFFG Manager’s role is to translate the Admin’s high-level abstract policy-based VNF service requirements into flow classification constructs as well as the sequence of detail L4~L7 VNF instance constructs. 
== VNF Manager ==
The VNF (Service Function) Manager manages the life cycle of the VNFs that are hosted on the Service VMs or on external devices. The VNF Manager registers its VNF instances with VNFFG Manager via VNF Registration API. VNFFG Manager imports the VNF instances into its VNF Catalog which is used to create the VNFFGs. 
== SDN Controller ==
The SDN Controller manages a data-plane service domain that consists of Classifiers, Service Function Forwarders, VNFs and Proxy Devices. The SDN controller is responsible for installing flow rules in the classifiers, SFFs and Proxy Devices to direct the flows to the VNFs. The SDN Controller receives the location information for the VNFs to be included in VNFFGs from the VNFFG Manager.
== Service Function Forwarder (OpenFlow Switch/Router) ==
Each SFF is responsible for forwarding the traffic to their designated local VNFs and for forwarding the traffic to the next hop SFF after the local VNF processing. A SFF may also perform a chain termination function where it removes a Service Chain Header before delivering the packet to its final destination using normal routing. The SFFs uses an overlay transport network such as VXLAN to forward the traffic in the service domain. The Service Function Forwarder can be a virtual/physical switch or router.
== VNF ==
The VNF (Service Function) performs the actual service function treatment on the traffic flows. It can be a virtual device that runs on a VM or a physical device. 
== Traffic Classifier ==
An ingress Traffic Classifier is used to classify packet flows to different VNFFGs at the entry point of the VNFFG. The Classifier performs packet inspection and maps flows to VNFFGs by adding a Service Chain Header encapsulation [SFC-SCH] to the packet. 
== Proxy Device ==
The Proxy Device is used to interface with a non SFC Header-aware VNF.
=== Interfaces ===
== Management Interfaces ==
The management interfaces include:
  - Management interface M1 is between the VNFFG Application/Admin and the VNFFG Manager. This allows the Application/Admin to express a high-level intent for the creation of VNFs and VNFFGs, but does not specify their actual realization. This includes the OpenStack Policy APIs and Advanced Services APIs for specification of user’s requirement/intention for service chaining. 
  - Management interface M2 is between the VNF Manager and the VNFFG Manager. The VNF Manager uses this API to register (on-board) VNF Instances and VNF Templates with the VNFFG Manager.
== Control Plane Interfaces ==
The control plane interfaces include:
  - Control plane interface C1 is between the VNFFG Plugin and different vendors’ SDN Controller drivers. This interface allows communication of VNF instance connectivity and flavor details as well as a VNFFG’s service function ordering information.  The interface information can be passed through transparently to the SDN Controller to become the NBI of the SDN Controller.  
  - Control plane interface C2 is between the SDN Controller and the OpenFlow vSwitches. This interface allows communication of OpenFlow commands between the Controller and the vSwitches so that vSwitches can be programmed to correctly steer different flows to different VNFFG paths.   
== Data-plane Interfaces ==
A data-plane VNFFG starts at the ingress Classifier and traverses Service Function Forwarders, SCH-aware VNFs, Proxy Devices and legacy non SCH-aware VNFs through to a terminating SFF at the end of the VNFFG are shown in the diagram below.
 * Data-plane interface D1 is the interface between the Classifier, Service Function Forwarder, and Service Proxy Device. An overlay network, such as VXLAN, creates a service transport domain connecting the Classifier, Service Function Forwarder, and the Proxy Device. 
  * Data-plane interface D2 is the interface between the Service Function Forwarder and SCH-aware VNF. 
  * Data-plane interface D3 is the interface between the Proxy Device and non SCH-aware VNF. 
==== Documentation: ====
OPNFV Documentation on all interfaces will be provided.
==== Dependencies: ====
There are no other OPNFV projects on OpenStack based and ONF compliant management of VNFFGs.
This project is dependent on OpenStack development work for VNFFG, Service VM and Policy. 
The SFC architecture is dependent on ONF SFC architecture specification work in the L4-L7 Work Group [ONF-SFC].
The SFC encapsulation in the data-plane is dependent on ongoing work in the SFC workgroup in IETF [SFC-ARCH] and [SFC-SCH].  
==== References ====
  * [NFVMAN001]	ETSI GS NFV MAN 001 Management and Orchestration
  * [NFVSWA001]	ETSI GS NFV SWA 001 NFV Virtual Network Functions Architecture
  * [ONF-SFC]	ONF Service Chain Architecture
  * [SFC-ARCH]  IETF Service Function Chaining (SFC) Architecture draft-ietf-sfc-architecture-02
  * [SFC-SCH]   IETF Service Chain Header draft-zhang-sfc-sch-02
===== Key Project Facts =====
 Repo name:  vnf_forwarding_graph
  * Data-plane interface D1 is the interface between the Classifier, Service Function Forwarder, and Service Proxy Device. An overlay network, such as VXLAN, creates a service transport domain connecting the Classifier, Service Function Forwarder, and the Proxy Device. 
  * Data-plane interface D2 is the interface between the Service Function Forwarder and SCH-aware VNF. 
  * Data-plane interface D3 is the interface between the Proxy Device and non SCH-aware VNF. 
==== Documentation: ====
OPNFV Documentation on all interfaces will be provided.
==== Dependencies: ====
There are no other OPNFV projects on OpenStack based and ONF compliant management of VNFFGs.
This project is dependent on OpenStack development work for VNFFG, Service VM and Policy. 
The SFC architecture is dependent on ONF SFC architecture specification work in the L4-L7 Work Group [ONF-SFC].
The SFC encapsulation in the data-plane is dependent on ongoing work in the SFC workgroup in IETF [SFC-ARCH] and [SFC-SCH].  
==== References ====
  * [NFVMAN001]	ETSI GS NFV MAN 001 Management and Orchestration
  * [NFVSWA001]	ETSI GS NFV SWA 001 NFV Virtual Network Functions Architecture
  * [ONF-SFC]	ONF Service Chain Architecture
  * [SFC-ARCH]  IETF Service Function Chaining (SFC) Architecture draft-ietf-sfc-architecture-02
  * [SFC-SCH]   IETF Service Chain Header draft-zhang-sfc-sch-02
===== Key Project Facts =====
 Repo name:  vnf_forwarding_graph