1 / 22

Wide Area OpenFlow Demonstration

This demonstration explores the implementation of Wide-Area OpenFlow architectures aimed at enhancing network control and switching efficiency. Utilizing the NOX framework in conjunction with NetFPGA, we showcase how Ethernet frames are encapsulated for transmission across OpenFlow switches. The SPP node serves as a gateway, ensuring seamless transition of packets within the OpenFlow environment. Key actions are outlined, including packet forwarding techniques and optional modifications. This research aims to advance the state of OpenFlow capabilities over extensive networks.

rufina
Télécharger la présentation

Wide Area OpenFlow Demonstration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Wide Area OpenFlow Demonstration Jon Turner, John DeHart, Fred KuhnsComputer Science & EngineeringWashington Universitywww.arl.wustl.edu

  2. Planned Wide-Area OpenFlow NOX hdrFmt lookup queue parse CP SC netFPGA NOX Princeton to SPP WashU Stanford 2 2 3 2 2 GaTech 3 3 Texas

  3. OpenFlow Site • Acts as gateway between Local OpenFlow Network and SPP node with OpenFlow code option. • Implemented in NetFPGA? • OpenFlow SPP • Receives Ethernet Frames from an OpenFlow Switch • Encapsulates Ethernet frames in IP/UDP pkt • Sends IP/UDP pkt to SPP • SPP  OpenFlow • Receives IP/UDP pkt from SPP node • Removes IP/UDP encapsulation • Sends Ethernet frame to OpenFlow switch NOX Gateway to SPP via I2

  4. SPP Node NPE TCAM GPE Filter Updates SPP-NOX lookup hdrFmt queue parse OFP CP SC netFPGA Switch LC

  5. T 0 (1b) Rx IP DA Index (4b) Slice ID (VLAN) (11b) Rx UDP DPort (16b) MN Key Bits 111-80 (32b) MN Key Bits 79-48 (32b) MN Key Bits 47-16 (32b) MN Key Bits 15-0 (16b) SPP Node Rsv (4b) Intf (4b) IP DAddr (32b) NPE TCAM Protocol (8b) UDP DPort (16b) Type (8b) GPE Filter Updates SPP-NOX lookup hdrFmt queue parse OFP CP SC netFPGA Switch NPE Lookup Key LC LC Lookup Key

  6. SPP Node NPE TCAM GPE Filter Updates SPP-NOX lookup hdrFmt queue parse OFP CP SC netFPGA Switch LC • LC Lookup(Interface, IP DA, Protocol, Rx UDP Dport)  Slice ID • Slice ID is encoded as VLAN used in Switch • VLAN will be used as Slice ID in NPE on other side of Switch

  7. SPP Node NPE TCAM GPE Filter Updates SPP-NOX lookup hdrFmt queue parse OFP CP SC netFPGA Switch LC • Rx Meta-Interface: (Interface, Slice ID, Rx UDP Dport) • NPE Lookup(Rx Meta-Interface, MN Key(112b))  Tx Meta-Interface • Hit: Causes pkt to be sent out on specificed physical interface with a new encapsulation header • Miss: Causes pkt to be sent to SC for communication to SPP-NOX

  8. NPE Lookup Key • NPE Lookup Key: • 144 bits • 32 bits of Substrate Key • 112 bits of MetaNet Specific key • MetaNet Specific Lookup Key: • 112 bits • For IPv4 MN: • IP DA (32b) • IP SA (32b) • Src Port (16b) • Dst Port (16b) • Proto/TCP Flags (16b) • Proposed For OpenFlow (109b) • VLAN Valid (1b) • VLAN (12b) • Src MAC (32b): Low 32 bits of Source MAC • Dst MAC (48b) • Ethertype (16b) • We are considering increasing the size of the NPE lookup key to a total of 288 bits, giving us 256 bits for the MetaNet specific lookup key. • Thus allowing us to support the full OpenFlow key (232b)

  9. OpenFlow Required Actions • Forward: • Forwarding the pkt to physical ports and the following virtual ones: • All: Send pkt out all interfaces, not including incoming interface • Controller: Encapsulate and send packet to the controller • Local: Send the packet to the switch’s local networking stack • Table: Perform the actions in the flow table. Only for packet-out messages • Packet-out messages are data packets that the controller wants to have the switch send out. • In-Port: Send pkt out the input port • Drop

  10. SPP-OpenFlow Supported Req’d Actions • Forward: • Forwarding the pkt to a physical ports and the following virtual ones: • All: Send pkt out all interfaces, not including incoming interface • Controller: Encapsulate and send packet to the controller • Local: Send the packet to the switch’s local networking stack • ???Table: Perform the actions in the flow table. Only for packet-out messages • Packet-out messages are data packets that the controller wants to have the switch send out. • In-Port: Send pkt out the input port • Drop

  11. OpenFlow Optional Actions • Forward • Normal: process the packet using the traditional forwarding path supported by the switch. • Flood: Flood the packet along the minimum spanning tree • Modify-Field • Set VLAN ID • Set VLAN Priority • Strip VLAN Header • Modify Ethernet SMAC • Modify Ethernet DMAC • Modify IP SA • Modify IP DA • Modify Transport Sport • Modify Transport DPort

  12. SPP-OpenFlow Supported Opt’l Actions • Forward • Normal: process the packet using the traditional forwarding path supported by the switch. • Flood: Flood the packet along the minimum spanning tree • Modify-Field • Set VLAN ID • Set VLAN Priority • Strip VLAN Header • Modify Ethernet SMAC • Modify Ethernet DMAC • Modify IP SA • Modify IP DA • Modify Transport Sport • Modify Transport DPort

  13. OpenFlow Switch/Controller Communication • Uses an SSL Connection • Can we support this? • If we use the NOX software, how easy is it to change this?

  14. OpenFlow Protocol (OFP) • Message Types: • Immutable Messages: • HELLO • Exchanged between Switch and Controller upon connection startup. • Negotiates OFP version to be used. • ERROR • Switch alerts Controller of problems or error conditions • ECHO {REQUEST, REPLY} • Initiated by either Switch or Controller, other side must reply. • May be used to indicate: latency, bandwidth or liveness of the connection • VENDOR • Identifies Switch Vendor using IEEE OUI (Organizationally Unique Identifier)

  15. OpenFlow Protocol (OFP) (con’t) • Message Types: • Switch Configuration Messages (initiated by controller) • FEATURES {REQUEST, REPLY} • Controller requests switch to report its capabilities • GET_CONFIG {REQUEST, REPLY} • Controller queries current configuration of switch • SET_CONFIG • Controller sets configuration parameters of switch • No response

  16. OpenFlow Protocol (OFP) (con’t) • Message Types: • Asynchronous Messages (Switch to Controller) • PACKET_IN • Packets with no matching flow entry are sent to controller • Packets that match a flow entry with an action of “send to controller” • FLOW_EXPIRED: switch reports expiration/removal of an entry. • Flow entries have idle timeouts assigned for inactivity removal • Flow entries have a hard timeout for removal regardless of activity. • Timeout based removal is done by the switch and the controller is notified. • PORT_STATUS • Switch sends port status messages to report port configuration state changes.

  17. OpenFlow Protocol (OFP) (con’t) • Message Types: • Controller Command Messages • PACKET_OUT • Controller to send packets out a specified port on switch • FLOW_MOD • Add, Delete, Modify Flow entries in Flow Table • PORT_MOD • Set Switch port properties • Statistics Messages: • STATS {REQUEST, REPLY} • Collect statistics from Switch

  18. OFP: FLOW_MOD Messages • ADD • Identical entry already exists (identical header fields and priority): • Remove existing entry and its counters and add new entry. • Conflicting entry already exists (same priority both could be match): • Refuse addition and respond with OFPEFM_ADD_OVERLAP error message. • No conflict: • Add new entry so priority is handled appropriately. • MODIFY • If a flow entry with identical header fields does not exist then the new flow entry should be added and its counters zeroed. • If one or more entries match then they are ALL modified • MODIFY_STRICT • If all fields including wildcards and priority match then that entry is modified • DELETE • If one or more entries match then they are ALL deleted • DELETE_STRICT • If all fields including wildcards and priority match then that entry is deleted

  19. SPP-OFP: FLOW_MOD Messages • ADD • Can we tell if there are conflicts? • MODIFY • Only support _STRICT? • MODIFY_STRICT • DELETE • Only support _STRICT? • DELETE_STRICT

  20. OFP: Capabilities • FLOW_STATS • Able to report per flow statistics • TABLE_STATS • Able to report per Flow Table statistics • PORT_STATS • Able to report per Port statistics • STP • Able to support 802.1d spanning tree protocol • MULTI_PHY_TX • Able to support transmitting received packet out multiple physical interfaces • IP_REASM • Able to support reassembly of IP fragments

  21. SPP-OFP: Capabilities • FLOW_STATS • Able to report per flow statistics • TABLE_STATS • ???Able to report per Flow Table statistics • PORT_STATS • Able to report per Port statistics • STP • Able to support 802.1d spanning tree protocol • MULTI_PHY_TX • Able to support transmitting received packet out multiple physical interfaces • IP_REASM • Able to support reassembly of IP fragments

  22. Plan for SPP Implementation • Step 1: Fast Path Code Option Implementation • Test using current set of control utilities to populate lookup table • Step 2: SC/NOX • Implemented using out-of-band SSL connections • Step 3: SC/NOX • Implemented through data path • Still unclear how to support SSL for this.

More Related