Cloud Networking Disruption with Software Defined Network Virtualization Ali Khayam
In the next one hour Let s discuss two disruptive new paradigms in the world of networking: Network Virtualization Software Defined Networking 2
Why virtualize the network? 3
Let s first ask: Why is server virtualization so popular? Virtualizing compute, I/O and memory on a machine as a pool of physical resources which can be assigned to different VMs on-demand. Hypervisor 4
Why is server virtualization so popular? Avoids underutilization of physical resources. Allows safe application deployment and multitenancy on the same machine. Reduces operational costs as VMs can be spun up, shut down and migrated at will User experience is not compromised as a VM looks and feels exactly like a local machine. 5
Why virtualize the cloud network? Server virtualization provides multitenancy, but networking resources are generally hidden from the tenants Basic primitives for VM connectivity are supported and that s about it What if a cloud s physical networking resources (switches, routers, firewalls) could be segmented and given to tenants on-demand? 6
Why virtualize the cloud network? Multitenacy Virtualizing the network resources would require defining an overlay network on top of the actual physical cloud network E.g., VM1 thinks it communicates with VM2 directly (one hop), but there are several physical hops between them. The overlay concept is similar to p2p networks, but network virtualization must go beyond that because: A tenant s traffic ownership and semantics must be preserved en-route. A tenant s traffic must be segmented from other tenants. A tenant should be allowed to define custom overlay topologies. 7
Why virtualize the cloud network? Maximize utilization of networking resources Cloud operators would want to maximize the usage of networking resources: 200,000 servers in a public cloud data center Fanout of 20 10,000 switches $5k commercial switch $50M Networking CAPEX in 10 data centers = $500M Oversubscription of networking resources is effective only when traffic is spread out through the data center Cloud traffic is unpredictably burstyand its not easy to spread VMs out in real-time. 8
Why virtualize the cloud network? Fault Localization If a tenant s virtual network breaks down for any reason, services of other tenant s should not be impacted. Application Agility Network virtualization would allow easy orchestration and deployment of new applications and services Lower hardware costs Lower IT installation costs 9
What is network virtualization? 10
What is network virtualization? A network comprises of a bunch of networking devices: Switches, routers, firewalls, load balancers, etc. These are physical networking resources. Let s think about how we can virtualize these resources so they can be segmented and given to different tenants on-demand. But first one slide on what we would expect from such a network virtualization solution. 11
What would be expect from a network virtualizer? Multi-tenancy through network segmentation Different tenants network segments should be completely isolated: Allowing overlapping topologies, IP addresses, etc. No spill over from one tenant s traffic domain to another. Tenants should be allowed to define their own topologies: Example 1: I want my 300 VMs to be connected to the same switch. Example 2: I want my VMs to be connected to one switch, but the servers should be connected to a router. Uncompromised user experience: Same user experience as if the resources were present locally. 12
What is network virtualization? Back to how we can virtualize these resources so they can be segmented and given to different tenants ondemand. 13
First things first: How does a physical switch work? Machine 1 Machine 2 Machine 3 14
How does a physical switch work? M1 M2 M3 1. Pkt from M1 for M3 3. M3 responds and switch learns the MAC addresses of M1 and M3. 2. Switch doesn t know where M3 is connected, so it floods on all the ports. 15
How can we build a virtual switch? VM1, VM2 and VM3 should feel like they are connected to the same (virtual) switch VM1 Server1 Rack1 VM2 Server2 Rack2 VM3 Server3 Rack3 16
How can we build a virtual switch? 2. Switch doesn t know where VM3 is connected, so it unicasts to all the VMs. 3. M3 responds and both switches learn the MAC addresses of VM1 and VM3. VM1 1. Pkt from VM1 for VM3 Server1 Rack1 VM2 Server2 Rack2 VM3 Server3 Rack3 17
How can we build a virtual switch? VM1 VM2 VM3 Virtual Switch 18
How can we build a virtual switch? We can also extend this basic virtual switch to provide the advanced switching functionality: VLANs QoS Secure MAC learning Trunking Tunneling CLI- and web-based configurations SNMP 19
Using network virtualization, we can. Virtualize any networking resource: Routers, firewalls, load balancers, etc. Design networking elements with a large number of (possibly infinite) ports E.g., an entire network connected to a big switch, router or firewall 20
Using network virtualization, we should. Be able to define arbitrary interconnects of virtual networking elements contained within a Virtual Network Domain i.e. a self-contained network abstraction equivalent to a Virtual Machine in the hypervisor domain 21
The Dream Decoupling of virtual data centers from physical data centers Extensible technology to deliver new Network Functions 22
Changing gears to Software Defined Networking. Why software-defined networking? 23
What is SDN? SDN moves networking technology from hardware boxes to software modules A purist SDN solution should software from a 3 rd party to programmatically control traffic on another its network devices. Note that network virtualization is not necessarily software defined There are plenty of hardware based network virtualization solutions in the market right now 24
Why do we need SDN? Freedom from Vendor Lock-in Vendor lock-in stifles innovation and drives costs up Agility in Innovation Agility in network design At the moment, it is difficult (at times impossible) to design/test new network protocols, architectures and algorithms 25
How is software-defined networking implemented? 26
How is SDN being implemented? Break CP-DP association Open up the platform Switch/Router Control Plane Switch/Router Switch/Router Data Plane Control Plane Control Plane Data Plane Switch/Router Control Plane Data Plane Data Plane
How is SDN being implemented? (The Openflow Model) Control Plane Control Plane Control Plane Control Plane Provide an API/protocol to access it Switch/Router Introduce simple homogeneous data plane definition Data Plane Switch/Router Switch/Router Data Plane Data Plane Switch/Router Data Plane
How is SDN being implemented? (The OpenFlow Model) The most prominent SDN DP API Standardization effort is OpenFlow OpenFlow 1.0 Flow Format Rule Action Stats Packet + byte counters 1. Forward packet to port(s) 2. Encapsulate and forward to controller 3. Drop packet 4. Send to normal processing pipeline 5. Modify Fields Switch Port VLAN ID MAC src MAC dst Eth type IP Src IP Dst IP Prot TCP sport TCP dport + mask what fields to match
Now let s ask Are we free from vendor lock-in? Has innovation in networks become more agile because of SDN? 30
Are we free from vendor lock-in? Management APIs Closed Network Functions Northbound APIs Software based networking vendors Hardware Box based networking vendors Controller Data Plane Southbound API + Extensions How to insert a new (3 rd party) network function in the OF SDN model? 31
Has innovation in networks become more agile? How to insert a new (3 rd party) network function in the OF SDN model? Closed Network Functions SDN Controller Data Plane How to talk to a closed NB API? SB API is available, but how to introduce new DP changes? 3 rd party Network Function From one vendor lock-in to another 32
Has innovation in networks become more agile? How do we support new wire protocols in the DP? How do we support new architectures that require functionality to be split between CP and DP? How do we avoid race conditions if a 3 rd party network function talks directly to a DP that is already talking to a proprietary controller?... 33
How can software defined network virtualization save the day? 34
Let s go back to the basics and ask How can the SDN and the network virtualization coevolution be poised for agility not conformity? How can SDN solve vendor lock-in once and forever? How can SDN support agile virtualized network functions for protocols of the past, the present, and the future? 35
Design for agility, not conformity Let s learn from similar experiences in other technologies designed for innovation. ANSI C Standard Unix SUS Standard Widespread adoption and enhancements from community ATT builds Unix and C 1 9 6 3 1 9 7 0 1 9 8 0 1 9 8 7 1 9 8 9 1 9 9 7 Standardization is the final step, as it stifles innovation early on. 36
Break vendor lock-in by seamlessly support protocols of the past, the present, and the future Change mindset from APIs to flexible DP Languages which allow easy definition of new protocols and architectures. Languages transcend beyond business constraints: If the language is semantically rich then the community can write compilers and use it on different platforms. This code is also inherently portable across platforms. 37
Break vendor lock-in by seamlessly support protocols of the past, the present, and the future Software Defined Control Plane with Open NB Interfaces Distributed Messaging fabric Control Plane Control Plane Switch/Router DP API Switch/Router Software HAL Defined Data Plane Switch/Router DP API Data Plane Data Plane Switch/Router DP API Data Plane
Thank you PLUMgrid sislamabad Office is Hiring! hr.isb@plumgrid.com 39
How do you implement network virtualization? 40
What are we missing here? 1There needs to a central database which know about the location and owner of every single VM in the data center and can then communicate this information to the switches. 2Packet headers will be changed by intermediate network entities (switches, routers, NAT, proxy) while the packet is passing through the network. 41
Centralized Control 1There needs to a central database which know about the location and owner of every single VM in the data center and can then communicate this information to the switches. Solution: This central database is maintained at an entity called the controller. When a VM s state changes (migration to another server, power on/off), the central controller encodes the right rules in the right switches. OpenFlow is a protocol that allows the controller and switches to talk to each other. 42
Centralized Control OpenFlow Controller OpenFlow Protocol (SSL) Control Path OpenFlow (Flow Tables) Data Path (Hardware) Control Path OpenFlow (Flow Tables) Control Path OpenFlow (Flow Tables) Data Path (Hardware) Data Path (Hardware) Control Path OpenFlow (Flow Tables) Data Path (Hardware) 43
OpenFlow 1.0: Rule Format Rule Action Stats Packet + byte counters 1. Forward packet to port(s) 2. Encapsulate and forward to controller 3. Drop packet 4. Send to normal processing pipeline Switch Port + mask MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport 44
OpenFlow 1.0: Limitations Single table support Rigid flow definition Single controller support 45
OpenFlow 1.2/1.3 Pipelined flow tables Packet In Action set = {} Table 0 Packet + ingress port + Metadata Table 1 Action set = {a1} Packet + ingress port + Metadata Table n Packet + Metadata Execute Actions Action set = {a1, a2, } Packet Out 46
OpenFlow 1.2/1.3 OpenFlow Extensible Matching (OXM) class fields mask 47
OpenFlow 1.2/1.3: Multiple Controllers Support Controller 1 Controller 2 Controller k Switch Channel Flow Table 0 pipeline Group Table Flow Table n 48
What are we missing here? 1There needs to a central database which know about the location and owner of every single VM in the data center and can then communicate this information to the switches. 2Packet headers will be changed by intermediate network entities (switches, routers, NAT, proxy) while the packet is passing through the network. 49
What are we missing here? 2Packet headers will be changed by intermediate network entities (switches, routers, NAT, proxy) while the packet is passing through the network. Solution: Tunnel the packets so that all the L2, L3, L4, L7 headers of the VM s packet are preserved. 50
Tunneling: NVGRE Outer Ethernet Header Outer IP Header GRE Header Inner Ethernet Header Inner IP Header 0 1 0 Reserved (10 bits) Version (3 bits) Protocol Type 0x6558 (16 bits) Tenant Network Identifier (TNI) (24 bits) Reserved (8 bits)
Tunneling: VXLAN Outer MAC VXLAN Outer IP Outer UDP L2 packet header Outer CRC R R R R I R R R Reserved (24 bits) Virtual Network Identifier (VNI) (24 bits) Reserved (8 bits)
Tunneling: STT VM 1 Soft Switch NIC VM 2 VM 1 VM 2 NIC Soft Switch Network Switch-Switch Tunnel
Tunneling: STT TCP Header Source Port 16 bits Destination Port 16 bits Data Offset 12 bits Sequence Number * 32 bits Acknowledgement Number * 32 bits U A P R S F Reserved R C S S Y I Window G K H T N N 84 bits Checksum 16 bits Urgent Pointer 16 bits Options 24 bits Padding 8 bits Data
Tunneling: STT STT s TCP-Like Header Version 8 bits Flags 8 bits L4 Offset 8 bits Reserved 8 bits Maximum Segment Size 16 bits PCP 8 bits V 1 bit VLAN ID 12 bits Context ID 64 bits Padding 16 bits Data
Tunneling: STT Guest VM Application TCP/IP stack Virtual NIC Port Soft Switch Hypervisor Host NIC Application DataStream Application DataStream TCP IP Application DataStream TCP IP L2 Application DataStream TCP IP L2 STT IP Data STT IP L2 Data STT IP Network L2