Engenharia de Serviços Services Engineering

Transcription

1 Mestrado em Engenharia de Telecomunicações e Informá=ca Master Degree (MSc) in Telecommunica=ons and Informa=cs Engineering Engenharia de Serviços Services Engineering Architectures: Modelling and Abstrac=on The Future of Networking, and the Past of Protocols Introduc=on to SoGware Defined Networking (SDN) Prof. Rui Santos Cruz rui.s.cruz@tecnico.ulisboa.pt

2 TODAY 2 Characteris=cs of Evolving Networks The OSI Model Modelling & Abstrac=ng the NGN Framework The classifica=on methods for ICT Layered Model for Convergence Domains & Func=onal Layers Planes Regulatory Domains Standards and Standardisa=on

3 3 The Future of Networking, and the Past of Protocols Based on the presenta=ons of Prof. ScoY Shenker of UC Berkeley

4 4 Key to Internet Success: Layers Applications built on Reliable (or unreliable) transport built on Best-effort global packet delivery built on Best-effort local packet delivery built on Physical transfer of bits

5 5 Why Is Layering So Important? Decomposed delivery into fundamental components Independent but compa=ble innovation at each layer A prac=cal success of unprecedented propor=ons but an academic failure

6 6 Built an Ar=fact, Not a Discipline Other fields in systems : Opera=ng Systems, DataBases, Distributed Systems, etc. Teach basic principles Are easily managed Con=nue to evolve Networking: Teach big bag of protocols Notoriously difficult to manage Evolves very slowly

7 7 Why Does Networking Lag Behind? Networks used to be simple: Ethernet, IP, TCP. New control requirements led to Payload analysis inspec=on (DPI).. Deep packet great complexity Isola=on VLANs, ACLs Mechanisms designed and deployed independently Traffic engineering MPLS, ECMP, Weights Packet processing Firewalls, NATs, middleboxes Complicated control plane design, primi=ve func=onality Stark contrast to the elegantly modular data plane

8 8 Infrastructure S=ll Works! Only because of our ability to master complexity This ability to master complexity is both a blessing and a curse!

9 9 A BeYer Example: Programming Machine languages: no abstrac=ons Mastering complexity was crucial Higher-level languages: OS and other abstrac=ons File system, virtual memory, abstract data types,... Modern languages: even more abstrac=ons Object orienta=on, garbage collec=on, Abstractions are key to extracting simplicity

10 10 The Power of Abstrac=on Modularity based on abstraction is the way things get done Barbara Liskov Abstractions Interfaces Modularity What abstractions do we have in networking?

11 11 Abstractions ~ Problem Decomposition 1. Decompose problem into basic components (tasks) 2. Define an abstrac=on for each component 3. Implementa=on of abstrac=on can focus on one task 4. If tasks s=ll too hard to implement, return to step 1

12 12 Layers are Great Abstrac=ons Layers only deal with the data plane We have no powerful control plane abstrac=ons! How do we find those control plane abstrac=ons? Two steps: define problem, and then decompose it.

13 13 The Network Control Problem Compute the configura=on of each physical device E.g., Forwarding tables, ACLs, Operate without communica=on guarantees Operate within given network-level protocol Only people who love complexity would find this a reasonable request

14 14 Programming Analogy What if programmers had to: Specify where each bit was stored Explicitly deal with all internal communica=on errors within a programming language with limited expressibility Programmers would redefine the problem: Define a higher level abstrac=on for memory Build on reliable communica=on abstrac=ons Use a more general language Abstractions divide the problem into tractable pieces And make programmer s task easier

15 15 From Requirements to Abstrac=ons Operate without communica=on guarantees Need an abstrac=on for distributed state Compute the configura=on of each physical device Need an abstrac=on that simplifies configuration Operate within given network-level protocol Need an abstrac=on for general forwarding model Once these abstractions are in place, control mechanism has a much easier job!

16 16 Network of Switches and/or Routers Traditional Control Mechanisms Distributed algorithm running between neighbors

17 SoGware Defined Networking 17

18 18 Two Key Defini=ons Data Plane: processing and delivery of packets Based on state in routers and endpoints E.g., IP, TCP, Ethernet, etc. Fast =mescales (per-packet) Control Plane: establishing the state in routers Determines how and where packets are forwarded Rou=ng, traffic engineering, firewall state, Slow =me-scales (per control event) These different planes require different abstractions

19 19 Limita=ons of Current Networks Switches

20 20 Limita=ons of Current Networks Enterprise networks are difficult to manage New control requirements have arisen : Greater scale Migra=on of VMS How to easily configure huge networks?

21 21 Limita=ons of Current Networks Old ways to configure a network App App App Operating System Specialized Packet Forwarding Hardware App App App Operating System App App App Operating System Specialized Packet Forwarding Hardware App App App Operating System Specialized Packet Forwarding Hardware App App App Specialized Packet Forwarding Hardware Operating System Specialized Packet Forwarding Hardware OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center

22 22 Limita=ons of Current Networks Feature Operating System Feature Million of lines of source code Many complex functions baked into infrastructure Specialized Packet Forwarding Hardware Billions of gates OSPF, BGP, multicast, differentiated services, Traffic Engineering, NAT, firewalls, Cannot dynamically change according to network conditions OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center

23 23 Limita=ons of Current Networks No control plane abstraction for the whole network! It s like old times when there was no OS Wilkes with the EDSAC, 1949

24 OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center 24 Idea: An OS for Networks Control Programs Network Operating System Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware Simple Packet Forwarding Hardware

25 25 Idea: An OS for Networks NOX: Towards an Operating System for Networks Software-Defined Networking (SDN) Control Programs Global Network View Network Operating System Control via forwarding interface Protocols Protocols The Future of Networking, and the Past of Protocols, Scott Shenker, with Martin Casado, Teemu Koponen, Nick McKeown

26 26 SoGware Defined Networking No longer designing distributed control protocols Much easier to write, verify, maintain, An interface for programming NOS serves as fundamental control block With a global view of network

27 27 SoGware Defined Networking Questions: How to obtain global informa=on? What are the configura=ons? How to implement? How is the scalability? How does it really work?

28 28 A Short History of SDN ~2004: Research on new management paradigms RCP, 4D [Princeton, CMU,.] SANE, Ethane [Stanford/Berkeley] 2008: Software-Defined Networking (SDN) NOX Network Opera=ng System [Nicira] OpenFlow switch interface [Stanford/Nicira] 2011: Open Networking Founda=on (~69 members) Board: Google, Yahoo, Verizon, DT, Msoft, F book, NTT Members: Cisco, Juniper, HP, Dell, Broadcom, IBM, : Latest Open Networking Summit Almost 1000 ayendees, Google: SDN used for their WAN Commercialised, in produc=on use (few places)

29 29 1. Distributed State Abstrac=on Shield control mechanisms from state distribu=on While allowing access to this state Natural abstrac=on: global network view Annotated network graph provided through an API Implemented with Network Opera=ng System Control mechanism is now program using API No longer a distributed protocol, now just a graph algorithm

30 30 SoGware Defined Network (SDN) e.g. routing, access control Control Program Global Network View Network OS

31 31 Major Change in Paradigm No longer designing distributed control protocols Design one distributed system (NOS) Use for all control func=ons Now just defining a centralized control function Configuration = Function(view)

32 32 2. Specifica=on Abstrac=on Control program should express desired behaviour It should not be responsible for implemen=ng that behaviour on physical network infrastructure Natural abstrac=on: simplified model of network Simple model with only enough detail to specify goals Requires a new shared control layer: Map abstract configuration to physical configuration This is network virtualisamon

33 33 Simple Example: Access Control What Abstract Network Model How Global Network View

34 34 SoGware Defined Network: Take 2 Abstract Network Model Network Control Virtualization Program Global Network View Network OS

35 35 What Does This Picture Mean? Write a simple program to configure a simple model Configura=on merely a way to specify what you want Examples ACLs: who can talk to who IsolaMon: who can hear my broadcasts RouMng: only specify rou=ng to the degree you care Some flows over satellite, others over landline Virtualisa=on layer compiles these requirements Produces suitable configura=on of actual network devices NOS then transmits these sewngs to physical boxes

36 36 SoGware Defined Network: Take 2 Specifies behavior Compiles to topology Transmits to switches Control Program Abstract Network Model Network Virtualization Global Network View Network OS

37 37 Two Examples Uses Scale-out router: Abstract view is single router Physical network is collec=on of interconnected switches Allows routers to scale out, not up Use standard rou=ng protocols on top Mul=-tenant networks: Each tenant has control over their private network Network virtualisa=on layer compiles all of these individual control requests into a single physical configura=on Hard to do without SDN, easy (in principle) with SDN

38 38 3. Forwarding Abstrac=on Switches have two brains Management CPU (smart but slow) Forwarding ASIC (fast but dumb) OpenFlow: Control switch by inser=ng <header;ac=on> entries Essen=ally gives NOS remote access Need a forwarding abstrac=on for both to forwarding table Instan=ated in OpenvSwitch CPU abstrac=on can be almost anything ASIC abstrac=on is much more subtle: OpenFlow

39 The case: OpenFlow 39

40 40 OpenFlow App App App Controller (Server Software) OpenFlow Protocol Ethernet Switch Control Path OpenFlow Data Path (Hardware)

41 41 OpenFlow Switching Controller Software Layer OpenFlow Client PC Hardware Layer MAC src MAC dst OpenFlow Table IP Src IP Dst TCP sport TCP dport Action * * * * * port 1 port 1 port 2 port 3 port The Stanford Clean Slate Program,

42 42 Step 1: Separate Control from Datapath Research Experiments

43 43 Step 2: Cache flow decisions in datapath If header = x, send to port 4 If header = y, overwrite header with z, send to ports 5,6 If header =?, send to me Flow Table

44 44 OpenFlow Table Entry 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. Switch MAC MAC Eth VLAN IP IP IP TCP TCP Port src dst type ID Src Dst Prot sport dport + mask The Stanford Clean Slate Program,

45 45 OpenFlow 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 Routing Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * * * * * * * * * port6 Firewall Switch Port MAC src MAC dst Eth type VLAN ID IP Src IP Dst IP Prot TCP sport TCP dport Action * * * * * * * * * 22 drop OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center

46 46 OpenFlow Usage Controller OpenFlow Switch Alice s Rule Alice s code PC Decision? OpenFlow Protocol OpenFlow Switch Alice s Rule OpenFlow Switch Alice s Rule OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center

47 47 OpenFlow Usage» Alice s code: Simple learning switch Per Flow switching Network access control/firewall Static VLANs Her own new routing protocol: unicast, multicast, multipath Home network manager Packet processor (in controller) IPvAlice Alice s code Controller PC OpenFlow/SDN tutorial, Srini Seetharaman, Deutsche Telekom, Silicon Valley Innovation Center

48 48 OpenFlow Standardiza=on Version 1.0: Most widely used version Version 1.1: Released in February OpenFlow transferred to ONF in March 2011.

49 49 Restructured Network Feature Feature Network OS Feature Feature Operating System Specialized Packet Forwarding Hardware Feature Operating System Feature Feature Operating System Feature Feature Feature Specialized Packet Forwarding Hardware Specialized Packet Forwarding Hardware Operating System Feature Feature Specialized Packet Forwarding Hardware Operating System Specialized Packet Forwarding Hardware

50 50 SoGware-Defined Network 3. Well-defined open API Feature Feature 2. At least one Network OS probably many. Open- and closed-source Network OS 1. Open interface to packet forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding

51 51 Does SDN Work? Is it scalable? Yes Is it less responsive? No Does it create a single point of failure? No Is it inherently less secure? No Is it incrementally deployable? Yes

52 52 SDN: Clean Separa=on of Concerns Control program: specify behaviour on abstract model Driven by Operator Requirements Net Virtualisation: map abstract model to global view Driven by Specification Abstraction NOS: map global view to physical switches API: driven by Distributed State Abstraction Switch/fabric interface: driven by Forwarding Abstraction

53 53 We Have Achieved Modularity! Modularity enables independent innova=on Gives rise to a thriving ecosystem Innova=on is the true value proposi=on of SDN SDN doesn t allow you to do the impossible It just allows you to do the possible much more easily This is why SDN is the future of networking

54 hyp://

55 55 SUMMARY Characteris=cs of Evolving Networks The OSI Model Modelling & Abstrac=ng the NGN Framework The classifica=on methods for ICT Layered Model for Convergence Domains & Func=onal Layers Planes Regulatory Domains Standards and Standardisa=on

56 Any Ques=ons? Architectures Modelling and AbstracMon 56