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 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.
This goal of the project is to demonstrate an OpenStack based and OpenFlow compliant solution which will dynamically set up VNFFG so that different tenants’ flows can be steered through different sequence of VNFs. The diagram below shows the VNF Chaining Architecture which is in line with Figure 4 in the ETSI NFV Architecture [NFVSWA001] and ONF Service Chain Architecture [ONF-SFC]. The NFV VNFFG architecture consists of the OpenStack-based VNFFG Manager, multiple OpenFlow based SDN Controllers, and other components in the NFV infrastructure such as the Traffic Classifiers hosted on the Server, the Service Function Forwarders hosted on vSwitch and the Service Functions running on VMs.
|Management||VNFFG Manager, VNF Instance Manager|
|Data||Classifier, SF Forwarder(Proxy), VNF Nodes|
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.
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.
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.
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.
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.
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.
The Proxy Device is used to interface with a non SFC Header-aware VNF.
The management interfaces include:
The control plane interfaces include:
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.
OPNFV Documentation on all interfaces will be provided.
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].
Any other contributors:
The following features will be developed as part of the project.
This project is built on top of OpenStack code base and has a dependency on successful integration of OpenStack code into OPNFV platform. It is also dependent on current development work for Intent Based Specification of Service Chaining and Service Instance Registration & Integration targeted at the OpenStack L release. So the first phase delivery of this OPNFV project will be a vendor-neutral SFC requirement and Interface specification that is based on OpenStack+SDN Controller integration and is ONF architecture compliant.
The second phase will bring in the code of the OpenStack VNFFG Orchestrator/Manager including the Intent Based SFC Interface, SFC Path Construction functionality on the SDN Controller, flow classification and Service Function Forwarder functionality on vSwitch. OpenStack VNFFG Manager will be developed in OpenStack targeted at L release time frame and then ported over to OPNFV. SFC path computation will be added to the SDN Controller. Flow classification and SFF functionality will be added to Open vSwitch code base. The interface between SDN Controller and vSwitch will be based on OpenFlow and its extensions.
The OpenStack VNFFG Manager, SDN Controller, VNFFG Classifier and the vSwitch will be developed as part of the project. In addition, Service Chain related work in OpenStack Horizon will also be included in the contribution.
The management plane, control plane, and the data plane interfaces described in the “Scope” section will be contributed as part of this project
May 2015 or aligned with OPNFV release.