Nice tutorial presentation on Openstack Horizon with AngularJS

https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/beyond-the-horizon-innovating-and-customizing-horizon-using-angularjs

Good textual information here:
http://superuser.openstack.org/articles/kilo-update-horizon

Pasting the relevant text here:

"

AngularJS

One of the main areas of focus for Horizon has been around better user experience. Horizon has been moving towards AngularJS as a client-side architecture in order to provide better, faster feedback to users, decrease the amount of data loading on each request, and push more of the UI onto the client side.

For the Kilo release, the team is working on a reference implementation to dictate how AngularJS will be implemented in Horizon.

Improved Table Experience

Currently, filtering and pagination within Horizon are inconsistent. For Kilo, the table experience will be improved by much of it to the client side, caching more data on the client and providing pagination and filtering in the Horizon code instead of relying on the APIs to do it.

David hopes this results in a more consistent user experience, and takes the guesswork out of understanding the paradigm on each page.

Wizard

There is a wizard in Horizon currently, but it's primitive and it has remained largely stagnant through Havana and Icehouse. David said he plans to refocus on that in this release because it's one of the biggest usability issues Horizon faces -- the launch instance workflow is confusing and requires a lot of upfront knowledge.

The Horizon team has been working with the OpenStack UX team to design a better workflow that will be implemented on the client side. The team will use the network wizard as well to make sure they have an extensible format and an extensible widget.

Refine plugin support

It’s important that Horizon has a clean plug-in mechanism that doesn’t involve editing horizon source code.

Right now it requires a user to add files into the directory where Horizon gets deployed; this isn't optimal because it causes problems when a user wants to update a package. The Kilo version of Horizon will have refined plug-in support that allows users to point to where the plug-in mechanism is and provide better Angular support.

Better theming

One concern that operators have is that they don't want to ship Horizon with the same UI as everyone else, especially if they’re putting it in front of customers. David said there's a need to be able to theme it better without having to hack the code.

The team plans to continue development and provide an improved theming mechanism that's easy to work with.

"

Security in Hybrid Cloud sans Private Cloud

Check this link :  http://blogs.barrons.com/techtraderdaily/2015/10/21/vmware-plunges-16-business-eaten-alive-by-the-public-cloud-says-street/?mod=yahoobarrons&ru=yahoo

Few predictions made before are becoming reality.  Pure private clouds are disappearing slowly. Enterprises are increasingly using public clouds for may workloads and going for very small private clouds for critical workloads.  Combination of public cloud hosting with private cloud is called hybrid cloud.

I believe that hybrid cloud market as defined today (Private + Public combination) would decline over time and would become niche market.  But another other kind of hybrid cloud market, where Enterprises use multiple public clouds, would increase in future.

Security considerations :  In my view,  Enterprises need to  embed security in their workloads and not depend on generic security solutions provided by cloud operators.  Few reasons on why this is required.

• Enterprises may need to host their services in various countries, where there may not be stringent laws on data protection,  data security.   
• Enterprises may not like to depend on the integrity of administrators of Cloud operators.
• Enterprises may not like Cloud operators to share the data & security keys to governments without their consent 

What it means is that :

• Enterprises would need to consider hypervisor domain as insecure, at least for data.

What is it Enterprises would do in future :

• Security will be built within the workloads (VMs)
• Threat Security such as firewall, IPS, WAF.
• Transport level data security such as SSL/TLS.
• Network Level Security such as Ipsec, OpenVPN
• Visibility would be built into the virtual machines for 
• Performance visibility
• Traffic visibility
• Flow visibility

Essentially, virtual machines would have all necessary security and visibility agents built into them. Centralized management systems, controlled by Enterprises,  will now configure these agents from a central location to make the configuration & management simpler.

There is a concern that if security is built into the VMs, then attacker exploiting the applications in the VMs may be able to disable the built-in security functions, falsify the data or send wrong information to analytic engines. 

That is a valid concern.  I believe that containers would help in mitigating those concerns.

• Run all security functions in the root container of  the VM.
• Run applications in non-root containers within the VM

Isolation provided by containers can mitigate the challenges associated with combining security with the applications.

Service Chaining :  Traditionally, multiple security services are applied by middle virtual appliances. If the traffic is encrypted end-to-end,  these middle virtual appliances will not be able to do good job. Yes, that is true.  This can be solved by Cloud-SFC (SFFs within the virtual machines) where VM SFF itself steer the traffic to various middle appliances or container services within the VM.  More later on this...

I believe that with increasing popularity, flexibility, scale-out, performance provided by CSPs,  it is just matter of time where private clouds would disappear or decline dramatically.  Cloud users (Enterprises) would go for inbuilt security within VMs to host them in public clouds and security/visibility companies would have to address this trend. In  my view only those security/visibility companies would survive.  May be dramatic?  What do you think?

Great and informative post about Micro-Service Architecture

Please see this post in techtarget -

 http://searchsoa.techtarget.com/tip/What-does-microservice-architecture-mean-for-the-cloud?utm_medium=EM&asrc=EM_NLN_48284106&utm_campaign=20151005_How%20will%20microservices%20impact%20the%20cloud?_fchurchville&utm_source=NLN&track=NL-1839&ad=903312&src=903312

It is logical to think that micro-service architecture requires store-front service which hides all the complexities of various micro services.  As the post says, it is also required multiple store-front services need to be chained externally.  By breaking the architecture into this two dimension solution, it provides flexibility and reduction in complexity.

Since SFC kind of solutions can be used to chain multiple store-front services , scale-out, reliability are taken care by SFC solutions.

But the services hidden by the store-front services need to have similar scale-out and high availability properties.  It means that store-front services need to be not only be providing a service, but also work as some kind of orchestrator of services working with VIM (virtual infrastructure manager) such as NOVA and Magnum to bring-up/bring-down micro-services they are front-ending.

It did not cross my mind that service VMs or service containers could be interacting with the schedulers. It certainly makes sense keeping this kind of architecture.

Great post from Tom Nolle on TechTarget.  Really enjoyed reading it.

I wonder what kind of security requirements that would prop-up in this kind of solution architecture.  I am guessing that security within the service would be a simpler solution.

Comments?

Openflow based Local fast path for distributed Security

OPNFV DPACC working group is trying to standardize the accelerator interface for vNFs to accelerate the workloads.

Accelerator standardization is required to ensure that  the virtual appliances can work on different types of compute nodes - Compute nodes having no acceleration hardware,  compute nodes having accelerator hardware from vendor 1,  compute nodes having accelerator hardware from vendor 2 etc..
Above becomes critical in cloud environments as compute node hardware is procured independent of procurement of virtual appliances.  Virtual appliance vendors like to have their virtual appliances' images work on multiple compute nodes.  Operators likes to ensure that any virtual appliances they purchase continue to work with future compute node hardware.

OPNFV DPACC team goal is to identify  various acceleration types. And then define software based interface for each acceleration type.

VMM which is typically bound to the compute node hardware is expected to have conversion module from the software interface to local hardware interface.

OPNFV DPACC team is choosing virtio and vring transport to implement software interface.

Accelerations normally fall into two categories -  Look-aside model and Inline/fast-path model.  In Look-aside model,  virtual appliance software sends command to the accelerator and expect response for each command.  The response can come back to virtual appliance in synchronous fashion or asynchronous fashion.  Inline/fast-path model typically is for packet processing kind of vNFs.  Any network function that does not need to inspect all the packets can take advantage of inline/fast-path acceleration model.

In inline/fast-path acceleration model,  network function in virtual appliance establishes a session state (either pro-actively or re-actively to the packets) and then it expects the fast-path accelerator to process further packets.

Many smart-NIC vendors provide facilities to their customers to create fast-path functions in the smart-NIC.  In physical appliances, typically this works best.  Physical appliances are fixed functions and the entire software and hardware comes from one vendor.  This vendor would ensure that both normal network function and fast-path functions work together.

In virtual world,  smart-NIC comes from one vendor and virtual appliances come from separate vendors.  Also, it is unknown at smart-NIC build time, the network functions that would be hosted on the compute node.  It may seem that smart-NIC vendors need to have all types of fast-path functions implemented in the smart-NIC.  It is obvious that it is not feasible and the smart-NIC may not have too much of code space to put all kinds of fast-path functions.  Note that, smart-NIC could be based on FPGA or constrained network processor.

Another model could be that smart-NIC is populated dynamically with fast-path functions based on the type of virtual appliances are being brought up on that node.  This also could be a problematic as there could be multiple smart-NIC vendors using various processors/network-processors/FPGA etc..  Hence, one may need to create similar fast path functions for many smart-NIC types.  There is always security & reliability issues as these functions may not co-exist s they come from various vendors.  Some function may misbehave or some functions might crash other functions. In addition, there is always a concern on amount of time it adds to bringing up and bringing down the virtual appliance.

Hence, some in OPNFV DPACC team believe that smart-NIC must implement flow processor such as openflow.  Openflow has very good advantages, Some of them are :

• Only one logic module.
• One could create multiple instances.
• Each instance can be controlled by separate entity.
• Multiple tables in each instance.
• Flows in the table can be pipelined.
• Flows can be programmed with pre-defined actions.

If smart-NIC implements OF,  orchestration module can create an instance for each vNF and assign the instance ownership for that vNF.  vNF at run time can program the flows with appropriate actions to create the fast path for those flows.  

It is already proven in Industry that OF and some proprietary extensions can be used to realize IPSec,  Firewall, NAT, forwarding,  SLB fast paths.  

Please see this link on the presentation slides made to OPNFV DPACC :  https://wiki.opnfv.org/_media/opnfv-dpacc-fast-path-and-inline-acceleration-flow-processor_v1.pdf.  This slide deck provides graphical picture of above description.

Comments?  Please post your comments here or  at https://app.pivot-it.com/public-583/Open-flow-based-distributed-data-path-for-virtualised-data-centers-openflowdatapath/enter/

Configuration relay feature in Open-SFC

https://github.com/Open-SFC - Even though Open-SFC project is for "Service Function Chaining", there is one feature called "Configuration relay" which is  very useful generic feature. 

Openstack neutron advanced services project provides configuration support for few network services.  VPN-as-a-Service,  Firewall-as-a-Service and LB-as-a-Service are few examples.  These services provide RESTFul API for IPSec VPN,  Stateful firewall and Load balancers.  These services also follow similar “plugins” and “agents” paradigm.  Plugins implement the RESTful API and store the configuration in the database.  Also,  these plugin send the configuration to the Agents.   Agents, today run in the "Network Nodes", which receives the configuration from plugin and configure local services such as Strongswan,  IP Tables and HA proxy.  Here, network nodes are reachable from the Openstack controller and hence plugin drivers and agents can communicate with each other (via AMQP).

In recent past, many network services are being implemented as vNFs.  With distributed security and end-to-end security becoming norm,  network security services (such as firewall and IPSec VPN) are embedded within the application VMs.  In these cases, advanced-network-service agents need to be run in these virtual machines.   But, there is an issue of communication reachability between plugin drivers and agents.  Virtual machines are on the data network and controller nodes are in the management network.  For isolation/security reasons,  virtual machines are normally not allowed to send/receive traffic from the management network directly.

Configuration relay is expected to mitigate this issue.  Configuration relay is expected to run in each compute node in the VMM/Hypervisor.  Since VMM is reachable from the controllers,  this relay in the VMM becomes conduit (just for configuration) between network service plugin drivers with the agents in the local virtual machines.

I will post more information on how this relay works technically. But following repositories/directories have source code.

FSL_NOVA_SerialPort_Patch in https://github.com/Open-SFC/nova is patch to the nova portion of the compute node – This patch allows creation of virtio-serial port (to allow communication between local virtual machine and configuration relay) via libvirtd and QEMU. 

crd_relay_agent.py and remote_control.py in https://github.com/Open-SFC/nscs/tree/master/nscs/crd_relay_agent is a small service in compute that enabled configuration relay.

Example program in the vNF that communicates with relay to get hold of configuration :  https://github.com/Open-SFC/nscs/tree/master/nscs/vNF_cfg_daemon  (Based on comment posted by Srikanth)

Thanks

Srini

VxLAN & Openflow Controller Role

 

Background

In one of previous posts here,  I argued that there is no need for Openflow controller to realize virtual networks.  In the same post,  I also mentioned that Openflow controller is required if intelligent traffic redirection is required to realize features such as network service chaining and advanced traffic visualization.  These advanced features require to control the traffic path on per flow basis (5-tuple based connections) across physical/virtual appliances.

VxLAN, by default, tries to discover the remote endpoint  using discovery mechanism. This discovery mechanism involves sending the packet using  multicast VxLAN encapsulation.   Compute nodes or end points that owns the DMAC address of the inner packet expects to consume the packet.  Using learning mechanisms,  each VxLAN end point creates VTEP entries.  Once VTEPs are learnt,  packets are sent only to the intended endpoint.  Please see this VxLAN tutorial to understand the VxLAN functionality. 

As discussed in the post about OVS & VxLAN based networks, OVS supports flow based overlay parameters such as remote endpoint address,  VNI etc.. 

Use cases requiring control from Openflow controller

One use case as briefly touched upon is the flow-control (FC) which is a some central entity across Openflow virtual switches controlling the traffic path, possibly on per connection basis. FC functionality running on top of OF controller, gets the packet-in (miss packet) from the OVS,  decides the next destination (an appliance implementing a network service) and then programs the flow in OF switch with appropriate overlay parameters.

Another use case of OF controller, in realizing VxLAN based virtual networking support, is send/receive of multicast & broadcast packets.  VxLAN specifications support multicast transport  for transporting inner mutlticast and broadcast packets.  As discussed above,  FC functionality is expected to get hold of any inner flows whether they are unicast based, multicast based or broadcast based.   Also,  I hear that many times some network operators don't allow multicast packets in their network infrastructure, but at the same time, they don't like to stop VMs using Multicast based protocols. OF Controller  can provide a feature to duplicate the broadcast and multicast inner packets as many times as number of possible destinations of the virtual network and send them over VxLAN using unicast VxLAN encapsulation.

Support available in Cloud Orchestration tools (Openstack)

Fortunately, in cloud computing world, Openstack already maintains inventory information such as

• Physical servers and their IP addresses.
• VMs on each physical server and MAC addresses of the VM Ethernet Ports.
• Virtual networks (VLAN based, VxLAN based or other overlay based).
• Physical servers that are participating in a given virtual network.
• Ports on OVS that are connected to the VMs and which virtual network they belong to.

Openstack provides APIs to get  hold of above information.  Also. Openstack has ability to notify interested parties when the repository changes.  Openflow controller can have a service called 'Cloud Resource Discovery' whose functionality is to keep the cloud resource repository in OF controller and make it available to OF controller applications such as FC. 

• When it comes up, it can go and read above information and keeps the repository with it. Also, it can register to get the notifications.  
• Upon any notification,  update local repository information. 

Note that there could be multiple OF controllers working in a cluster to take care of the load among them.  Since Openstack is one entity across OF controllers, responsibility of ensuring that the cloud repository is consistent across OF controllers is with the Openstack entity.

Details of OF Controller Role

Now, let us discuss the capabilities required in OF controllers to realize VxLAN based virtual networks to take of two functions - Enable FC & Work with Multicast/Broadcast packets.  In this,  I am assuming that OF controller is being used along side with Openstack. I am also assuming that VMs are the ones which are generating the traffic destined for another VM.  OVS is used to implement OF virtual switches and VxLAN overlays.  Essentially, OVS provides virtual switch where VMs are connected to on its north side and VxLAN ports which are connected to it on south side.

OF Controller predominantly need to have three main components;

• Cloud Resource Discovery (CRD) component
• Flow Control (FC) component
• OF Controller Transport (OCT) component (such as Opendaylight,  Freescale Openflow Controller Transport,  NOX Controller etc..).

Cloud Discovery component: 

Discovers following from Openstack

•  Virtual Networks configured
•  Physical Servers (OF Capable switches)
•  OF Logical switches within each OF Capable switch (For example, in Openstack world,  there are always to OF logical switch br-int and br-tun).
•  Names of ports attached to the OF logical switches
• Qualification of Ports (Network Port,  Port that is connected to VM  or patch port and the virtual network it corresponds to).
• Local VLAN IDs used in br-int of each OF Capable switch and their mapping to VxLAN network and dices.
• VMs - MAC Addresses and the corresponding physical servers.

Repositories:

OF Controller components typically maintain the repository, which is either populated by  CRD.  Many OCT do have repositories.  For example,  Freescale OCT has capability to store via its DPRM module

• OF Capable switches
• OF logical switches in each OF capable switch
• Containers (Domains)
• OF Logical switches that belong to domains.
• Port names associated with OF logical switch.
• Table names associated with each domain.
• It also has ability to put various attributes to each of above elements for extensibility.

Additional repositories are required : 

• Virtual Networks.  For each virtual network
• Fields:
• Virtual Network Name
• Virtual Network Description.
• Type of virtual network
• In case of VLAN:
• VLAN ID

• In case of VxLAN
• VNI

• Attributes
• To store the Openstack UUID.
• List of references to OF Capable switches.
• In each reference  node
• Array of OF Logical switch references. (Example:  br-int, br-tun)
• For br-int logical switch
• List of references of Ports that are connected towards VMs.
• For each reference,  also  store the reference to VM.
• List of references of ports that are connected to br-tun.
• For  br-tun logical switch
• List of references of ports that are connected to br-int
• List of references of ports that are connected to network
• List of references to OF VMs
• List of references to Ports that are 
• Views:
• Based on name
• Based on Openstack UUID

•  VM Repository - Each record consists of
• Fields:
• VM Name
• VM Description
• Attributes;
• Openstack VM UUID
• Kind of VM -  Normal Application VM or  NS VM.
• List of references of ports connected towards this VM  on br-int (MAC address is supposed to be part of the Port repository in DPRM).  Fore each reference
• VLAN associated with it (in br-int)
• Reference to Virtual Network.
• Reference to physical server (OF Capable switch)
• Views
• Based on VM name
• Based on VM UUID

•  Cell Repository
•  Availability Zone repository
•  Host Aggregate  repository

Existing repositories would be updated with following:

•  Port repository in each OF logical switch: Each port entry is updated with using attributes
•  Port Qualification attribute
• VM Port or Network Port or Patch Port.
• MAC Address attribute 
• MAC Address (in case this is connected to VM port)
• VM Reference attribute:
• Reference to VM record.
•  Virtual Network Reference attribute
• Reference to Virtual network record.
• OF Switch Repository :  I am not sure whether this is useful anywhere, but it is good to have following attributes 
• VM Reference attribute
• List of references to VMs that are being hosted by this switch.
• VN References attribute:
• List of references to VNs for which this switch is part of.
• Availability Zone Reference attribute
• Reference to  availability Zone record
• Host Aggregate Zone Reference Attribute
• Reference Host Aggregate Zone record.
• Cell Reference Attribute
• Reference to Cell record 

Flow Control

This component is the one which creates flows based on the information available in the repositories.  Assuming the flow granularity is at the connection level,  first packet from a VM of any connection results into a packet-miss (packet-in) in br-int.  OF controller Transport receives it from the OF switch and gives it over to the FC.  FC application knows the DPID of the switch,  in_port of the packet. From this information,  port repository is checked and from the port repository it finds the virtual network information such as local VLAN ID used in br-int and VxLAN VNI. It also finds out the remote IP address of the overlay endpoint based on VM MAC (DMAC of the packet).

Assuming that VMs communicating are in different compute nodes,  there are total 8 flows the FC module would need to create to let rest of packets of the connection go through between two VMs.
Any connection contains client-to-server side and server-to-client side.  There are two OF logical switches in each compute node.  Since, there are two compute nodes, total flows would be 2 (Due to Client to Server AND Server to Client) * 2 (Due to two Openflow switches) * 2 (because of two compute nodes).

Example:
Let us assume that compute nodes, node1 & node2, have outIP1  and outIP2 IP addresses.
Let us also assume that VM1 on Node1 is making HTTP connection (TCP, source port 30000,  destination port 80) with VM2 on Node2.  VM1 IP address is inIP1 and VM2 IP address InIP2.   Let us also assume that VxLAN  uses port number 5000.

When VxLAN based network is created,  let us assume that OVS agent created local VLAN 100 on node1 and VLAN 101 on Node2 for VxLAN network whose VNI is 2000.

FC establishes the following flows:

• Node1
• BR-INT:
• Client to Server flow
• Match fields
• Input Port ID:  < Port ID to which VM is connected to>
• Source IP;  inIP1
• Destination IP:  inIP2
• Protocol:  TCP
• source port : 30000
• destination port: 80
• Actions:
• Add VLAN tag 100 to the packet.
• Output port :  Patch Port that is connected between br-int and br-tun.
• Server to Client flow
• Match fields:
• Input Port ID: 
• VLAN ID: 100
• Source IP: inIP2
• Destination IP: inIP1
• Protocol:  TCP
• Source port: 80
• Destination Port: 30000
• Actions
• Remove VLAN tag 100
• Output port
•  
• BR-TUN
• Client to Server flow
• Match fields:
• Input Port ID:  Patch Port 
• VLAN ID:  100
• Source IP;  inIP1
• Destination IP:  inIP2
• Protocol:  TCP
• source port : 30000
• destination port: 80
• Actions
• Set Field:
• Tunnel ID: 2000
• Tunnel IP : outIP2
• Remove VLAN tag 100
• Output Port: 
• Server to Client flow:
• Match fields:
• Input Port ID: 
• Tunnel ID:  2000
• Source IP: inIP2
• Destination IP: inIP1
• Protocol:  TCP
• Source port: 80
• Destination Port: 30000
• Actions
•  Add VLAN tag 100
• Output port: < br-tun end of patch port pair>
• Node 2:
• BR-INT:
• Server to Client flow:
• Match fields
• Input Port ID:  < Port ID to which VM is connected to>
• Source IP;  inIP2
• Destination IP:  inIP1
• Protocol:  TCP
• source port :80
• destination port: 30000
• Actions:
• Add VLAN tag 101 to the packet.
• Output port :  .
• Client to Server flow
• Match fields
• Input Port ID:
• VLAN ID: 101
• Source IP: inIP1
• Destination IP: inIP2
• Protocol:  TCP
• source port: 30000
• destination port: 80
• Actions:
• Remove VLAN tag 101
• Output port: 
• BR-TUN :
• Client to Server flow:
• Match fields:
• Input Port ID: 
• Tunnel ID:  2000
• Source IP;  inIP1
• Destination IP:  inIP2
• Protocol:  TCP
• source port : 30000
• destination port: 80
•  Actions
• Add VLAN tag 101
• Output port:
• Server to Client flow:
• Match fields:
• Input port ID:
• VLAN ID: 101
• Source IP;  inIP2
• Destination IP:  inIP1
• Protocol:  TCP
• source port :80
• destination port: 30000
• Actions:
• Set field:
• Tunnel ID: 2000
• Remote IP :  outIP1
•  Remove vlan 101.
•  Output port:

In case of broadcast and multicast inner packets,  FC could use OF 1.3 groups with 'ALL' type with as many buckets as number of destinations.  Each bucket must have action with separate set of 'set-field' actions.

Assume that FC sees a Multicast flow from VM1 in Node1 (outIP1) with DIP: inMIP, UDP protocol and Destination Port : 2222 and Source port 40000.  Assuming that it should go to compute nodes Node2 (outIP2), Node3 (outIP3) and Node4 (outIP4) as there are VMs that are interested in these multicast packets. Then FC would generate following flows in Node1 and Node2.  Flows in Node3 and Node4 look similar.

• Node 1:
• br-int
• Match fields
• Input port: 
• Source IP :  inIP1
• Destination IP:  inMIP
• Protocol: UDP
• Source port: 40000
• Destination POrt:  2222
• Actions
• Add VLAN tag : 100
• Output port: 
•  br-tun
• Group object (G1):
• Type: ALL
• Bucket 1: 
• Set-fields:
• Tunnel ID: 2000
• Remote IP: outIP2
• Remove VLAN tag 100
• Output port:
• Bucket 2
• Set-fields:
• Tunnel ID: 2000
• Remote IP: outIP3
• Remove VLAN tag 100
• Output port:
• Bucket 3
• Set-fields:
• Tunnel ID: 2000
• Remote IP: outIP4
• Remove VLAN tag 100
• Output port:
• Match fields:
• Input port :
• VLAN ID: 100
• Source IP :  inIP1
• Destination IP:  inMIP
• Protocol: UDP
• Source port: 40000
• Destination POrt:  2222
• Actions
• Group Object: G1
•  Node 2
• br-tun
• Match fields:
• Input port:
• Tunnel ID: 2000
• Source IP :  inIP1
• Destination IP:  inMIP
• Protocol: UDP
• Source port: 40000
• Destination Port:  2222
• Actions:
• Push VLAN tag 101
• Output port:
• br-int
• Match fields:
• Input port:
• VLAN ID: 101
• Source IP :  inIP1
• Destination IP:  inMIP
• Protocol: UDP
• Source port: 40000
• Destination Port:  2222
• Actions
• Remove VLAN tag 101
• Output port:

FC would use repository information to create above flows.  Hence it is important to have the repository information arranged in a good data structure to get information upon packet-miss.

Evey flow that is created by FC in OF logical switches, FC maintains the flows locally too.  This is to enable cases where OF switches evict the flows.  When there is a packet-miss due to this,  FC would push the locally available flow into the OF switch.  That is, whenever there is packet-in,  FC first needs to check its local run time flow store before creating new flows by referring to repository.

Few more considerations that FC and CRD components that need to take care of are;

• VM Movement:  When VM is moved,  flows created in the OVS OF switches also should be moved accordingly.  CRD component is expected to listen for VM movement events from Openstack and internally update the repositories.  FC component, in turn, should update the OF flows accordingly - Removing flows from old compute node and put them in new compute node.