Management in SDN/NFV

Transcription

1 Management in SDN/NFV Network Management Spring 2018 Bahador Bakhshi CE & IT Department, Amirkabir University of Technology

2 Outline Introduction What is the SDN? NM in SDN What is the NFV? NM in NFV Summary 2

3 Outline Introduction What is the SDN? NM in SDN What is the NFV? NM in NFV Summary 3

4 Limitation of Existing Architectures Lake of centralized global view Protocols try to approximate an understanding of global network conditions based on local communication Different protocols & mechanisms solve different parts of networking puzzle Complexity Fairly Static Network Contradiction with currently highly dynamic traffic (e.g., VM Migration) Difficult to implement network wide consistent (e.g., security, QoS, ) policies Complexity of scaling up the network in timely manner Vendor dependency due to lake of standard open interfaces 4

5 New Business Requirements 6

6 New Networking Requirements 7

7 SDN Main Idea Collection of network embedded applications used to control the operation of the network The architecture claims: Adaptable agile: adjust network-wide traffic flow to meet changing needs Manageable: logically centralized network state is managed automatically by programs Cost-effective: Open standard based & vendor-neutral HW & SW Through directly programmable control plane 8

8 SDN Concept f ( Map) f ( Map) f ( Map) Control Program Control Program Global Network Map Network OS Control Program Abstract Forwarding Model (e.g. OpenFlow) Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding Packet Forwarding 9

9 NFV Main Idea Abstraction of network functions (as software) from dedicated hardware Traditional Model Dedicated embedded system for each function Long product cycle Virtualizing network functionalities on standard servers 11

10 NFV Concept 12

11 Management of SDN/NFV based Nets. Technical aspects New architectures new components Management improvement Management challenges Business issues: Effect on OpEx and CapEx Cost reduction is an objective of SDN & NFV NM is service providers tool to success business Both have a objective in common 14

12 SDN Promise for Capex Reduction Reduce the purchase cost of hardware Reduced vendor lock-in and use of commodity hardware Reduced cost of software A single controller can steer multiple devices Higher utilization rates of network Effective traffic steering and open the network for other operators via network virtualization 15

13 SDN Promise for Opex Reduction Lower maintenance and repair cost SDN creates a single cohesive structure and better testing possibilities ahead of rollout Lower service provisioning and management cost SDN enables automated configuration of network Lower energy cost There is no more energy consumption by the control plane and better traffic steering 16

14 NFV Promise for Capex Reduction Lower hardware purchase cost Common hardware is cheaper then proprietary specialized hardware Higher utilization of equipment Physical resource sharing among virtualized functions 17

15 NFV Promise for Opex Reduction Lower service provisioning cost Automated service provisioning Lower energy cost Hardware sharing among functions Lower maintenance cost Common hardware is cheaper than dedicated one Lower system/function upgrade No need to hardware upgrade 18

16 Outline Introduction What is the SDN? Big Picture Technical Details NM in SDN What is the NFV? NM in NFV Summary 19

17 Implementation of the SDN idea Remark: programmable control plane Question: How to build programmable control plane? Similar question: how to build a programmable computers? Answer Simple and general purpose hardware Abstraction of HW resources Answer: Variables are abstraction of main memory Operators are abstraction of ALU Simple & general purpose network equipment Abstraction of control plane 20

18 Implementation of the SDN idea Question 1: What should the Simple & general purpose network equipment do? Einstein: as simple as possible, but no simpler As simple as possible Just forward packets But no simpler But not blind!! Flow based Answer: Forwards packets based on rules installed for flows by application Similar to computer: Performs bit operations based on instructions by the programs Question 2: What should be abstracted? 21

19 Control Plane Abstraction Control plane must compute forwarding state. To accomplish its task, the control plane must: Figure out what network looks like (topology) Figure out how to accomplish goal on given topology Tell switches what to do (configure forwarding state) We view this as a natural set of requirements... It is similar to machine-level languages Every program should management every details of hardware (RAM, console IO, ) Solution Abstract operation are compiled to machine level Abstract resources by OS and libraries 22

20 The Control Plane Problem These part of control plane can be abstracted Determining the topology information Configuring forwarding state on switches SDN = Two Control Plane Abstractions Abstraction: global network view Provides information about current network Implementation: Network Operating System Runs on servers in network (replicated for reliability) Abstraction: forwarding model Provides standard way of defining forwarding state An example is the OpenFlow protocol 23

21 SDN Example RFC 2328: 245 pp ~ 2-3 pp ~ 120 pp 24

22 Main Characteristics of SDN The control and data planes are decoupled Control functionality is removed from network devices that will become simple (packet) forwarding elements Forwarding decisions are flow-based, instead of destination-based Allows unifying the behavior of different types of network devices including router, firewall, Control logic is moved to an external entity, the so called SDN controller or Network Operating System (NOS) The network is programmable through software applications running on top of the NOS 25

23 SDN Detailed Architecture 26

24 Outline Introduction What is the SDN? Big Picture Technical Details NM in SDN What is the NFV? NM in NFV Summary 27

25 OpenFlow based SDN OpenFlow Controller OpenFlow Protocol (SSL/TCP) Control Path OpenFlow Data Path (Hardware) 28

26 OpenFlow Protocol OpenFlow is the de-facto protocol for southband interface Between controller and switches Version Date Pages 1.0 Dec Dec Apr Oct Apr

27 Switch Architecture 30

28 Switch Architecture (cont d) 31

29 Switch Architecture (cont d) 32

30 Controller: The NOS!! Do not control the network itself Applications implemented on top of it would perform the actual management tasks Provide a uniform and centralized programmatic interface to the entire network Requirements Present programs with a centralized programming Centralizing Network State Programs be written in terms of high-level abstraction 33

31 Controller General Architecture 34

32 Controller Challenges Generality Wide range of functionalities Reliability Flexibility Scalability Support large # of switches Control plane performance Security 35

33 Controller Deployment Physically centralized Single Thread: NOX, POX, Multi Thread: Beacon, Maestro, Floodlight, Trema, Hierarchical Global controller, with multiple local controllers E.g., Kandoo, Helios, Midonet, Logical xbar Peers Each handling different portions of the topology, flow space, slice, or applications E.g., HyperFlow, Onix, SiBF, ONOS, Elasticon, Replicas Master, with multiple slaves; Multiple active replicas 36

34 Outline Introduction What is the SDN? NM in SDN What is the NFV? NM in NFV Summary 37

35 NM in SDN?! Different points of view about NM SDN SDN is the new kind of NM SDN controller is the NMS SDN has no effect on NM SDN is responsible for the control plane not the management plane SDN improves NM while raising new challenges NM include management of control plane too Role & Responsibility overlap between the NMS and the Controller 38

36 SDN for NM: Current NM Challenges Heterogeneity & Diversity Vendor dependent management Different MIB for different vendors Device type dependent management E.g., Firewall vs L2 switch?! Function type dependency E.g., Fault vs Performance management?! Coarse-grained distributed traffic management Agile & fined-grained flow controller needed in FCAPS 39

37 SDN Benefits for NM Vendor independency By OpenFlow, the standard protocol Device type independency Since all devices are OpenFlow switches Common needs in all NM functions Centralized view of network by the controller Agile traffic management By centralized controller Policy automation by SDN Programming languages (e.g., Frenetic) 40

38 SDN Management Challenges Controller management Fault, Security and Performance of the controller is vital for SDN operation Application management Most control plane and policies are implemented as application which are new in NM context Northbound interface There is not any standard controller dependency Switch management New kind of resources (Flow Table) and Protocol (OpenFlow) need new management requirements 41

39 FCAPS in SDN Pros: Faster service restoration Reactive: flow rerouting by an application Proactive: backup path provisioning per flow Shared & Dedicated paths Realtime switching by Group tables Cons: New kinds of failures Switch, Controller, and application failures South, West, North interfaces failure P. Fonseca, E. Mota, A Survey on Fault Management in Software-Defined Networks, IEEE Communications Surveys & Tutorials Jun. 42

40 FCAPS in SDN Pros: automated provisioning Flow path is determined by applications No need to think in flow-level, high-level programming languages are available Cons: New kinds of configurations How to configure applications, controller and switches OF-Config is proposed for switch configuration C. Trois, MD. Del Fabro, LC. de Bona, M. Martinello M, A survey on SDN programming languages: Toward a taxonomy, IEEE Communications Surveys & Tutorials Apr. 43

41 FCAPS in SDN Pros: Fine-grained flow monitoring & engineering Statistics of the Flow Table and the Meter Table Better Network and SLA monitoring Reactive & Proactive traffic engineering SLA guarantee Cons: New kinds of performance issues The performance of Flow Table lookup The performance of controller and applications IF. Akyildiz, A. Lee, P. Wang, M. Luo, W. Chou, A roadmap for traffic engineering in SDN-OpenFlow networks, Computer Networks Oct 44

42 FCAPS in SDN Pros: Fine-grained flow monitoring & control Centralized view of the network Complex and advanced traffic analysis Fast network-wide reaction E.g. DDoS protection Cons: New kinds of security issues The security of controller The security of interfaces The security of applications S. Scott-Hayward, S. Natarajan, S. Sezer, A survey of security in software defined networks, IEEE Communications Surveys & Tutorials Mar;18(1):

43 SDN Management What are the management interfaces? Which Standard Protocols? 46

44 OF-Config: OpenFlow Configuration OpenFlow determines how packets are forwarded but doesn t provide the configuration and management functions likes IP addresses OF-Config is used to manage physical and virtual switches in an OpenFlow environment OF-CONFIG defines an OpenFlow switch as an abstraction called an OpenFlow Logical Switch Which is contained by OpenFlow Capable Switch 47

45 OF-Config vs NETCONF OF-Config is the NETCONF based configuration for OpenFlow switch The OpenFlow Capable Switches MUST implement NETCONF In fact, OF-Config defines the standard tags (the MIB) to manage OpenFlow specific resources E.g., Ports, Flow Table, 48

46

47 Outline Introduction What is the SDN NM in SDN What is the NFV Big picture Technical view NM in NFV Summary 50

48 What is the NFV? Remark The main idea of Network Function Virtualization A network service is a chain of network functions Routing, Firewall, NAT, Filtering, The functions are hardware appliances in the current architecture Dedicated special purpose hardware In NFV, the functions are software Can be run on any general purpose hardware Virtualization technologies are used to be completely hardware independent 51

49 NFV Big Picture 52

50 NFV Architecture 53

51 1. VNF (Virtualized Network Function) A VNF is the basic block in NFV architecture Software implementation of networking functionalities Not necessarily pure software May use some kind of HW acceleration Examples of VNF include firewalls, IPS, GGSN, SGSN, RNC, EPC etc. 54

52 2. EMS (Element Management System) Responsible for the management of VNF operation In the same way as physical network elements Device-level management May manage the VNFs through proprietary interfaces There may be one EMS per VNF or an EMS can manage multiple VNFs 55

53 4.1 & 4.2 NFVI Physical and Virtual Resources The environment in which VNFs run Physical & virtual resources and virtualization layer Physical Compute, Memory and Networking Resources Virtual resources instantiated on physical resources Virtual Compute, Memory and Networking Resources The virtual resources utilized by VNFs 56

54 4.3 NFVI Virtualization Layer Hypervisor : Abstracting physical resources into virtual resources Decouples software from hardware software to progress independently from hardware 57

55 = MANO MANO: Management and Orchestration Orchestration (6) VNF Manager (3) VIM (Virtualized Infrastructure Manager) (5) MANO is not the only managing entity in the NFV architecture OSS/BSS and EMS are also considered in architecture Standard interfaces defined between MANO and OSS/BSS EMS 58

56 3. VNFM (VNF Manager) Does the life cycle management of VNF instances Setting up, maintaining and tearing down VNFs Instantiate, Feasibility check, Upgrade, monitor, tear down, reporting VNF VNFD describes how to do that A VNF manager can do the same functions as EMS but through open interface The Ve-Vnfm interface 59

57 5. VIM (Virtualized Infrastructure Manager) The management system for NFVI Responsible for controlling and managing the NFVI compute, network and storage resources Responsible for collection of performance measurements and events 60

58 6. NFV Orchestrator Generates, maintains and tears down network services of VNF themselves Enable creation of end to end service over multiple VNFs Responsible for global resource management of NFVI resources Managing the NFVI resources among multiple VIMs Performs its functions by NOT talking directly to VNFs but through VNFM and VIM 61

59 7. OSS/BSS OSS/BSS!!!! ;-) Existing OSS/BSS of an operator may be integrated with the NFV Management and Orchestration using standard interfaces 62

60 Outline Introduction What is the SDN NM in SDN What is the NFV Big picture Technical view NM in NFV Summary 63

61 Relation between NM & NFV The relation is more clear than SDN A new management entity (MANO) in the architecture Responsible for new management functionalities not covered by traditional OSS/BSS NFVI resource management, VNF lifecycle management Explicit relation with OSS/BSS Well defined interfaces for OSS/BSS & EMS Like SDN, improves NM while raising new challenges 64

62 NFV for NM: Current Challenges Complicated service provisioning Heterogeneous devices and protocols need to be configured to provide end-to-end services Time consuming and error-prone due to lake of automation Complicated performance management Resource-constrained equipment per function Dynamic scale-up is not easy Challenges in fault management Hardware failure service/function disruption 65

63 NFV for NM: Benefits Agile service provisioning Automated service function chaining Efficient resource utilization Optimized resource allocation for VNFs SLA guarantee Dynamic virtualized resource allocation Fast failure recovery 66

64 NFV Management Challenges Efficient implementation of MANO components Orchestrator: Optimal service function chaining (SFC) VNF manager: life-time management of huge number of virtual functions VIM: FCAPS for the NFVI MANO vs OSS/BSS Responsibility overlap Supported interfaces New issues complicate security managements 67

65 FCAPS in NFV Pros: Faster service restoration Faster fault detection VIM and NFVM monitor the infrastructure and VNFs Faster fault restoration Cons: Softwarization and virtualization help New kinds of failures Failure of hypervisor or MANO Complicated coordination between OSS & MANO for root-cause analysis 68

66 FCAPS in NFV Pros: automated service provisioning The orchestrator of the MANO is responsible to deploy the chains in the network Cons: Different type of optimization problems have been considered in the literature Coordination between OSS and MANO to achieve fully automated service provisioning Role & Responsibility overlap between OSS and MANO to configure physical infra. + hypervisor + 69

67 FCAPS in NFV Pros Better monitoring VIM and VNFM have dedicated responsibility for monitoring the infrastructure and VNFs On demand scale-up Softwarization and Virtualization help New kind of business and billings Cons: Software performance vs. Hardware Hardware accelerators can help 70

68 FCAPS in SDN Pros: More advanced security services Need more investigation in the future Cons: New kinds of security issues The security of hypervisor The security of MANO 71

69 Outline Introduction What is the SDN NM in SDN What is the NFV NM in NFV Summary 72

70 Summary SDN & NFV complementary solution for the same problem Dedicated locked Equipment per network function Network operators are moving to SDN/NFV Management of SDN/NFV based networks These technologies improves NM There technologies make new challenges in NM Future researches and industry practices needed 73

71 References ON.LAB, ONOS: Open Network Operating System, an open source distributed SDN OS, 2013 Marco Cello, Software Defined Networking, 2014 SDN Course at Princeton University, SDxCentral, Network Virtualization Report, 2014 Edition D. Kreutz, et. al., Software-Defined Networking: A Comprehensive Survey, 2014 M. Boucadair and C. Jacquenet, Software-Defined Networking: A Perspective from within a Service Provider Environment, 2014 E. Haleplidis, et. al., SDN Layers and Architecture Terminology, draft-haleplidissdnrg-layer-terminology-07, August 1, Naudts.pdf 74