wiki:OpenFlow/Slicer/Requirements

Version 5 (modified by tupty@bbn.com, 9 years ago) (diff)

--

Naming Convention

The formalized requirements for this section follow the naming convention that is shown in the following diagram:

Slicer Goals

  • Isolation of traffic between experimenters
  • High scalability with number of supported devices and number of concurrent slices
  • Operational stability and code base simplicity
    • Limited number of crashes and errors of slicer software
    • Limited number of GENI-wide updates
  • Protection of substrate resources
  • Full OpenFlow 1.0 spec support
  • Transparency of control plane traffic where possible
    • Don't over-optimize in the control plane
    • Don't try to outsmart the switch or controller

Formalized Requirements

This page should capture our requirements for a slicer of GENI OpenFlow infrastructure. These requirements have been written following keyword BCP http://www.ietf.org/rfc/rfc2119.txt

Functional Requirements

  • OF-EXP-SLCR-FN-001: The slicer MUST support slicing infrastructure by VLAN ID.
    • OF-EXP-SLCR-FN-001-a:The slicer MUST be able to support allocating between one and some number n with n>1 VLANs to a single slice while having that slice be controlled by a single controller.
    • OF-EXP-SLCR-FN-001-b: The slicer MAY support allocating an entire physical port to a slice.
  • OF-EXP-SLCR-FN-002: The slicer MUST be capable of enforcing data plane traffic isolation when it is the first control plane entity in the path of a network device.
    • OF-EXP-SLCR-FN-002-a: The slicer MUST NOT allow the strip_vlan action to be performed followed by an output to a port unless the slice owner owns the untagged space for that port.
    • OF-EXP-SLCR-FN-002-b: The slicer MUST NOT allow the set_vlan_id action to be performed followed by an output to a port unless the slice owner owns that particular VLAN tag on that port.
    • OF-EXP-SLCR-FN-002-c: The slicer MUST support constraining traffic sent to the OFPP_ALL and OFPP_FLOOD ports to the ports that are in a user's slice.
  • OF-EXP-SLCR-FN-003: The slicer MUST be able to map all OpenFlow 1.0 control plane messages to either a slice or to the space which has not been sliced.
    • OF-EXP-SLCR-FN-003-a: In the event that control plane traffic from a network device does not belong to a slice, it MUST NOT be sent to controllers belonging to experimenters' slices.
    • OF-EXP-SLCR-FN-003-b: In the event that control plane traffic from a network device does belong to a slice, it MUST be sent to only the controller associated with the slice.
    • OF-EXP-SLCR-FN-003-c: There MUST NOT be a situation where it is unclear if control plane traffic from a network device belongs to a slice or not.
    • OF-EXP-SLCR-FN-003-d: There MUST NOT be a situation where it is unclear which slice control plane traffic from a network device belongs to.
    • OF-EXP-SLCR-FN-003-e: The slicer MUST ensure all traffic from a controller maps to a slice, or else it must drop the traffic. If the traffic is dropped the slicer SHOULD notify the controller through an OpenFlow error message.
    • OF-EXP-SLCR-FN-003-f: The slicer MUST NOT prevent any OpenFlow 1.0 match or action primitives from being used unnecessarily. Only match or action primitives that violate the slice restrictions may be prevented.
    • OF-EXP-SLCR-FN-003-g: The slicer MUST know which controller sent a give request message (e.g. stats request, barrier request, etc) and only send the reply message back to that controller.
  • OF-EXP-SLCR-FN-004: The slicer MUST have support for functions needed to implement GENI AM API on top of it. The API calls and parameters MAY implement a superset of what is needed for the GENI API (e.g. flowspace[] instead of vlan_ids[]).
    • OF-EXP-SLCR-FN-004-a: There MUST be an API call similar to the following: add_slice(slice_id, controller_url, vlan_ids[]). The slice should not timeout from the slicer without explicit removal from a separate API call or from the administrator.
    • OF-EXP-SLCR-FN-004-b: There MUST be an API call similar to the following: delete_slice(slice_id)
    • OF-EXP-SLCR-FN-004-c: There MUST be an API call similar to the following: change_controller(slice_id, controller_url)
    • OF-EXP-SLCR-FN-004-d: There MUST be an API call similar to the following: dump_slices(). This can be used by a GENI AM for synchronization purposes. It should list all slices managed by the slicer, all DPIDs connected to the slicer, and the controllers and VLANs that correspond to each slice.
    • OF-EXP-SLCR-FN-004-e: There MAY be an API call similar to the following: update_slice(slice_id, vlan_ids[])
  • OF-EXP-SLCR-FN-005: The slicer MUST ensure that OpenFlow 1.0 synchronous messages which arrive at the slicer and that are initiated by the controller receive a response, either from the switch or from the slicer itself. This includes forwarding OpenFlow error messages which are generated by the switches.
  • OF-EXP-SLCR-FN-006: The slicer MUST prevent device configuration change requests that would affect other slices (such as port down, adding a queue to a port, etc) from reaching the network device.
    • OF-EXP-SLCR-FN-006-a: The slicer MUST prevent OFPT_PORT_MOD messages from reaching a switch.
    • OF-EXP-SLCR-FN-006-b: The slicer MUST prevent OFPT_SET_CONFIG messages from reaching a switch.
    • OF-EXP-SLCR-FN-006-c: The slicer MAY emulate some OFPT_PORT_MOD or OFP_SET_CONFIG changes within a slice for the slice's controller.
  • OF-EXP-SLCR-FN-007: The slicer SHOULD provide some reasonable notification to slice owners in the event that they hit error conditions.
    • OF-EXP-SLCR-FN-007-a: The slicer MUST notify the controller if an OpenFlow message falls outside the bounds of a slice (either in terms of VLANs or in terms of limits), and it should be clear to the experimenter what the problem was.
    • OF-EXP-SLCR-FN-007-b: The slicer MUST make it possible for the GENI AM to notify the slice owner if their slice is programmatically disabled.
    • OF-EXP-SLCR-FN-007-c: The slicer MUST make it possible for the GENI AM to notify the slice owner if their slice is administratively removed.
  • OF-EXP-SLCR-FN-008: The slicer SHOULD NOT modify control plane traffic more than is necessary to perform the function of slicing.
  • OF-EXP-SLCR-FN-009: The slicer MUST implement critical features in a way that allows for additional slicers to run in the northbound control plane for a slice.
  • OF-EXP-SLCR-FN-010: The slicer MAY support control plane performance isolation.
  • OF-EXP-SLCR-FN-011: The slicer MAY support data plane performance isolation if the substrate can support it.
  • OF-EXP-SLCR-FN-012: The slicer MAY support per-slice flow limits.
  • OF-EXP-SLCR-FN-013: The slicer SHOULD be able to abstract the VLAN in the substrate away from the controller when possible. It SHOULD be possible to disable this feature per slice.
    • OF-EXP-SLCR-FN-013-a: In the case where a slice only includes one VLAN for a particular device belonging to that slice and this feature is enabled for the slice, the slicer SHOULD apply VLAN tags to the data packets in packet-out messages.
    • OF-EXP-SLCR-FN-013-b: In the case where a slice only includes one VLAN for a particular device belonging to that slice and this feature is enabled for the slice, the slicer SHOULD remove VLAN tags from the data packets in packet-in messages.
    • OF-EXP-SLCR-FN-013-c: In the case where a slice only includes one VLAN for a particular device belonging to that slice and this feature is enabled for the slice, and when the VLAN ID of the match in a flowmod is wildcarded, the slicer SHOULD apply a VLAN tag and remove the wildcard flag for the VLAN ID in the match.
    • OF-EXP-SLCR-FN-013-d: In the case where a slice includes multiple VLANs for a particular device belonging to that slice, the slicer SHOULD NOT attempt to modify data packets in packet-outs, data packets in packet-ins, or matches and wildcards in flowmods.

Operational Requirements

  • OF-EXP-SLCR-OP-001: The slicer MUST NOT require operator intervention for normal operations in the GENI environment.
    • OF-EXP-SLCR-OP-001-a: Creating a slice MUST NOT require operator approval from the slicer for new slices. The slicer MAY have some kind of policy enforcement for slice approval.
    • OF-EXP-SLCR-OP-001-b: Deleting a slice MUST NOT require operator action at the slicer layer. The slicer MAY have some kind of policy enforcement for slice deletion.
    • OF-EXP-SLCR-OP-001-c: Changing a controller URL for a slicer MUST NOT require operator action at the slicer layer. The slicer MAY have some kind of policy enforcement for slice controller URL changes.
    • OF-EXP-SLCR-OP-001-d: The slicer MAY disable slices which it thinks are misbehaving, but it MUST notify the slice owner. Re-enabling the slice MAY require operator intervention. It MUST be possible for operators to configure the slicer to avoid automatic disabling of slices.
  • OF-EXP-SLCR-OP-002: The slicer MUST NOT prevent metric collection for GENI operational monitoring. The slicer MAY provide administrative interfaces to operational monitoring data. The slicer MAY provide the ability to support read-only controllers for the full slicing space which require manual approval.
  • OF-EXP-SLCR-OP-003: The slicer MUST be able to support x with x>1 concurrent slices of a substrate of y with y>1 network devices which are passing traffic.
  • OF-EXP-SLCR-OP-004: The slicer MUST allow for slices to be added and removed without disrupting other slices.
  • OF-EXP-SLCR-OP-005: The slicer MUST have some logging mechanism for tracking important operational events.
  • OF-EXP-SLCR-OP-006: The slicer MUST NOT cause operational issues with things like disk usage.
    • OF-EXP-SLCR-OP-006-a: The slicer MUST NOT log excessive information which is not generally useful during default operations.
    • OF-EXP-SLCR-OP-006-b: The slicer SHOULD support different log levels or enabling of additional debugging logs, and that SHOULD be possible to change while the software is running.
    • OF-EXP-SLCR-OP-006-c: The slicer SHOULD continue to log properly in the event that its logs are rotated.
  • OF-EXP-SLCR-OP-007: The slicer SHOULD handle data plane traffic that doesn't belong to a slice gracefully, regardless of the traffic rate on the data plane.
  • OF-EXP-SLCR-OP-008: The slicer SHOULD prevent packet-ins from the switches it controls if the controller for a corresponding slice is not connected.
  • OF-EXP-SLCR-OP-009: When a slice is created or deleted the slicer SHOULD clear out flow tables of switches for the corresponding VLANs of that slice.

Software Development Requirements

  • OF-EXP-SLCR-SW-001: The slicer code base SHOULD be have an active maintainer who is willing to provide bug fixes in a timely fashion.
  • OF-EXP-SLCR-SW-002: The slicer code base SHOULD have an active development team who is willing to discuss feature requests, add features, and update code to keep up with the requirements of the GENI AM API.
  • OF-EXP-SLCR-SW-003: The slicer development team SHOULD have a plan for moving to later versions of OpenFlow, including a target of OpenFlow 1.3.
  • OF-EXP-SLCR-SW-004: The slicer should be maintained in an open repository so that requirements can be verified in an ongoing basis.
  • OF-EXP-SLCR-SW-005: The slicer development team MUST be willing to iterate on features and fixes for requirements over the next six months.
  • OF-EXP-SLCR-SW-006: The GENI-wide deployment of the slicer SHOULD NOT be required for a normal release. Slicer upgrades SHOULD be possible on an aggregate by aggregate basis over time, unless a specific emergency release and upgrade is agreed upon.
  • OF-EXP-SLCR-SW-007: Updates to or restarts of the slicer SHOULD NOT destroy existing configuration without explicit slice owner approval. Restarts and upgrades also SHOULD NOT disrupt the flow tables of the switches.
  • OF-EXP-SLCR-SW-008: The software should be ready for first attempted production deployments in GENI (meeting all requirements) within three months.

Wishlist

This section is for tracking things that we would really like but likely don't qualify as requirements. Don't hesitate to put stuff in here! If you are unsure if something belongs in the requirements or the wishlist, feel free to ask Tim.

  • Slicer protection of substrate
    • Slicer can install rules to drop certain kinds of traffic like CDP with no VLAN, STP with no VLAN, LLDP with no VLAN, etc
    • If traffic within a slice is disrupting a switch (e.g. causing a bunch of packet ins) then add a drop rule in addition to disabling the slice
  • Slicer should come in the form of a package, and preferably should be installable from a repo through a package manager
  • Support for "untagged" in addition to VLAN IDs in slicer
  • Allow support for experimenter setting of priority
  • Data plane performance isolation would be an awesome feature for a slicer if both it and the substrate could support it. We'd definitely like to see it if it is possible.

Attachments (1)

Download all attachments as: .zip