[[PageOutline]] This page describes how to write [http://www.protogeni.net/trac/protogeni/wiki/RSpecSchema2 GENI compliant] Openflow rspecs. These new rspecs are supported by FOAM, the new Openflow AM. This page also provides instructions and how to convert Expedient rspecs to the new form of rspecs. For a detailed explanation of the tags and attributes look at [wiki:HowTo/WriteOFv3Rspecs/Spec this specification page]. = Openflow Slivers = In an Openflow Aggregate, an experimenter can control how the packets are forwarded within the network, using a custom controller running in an external compute resource. In the general case an Openflow Aggregate consists of Openflow-enabled devices(e.g. switches) which forward packets based on instructions received by the controllers. The traffic of an Openflow network can be sliced, using matching rules on the traversing packets. A set of rules that describes part of the passing traffic is called a ''flowspace''. A flowspace can be defined based on the datapath ids (aka dpids) and ports that the packets are going through, and/or based on their headers. Datapath is a virtual network device that is controlled using the Openflow protocol and can forward packets. So for example a switch running an Openflow compatible firmware might be a datapath. More details about how Openflow works and about which fields of the packet headers can be used in flowspaces can be found in the [http://www.openflow.org/documents/openflow-spec-v1.0.0.pdf Openflow Spec 1.0.0] and in the [http://www.openflow.org/ Openflow website]. For example a sliver on an Openflow network might request for : ''"All packets coming in port 5 on datapath 15, and have a source IP address in subnet 10.10.10.0/24."''' = Writing !OpenFlowv3 request rspecs = The best way to understand and write FOAM rspecs is by looking at example rspecs. Keep in mind that the rspec is merely a structured representation of flowspaces that describe the traffic that an experiment wants to control. This [https://openflow.stanford.edu/display/FOAM/rspec example rspec], is a complete example. In [wiki:HowTo/WriteOFv3Rspecs/Examples this wiki page] you can also find other simpler examples. In essence your rspec should: 1. start with the and the tags : {{{ #!xml }}} 2. Specify where your controller is running. E.g.: {{{ #!xml }}} 3. Organize the datapaths that are relevant to this sliver within groups. The best way to construct the elements is by copying them from the advertisement rspecs. E.g if [attachment:ad-sample.rspec this] is the advertisement rspec, and you want : * ports 7 and 20 of datapath with dpid 06:a4:00:12:e2:b8:a5:d0 * ports 50 and 71 of datapath with dpid 06:af:00:24:a8:c4:b9:00 Then you can construct a group that looks like : {{{ #!xml }}} 4. Specify your flowspace. E.g. if you want for the above group to get all traffic that is sourced or destined to the IP subnet 10.1.1.0/24 and uses tcp port 80, then you will need two tags, one to match the packets that are sourced from that subnet and one to match the packets that are destined to that subnet. Keep in mind that your flowspace is the union of the traffic that is described by each. If you need to get a list of all possible filters and how the tags are named look [wiki:HowTo/WriteOFv3Rspecs/Spec#Filterelements here.] {{{ #!xml }}} Notice that although we need to match on IP source/destination and on the transport protocol port, we also applied filters to ensure that the packet is an IP packet and that the IP protocol is TCP or UDP. Openflow can filter on any Layer 2, Layer 3 or Layer 4 header field but you would need to match the type on the lower level in order to filter at the higher one, e.g. in order to match on IP fields you need to first ensure that the packet is indeed an IP packet. Done! The complete rspec looks like : {{{ #!xml }}} = !OpenFlowv3 vs v2 and v1 (FOAM vs Expedient)= Although OpenFlow rspecs version 3 (supported by FOAM) are completely different in structure from previous Openflow rspecs (supported by Expedient), all of them basically describe the same information, so it should be straight forward, though manual, to translate from one rspec format to the other. Before starting with the conversion get familiar with the Openflow v3 rspecs by looking at [wiki:http://groups.geni.net/geni/wiki/HowTo/WriteOFv3Rspecs/Examples examples]. If you are starting with an Expedient (v1 or v2) rspec basic guidlines are * replace tag with the tag, look at the [[https://openflow.stanford.edu/display/FOAM/rspec example rspec] for how this looks like. * the rest of the rspec should be inside the tag * the , , tags do not exist anymore but some of the information there is used in the and tags. In detail : * => * => * => * In tag set the type attribute as primary {{{ #!xml OPENFLOW v1-2 OPENFLOW v3 }}} * The tag is now called * Both and tags map to the tag. * a switch tag corresponds to an with no tags. Just like in v1-2, an tag with no ports implies the whole datapath. {{{ #!xml OPENFLOW v1-2 OPENFLOW v3 }}} * a port tag corresponds to an tag with {{{ #!xml OPENFLOW v1-2 OPENFLOW v3 }}}