OVS Wrapper

OVS Networking Wrapper

Service Function Chaining is a fundamental operation at the very bottom of the NFV concept. Nonetheless and maybe for this reason, there is no standard solution to SFC in the most common VIMs or cloud managers. Project Service Insertion And Chaining of OpenStack Neutron and IETF NSH protocol draft are among the various examples of how SFC could be implemented. Since none of this solution is at a mature stage or provides a mature implementation yet, we implemented our own custom SFC agent. The agent allows inserting flow rules in the OVS switch used by OpenStack VIM to redirect traffic from port to port through a chain of virtual machines. The OVS wrapper is the VIM Network Wrapper responsible for wrapping SFC request coming from the MANO framework into the series of commands needed to enforce such SFC configurations in the VIM. The OVS wrapper takes as input path that needs to be configured, represented by lists of VNF connection points, and the VNF record with the information on the ports and internal connectivity of VNF and VNFC. This information is used to map the chains into ordered list of OpenStack virtual ports (i.e. layer 2 MAC addresses), that can be sent to the TANGO SFC agent, together with information (source/destination addresses) on the flows that must be steered through the chain and on the service instance the chain belongs to.

TANGO Service Function Chaining agent

Our own custom SFC agent is based on OpenVSwitch, in particular on the ovs-ofctl, which allows to set and manage open flow rules. This agent, running on the Neutron controller of an OpenStack instance, can re-write flow rules so to re-direct specific flows, identified by a pair of IP addresses, through an ordered list of ports, identified by their MAC address, i.e. input and output ports of the VNFCs running inside that OpenStack instance. The TANGO IA provides a relevant network wrapper that is able to interact with this SFC agent, providing the ordered list of MAC addresses ports which compose the chain and the flow identifier. The ordered set of MAC addresses is created by the wrapper, which parses the forwarding paths in the forwarding graph, mapping each edge of the graph to the pair of MAC addresses associated with the connection point that the edge unite, using the information contained in the provided NSR and VNFR. Upon launch, the SFC Agent open a TCP socket at default port 55555 and awaits for an appropriate JSON payload. When such payload is accepted, then the Agent places flow rules that drive the incoming traffic, with the relevant start and destination point, through the internal virtual bridges created and eventually through the requested VNF ports with the order requested. Finally it drives the traffic back to the WAN.

As mentioned the SFC agent exposes two API calls through a TCP socket listening on default port 55555. It expects payloads formatted as JSON string, encoded in UTF-8. The appropriate JSON format for each call is:

ADD

{
  action : 'add',
  in_segment : String,
  out_segment : String,
  instance_id : String, 
  port_list : [
    {
      port : String,
      order : Integer
    }
  ]
}

• action: this field should be "add" for this function
• in_segment: CIDR (x.x.x.x/n) of the source address of the flow to be steered through the chain
• out_segment: CIDR (x.x.x.x/n) of the destination address of the flow to be steered through the chain
• instance_id: an identifier for the chain
• port: a String with the MAC address of a virtual interface
• order: an integer indicating the order of the port in the chain (starts with 0

DELETE

{ "action":"delete", "instance_id":"0000-00000000-00000000-0000" }

• action: this field should be "delete" for this function
• instance_id: an identifier for the chain