HowTo/WriteOFv3Rspecs/Spec

OFv3 rspecs

An Openflow rspec is describing the flowspace for an experiment and thus it has ways of describing datapaths, ports and rules to filter packets based on packet headers.

FOAM, that is an Openflow Aggregate Manager, is using GENI compliant rspecs, with an Openflow extention(v3). You can find an example rspec  here.

Here a list of supported tag is provided. The shorthand notations used in the description is:

[1] An element is mandatory and it can only appear once
[?] An element is optional, but it can appear at most once
[*] An element is optional but it can appear multiple times in the rspec
[+] An element is mandatory , but it can appear multiple times in the rspec

<openflow:sliver>

[1] This element contains all the information about the requested sliver.

Attributes

  • description : [?] a short description of your experiment
  • ref : [?] A URL pointing to a page describing your project
  • email : [?] user's email address that is used by FOAM to send notifications about the sliver.
Children tags
The order of the children matters. Although the rspec can have multiple instances of each child the order should be maintained; i.e. first all the <openflow:controller> tags and then the <openflow:group> and so on.
  1. <openflow:controller> [+]
  2. <openflow:group> [+]
  3. <openflow:match> [+]
Parent tags
<rspec>

<openflow:controller>

[+] This element provides information about the controller for the sliver. It is MANDATORY to have one and only one primary controller.

Attributes

  • url : [1] the information about where your openflow controller is running in the form of tcp:<hostname/ip address>:<tcp port>. Examples : tcp:10.0.0.1:6633 , tcp:myctrl.example.net:6637
  • type : [1] this defines what type of controller this is. There can be only three types of controllers:
    • primary : this is the controller that handles the network traffic and makes decisions about how packets should be forwarded. [MANDATORY to have one and only one primary controller].
    • monitor : a monitor controller can not make decisions about how packets are forwarded, but it has the capability of creating and sending packets in the network, e.g. LLDP packets for performing topology discovery. [An rspec can have more than one monitor controllers]
    • backup : a backup controller is used if the primary controller goes down, multiple backup controllers can be defined and they are used in the order they appear in the request rspec. Right now defining backup monitors will have no effect. [An rspec can have more than one backup controllers]
Children tags
None
Parent tags
<openflow:sliver>

<openflow:group>

[+] This tag is used to group multiple datapath resources together, so they can be used as a bundle in defining matches. So if this sliver is interested in packets that go through some ports on datapaths A, B and C then the group should contain three <openflow:datapath> elements on for each of A, B and C.

Attributes

  • name : [1] this is the name of the group.
Children tags
<openflow:datapath>[*], a group element with no children implies ALL datapaths.
Parent tags
<openflow:sliver>

<openflow:datapath>

[*] This tag provides information about a single datapath resource.

Attributes

  • component_id : [1] the urn of the component, the best way to get this is from the advertisement rspec
  • component_manager_id : [1] is urn of the Openflow Aggregate Manager that manages this resource as listed in the advertisement rspec
Children tags
<openflow:port>[*], a datapath element with no children implies ALL ports
Parent tags
<openflow:group>, <openflow:match>

<openflow:port>

[*] This provides information about a port on a datapath.

Attributes

  • num : [1] the number of the port, the best way to get this is from the advertisement rspec
  • name : [?] the name of the port as defined in the advertisement rspec
Children tags
None
Parent tags
<openflow:datapath>

<openflow:match>

[+] This is the tag for describing requested matches. Conceptually this tag has two parts, one for describing the datapaths in which we would like to control the forwarding of packets and another part that defines filters on which packets to control. The first part is mandatory and uses the <openflow:use-group> and <openflow:datapath> tags. The second part is optional and uses the <openflow:packet> tag. If no filters are defined, ALL packets in the specified datapaths are requested.

Attributes
None
Children tags
The order of the children matters. Although the rspec can have multiple instances of each child the order should be maintained; i.e. first all the <openflow:controller> tags and then the <openflow:group> and so on. [AT LEAST ONE OF THE <openflow:use-group> or <openflow:datapath> MUST BE PRESENT]

  1. <openflow:use-group> [*]
  2. <openflow:datapath> [*]
  3. <openflow:packet> [?]
Parent tags
<openflow:sliver>

<openflow:use-group>

[*] This tag specifies which group of datapaths should be used for this match.

Attributes

  • name : [1] the name of the group as it is defined in the corresponding <openflow:group> tag, if the group has not been defined the rspec will be rejected.
Children tags
None
Parent tags
<openflow:match>

<openflow:packet>

[?] This tag describes the packet filters for defining this match.

Attributes
None
Children tags
[AT LEAST ONE OF THOSE SHOULD BE PRESENT]

  • <openflow:dl_src> [*]
  • <openflow:dl_dst> [*]
  • <openflow:dl_type> [*]
  • <openflow:dl_vlan> [*]
  • <openflow:nw_src> [*]
  • <openflow:nw_dst> [*]
  • <openflow:dl_proto> [*]
  • <openflow:tp_src> [*]
  • <openflow:tp_dst> [*]
Parent tags
<openflow:match>

Filter elements

In order to filter the traffic that will be delegated to this sliver packets can be filtered based on the following packet header fields. Each field corresponds to an element. In all of them you can specify a list of values by using a comma separated list (e.g. a,b,c) , or if ranges are supported to use the dash (e.g a-c), or a mixture of the two (e.g. a-c, f-j). Each element can appear multiple times within a packet element. If an element appears more than once, then the union of all the requested values is requested. All of the match elements have the same structure so we will describe it here :

Attributes
  • value : [1] A list or a range of values, the value format id different for each element
Children tags
None
Parent tags
<openflow:match>

<openflow:dl_src>

[*] Matches on the source ethernet address of the packet. Format xx:xx:xx:xx:xx:xx, does NOT support ranges. For details on the structure look here

<openflow:dl_dst>

[*] Matches on the destination ethernet address of the packet. Format xx:xx:xx:xx:xx:xx, does NOT support ranges. For details on the structure look here

<openflow:dl_type>

[*] Matches on the ethernet type of the packet. Format is only hex numbers, does NOT support ranges. For details on the structure look here

<openflow:dl_vlan>

[*] Matches on the vlan id of the packet. Format is only decimal numbers, supports ranges. For details on the structure look here

<openflow:nw_src>

[*]Matches on the IP source address of the packet. IP addresses or subnets in CIDR format (e.g. 10.43.123.0/24), does not support ranges. If this is used then <openflow:dl_type> should be matching IP (0x0806) and/or ARP (0x806) packets. For details on the structure look here

<openflow:nw_dst>

[*]Matches on the IP destination address of the packet. IP addresses or subnets in CIDR format (e.g. 10.43.123.0/24), does NOT support ranges. If this is used then <openflow:dl_type> should be matching IP (0x0800) and/or ARP (0x806) packets. For details on the structure look here

<openflow:nw_proto>

[*]Matches on the IP protocol. Protocol numbers (e.g. 17 for UDP) in only decimal format, supports ranges. If this is used then <openflow:dl_type> should be matching IP (0x0800) and/or ARP (0x806) packets. For details on the structure look here

<openflow:tp_src>

[*]Matches on the source port of TCP or UDP headers. Format is only decimal numbers, supports ranges. If this is used then <openflow:nw_proto> should be matching TCP (6) and/or UDP (17) packets.For details on the structure look here.

<openflow:tp_dst>

[*]Matches on the destination port of TCP or UDP headers. Format is only decimal numbers, supports ranges. If this is used then <openflow:nw_proto> should be matching TCP (6) and/or UDP (17) packets. For details on the structure look here.