Please Note: This website has been archived and is no longer maintained.
See the Open Networking Foundation for current OpenFlow-related information.

Virtual Ports

From OpenFlow Wiki

Jump to: navigation, search

Contents

High Level

  • Re-use the existing physical "port" interface for additional functionality:
    • Quality of Service - Main goal *for now*
    • For later:
      • Tunneling
      • Encryption (isn't this just a type of tunnel?)
  • Critical/Subtle design feature: physical ports and virtual ports are in the same 16-bit name space. For example, if a switch had physical ports numbered 1-8, the first virtual port would dynamically appear as "port 9", the second as "port 10", etc. This allows the rest of the openflow protocol to transparently use virtual ports in any place a physical port could be used, i.e., output action, port_status, etc.
  • This design allows a number of subtle but nice features:
    • support for creating virtual ports from other virtual ports, e.g., hierarchical QoS in high-end switches and routers
    • packets that come from virtual ports need no special handling from the controller
      • see False steps for other solutions
  • Implementation should be done through vendors extensions.This allows to test the vendor extension functionality and be compatible with OpenFlow until merging with OpenFlow spec.

New Messages

  • ofpe_vport_create
    • ask the switch to dynamically create a new virtual port with given properties
    • parameters are a port number and a list of properties (see below)
  • ofpe_vport_query
    • queries for the details of a port. These are virtual port specific details (parents, properties etc). Other details (stats,BW etc) can be retrieved by the standard OpenFlow messages.
    • querries for port OFPP_ALL should return a list of all virtual ports
  • ofpe_vport_response
    • response from switch to create and query message;
      • for now, error codes should be returned using the predefined BAD_VENDOR, BAD_SUBTYPE. Though, we may need to have more specific messages such as NO_RESOURCES etc.
      • reflects only the virtual ports characteristics (parent,properties etc).
  • ofpe_vport_destroy
    • destroys the virtual port. (port should not have any children)

A detailed description of these can be found here

Virtual Port Properties

  • initially only QoS
    • property "weighted round robin"
      • parameter is 16 bit weight
    • property WFQ
      • parameter is 16 bit weight
    • add more QoS properties as needed
  • eventually have "tunnel", "encryption", etc. properties

Example uses

  • a controller manages a switch with 4 ports (netfpga) and wants to ensure that non-bittorrent traffic has at least 80% of the bandwidth on port 2
    • controller sends two create_vport_request messages
      • the first with port=2 and property list to be WFQ, weight =8
        • this returns a new virtual port 5
      • the second with port=2 and property list to be WFQ, weight =2
        • this returns a new virtual port 6
    • for each new flow, the controller decides if the flow is using bittorrent or not (potentially by tcp port) and sets the output port of that flow to port 5 if not bittorrent or 6 if it is
  • the flowvisor wants to ensure that each of 4 experiments does not hog disproportionate traffic
    • the flowvisor creates 4 create_vport_requests, each for WFQ with weight=1
    • when the flowvisor rewrites each guests features_reply message, it removes mention of the switches physical ports and only leaves the corresponding virtual port
      • the guest controller can use the virtual port transparently just like it is a physical port

False Steps

Things we thought about but don't seem to work
  • Adding a separate "Queue" type that is different than a physical port
    • we would need new output actions for Queues vs physical ports
    • you couldn't tag a queue for flooding via port_mod (create a new msg?)
    • you couldn't query a queue's statistics via stats_request
    • just seems like a mess, and then you would have to repeat for tunneling, etc.


  • Tunnels shouldn't be implemented as an "encap/decap" action
    • at tunnel end points, you want the packets coming out of the tunnels to be checked against the flow table *after* they are decapsulated, i.e., just as if they had come in off of a physical port
    • If tunnels were implemented as an encap/decap actions, this wouldn't seem possible
      • what fields would you match on? everything in the tunneled packet would be offset by the tunneling encapsulation layer