Software-Defined Networking

Network intelligence is (logically) centralized in software-based SDN controllers

network operators and administrators can programmatically configure this simplified network abstraction rather than having to hand-code tens of thousands of lines of configuration scattered among thousands of devices.

OpenFlow is the first standard communications interface defined between the control and forwarding layers of an SDN architecture.

OpenFlow allows direct access to and manipulation of the forwarding plane of network devices such as switches and routers, both physical and virtual (hypervisor-based).

The OpenFlow protocol is implemented on both sides of the interface between network infrastructure devices and the SDN control software.

SDN Architecture

SDN Application (SDN App): SDN Applications are programs that explicitly, directly, and programmatically communicate their network requirements and desired network behavior to the SDN Controller via NBIs (NorthBound Interface).

An SDN Application consists of one SDN Application Logic and one or more NBI Drivers.

SDN Controller: The SDN Controller is a logically centralized entity in charge of (i) translating the requirements from the SDN Application layer down to the SDN Datapaths and (ii) providing the SDN Applications with an abstract view of the network (which may include statistics and events).

An SDN Controller consists of one or more NBI Agents, the SDN Control Logic, and the CDPI(Control-Data-Plane Interface) driver.

SDN Datapath: The SDN Datapath is a logical network device, which exposes visibility and uncontended control over its advertised forwarding and data processing capabilities. The logical representation may encompass all or a subset of the physical substrate resources.

An SDN Datapath comprises a CDPI agent and a set of one or more traffic forwarding engines and zero or more traffic processing functions.

SDN Control to Data-Plane Interface (CDPI): The SDN CDPI is the interface defined between an SDN Controller and an SDN Datapath, which provides at least (i) programmatic control of all forwarding operations, (ii) capabilities advertisement, (iii) statistics reporting, and (iv) event notification.

SDN Northbound Interfaces (NBI): SDN NBIs are interfaces between SDN Applications and SDN Controllers and typically provide abstract network views and enable direct expression of network behavior and requirements.

Interface Drivers & Agents: Each interface is implemented by a driver-agent pair, the agent representing the “southern”, bottom, or infrastructure facing side and the driver representing the “northern”, top, or application facing side.

Management & Admin: The Management plane covers static tasks that are better handled outside the application, control and data planes.

OpenFlow Switch Components

An OpenFlow Switch consists of one or more ow tables and a group table, which perform packet lookups and forwarding, and an OpenFlow channel to an external controller.

The switch communicates with the controller and the controller manages the switch via the OpenFlow protocol.

The controller can add, update, and delete flow entries in flow tables

Each flow table in the switch contains a set of flow entries; each flow entry consists of match fields, counters, and a set of instructions to apply to matching packets

Matching starts at the first flow table and may continue to additional flow tables

Flow entries match packets in priority order

If a matching entry is found, the instructions associated with the specific flow entry are executed. If no match is found in a flow table, the outcome depends on con guration of the table-miss flow entry: for example, the packet may be forwarded to the controller over the OpenFlow channel, dropped, or may continue to the next flow table.

Instructions associated with each flow entry either contain actions or modify pipeline processing

• Actions describe packet forwarding, packet modi cation and group table processing.
• Pipeline processing instructions allow packets to be sent to subsequent tables for further processing and allow metadata to be communicated between tables.

Flow entries may forward to a port.

• physical port
• logical port
• reserved port: specify generic forwarding actions such as sending to the controller, flooding, or forwarding using non-OpenFlow methods

Actions may also direct packets to a group

• Groups represent sets of actions for flooding, as well as more complex forwarding semantics (e.g. multipath, fast reroute, and link aggregation).
• Groups also enable multiple flow entries to forward to a single identifier (e.g. IP forwarding to a common next hop).
• The group table contains group entries; each group entry contains a list of action buckets with specific semantics dependent on group type

OpenFlow Ports

OpenFlow ports are the network interfaces for passing packets between OpenFlow processing and the rest of the network.

OpenFlow packets are received on an ingress port and processed by the OpenFlow pipeline which may forward them to an output port.

The OpenFlow standard ports are de ned as physical ports, logical ports, and the LOCAL reserved port if supported. Standard ports can be used as ingress and output ports, they can be used in groups, and they have port counters.

The OpenFlow physical ports are switch de ned ports that correspond to a hardware interface of the switch. For example, on an Ethernet switch, physical ports map one-to-one to the Ethernet interfaces.

The OpenFlow logical ports are switch defined ports that don’t correspond directly to a hardware interface of the switch.

Logical ports are higher level abstractions that may be de ned in the switch using non-OpenFlow methods (e.g. link aggregation groups, tunnels, loopback interfaces).

Reserved Ports: The OpenFlow reserved ports are de ned by this specification.

• ALL: Represents all ports the switch can use for forwarding a speci c packet. Can be used only as an output port.
• CONTROLLER: Represents the control channel with the OpenFlow controller. Can be used as an ingress port or as an output port.
• TABLE: Represents the start of the OpenFlow pipeline. This port is only valid in an output action in the action list of a packet-out message (see 7.3.6), and submits the packet to the first flow table so that the packet can be processed through the regular OpenFlow pipeline.
• IN PORT: Represents the packet ingress port.
• ANY: Special value used in some OpenFlow commands when no port is specified
• LOCAL: Represents the switch’s local networking stack and its management stack.
• NORMAL: Represents the traditional non-OpenFlow pipeline of the switch
• FLOOD: Represents flooding using the normal pipeline of the switch

OpenFlow Tables

The flow tables of an OpenFlow switch are sequentially numbered, starting at 0. Pipeline processing always starts at the first flow table

When processed by a flow table, the packet is matched against the flow entries of the flow table to select a flow entry. If a flow entry is found, the instruction set included in that flow entry is executed.

If a packet does not match a flow entry in a flow table, this is a table miss.

Each flow table entry contains:

• match fields: to match against packets. These consist of the ingress port and packet headers, and optionally metadata specified by a previous table.
• priority: matching precedence of the flow entry.
• counters: updated when packets are matched.
• instructions: to modify the action set or pipeline processing.
• timeouts: maximum amount of time or idle time before flow is expired by the switch.
• cookie: opaque data value chosen by the controller. May be used by the controller to filter flow statistics, flow modification and flow deletion. Not used when processing packets.

Every flow table must support a table-miss flow entry to process table misses.

The table-miss flow entry is identified by its match and its priority, it wildcards all match fields (all fields omitted) and has the lowest priority (0).

Flow entries are removed from flow tables in three ways, either at the request of the controller, via the switch flow expiry mechanism, or via the optional switch eviction mechanism.

Each flow entry has an idle_timeout and a hard_timeout associated with it. If the hard_timeout eld is non-zero, the switch must note the flow entry’s arrival
time, as it may need to evict the entry later. A non-zero hard_timeout eld causes the flow entry to be removed after the given number of seconds, regardless of how many packets it has matched.

If the idle_timeout eld is non-zero, the switch must note the arrival time of the last packet associated with the flow, as it may need to evict the entry later. A non-zero idle_timeout eld causes the flow entry to be removed when it has matched no packets in the given number of seconds.

The controller may actively remove flow entries from flow tables by sending delete flow table modification messages

A group table consists of group entries. The ability for a flow entry to point to a group enables OpenFlow to represent additional methods of forwarding (e.g. select and all).

Each group entry is identi ed by its group identi er and contains:

• group identifier: a 32 bit unsigned integer uniquely identifying the group
• group type: to determine group semantics
  • all: Execute all buckets in the group.
  • select: Execute one bucket in the group. Packets are processed by a single bucket in the group, based on a switch-computed selection algorithm
  • indirect: Execute the one de ned bucket in this group.
  • fast failover: Execute the rst live bucket.
• counters: updated when packets are processed by a group
• action buckets: an ordered list of action buckets, where each action bucket contains a set of actions to execute and associated parameters

A meter table consists of meter entries, defining per-flow meters. Per-flow meters enable OpenFlow to implement various simple QoS operations, such as rate-limiting, and can be combined with per-port queues to implement complex QoS frameworks, such as DiffServ.

A meter measures the rate of packets assigned to it and enables controlling the rate of those packets. Meters are attached directly to flow entries (as opposed to queues which are attached to ports). Any flow entry can specify a meter in its instruction set: the meter measures and controls the rate of the aggregate of all flow entries to which it is attached.

Each meter entry is identified by its meter identi er and contains:

• meter identifier: a 32 bit unsigned integer uniquely identifying the meter
• meter bands: an unordered list of meter bands, where each meter band specifies the rate of the band and the way to process the packet
• counters: updated when packets are processed by a meter

Each meter band is identified by its rate and contains:

• band type: defines how packet are processed
• rate: used by the meter to select the meter band, de nes the lowest rate at which the band can apply
• counters: updated when packets are processed by a meter band
• type specific arguments: some band types have optional arguments

Counters are maintained for each flow table, flow entry, port, queue, group, group bucket, meter and meter band.

Each flow entry contains a set of instructions that are executed when a packet matches the entry.

• Meter meter id: Direct packet to the speci ed meter. As the result of the metering, the packet may be dropped
• Apply-Actions action(s): Applies the speci c action(s) immediately, without any change to the Action Set. This instruction may be used to modify the packet between two tables or to execute multiple actions of the same type.
• Clear-Actions: Clears all the actions in the action set immediately.
• Write-Actions action(s): Merges the speci ed action(s) into the current action set
• Write-Metadata metadata / mask: Writes the masked metadata value into the metadata field.
• Goto-Table next-table-id: Indicates the next table in the processing pipeline.

An action set is associated with each packet. This set is empty by default. A flow entry can modify the action set using a Write-Action instruction or a Clear-Action instruction associated with a particular match. The action set is carried between flow tables. When the instruction set of a flow entry does not contain a Goto-Table instruction, pipeline processing stops and the actions in the action set of the packet are executed.

The actions in an action set are applied in the order speci ed below, regardless of the order that they were added to the set.

1. copy TTL inwards: apply copy TTL inward actions to the packet
2. pop: apply all tag pop actions to the packet
3. push-MPLS: apply MPLS tag push action to the packet
4. push-PBB: apply PBB tag push action to the packet
5. push-VLAN: apply VLAN tag push action to the packet
6. copy TTL outwards: apply copy TTL outwards action to the packet
7. decrement TTL: apply decrement TTL action to the packet
8. set: apply all set-field actions to the packet
9. qos: apply all QoS actions, such as set queue to the packet
10. group: if a group action is speci ed, apply the actions of the relevant group bucket(s) in the order speci ed by this list
11. output: if no group action is speci ed, forward the packet on the port speci ed by the output action

The Apply-Actions instruction and the Packet-out message include an action list.

The actions of an action list are executed in the order speci ed by the list, and are applied immediately to the packet.

Actions:

• Output. The Output action forwards a packet to a speci ed OpenFlow port
• Set-Queue. The set-queue action sets the queue id for a packet. When the packet is forwarded to a port using the output action, the queue id determines which queue attached to this port is used for scheduling and forwarding the packet.
• Drop. There is no explicit action to represent drops.
• Group. Process the packet through the specified group.
• Push-Tag/Pop-Tag. Switches may support the ability to push/pop tags

• Set-Field. The various Set-Field actions are identified by their eld type and modify the values of respective header elds in the packet.
• Change-TTL. The various Change-TTL actions modify the values of the IPv4 TTL

原著是一个有趣的人,若有侵权,请通知删除