Recomendados
Mais conteúdo relacionado
Semelhante a Stefan Wallin Ph D Presentation : Rethinking Network Management
Semelhante a Stefan Wallin Ph D Presentation : Rethinking Network Management (20)
Último
Último (20)
Stefan Wallin Ph D Presentation : Rethinking Network Management
- 1. The Thesis
- 2. What is Network Management ? Alarms Service Status Control workflow Trouble-shoot Configure Service with trouble-tickets Configure Device 2
- 3. What is Network Management ? Problems? Alarm Monitoring Service Management - Monitor - Configure 3
- 4. Main Thesis Use domain-specific languages to specify alarm and service models Explicit knowledge Text-based representation Use data-mining and self-learning to capture “hard-to-model” things Tacit knowledge 4
- 5. Research Structure Service Models Alarm Models Configuration Changes Service Type Status Calculation Causality Alarm Type Service Type Component Alarm Type Device Type Constraints Constraints 5
- 6. Problems and Contributions Alarm Models Defined a Domain-Specific Alarm Type Language BASS for specifying Causality alarm models Alarm Type Model Quality Constraints Automatic Correlation Data-Mining and Self-Learning to assign alarm severity levels Service Models Domain-Specific Languages for Configuration Changes Service Service Management Status Calculation Type Service Defined SALmon for monitoring Type Component Test of IETF YANG for Service Configuration Device Type Constraints 6
- 7. Attacking the Problems Challenges Solutions Computer Science Service Providers Validations Solutions specialists from Equipment Vendors me • LTU • Data Ductus • Tail-f • YALTS Journals Conferences 7
- 8. Publication Overview Journals Conferences/Workshops IEEE IT Professional IFIP ManWeek Springer Journal of Network and IEEE IM Systems Management IEEE NOMS John Wiley & Sons International Journal of Usenix LISA Network Management IEEE AINA TeNAS Inderscience International Journal of IEEE SOSE Business Intelligence and Data-Mining Springer Telecommunications Systems 8
- 9. Contents Problems? – Input from Service Providers The Alarm Problem The Service Management Problem Alarm Solutions Service Management Solutions BASS Monitoring with SALmon Alarm prioritization Configuring with IETF YANG Conclusions and Future Work Acknowledgements 9
- 11. Coming Changes 20 Operators 11
- 14. Alarm Chain ? Managed System Management System Estimated Resource Alarm Estimated Alarms Resource States Notifications Alarms States Alarm Type Resource Severity Raise / Clear Text 14
- 15. The Alarm Problem Most network elements […] does not have the notion of an alarm state. Devices emit event notifications whenever an implementor thought this is a good idea [around] 40% percent of the alarms are considered to be redundant as many alarms appear at the same time for one ’fault’. Many alarms are also repeated [...]. One alarm had for example appeared 65000 times in today’s browser. Correlation is hardly used even if it supported by the systems, [current correlation level is] 1-2 % maybe. 15
- 16. The Alarm Problem Too many ? > 1 / Sec Which ones are relevant? Several alarms for the same fault Wrong severity levels Interpreting meaning and impact 16
- 17. Interpreting an Alarm *A0628/546 /08-07-01/10 H 38/ N=0407/TYP=ICT/CAT=SI /EVENT=DAL/NCEN=AMS1 /AM=SMTA7/AGEO=S1-TR03-B06-A085-R000 /TEXAL=IND RECEPTION/COMPL.INF: /AF=URMA7/ICTQ7 AGCA=S1-TR03-B06-A085-R117/DAT=08-07-01/HRS=10-38-14 /AMET=07-020-01 /AFLR=175-011/PLS/CRC=NACT /NSAE=186/NSGE=186/NIND=14/INDI=956/NSDT=0 17
- 18. Confusing Alarm Severity Original Severity Priority set by from Device Operator 18
- 19. Hard-to Manage Severity Distribution Hollifield, B., Habibi, E.: The Alarm Management Handbook 19
- 20. Alarm Type Distribution 90% …3500 26 20
- 21. Alarm Monitoring Domain-Specific Models Modeling Alarms – Enable Automation and Increase Quality 21
- 22. Research Structure Service Models Service Type Alarm Models Configuration Changes Status Calculation Alarm Type Causality Service Type Component Alarm Type Device Type Constraints Constraints 22
- 23. Alarms Today ? We have: Alarm interface standards Envelope, the parameters Alarm documentation Informal documents for humans What we do not have: Formal alarm definitions that can be used for automation The contents of the envelope “Alarm Model” 23
- 24. Alarm Model BASS Alarm Types Predicates Constraints - Information - Semantic 24
- 25. BASS 25
- 26. Bass Prototype and Validation .alarm Correlated Alarm Doc Alarm DB from Feedback Correlation BASS Rules Alarms from Real Vendor Real Operator Uncorrelated Documentation Graphs Information Constraints Semantic Constraints 26
- 27. Semantic Constraints 173 warnings in approved and released alarm interface 27
- 28. Information Constraints to Automate Correlation Automatic identification of root-cause candidates 28
- 29. Alarm Monitoring Data-Mining and Self-Learning Assigning Correct Severity Levels by Learning from Experts 29
- 30. Research Structure Service Models Service Type Alarm Models Configuration Changes Status Calculation Alarm Type Causality Service Type Component Alarm Type Device Type Constraints Constraints 30
- 31. Learning Alarm Priorities Databases From Real Service Provider Suggest Neural Network Priority Alarm Trouble Ticket Alarm Prio System System Training Priority 31
- 32. Result Distribution of Errors Neural Original network severity • Neural network correct in 53 % Percentage of Alarms • Original severity correct in 11 % Magnitude of Error 32 Too high Too low
- 34. Service Management ”Services are not currently managed well in any suite of applications and require a tremendous amount of work to maintain” ”Service models are becoming more and more important” ”Focus on service management - bringing this up to 40% from [the] current level of 5-10%” ”Managing services must be the focus of the future development, while pushing network management into a supporting role” 34
- 35. Complex Structures “Service Models” Configuration Class Name Attribute Attribute Operation Operation Software Class Name Implementation Attribute Attribute Operation Operation Monitoring Interpretations and Tedious Mappings 35
- 37. Research Structure Service Models Service Type Alarm Models Configuration Changes Status Calculation Alarm Type Causality Service Type Component Alarm Type Device Type Constraints Constraints 37
- 38. My Two Tracks for Service Management Configuration Changes Service Type Status Calculation IETF YANG SALmon Service Type Component Device Type 1 Model the Services 2 Express the transformations 38
- 39. Simplifed Structures Configuration Models Models Monitoring Remove room for interpretations and automate mappings 39
- 40. SALmon Example Broadband Forum TR-126 Triple Play QoE Requirements 40
- 41. SALmon Test • The TR-126 model could be executed SLA and Service • Compact complete model monitor UI • Easy to change in one place 41
- 42. My Two Tracks for Service Management Configuration Changes Service Type IETF YANG Status Calculation SALmon Service Type Component Released Device Type 2010 1 Model the Services 2 Express the transformations 42
- 43. Service Configuration and Activation IETF Defined YANG as data-modeling language for managing devices “Replacing SNMP MIBs” Thesis: YANG can be used to model services, not only devices Service Configuration as a YANG – YANG transform Work: Service Modeling projects at service providers Service Activation product, Tail-f NCS 43
- 44. SALmon and YANG SALmon IETF YANG Comment Model Object Oriented Tree Tree structures more Structure suited for rendering Purpose Operational Data Configuration Data and Operational Data Time-Series Calculations Functional - - YANG to YANG mapping in Java for imperative configuration - XPATH possible to express aggregation Constraints - XPATH 44
- 46. Conclusions For Research Closer cooperation with equipment and service providers Network management is in need of computer science For Network Equipment Providers Provide models (in a form) that can be used for automation Interface quality For Service Providers Overcome current practice of incomplete illustrations and free-form documents Model the offered services Knowledge management 46
- 47. Future Work Alarm Models SALmon features represented in YANG Alarm Type Language extensions or as models Causality Time-series Alarm Type Functional calculations Constraints XPATH Database representation Service Models Imperative activation as part of Configuration Changes Service Status Calculation the model ? Type Service More knowledge management by using Type Component data-mining and self-learning Device Type Constraints 47
- 48. Errata Paper C : Says trivial approach is correct in 17 % of the cases Should be 11 % Section 2 : Wrong “T”, should be: 48
- 49. Thank You ! Klacke Wikström Jörgen Öfjell Håkan Millroth Johan Ehnmark Martin Björklund Christer Åhlund Andreas Jonsson Seb Strollo Johan Nordlander Ulrik Forsgren Johan Bevemyr Viktor Leijon Magnus Karlsson Joakim Grebenö Robert Brännström Leif Landén Chris Williams Karl Andersson Daniel Granlund Dan Johansson Nicklas Bystedt Mikael Börjesson EU Funded Equipment Vendors and Sidath Handurukande Service Providers Magneto Project Test Data 49
- 50. 50