标签：des style blog code http tar
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 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.
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
Flow entries may forward to a port.
Actions may also direct packets to a group
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.
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:
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:
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:
Each meter band is identified by its rate and contains:
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.
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:
标签：des style blog code http tar
原文地址：http://www.cnblogs.com/popsuper1982/p/3800558.html
