• No results found

Software Defined Networking: The 2 nd Wave of Cloud Computing

N/A
N/A
Protected

Academic year: 2021

Share "Software Defined Networking: The 2 nd Wave of Cloud Computing"

Copied!
47
0
0

Loading.... (view fulltext now)

Full text

(1)Software Defined Networking: The 2nd Wave of Cloud Computing Turning Appliances to Apps. Ying-Dar Lin IEEE Fellow, IEEE Distinguished Lecturer, ONF Research Associate, Associate EiC of IEEE Computer Distinguished Professor, National Chiao Tung University, Taiwan Director, Network Benchmarking Lab December 2015. 1.

(2) 林盈達 Ying-Dar Lin  .  . .       .  Areas of research interests B.S., NTU-CSIE, 1988; Ph.D., UCLA-CS, 1993  Software Defined Networking Distinguished Professor (2014~)/Professor (1999~2013)/Associate Professor (1993~1999), NCTU-CS;  Deep Packet Inspection IEEE Fellow (2013~); IEEE ComSoC Distinguished Lecturer  Attack, virus, spam, porno, P2P (2014&2015), ONF Research Associate (6/2014~)  Software, algorithm, hardware, SoC Founder and Director, NCTU Network Benchmarking Lab (NBL; www.nbl.org.tw, ONF Approved Lab), 2002~  Real traffic, beta site, botnet Editorial Boards: Associate EiC of IEEE Computer (2015~),  Internet security and QoS IEEE Wireless Comm. (2013~), IEEE Transactions on  Wireless communications Computers (2011~2015), IEEE Computer (2012~), IEEE Network (2011~), IEEE Communications Magazine – Network  Test technologies of switch, router, WLAN, Testing Series (2010~), IEEE Communications Letters (2010~), security, VoIP, 4G/LTE, SDN, and smartphones Computer Communications (2010~), Computer Networks  Publications (2010~) , IEEE Communications Surveys and Tutorials (2008~), IEICE Transactions on Information and Systems (11/2011~)  International journal: 109 Guest Editors of Special Issues: Traffic Forensics, IEEE  International conference: 53 Systems Journal, May 2015; SDN, IEEE Computer, Nov 2014; Multi-Hop Cellular, IEEE Wireless Communications, Oct 2014;  IETF Internet Draft: 1 Deep Packet Inspection, IEEE JSAC, Oct 2014; Mobile  Industrial articles: 170 Application Security, IEEE Computer, June 2014; Open  Textbooks: 3 (Ying-Dar Lin, Ren-Hung Hwang, Source for Networking, IEEE Network, Mar&Sept 2014. Fred Baker, Computer Networks: An Open Source Founder and Director, III-NCTU Embedded Benchmarking Lab Approach, McGraw-Hill, Feb 2011) (EBL; www.ebl.org.tw), 2011~2015  Patents: 31 CEO, Telecom Technology Center (www.ttc.org.tw), 7/2010~5/2011  Tech transfers: 8 Director, Computer and Network Center, NCTU, 2007~2010  Well-cited paper: Multihop Cellular: A New Consultant, ICL/ITRI, 2002~2010 Architecture for Wireless Communications, INFOCOM Visiting Scholar, Cisco, San Jose, 7/2007-7/2008 2000, YD Lin and YC Hsu; #citations: 675; standardized Director, Institute of Network Engineering, NCTU, 2005~2007 into IEEE 802.11s, Bluetooth, WiMAX, and LTE Co-Founder, L7 Networks Inc. (www.L7.com.tw), 2002. 2.

(3) Outline (1/2) • Overview    . Why SDN How to SDN Where and when to SDN Market forecast. • Research Survey  . Survey My roadmap. • Standardization    . Basic SDN architecture Related standards Introduction to OpenFlow Extended SDN architecture. • Development   . Resources for developers Data plane Control plane  Introduction to RYU  Routing in SDN. . Management plane  Introduction to OpenFlow extension. . Case study: Campus Wi-Fi SDN solution  Functional specification  Architecture design. 3.

(4) Outline (2/2) • Testing    . Resources for testers Testing tools Test items and methodologies Case study: SDN conformance test. • Lessons Learned • References. 4.

(5) Overview. 5.

(6) Why SDN? • 2nd wave of cloud computing . 1st wave to servers: centralized and virtualized. • NaaS (Networking as a Service) From operators to enterprise and residential subscribers  Turning appliances to apps . • Virtues Reduced CAPEX (simpler devices) and OPEX (fewer administrators)  Fast service orchestration (centralized programmability) . 6.

(7) But How To Centralize Networking? • Centralized control and management planes . . At controllers (basic connectivity) and applications (advanced services) Control and manage data plane at switches. • Southbound API between controllers and switches: OpenFlow over SSL • Northbound API between controllers and applications 7.

(8) SDN versus Traditional (1/2) • Control-Plane: routing Traditional network. SDN. OSPF. RIP. LLDP + OpenFlow Flow_modify. Link state. Distance Vector. LLDP Message. Dijkstra algorithm. Bellman-Ford algorithm. Any (e.g. Dijkstra algorithm). Topology information. Global /Distributed. Partial /Distributed. Global, partial /Centralized. Link failure handling. Flood the link states. Exchange the distance vectors. 1. Switch sends portstatus to controller 2. Controller updates the partial topology. Congestion handling. Flood the link states. Exchange the distance vectors. Wait for next interval to update routing path. Computation. 8.

(9) SDN versus Traditional (2/2) • Management-Plane Traditional network. SDN. Management information. Centralized. Centralized. Access method. SNMP. OpenFlow protocol and OF-CONFIG. Control level. Limited Unlimited (e.g. can’t modify the (e.g. can modify the routing table) routing table). Information usage. Management-plane. Control-plane & Management-plane. 9.

(10) Too Primitive?. Basic SDN to Extended SDN by Centralizing Data Plane • To extend data plane . Network Function Virtualization (NFV)  To run new services on appliances or VMs. • To extend control plane for the extended data plane . Service Chaining (SC) at applications  To decide service path. . Network Service Header (NSH) onto switches  To program service path. 10.

(11) Where and When to SDN? • Data centers: since late 2000s • Operators: NaaS Enterprises: service trials from 2014/2015  Residential: after 2017?  Wireless: after 2018? (small cells in 5G, HetNet in 4G) .  Cloud-RAN (Radio Access Network) . Mobile and M2M: after 2020?. 11.

(12) Driving Force on Operators • Challenges faced by all Communications Service Providers (CSPs). EB / month. Rapid mobile traffic growth, especially video content 20. Network cost is going to surge while revenue is steady…. Global mobile data traffic (2013-2018). 15 10 5 0 2013 2014 2015 2016 2017 2018 Data File Sharing Video M2M Source: SNS research. • CAPEX /OPEX surges due to boosted data traffic demand and 4G investment • Need to control network cost while boosting new service revenue. 12.

(13) Revenue Generation based on the Forecasted Fastgrowing of SDN-enabled Industry • SDN market value will hit US$36.3B by 2018 with a 60 CAGR of 75%. 50 • A visible ceiling in hardware market is a 40 huge threat to Taiwan ICT 30 industry. 20 • If TW can gain 10% of 10 market share, the revenue generation will be US$3.63B (NT$108.8B), even 5% will be US$1.28B (NT$54.4B). Source: SNS research. Global SDN sales by SW & HW (2010-2020) 400% 350% 300% 250% 200% 150% 100% 50% 0% -50%. SDN Controller Hardware Appliances SDN Controller Software YoY - SDN hardware - RHS YoY - SDN software - RHS. 13.

(14) SDN Market Forecasts US$bn. • Global SDN sales by user base (2010-2020) 60. 350%. 50. 300% 250%. 40. 200%. 30. 150%. 20. 100%. 10. 50%. -. 0%. Data Centers & Enterprises Service Providers YoY - Service provider - RHS YoY - Data center & Enterprise - RHS. Global service provider SDN & NFV revenue by functional area (2020) Wireline Fixed Access Networks 8%. CPE/Hom e Environm ent 5%. Radio Access Networks 20%. Mobile Backhaul 11%. Data Center 21%. OSS/BSS 4%. Mobile Core, EPC, IMS & Services 31%. Source: SNS Research. 14.

(15) SDN in Taiwan – SNS Forecast 80. Global SDN, NFV & Network Virtualization sales by Region (2010 - 2020 ) (US$bn). Asia Pacific SDN, NFV & Network Virtualization sales by country (2020) Rest of Asia Pacific 27%. 60 40. Singapore 1%. 20. South Korea 9%. 10' 11' 12' 13' 14' 15' 16' 17' 18' 19' 20' Asia Pacific Eastern Europe Latin & Central America Middle East & Africa North America Western Europe. Japan 23%. Taiwan 2% Australia 4% China 18%. India 16%. • Asia Pacific is the biggest market driver for SDN growth • SNS forecasts Taiwan SDN & NFV sales to enjoy a similar growth pattern as other Asian countries does as Pakistan, Thailand, Indonesia, Philippines and Singapore. 15.

(16) Research Survey. 16.

(17) Survey: Correctness and Conformance Issue. Layer. Type of verification. Ref. Correctness of flow entry. Infrastructure layer. Run time verification. [1]. Offline verification. [2],[3]. Network correctness. Control and Infrastructure layer. Algorithm for verification. [4],[5]. Offline test. [6],[7]. Policy correctness. Application and control layer. Algorithm for verification. [8],[9]. Run time verification. [10]. Policy update correctness. Application, control and Infrastructure layer. Verification of updates. [11],[12]. 17.

(18) Survey: Performance and Scalability Issue. Sub issue. Solution. Require modification. Ref. Lookup procedure. Flow table size Lookup procedure CPU power. Implement Full line-rate switch on NetFPGA. Switch hardware. [13]. CPU power. Network processor acceleration card. Switch hardware. [14]. Software base lookup procedure. By caching table entry on network interface card. Switch hardware. [15]. Flow table size CPU power. Multi-core. Switch hardware. [16]. Buffer size CPU power. High-bandwidth internal link. Switch hardware. [17]. Flow table size. Algorithm for rules placement. Rule placement algorithm. [18]. Switch resources utilization. 18.

(19) Survey: Security [19] Solution to Security issue. SDN layer App. Unauthorized Access. Ref Control. Data. O. [20]. O. Malicious Applications. O. O. O. O. O. O. Denial of Service O Configuration Issues. [21] O. [24] [25] O. [26]. O. O. [27] [28]. O. [29]. O. O. O. O. O O. [23]. O. O System Level SDN Security. [22]. [30] [31] [32] O. [33] [34] [35] [36] [37]. O. [38]. 19.

(20) Survey: Use Cases Case. Benefits. Ref. Cloud. • Large in scale • Cost-effective • Easy to operate. [39] [40]. Mobile. • Speed up the deployment of new solutions. [41][42]. ICN (Information content network) • Easy to deploy. [43][44]. Network function virtualization. • Reduce deployment time • Allow service scale up and down • Create new virtual applications. [45]. Network virtualization. • Customize virtual network. [46]. Security. • Controller security • Northbound interface security. [47][48]. 20.

(21) My Works on SDN/NFV • Services   . Lead guest editor, 1st SI on SDN, IEEE Computer, Nov 2014. Guest editor, SI on SDN-NFV Security, IEEE Comm. Mag., to submit. Publicity co-chair, 1st IEEE Conference on NFV-SDN, Nov 2015.. • Standard contributions   . ONF Research Associate, June 2014 ~ 5th ONF approved test lab (Network Benchmarking Lab, NBL), July 2014 ~ ONF OpenFlow 1.3.4 Conformance Test Plan, June 2015. • Development . SDN campus Wi-Fi solution. • Research  . Virtualized control plane: SDN track Virtualized data plane: NFV track 21.

(22) IEEE Computer Special Issue on SDN Standardization, Nov 2014 Title. Authors. Organization. The Evolution of SDN and OpenFlow: A Standards Perspective. Sujata Banerjee Puneet Sharma Jean Tourrihes Justin Pettit. • •. HP Labs VMware. •. OpenFlow evolution. Team of Rivals: Aligning Technology & Market Drivers in an Open-Source Standards. Rick Bauer Ron Milford Li Zhen. • • •. ONF InCNRTE BII. •. Testing programs. Network Functions Virtualization in Home Networks: A Test Lab Perspective. Marion Dillon Winter. • •. Timothy UNH/IOL. •. NFV for home networking. Service Function Chaining: Network Service Header. Paul Quinn, Jim Guichard. •. Cisco. •. Service chaining by NSH. When Open Source Meets Network Control Planes. Christian Esteve Rothenberg Roy Chua Josh Bailey Martin Winter Carlos Correa Sidney C. de Lucena Marcos Rogério Salvador. • •. UNICAMP SDNCentral Google NetDEF UFF UNIRIO Lenovo Innovation Center Brocade. •. Open source resources, APIs, and a case study RouteFlow. • • • •. •. Issues. 22.

(23) Multi-Path Routing for Failures and Congestion (1/2). Fast Failover • Computing multiple paths for each pair of subnets • Installing flow and group entries proactively . “fast failover” group entry. IP/mask. BPad BPbd. packet A. port2 port1. Match. B port2. Instruction. IP/mask. D C. port1. APad. port2. Group1 Gid 1. Type fast failover. port1. BPcd Action buckets Output 1, Output 2. Y. D. Lin, H. Y. Deng, C. R. Hsu, C. C. Liao, Y. C. Lai, “Fast failover and switchover for link failures and congestion in software defined networks,” 1st IEEE Conference on Network Function Virtualization and Software Defined Networks (IEEE NFV-SDN), submitted, June 2015.. 23.

(24) Multi-Path Routing for Failures and Congestion (2/2) Fast Switchover. • Monitoring port status periodically • Switching flows to another path to resolve network congestion IP1/mask1. IP2/mask2. E. packet packetA. BPbe. Flow switchover port1. Match. B. port2. Instruction. IP1/mask1. Group1. IP2/mask2. Group2. D C. port2 port1. APad port1. Gid. congestion Type. Controller detects. Action buckets. 1. fast failover. Output 2, 1, 12. 2. fast failover. Output 1, 2. 24.

(25) An Extended SDN Architecture for Network Function Virtualization. Extended components: two-layer traffic classification in the data plane extended OpenFlow protocol messages service chaining mechanisms * indicates one or more instances indicates parts to be extended. SDN Application Service Routing Module. SDN Northbound Interfaces. SDN Controller Messages. Messages Redirected Traffic. Switch* Classification. OpenFlow Pipeline. NFV modules Service Chaining Mechanism. Deep Packet Inspection. Y. D. Lin, P. C. Lin, C. H. Yeh, Y. C. Wang, Y. C. Lai, “An extended SDN architecture for network function virtualization with a case study on intrusion prevention,” IEEE Network, Special Issue on NFV-SDN, May 2015.. 25.

(26) Case Study Extended Messages for Intrusion Detection CLA. SR. NFV. SYN flood packet OFPT_PACKET_IN_EXT OFPT_FLOW_MOD_EXT OFPT_PACKET_OUT_EXT. SYN flood packet. (1). ※(2) OFPT_MULTIPART_REQUEST_EXT *OFPT_MULTIPART_REPLY_EXT. (3). SYN flood packet +OFPT_MULTIPART_REPLY_EXT +OFPT_FLOW_OUT_EXT SYN flood packet DROP. ※(4). ※(5). ※ indicates that it happens one or more times * indicates that it comes with one or more instances + indicates that it happens depending on what is configured by SR. 26.

(27) SDN Multicast with Multiple Shared Trees • Building multi-group shared trees to reduce control-plane and data-plane overheads • Given 100 multicast sources, only 2-6 shared trees are built • The computation time is less than 100 ms and 4% flow entries of per-source tree are installed. 27.

(28) Cross-Domain SDN Service Extension • How controller architectures affect the performance of interdomain service extension? • Multi-controller architectures can reduce the initial latency and the processing time because requests can be handled in parallel. 28.

(29) SDN Wi-Fi Load Balancing (1/3) • Characteristics  . Application-based: Hardware independent Add one SDN controller and update APs. • Key functionalities . Balance degree  Senses the balance degree of network  Improves with 34%~41%, compared to load balancing disabled. . Two-tier dynamic method  Saves the re-association time about 28%~36%, compared to totally controlled by the controller  Relieves the network bottleneck in server by control level.  Provides easy admission control for stations’ association requests. 29.

(30) SDN Wi-Fi Load Balancing (2/3) • Architecture RYU controller (Events) AP Features Calculation. Make Decision. Wi-Fi devices (APs) 1. TCP Connected 2. AP Features. Initialization: Reports status & assoc_tbl. AP Enter. Change detected: Reports status & assoc_tbl. AP Experimenters. Action: Add/ delete stations. AP Leave. 3. Experimenter Message. Detection. Action. Shutdown: Disconnect/ 4. TCP Disconnected Crash/ Kill ps. 30.

(31) SDN Wi-Fi Load Balancing (3/3) RYU-controller Calculation: 1) Balance index 2) Average load level 3) Suggested control level (replaced by manual control level in experimental mode). Yes Stop. AP1, AP2 and AP3 report dev_info. Response the result to AP1, AP2, AP3. Balanced Yes. dev_info detection: 1) Max_conn (Mi,j): AP’s capacity 2) Curr_conn (nsi,j): |stations| 3) Loading: cpu, mem, per Action for calculation: 1) Keep result of calculation 2) If control level(Ci) isn’t equal to 0, report association table 3) nsi,j – (100-Ci)* Mi,j /100 = associ,j. Recv_msg == done? No. Yes. Stop. AP1, AP2, AP3. Balance index == 1? No. AP1, AP2 and AP3 report association table with size associ,j. Control level == 0?. Action for decision: 1) add/ delete the MAC of stations to apply the decision 2) Report done. No Make decision: 1) Make re-association table. dev_info changed with msg: done. Response the decision to AP1, AP2, AP3. 31.

(32) SDN-NFV Balanced Service Chaining and Traffic Steering (1/2) • Balanced service chaining on the data plane without resorting to the controller • Leverages the OpenFlow group table with the SELECT type according to the hashing-based selection algorithm Flow Table. rootA. rootB. rootC. rootD. Inter-Tree Tunnel Intra-Tree Path. Flow Table. Software Switch. Group Table. VM VM Service Functions. sv1. sv2. sv3. sv4. sv1. sv2. sv3. sv4. sv1. sv2. sv3. sv4. sv1. sv2. sv3. sv4. 32.

(33) SDN-NFV Balanced Service Chaining and Traffic Steering (2/2) sv2. sv2. sc1 = [ sv1, sv2, sv3 ] path1 = [ ingress, root1, root2, root3, egress ] path_id1 = 1. Match Fields SPI = 1, SI = 2 SPI = 1, SI = 1. Match Fields dst_port = 80. Actions Tag SPI = 1, SI = 3 label = 5 Output : sw1. Match Fields label = 5 label = 10. ingress. sw1. tunnel ingress, root1. Match Fields SPI = 1, SI = 3 SPI = 1, SI = 2. Actions Output = root1 label = 10  15 Output = sw2. Actions Output = Group table label = 10 Output = sw1. root2 Match Fields label = 35 label = 40. sw2. tunnel root1, root2 Match Fields label = 15. root1. label = 25. Actions Output = Group table label = 25 Output = sw2. Actions Output = root3 Output = egress. Match Fields **. sw3. tunnel root2, root3 Actions Output = root2 label = 25  35 Output = sw3. Actions Remove NSH. egress. tunnel root3, egress. root3. Match Fields Actions SPI = 1, SI = 1 Output = Group table label = 40 SPI = 1, SI = 0 Output = sw3. Inter-Tree Tunnel Intra-Tree Path sv1. sv1. sv3. sv3. 33.

(34) On-going Research Topics • Virtualized control plane (without NFV) SDN ONF performance test suite: switch, controller, app  SDN conflict detection for apps  SDN network QoS: multi-path load balancing  Hybrid SDN optimization: cost and coverage . • Virtualized data plane (with NFV) Scheduling service chains in NFV  NFV QoS with multi-path/multi-server load balancing  SDN/NFV App Store: VM allocation and reallocation . 34.

(35) Development. 35.

(36) Resources for Developers Topic. Purpose. Installation. Guide. Ryu. Controller. Ryu install [49]. Ryu API [50]. Ryu GUI. Ryu GUI install [51] Ryu gui [52]. Ofsoftswitch. Software openflow Ofsoftswitch install switch [53]. Mininet. Simulator. Mininet install [54]. Add experimenter message. Design openflow experimenter message. Environment setup Ofsoftswitch [56] dev.doc. Horst. Spectrum analyzer for Wi-Fi. Horst install [57]. Horst guide [58]. simple_switch_igmp.py. Multicast controller module. Install in ryu. -. Mininet tutorial [55]. 36.

(37) DPDK (standard vs DPDK). 37.

(38) Data Plane within Open vSwitch. udatapath.c. 38.

(39) Comparison on Controllers (Ryu, NOX, POX, Floodlight, OpenDayLight, ONOS) Controller. routing method. Language. Multithread. framework. Ryu. SPF. Python. YES. -. NOX. OSPF. C/python. YES. Boost library. POX. OSPF. Python. NO. -. Floodlight. SPF. Java. YES. Netty. OpenDayLight SPF. Java. YES. OSGi. ONOS. Java. YES. Intent. SPF. [59]NOX [60]POX. 39.

(40) Comparison on Modules Network apps. Web apps. Third-party extensions. NOX. Discovery, Topology Authenticator, Routing. Webserviceserver Webserviceclient. OVN, Basic Spanning Tree, Mobile VMs, RipCord, LAVI. POX. Discovery, Spanning tree, Topology. Webservice Load-balancer (http). Floodlight. Load Balancer Port Down Reconciliation Firewall, Static Flow Entry Pusher. Rest API. VirtualNetworkFilter (Quantum Plugin). RYU. Discovery, Topology Routing, GRE Tunnel BGP, VRRP. Rest API Ryu GUI. Basic Spanning Tree. OpenDayLight. Management GUI/CLI VTN coordinator OpenStack Neutron DDoS protection. Rest API. X. ONOS. Management GUI/CLI Topology Load balance. All Web APIs. Policy Enforcement, Conflict resolution. 40.

(41) Features vs. Components SDN Controller App. SDN Access Point. OAM Web System. System Management Generic Wireless Control Device Description Retrieval Auto Provision Function Channel Non-overlapping Function MAC Address Filter Control Local Service Management Diagnostic Function Device Status Retrieval Device Logging Retrieval Roaming Authentication Portal Function Quality of Service. 41.

(42) SDN Wi-Fi OAM • Centralized OAM with user friendly Web UI • Easy to maintain and will support multiple controllers. 42.

(43) Architecture Design (Beta Site). Controller: VM server Portal: VM server Router/NAT: Draytek SDN AP: TP-Link, EstiNet. 43.

(44) Architecture Design (Campus Network) OFSwitch: arista7050 NAT: Tplink 1043ND. 44.

(45) Resources for Testers Tool. Purpose. Reference. Mininet. Generate topology and simulate network behavior. OpenFlowVMs. Connect VM to openflow network. Openflow Conformance Test Plan. Conformance test. [63]. NICE. Auto testing tool for OpenFlow application. [64]. NDB. Network debugger (1)break point (2)packet back trace. [65][66]. OFLOPS. OpenFlow testing platform. [67]. 45.

(46) Test Tools Company. Product. Spirent. TestCenter OpenFlow. Functional Conformance. O. Codenomicon. O. Spirent Avalanche. O. TestCenter Virtual & Avalanche Virtual. O O. IxANVL IxNetwork. Negative testing. O. TestCenter. Ixia. Performance. O. O. O. OpenFlow Controller Test Suite. O. OpenFlow Switch Test Suite. O. 46.

(47) Lessons Learned nd. • SDN is the 2 wave of cloud computing. It provides NaaS (Networking as a Service). • With SDN, we can reduce CAPEX and OPEX, and ease service provisioning. • SDN will reorganize the ICT industry. • Cisco’s position OpenDaylight  Dominance  one of . • App matrix Appliances to apps  100 x 3~5 . • Tons of research, plus business opportunities, await us. 47.

(48)

References

Related documents

Ramamurthy, “Simplifying network management using software defined networking and OpenFlow,” in 2012 IEEE International Conference on Advanced Networks and Telecommuncations

A logically centralized SDN control plane will provide a holistic picture of cloud resources and access network availability (abstract view). This will ensure