1. Software Defined Network and Network Virtualization Sándor Laki (Slides by Yeh-Ching Chung)

2. SOFTWARE DEFINED NETWORK Introduction Motivation Concept Open Flow Virtual Switch

3. Million of lines of source code 5400 RFCsBarrier to entry 500M gates 10Gbytes RAM BloatedPower Hungry Many complex functions baked into the infrastructure OSPF, BGP, multicast, differentiated services, Traffic Engineering, NAT, firewalls, MPLS, redundant layers, … An industry with a “mainframe-mentality” We have lost our way Specialized Packet Forwarding Hardware Operating System Operating System App Routing, management, mobility management, access control, VPNs, …

4. Operating System Reality App Specialized Packet Forwarding Hardware Operating System Operating System App Lack of competition means glacial innovation Closed architecture means blurry, closed interfaces Vertically integrated, complex, closed, proprietary Not suitable for experimental ideas Not good for network owners & users Not good for researchers

5. Glacial process of innovation made worse by captive standards process Deployment IdeaStandardize Wait 10 years Driven by vendors Consumers largely locked out Lowest common denominator features Glacial innovation

6. SOFTWARE DEFINED NETWORK Introduction Motivation Concept Open Flow Virtual Switch

7. Windows (OS) Windows (OS) Windows (OS) Windows (OS) Linux Mac OS Mac OS x86 (Computer) x86 (Computer) Windows (OS) Windows (OS) App Linux Mac OS Mac OS Mac OS Mac OS Virtualization layer App Controller 1 App Controller 2 Controller 2 Virtualization or “Slicing” App OpenFlow Controller 1 NOX (Network OS) NOX (Network OS) Controller 2 Controller 2 Network OS Trend Computer IndustryNetwork Industry

8. Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Ap p Specialized Packet Forwarding Hardware Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Operating System Ap p Network Operating System App The “Software-defined Network”

9. App Simple Packet Forwarding Hardware App Simple Packet Forwarding Hardware Network Operating System 1. Open interface to hardware 3. Well-defined open API 2. At least one good operating system Extensible, possibly open-source The “Software-defined Network”

10. Simple Packet Forwarding Hardware Network Operating System 1 Open interface to hardware Virtualization or “Slicing” Layer Network Operating System 2 Network Operating System 3 Network Operating System 4 App Many operating systems, or Many versions Open interface to hardware Isolated “slices” Simple Packet Forwarding Hardware

11. Consequences More innovation in network services – Owners, operators, 3 rd party developers, researchers can improve the network – E.g. energy management, data center management, policy routing, access control, denial of service, mobility Lower barrier to entry for competition – Healthier market place, new players

12. SOFTWARE DEFINED NETWORK Introduction Motivation Concept Open Flow Virtual Switch

13. Traditional network node: Router Router can be partitioned into control and data plane – Management plane/ configuration – Control plane / Decision: OSPF (Open Shortest Path First) – Data plane / Forwarding Adjacent Router Router Management/Policy plane Configuration / CLI / GUI Static routes Control plane OSPF Neighbor table Link state database IP routing table Forwarding table Data plane Control plane OSPF Adjacent Router Data plane Control plane OSPF Routing Switching

14. Traditional network node: Switch Typical Networking Software – Management plane – Control Plane – The brain/decision maker – Data Plane – Packet forwarder

15. SDN Concept Separate Control plane and Data plane entities – Network intelligence and state are logically centralized – The underlying network infrastructure is abstracted from the applications Execute or run Control plane software on general purpose hardware – Decouple from specific networking hardware – Use commodity servers Have programmable data planes – Maintain, control and program data plane state from a central entity An architecture to control not just a networking device but an entire network

16. Control Program Control program operates on view of network – Input: global network view (graph/database) – Output: configuration of each network device Control program is not a distributed system – Abstraction hides details of distributed state

17. Software-Defined Network with key Abstractions in the Control Plane Network Operating System Routing Traffic Engineering Other Applications Well-defined API Network Map Abstraction Forwarding Separation of Data and Control Plane Network Virtualization

18. Forwarding Abstraction Purpose: Abstract away forwarding hardware Flexible – Behavior specified by control plane – Built from basic set of forwarding primitives Minimal – Streamlined for speed and low-power – Control program not vendor-specific OpenFlow is an example of such an abstraction

19. OpenFlow Protocol Data Path (Hardware) Control PathOpenFlow Network OS Control Program A Control Program B OpenFlow Basics

20. Control Program A Control Program B Network OS OpenFlow Basics Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Flow Table(s) Flow Table(s) “If header = p, send to port 4” “If header = ?, send to me” “If header = q, overwrite header with r, add header s, and send to ports 5,6”

21. Plumbing Primitives Match arbitrary bits in headers: – Match on any header, or new header – Allows any flow granularity Action – Forward to port(s), drop, send to controller – Overwrite header with mask, push or pop – Forward at specific bit-rate 21 Header Data Match: 1000x01xx0101001x

22. General Forwarding Abstraction Small set of primitives “Forwarding instruction set” Small set of primitives “Forwarding instruction set” Protocol independent Backward compatible Protocol independent Backward compatible Switches, routers, WiFi APs, basestations, TDM/WDM

23. SOFTWARE DEFINED NETWORK Introduction Motivation Concept Open Flow Virtual Switch

24. What is OpenFlow OpenFlow is similar to an x86 instruction set for the network Provide open interface to “black box” networking node – (ie. Routers, L2/L3 switch) to enable visibility and openness in network Separation of control plane and data plane. – The datapath of an OpenFlow Switch consists of a Flow Table, and an action associated with each flow entry – The control path consists of a controller which programs the flow entry in the flow table OpenFlow is based on an Ethernet switch, with an internal flow-table, and a standardized interface to add and remove flow entries

25. OpenFlow Consortium http://OpenFlowSwitch.org Goal – Evangelize OpenFlow to vendors – Free membership for all researchers – Whitepaper, OpenFlow Switch Specification, Reference Designs – Licensing: Free for research and commercial use

26. OpenFlow building blocks Controller NOX Slicing Software FlowVisor Console 26 Applications LAVI ENVI (GUI) Expedient n-Casting NetFPGA Software Ref. Switch Software Ref. Switch Broadcom Ref. Switch Broadcom Ref. Switch OpenWRT PCEngine WiFi AP Commercial Switches Stanford Provided OpenFlow Switches ONIX Stanford Provided Monitoring/ debugging tools oflops oftrace openseer Open vSwitch HP, NEC, Pronto, Juniper.. and many more Beacon Trema Maestro

27. Components of OpenFlow Network Controller – OpenFlow protocol messages – Controlled channel – Processing Pipeline Processing Packet Matching Instructions & Action Set OpenFlow switch – Secure Channel (SC) – Flow Table Flow entry

28. OpenFlow Controllers 28 NameLangPlatform(s)LicenseOriginal Author Notes OpenFlow Reference CLinuxOpenFlow License Stanford/Nici ra not designed for extensibility NOXPytho n, C++ LinuxGPLNiciraactively developed BeaconJavaWin, Mac, Linux, Android GPL (core), FOSS Licenses for your code David Erickson (Stanford) runtime modular, web UI framework, regression test framework MaestroJavaWin, Mac, Linux LGPLZheng Cai (Rice) TremaRuby, C LinuxGPLNECincludes emulator, regression test framework OpenDaylightJavaLinux? OpenDaylight Community Linux Foundation Effort is supported by large vendors

29. Secure Channel (SC) SC is the interface that connects each OpenFlow switch to controller A controller configures and manages the switch via this interface. – Receives events from the switch – Send packets out the switch SC establishes and terminates the connection between OpneFlow Switch and the controller using the procedures – Connection Setup – Connection Interrupt The SC connection is a TLS connection. Switch and controller mutually authenticate by exchanging certificates signed by a site-specific private key.

30. Flow Table Rule (exact & wildcard) ActionStatistics Rule (exact & wildcard) ActionStatistics Rule (exact & wildcard) ActionStatistics Rule (exact & wildcard) Default ActionStatistics Flow table in switches, routers, and chipsets Flow 1. Flow 2. Flow 3. Flow N.

31. Flow Entry A flow entry consists of – Match fields Match against packets – Action Modify the action set or pipeline processing – Stats Update the matching packets Match Fields StatsAction In Port Src MAC Dst MAC Eth Type Vlan Id IP Tos IP Proto IP Src IP Dst TCP Src Port TCP Dst Port Layer 2 Layer 3Layer 4 1.Forward packet to port(s) 2.Encapsulate and forward to controller 3.Drop packet 4.Send to normal processing pipeline 1.Forward packet to port(s) 2.Encapsulate and forward to controller 3.Drop packet 4.Send to normal processing pipeline 1. Packet 2. Byte counters 1. Packet 2. Byte counters

32. Examples Switching * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * 00:1f:.. *******port6 Flow Switching port3 Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action 00:20..00:1f..0800vlan11.2.3.45.6.7.841726480port6 Firewall * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action ********22drop 32

33. Examples Routing * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action *****5.6.7.8***port6 VLAN Switching * Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action ** vlan1 ***** port6, port7, port9 00:1f.. 33

34. OpenFlowSwitch.org Controller OpenFlow Switch PC OpenFlow Usage OpenFlow Switch OpenFlow Switch OpenFlow Protocol Peter’s code RuleActionStatisticsRuleActionStatisticsRuleActionStatistics Peter

35. Usage examples Peter’s code: – Static “VLANs” – His own new routing protocol: unicast, multicast, multipath, load- balancing – Network access control – Home network manager – Mobility manager – Energy manager – Packet processor (in controller) – IPvPeter – Network measurement and visualization – …

36. Separate VLANs for Production and Research Traffic Normal L2/L3 Processing Flow Table Production VLANs Research VLANs Controller

37. Dynamic Flow Aggregation on an OpenFlow Network Scope – Different Networks want different flow granularity (ISP, Backbone,…) – Switch resources are limited (flow entries, memory) – Network management is hard – Current Solutions : MPLS, IP aggregation

38. Dynamic Flow Aggregation on an OpenFlow Network How do OpenFlow Help? – Dynamically define flow granularity by wildcarding arbitrary header fields – Granularity is on the switch flow entries, no packet rewrite or encapsulation – Create meaningful bundles and manage them using your own software (reroute, monitor)

39. Virtualizing OpenFlow Network operators “Delegate” control of subsets of network hardware and/or traffic to other network operators or users Multiple controllers can talk to the same set of switches Imagine a hypervisor for network equipments Allow experiments to be run on the network in isolation of each other and production traffic

40. Switch Based Virtualization Exists for NEC, HP switches but not flexible enough Normal L2/L3 Processing Flow Table Production VLANs Research VLAN 1 Controller Research VLAN 2 Flow Table Controller 40

41. FlowVisor A network hypervisor developed by Stanford A software proxy between the forwarding and control planes of network devices

42. FlowVisor-based Virtualization OpenFlow Switch OpenFlow Protocol OpenFlow Protocol OpenFlow FlowVisor & Policy Control Craig’s Controller Heidi’s Controller Aaron’s Controller OpenFlow Protocol OpenFlow Protocol OpenFlow Switch OpenFlow Switch 42 Topology discovery is per slice

43. OpenFlow Protocol OpenFlow FlowVisor & Policy Control Broadcast Multicast OpenFlow Protocol http Load-balancer FlowVisor-based Virtualization OpenFlow Switch OpenFlow Switch OpenFlow Switch 43 Separation not only by VLANs, but any L1-L4 pattern dl_dst=FFFFFFFFFFFF tp_src=80, or tp_dst=80

44. FlowVisor Slicing Slices are defined using a slice definition policy – The policy language specifies the slice’s resource limits, flowspace, and controller’s location in terms of IP and TCP port-pair – FlowVisor enforces transparency and isolation between slices by inspecting, rewriting, and policing OpenFlow messages as they pass

45. FlowVisor Resource Limits FV assigns hardware resources to “Slices” – Topology Network Device or Openflow Instance (DPID) Physical Ports – Bandwidth Each slice can be assigned a per port queue with a fraction of the total bandwidth – CPU Employs Course Rate Limiting techniques to keep new flow events from one slice from overrunning the CPU – Forwarding Tables Each slice has a finite quota of forwarding rules per device

46. Slicing

47. FlowVisor FlowSpace FlowSpace is defined by a collection of packet headers and assigned to “Slices” – Source/Destination MAC address – VLAN ID – Ethertype – IP protocol – Source/Destination IP address – ToS/DSCP – Source/Destination port number

48. FlowSpace: Maps Packets to Slices

49. FlowVisor Slicing Policy FV intercepts OF messages from devices – FV only sends control plane messages to the Slice controller if the source device is in the Slice topology. – Rewrites OF feature negotiation messages so the slice controller only sees the ports in it’s slice – Port up/down messages are pruned and only forwarded to affected slices

50. FlowVisor Slicing Policy FV intercepts OF messages from controllers – Rewrites flow insertion, deletion & modification rules so they don’t violate the slice definition Flow definition – ex. Limit Control to HTTP traffic only Actions – ex. Limit forwarding to only ports in the slice – Expand Flow rules into multiple rules to fit policy Flow definition – ex. If there is a policy for John’s HTTP traffic and another for Uwe’s HTTP traffic, FV would expand a single rule intended to control all HTTP traffic into 2 rules. Actions – ex. Rule action is send out all ports. FV will create one rule for each port in the slice. – Returns “action is invalid” error if trying to control a port outside of the slice

51. FlowVisor Message Handling OpenFlow Firmware Data Path Alice Controller Bob Controller Cathy Controller FlowVisor OpenFlow Packet Exception Policy Check: Is this rule allowed? Policy Check: Who controls this packet? Full Line Rate Forwarding Rule Packet

52. SOFTWARE DEFINED NETWORK Introduction Motivation Concept Open Flow Virtual Switch

53. INTRODUCTION Due to the cloud computing service, the number of virtual switches begins to expand dramatically – Management complexity, security issues and even performance degradation Software/hardware based virtual switches as well as integration of open-source hypervisor with virtual switch technology is exhibited 53

54. Software-Based Virtual Switch The hypervisors implement vSwitch Each VM has at least one virtual network interface cards (vNICs) and shared physical network interface cards (pNICs) on the physical host through vSwitch Administrators don’t have effective solution to separate packets from different VM users For VMs reside in the same physical machine, their traffic visibility is a big issue 54

55. Issues of Traditional vSwitch The traditional vSwitches lack of advanced networking features such as VLAN, port mirror, port channel, etc. Some hypervisor vSwitch vendors provide technologies to fix the above problems – OpenvSwitch may be superior in quality for the reasons 55

56. Open vSwitch A software-based solution – Resolve the problems of network separation and traffic visibility, so the cloud users can be assigned VMs with elastic and secure network configurations Flexible Controller in User-Space Fast Datapath in Kernel Server Open vSwitch Datapath Open vSwitch Controller

57. Open vSwitch Concepts Multiple ports to physical switches – A port may have one or more interfaces Bonding allows more than once interface per port Packets are forwarded by flow Visibility – NetFlow – sFlow – Mirroring (SPAN/RSPAN/ERSPAN) IEEE 802.1Q Support – Enable virtual LAN function – By attaching VLAN ID to Linux virtual interfaces, each user will have its own LAN environment separated from other users

58. Open vSwitch Concepts Fine-grained ACLs and QoS policies – L2-­‐L4 matching – Actions to forward, drop, modify, and queue – HTB and HFSC queuing disciplines Centralized control through OpenFlow Works on Linux-based hypervisors: – Xen – XenServer – KVM – VirtualBox

59. Open vSwitch Contributors(Partial)

60. Packets are Managed as Flows A flow may be identied by any combination of – Input port – VLAN ID (802.1Q) – Ethernet Source MAC address – Ethernet Destination MAC address – IP Source MAC address – IP Destination MAC address – TCP/UDP/... Source Port – TCP/UDP/... Destination Port

61. Packets are Managed as Flows The 1st packet of a flow is sent to the controller The controller programs the datapath's actions for a flow – Usually one, but may be a list – Actions include: Forward to a port or ports mirror Encapsulate and forward to controller Drop And returns the packet to the datapath Subsequent packets are handled directly by the datapath

62. Migration KVM and Xen provide Live Migration With bridging, IP address migration must occur with in the same L2 network Open vSwitch avoids this problem using GRE tunnels

63. Hardware-Based Virtual Switch Why hardware-based? – Software virtual switches consume CPU and memory usage – Possible inconsistence of network and server configurations may cause errors and is very hard to troubleshooting and maintenance Hardware-based virtual switch solution emerges for better resource utilization and configuration consistency 63

64. Virtual Ethernet Port Aggregator A standard led by HP, Extreme, IBM, Brocade, Juniper, etc. An emerging technology as part of IEEE 802.1Qbg Edge Virtual Bridge (EVB) standard The main goal of VEPA is to allow traffic of VMs to exit and re-enter the same server physical port to enable switching among VMs 64

65. Virtual Ethernet Port Aggregator VEPA software update is required for host servers in order to force packets to be transmitted to external switches An external VEPA enabled switch is required for communications between VMs in the same server VEPA supports “hairpin” mode which allows traffic to “hairpin” back out the same port it just received it from--- requires firmware update to existing switches 65

66. Pros. and Cons. for VEPA Pros – Minor software/firmware update, network configuration maintained by external switches Cons – VEPA still consumes server resources in order to perform forwarding table lookup 66

67. References "OpenFlow: Enabling Innovation in Campus Networks“ N. McKeown, T. Andershnan, G. Parulkar, L. Peterson, J. Rexford, S. Shenker, and J. Turneron, H. Balakris ACM Computer Communication Review, Vol. 38, Issue 2, pp. 69-74 April 2008 OpenFlow Switch Specication V 1.1.0. Richard Wang, Dana Butnariu, and Jennifer Rexford OpenFlow-based server load balancing gone wild, Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise 66 IP Infusion Proprietary and Confidential, released under Customer NDA, Roadmap items subject to change without notice © 2011 IP Infusion Inc. gone wild, Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services (Hot-ICE), Boston, MA, March 2011. Saurav Das, Guru Parulkar, Preeti Singh, Daniel Getachew, Lyndon Ong, Nick McKeown, Packet and Circuit Network Convergence with OpenFlow, Optical Fiber Conference (OFC/NFOEC'10), San Diego, March 2010 Nikhil Handigol, Srini Seetharaman, Mario Flajslik, Nick McKeown, Ramesh Johari, Plug-n-Serve: Load-Balancing Web Traffic using OpenFlow, ACM SIGCOMM Demo, Aug 2009. NOX: Towards an Operating System for Networks https://sites.google.com/site/routeflow/home http://www.openflow.org/ http://www.opennetsummit.org/ https://www.opennetworking.org/ http://conferences.sigcomm.org/sigcomm/2010/papers/sigcomm/p195.pdf http://searchnetworking.techtarget.com/

68. References Network Virtualization with Cloud Virtual Switch S. Horman, “An Introduction to Open vSwitch,” LinuxCon Japan, Yokohama, Jun. 2, 2011.An Introduction to Open vSwitch J. Pettit, J. Gross “Open vSwitch Overview,” Linux Collaboration Summit, San Francisco, Apr. 7, 2011.Open vSwitch Overview J. Pettit, “Open vSwitch: A Whirlwind Tour,” Mar. 3, 2011.Open vSwitch: A Whirlwind Tour Access Layer Network Virtualization: VN-Tag and VEPA OpenFlow Tutorial

69. Network Virtualization

70. Network Design Rules Hierarchical approach – Traffic is aggregated hierarchically from an access layer into a layer of distribution switches and finally onto the network core. – A hierarchical approach to network design has proven to deliver the best results in terms of optimizing scalability, improving manageability, and maximizing network availability.

71. Network Virtualization What is network virtualization ? 71

72. Network Virtualization What is network virtualization ? – In computing, network virtualization is the process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Two categories : – External network virtualization Combine many networks, or parts of networks, into a virtual unit. – Internal network virtualization Provide network-like functionality to the software containers on a single system.

73. Network Virtualization Desirable properties of network virtualization : – Scalability Easy to extend resources in need Administrator can dynamically create or delete virtual network connection – Resilience Recover from the failures Virtual network will automatically redirect packets by redundant links – Security Increased path isolation and user segmentation Virtual network should work with firewall software – Availability Access network resource anytime 73

74. Network Virtualization External network virtualization in different layers : – Layer 1 Seldom virtualization implement in this physical data transmission layer. – Layer 2 Use some tags in MAC address packet to provide virtualization. Example, VLAN. – Layer 3 Use some tunnel techniques to form a virtual network. Example, VPN. – Layer 4 or higher Build up some overlay network for some application. Example, P2P.

75. Network Virtualization Internal network virtualization in different layers : – Layer 1 Hypervisor usually do not need to emulate the physical layer. – Layer 2 Implement virtual L2 network devices, such as switch, in hypervisor. Example, Linux TAP driver + Linux bridge. – Layer 3 Implement virtual L3 network devices, such as router, in hypervisor. Example, Linux TUN driver + Linux bridge + iptables. – Layer 4 or higher Layer 4 or higher layers virtualization is usually implemented in guest OS. Applications should make their own choice.

76. NETWORK VIRTUALIZATION Introduction External network virtualization Internal network virtualization

77. Network Virtualization Two virtualization components : – Device virtualization Virtualize physical devices in the network – Data path virtualization Virtualize communication path between network access points 77 Router Switch Data Path

78. Network Virtualization Device virtualization – Layer 2 solution Divide physical switch into multiple logical switches.  Layer 3 solution 3 VRF technique ( Virtual Routing and Forwarding ) Emulate isolated routing tables within one physical router. 78

79. Network Virtualization Data path virtualization – Hop-to-hop case Consider the virtualization applied on a single hop data-path. – Hop-to-cloud case Consider the virtualization tunnels allow multi-hop data- path. 79

80. Network Virtualization Protocol approach – Protocols usually use for data-path virtualization. – Three implementations 802.1Q – implement hop to hop data-path virtualization MPLS ( Multiprotocol Label Switch ) – implement router and switch layer virtualization GRE (Generic Routing Encapsulation ) – implement virtualization among wide variety of networks with tunneling technique. 80

81. Network Virtualization 802.1Q – Standard by IEEE 802.1 – Not encapsulate the original frame – Add a 32-bit field between MAC address and EtherTypes field ETYPE(2B): Protocol identifier Dot1Q Tag(2B): VLAN number, Priority code 81 CE: Customer Edge router PE: Provider Edge router

82. Network Virtualization 82 Physical Network VN 1 VN 2 Sourcedestination Source Example of 802.1Q

83. Network Virtualization MPLS ( Multiprotocol Label Switch ) – Also classified as layer 2.5 virtualization – Add one or more labels into package – Need Label Switch Router(LSR) to read MPLS header 83

84. Packet Traversing a Label-Switched Path

85. Network Virtualization 85 Physical Network VN 1 VN 2 4 4 5 7 8 9 2 CE LER LSR LER CE LSR 9 2 5 7 Example of MPLS

86. Network Virtualization GRE ( Generic Routing Encapsulation ) – GRE is a tunnel protocol developed by CISCO – Encapsulate a wide variety of network layer protocols inside virtual point-to-point links over an Internet Protocol internetwork – Stateless property This means end-point doesn't keep information about the state 86 Built Tunnel

87. NETWORK VIRTUALIZATION Introduction External network virtualization Internal network virtualization

88. Internal Network Virtualization Internal network virtualization – A single system is configured with containers, such as the Xen domain, combined with hypervisor control programs or pseudo-interfaces such as the VNIC, to create a “network in a box”. – This solution improves overall efficiency of a single system by isolating applications to separate containers and/or pseudo interfaces. – Virtual machine and virtual switch : The VMs are connected logically to each other so that they can send data to and receive data from each other. Each virtual network is serviced by a single virtual switch. A virtual network can be connected to a physical network by associating one or more network adapters (uplink adapters) with the virtual switch.

89. Internal Network Virtualization Properties of virtual switch – A virtual switch works much like a physical Ethernet switch. – It detects which VMs are logically connected to each of its virtual ports and uses that information to forward traffic to the correct virtual machines. Typical virtual network configuration – Communication network Connect VMs on different hosts – Storage network Connect VMs to remote storage system – Management network Individual links for system administration

90. Internal Network Virtualization Network virtualization example form VMware

91. KVM Approach In KVM system – KVM focuses on CPU and memory virtualization, so IO virtualization framework is completed by QEMU. – In QEMU, network interface of virtual machines connect to host by TUN/TAP driver and Linux bridge. Virtual machines connect to host by a virtual network adapter, which is implemented by TUN/TAP driver. Virtual adapters will connect to Linux bridges, which play the role of virtual switch.

92. KVM Approach TUN/TAP driver – TUN and TAP are virtual network kernel drivers : TAP (as in network tap) simulates an Ethernet device and operates with layer 2 packets such as Ethernet frames. TUN (as in network TUNnel) simulates a network layer device and operates with layer 3 packets such as IP. – Data flow of TUN/TAP driver Packets sent by an operating system via a TUN/TAP device are delivered to a user-space program that attaches itself to the device. A user-space program may pass packets into a TUN/TAP device. TUN/TAP device delivers (or "injects") these packets to the operating system network stack thus emulating their reception from an external source.

93. KVM Approach

94. Linux bridge – Bridging is a forwarding technique used in packet-switched computer networks. – Unlike routing, bridging makes no assumptions about where in a network a particular address is located. – Bridging depends on flooding and examination of source addresses in received packet headers to locate unknown devices. – Bridging connects multiple network segments at the data link layer (Layer 2) of the OSI model.

95. KVM Approach TAP/TUN driver + Linux Bridge

96. Xen Approach In Xen system – Since implemented by para-virtualization, guest OS loads modified network interface drivers. – Modified network interface drivers, which act as TAP in KVM approach, communicate with virtual switches in Dom0. – Virtual switch in Xen can be implemented by Linux bridge or work with other approaches.

97. Network Virtualization Summary Virtualization in layers – Usually in Layer 2 and Layer 3 External network virtualization – Layer 2 802.1q – Layer 3 MPLS, GRE Internal network virtualization – Traditional approach TAP/TUN + Linux bridge – New technique Virtual switch

98. Reference Books : – Kumar Reddy & Victor Moreno, Network Virtualization, Cisco Press 2006 Web resources : – Linux Bridge http://www.ibm.com/developerworks/cn/linux/l-tuntap/index.html – Xen networking http://wiki.xensource.com/xenwiki/XenNetworking – VMware Virtual Networking Concepts http://www.vmware.com/files/pdf/virtual_networking_concepts.pdf – TUN/TAP wiki http://en.wikipedia.org/wiki/TUN/TAP – Network Virtualization wiki http://en.wikipedia.org/wiki/Network_virtualization Papers : – A. Menon, A. Cox, and W. Zwaenepoel. Optimizing Network Virtualization in Xen. Proc. USENIX Annual Technical Conference (USENIX 2006), pages 15–28, 2006.