CogMan : Cognitive Network Management Architecture - PhD Thesis Defense -

1. CogMan: Cognitive Network Management Architecture- PhD Thesis Defense - Sungsu Kim kiss@postech.ac.kr Supervisor: Prof. James Won-Ki Hong June 27, 2013 Distributed Processing & Network Management Lab. Dept. of Computer Science and Engineering POSTECH, Korea

2. 01 Introduction Network management approaches Research motivation Problems Research approach 02 Related Work Autonomic control loop Human cognition model Table of Contents 03 CogMan Conceptual representation of CogMan Cognitive Control loop Reasoning for the Reflective Loop 04 Validation SDN overview Failure recovery problems in SDN Experiment results Summary Contributions Future work 05 Concluding Remarks

3. Introduction

4. Network Management Approaches • Autonomic approach • Traditional approach Autonomic Network Management System Decision making Policy repository Administrator Commands for reconfiguration Monitor Analyze Execute Monitoring data: Port up/down state, Number of packet in/out, Network alarms Commands for reconfiguration Monitoring data: Port up/down state, Number of packet in/out, Network alarms Managed network Managed network

5. Research Motivation • Previous studies have discussed various autonomic network management technologies • Existing autonomic network management technologies are heavily dependent on policies to fix problems • Autonomic network management systems are not widely deployed in real networks and most networks are managed by human administrators • In new networking architectures, such as Software Defined Networking (SDN) and OpenFlow networks, network control is centralized, so an autonomic network management approach is appropriate for control and management

6. Problems in Autonomic Network Management • Understanding of current state of the managed network is weak • Autonomic network management systems cannot solve complex problems • Response time of autonomic network management systems is not fast

7. Research Approach Previous Researches • Existing autonomic network management systems cannot handle complex problems • Autonomic network management systems are not deployed in real networks Efficient management of complex problems • An autonomic network management architecture based on the human cognition model • Validation of the architecture in an SDN network Proposed Method

8. Related Work

9. Related Work (1/3) Plan Analyze Execute Monitor Knowledge Sensors Sensors Effectors Effectors Managed Resources • IBM MAPE [IBM, ‘03] Autonomic Manager

10. Related Work (2/3) • FOCALE control loop [Strassner, ‘07]

11. Related Work (3/3) • Human cognition model [Shrobe, 06] Actuation Perception Control Intellectualgoals Perceptualgoal Reflective Recall and attention algorithm Conceptual gist Behavioralplan Deliberative Emotions Motor Goal Actions: PostureLocomotion Sensoryimage Reactive Sensorimotortransformation Body World

12. CogMan: Cognitive Network Management Architecture

13. Conceptual Representation of CogMan Business goals Policy manager User interface Policy Autonomic manager A set of actionsfor reconfiguration Reactive loop Compare state and classify problems Compare Deliberative loop Normalized data Reactive: a single failure, backup path is prepared Reflective loop Backup path Deliberative: a single failure, backup path is prepared, optimal path is required Support Act Information model mapping Observe &Normalize Reasoning Cisco data Juniper data Port down alarm Port down alarm Reflective: multiple failures & backup path is failed Reasoning is required to solve complex problems Vendor-specific commands Vendor-specific data Correlate alarms Managed resource(s) Backup path

14. Cognitive Control Loop (1/2) • Original FOCALE control loop + human cognition model Actuation Perception Control Perception Decision making Actuation Intellectualgoals Perceptualgoal Plan & Decide Reflective Act Compare Recall and attention algorithm Conceptual gist Behavioralplan Deliberative Emotions Motor Goal Observe Actions: PostureLocomotion Sensoryimage Reactive Sensorimotortransformation Managed resource(s) Normalize Body Human cognition model FOCALE World

15. Cognitive Control Loop (2/2) Perception Decision making Actuation Plan & Decide Reasoning Reactive Act Compare Deliberative Reasoning algorithm is necessary Deliberative loop Problems defined by policy Reactive loop Reflective loop Complex problems Problems can be solved fast Reflective Observe Managed resource(s) Normalize

16. Reasoning for the Reflective Loop • Reasoning algorithm is used to solve complex problems • Multiple failures cannot be solved if backup paths are failed • We propose a Fast Flow Setup (FFS) algorithm to recover multiple failures in SDN networks • FFS recovers failures fast even if backup paths are failed • FFS reduces load of an SDN controller

17. Validation: Fault Management in SDN Networks

18. Software Defined Networking (SDN) • SDN: separation of data and control planes Logically-centralized control API to the data plane (e.g., OpenFlow) Controller Switches Routing Traditional networks SDN networks

19. OpenFlow Flow Table Entry Action Stats Matching fields Packet + byte counters • Forward packet to port(s) • Encapsulate and forward to controller • Drop packet • Send to normal processing pipeline • Modify Fields L1 L3 L2 L4 IP Src IP Dst IP Prot TCP sport TCP dport Switch Port Eth type VLAN ID MAC src MAC dst + mask what fields to match

20. Failure Recovery in SDN Networks • Traditional IP networks • Distributed routing protocols reroute packets to alternative paths • Manual reconfiguration • Path protection (MPLS) • SDN networks • Protection • Backup paths • Fast failure recovery time (less than 50ms) • Restoration • Redirect affected flows one by one • Failure recovery time is relatively long

21. Restoration Example 1. Obtain affected flows (host1host2) 2. Find an alternative path for each flow path: <ACED> Controller 3. set up alternative paths Port down message Port down message Working path B D A Host 2 C Backup path E Host 1

22. Protection Example Controller Set working and backup paths 1. Switch A detects port down 2. Send packets to the backup path Working path B D A Host 2 C E Host 1 Backup path

23. Problems in SDN Fault Management • Protection can recover a failure in 50ms • Protection is the best solution for a single failure • Problems of the protection mechanism • Extra packet exchanges are required during flow setup • Protection cannot handle multiple failures that affect both working and backup paths • Practically, providing perfect protection to all links is difficult • Restoration is an appropriate method for multiple failures • Failure recovery time of restoration is longer than 200ms

24. Why Restoration Takes Too Long? The controller calculate the path between host1 and host 2 path= <ABD> • Flow setup example Add flow entries to A, B, and D Controller Ask controller dst: host2 B D A Host 2 C E Host 1

25. Fast Flow Setup (FFS) • Original flow setup requires many packet exchanges • We propose a Fast Flow Setup (FFS) algorithm • FFS implants path information to a flow entry • Reduce the number of packet exchanges for flow setup n=number of switches in a path t= latency between the controller and a switch

26. Example of the FFS Algorithm 1. The controller calculates the path between host1 and host 2 path= <ABD> 2. Implant path <BD> into flow table entry Controller Flow entry Ask controller dst: host2 <DB> dst: host2 D dst: host2 B D A dst: host2 D dst: host2 B Host 2 C E Host 1

27. The Proposed SDN Fault Management

28. System Architecture Port state alarm Observe Port state handler Alarm clustering Normalize Affected flow detector Compare Plan & Decide Routing Path encoder Reasoning Act Flow table modifier Flow_modmessage CogMan processes Functions for actual fault management

29. Prototype Implementation CogMan FOCALE MAPE • Management module • Protection • FFS algorithm • CogMan • FOCALE • MAPE Floodlight Controller Controllercore • OpenFlow network • Topology construction • Fault injection S1 S3 S2 S6 S4 S5 Host 1 … … … Host n

30. Recovery Time (Single Failure) Number of affected flows = 10 Restoration CogMan (protection)

31. Recovery Time (Multiple Failures) CogMan (FFS) vs. FOCALE (restoration) Minimum: recovery time of the first affected flow Maximum: recovery time of the last affected flow

32. Packet Exchange Ratio Number of affected flows = 50 Traffic volume Packet exchange ratio Packet exchanges between the controller and switches

33. Packet Exchanges for Flow Setup Number of packet exchanges Analytic and measured difference Number of packet exchanges required to set up flow (normal vs. protection)

34. Concluding Remarks

35. Summary • Autonomic network management technologies are required to solve complex problems • Autonomic network management architecture based on the cognition model is proposed • FFS is proposed for fast recovery of multiple failures • The algorithm and architecture are validated by conducting experiments in an SDN network

36. Contributions • The problems of network management approaches are described • By applying a human cognition model to FOCALE control loop, we propose CogMan which is able to handle complex problems • A novel failure recovery mechanism, which can be used instead of restoration, is described for fast failure recovery in SDN networks • A complete monitoring, analysis, and recovery cycle of managing fault in SDN networks is described. This thesis shows that the proposed methods recover various failure cases by conducting experiments in our testbed

37. Future Work • Validation of the proposed methods in a large-scale testbed • Combination of protection and FFS for recovery from multiple failures in 50ms • Applying CogMan to other management cases • E.g., Quality of Service (QoS) management of video streaming services • Feasibility test for replacing the current flow setup algorithm

38. 바쁘신 와중에도 시간 내주셔서 감사합니다 Q&A

39. Publications (1/2) • International Journal/Magazine Papers (2) • Sungsu Kim, Joon-Myung Kang, Sin-seokSeo, and James Won-Ki Hong, “ A Cognitive Model based Approach for Autonomic Fault Management in OpenFlow Networks,” International Journal of Network Management (IJNM), (submitted) (SCIE). • Taesang Choi, Tae-Ho Lee, NodirKodirov, Jaegi Lee, Doyeon Kim, Joon-Myung Kang, Sungsu Kim, John Strassner, and James Won-Ki Hong, “HiMang: Highly Manageable Network and Service Architecture for New Generation”, Journal of Communications and Networks, vol. 13, no. 6, pp. 547-551, Dec. 30, 2011. (SCI) • International Conference/Workshop Papers (9) • Sungsu Kim, Sin-seokSeo, Joon-Myung Kang, Guy Pujolle, and James Won-Ki Hong, “Autonomic Resource Allocation for Video Streaming Services in Content Delivery Networks,” Global Information Infrastructure and Networking Symposium (GIIS 2012), Chroni, Venezuela, Dec. 2012. • Sungsu Kim, Sin-seokSeo, Joon-Myung Kang, and James Won-Ki Hong, “ Autonomic Fault Management based on Cognitive Control Loops,” 2012 IEEE/IFIP International Workshop on Management of the Future Internet (ManFI 2012), Maui, Hawaii, USA, April 20, 2012, pp. 1104-1110. • Sungsu Kim, John Strassner, and James Won-Ki Hong, “Semantic Overlay Network for Peer-to-Peer Hybrid Information Search and Retrieval,” 12th IFIP/IEEE International Symposium on Integrated Network Management (IM 2011), Dublin, Ireland, May 23-27, 2011, pp. 430-437. • Arum Kwon, Joon-Myung Kang, Sin-seokSeo, Sung-Su Kim, Jae Yoon Chung, John Strassner, and James Won-Ki Hong, “The Design of a Quality of Experience Model for Providing High Quality Multimedia Services,” Lecture Notes in Computer Science, Vol. 6473, Modelling Autonomic Communication Environments, 5th International Workshop on Modelling Autonomic Communication Environments (MACE 2010), Niagara Falls, Canada, Oct. 28, 2010, pp. 24-36. • Sin-seokSeo, Sung-Su Kim, Nazim Agoulmine, and James Won-Ki Hong, “On Achieving Self-Organization in Mobile WiMAX Network,” the 5th IEEE/IFIP International Workshop on Broadband Convergence Networks (BcN 2010), Osaka, Japan, Apr. 19, 2010, pp. 43-50. • Sung-Su Kim, Young J. Won, John Strassner, and James Won-Ki Hong, “Manageability of the Internet: Management with New Functionality,” the 12th IEEE/IFIP Network Operations and Management Symposium (NOMS 2010), Osaka, Japan, Apr. 19-23, 2010.

40. Publications (2/2) • John Strassner, SungSu Kim, and James Won-Ki Hong, “Using Semantics to Learn About Routing Data for Improved Network Management in the Future Internet,” the 1st IEEE/IFIP International Workshop on Knowledge Management for Future Services and Networks, Osaka, Japan, Apr. 23, 2010. • John Strassner, Sung-Su Kim, James Won-Ki Hong, “Semantic Routing for Improved Network Management in the Future Internet,” Recent Trends in Wireless and Mobile Networks (WiMo), 2010. • Sung-Su Kim, Young J. Won, Mi-Jung Choi, James W. Hong, and John Strassner, “Towards Management of the Future Internet,” IFIP/IEEE Workshop on Management of the Future Internet (conjunction with IM 2009), New York, USA, June 5, 2009, pp. 1-6. • Domestic Journal / Conference Papers (6)

41. Appendix

42. Related Work

43. Knowledge Representation

44. Knowledge Representation • Information model • A representation of concepts and relationships, constraints, rules, and operations to specify data semantics Data Knowledge Information

45. Policy Continuum Business View John gets a gold service Network/System View Unique ID Subscribe SLA Gold Silver Bronze Device View DiffServ, bandwidth configuration Device configuration SRC/DST IP Address

46. Model based Translation Layer Event ev= new Event(); ev. Type ev. Problem DEN-ng Vendor-neutral commands/data MBTL Intermediate Event { Source=IP address; Problem=egp_neighbor_loss} CLI SNMP Cisco Managed Resources Juniper Nortel Trap name: egpNeighborLoss Raw data

47. Control Loop (2/3) • OODA loop [Boyd, ‘95] Observe Orient Decide Act UnfoldingCircumstances Implicit Guidanceand Control Implicit Guidanceand Control OutsideInformation Observations Decision Action Analyses &Synthesis PreviousExperience NewInformation GeneticHeritage CulturalTraditions Act on Hypothesis Act on Decision Act on Unfolding Interaction with the Environment

48. Hierarchical Management Architecture

49. Management Architecture • Client-server based architecture • Centralized management • Poor scalability • P2P based management architecture [14] • Highly distributed and scalable • Load balancing of management tasks • Overhead for exchanging information between management nodes • Hierarchical management architecture [13] • Distributed and scalable • May not appropriate for dynamic environment, such as virtual networks or cloud computing • Require algorithms for structuring management nodes

50. Related Projects • Comparison with related projects