1. Choong Seon Hong Kyung Hee University cshong@khu.ac.kr November 23, 2010 Manageability of Future Internet

2. 2 Contents  Introduction to Future Internet and its Manageability  GENI Working Groups related to Mgmt  GMOC  Federation

3. 3 SecurityVirtualizationManageabilityProgrammabilityMobility Requirements for Future Internet Scalability Interoperability Reliability Availability Scalability Interoperability Reliability Availability Seamless handoff/roaming Identity/addressing Integrity, authenticity, confidentiality of communication with any given peer Virtualization of Resources FCAPS Autonomic Management Intelligent and programmable network nodes

4. 4 SecurityVirtualizationManageabilityProgrammabilityMobility Requirements for Future Internet Scalability Interoperability Reliability Availability Scalability Interoperability Reliability Availability Seamless handoff/roaming Identity/addressing Integrity, authenticity, confidentiality of communication with any given peer Virtualization of Resources FCAPS Autonomic Management Intelligent and programmable network nodes Manageability

5. 5

6. 6 Current Network Environment INTERNET Satellite Broadcast Networks (DAB, DVB-T) CDMA, GSM, GPRS IP-based micro-mobility Wireless LANs WiBro, HSDPA Bluetooth Zigbee 6LoWPAN Fast Ethernet B-ISDN ATM SONET PSTN ISDN 10 Gigabit Ethernet Gigabit Ethernet WANs SS#7 IN/AIN PSDN xDSL/Cable Ethernet FTTH

7. 7 Agent Current Network Management Framework Collect, organize & interpret Operational Data Administrator Workstation Management Platform Observation & Control mgmt requests/replies event reports

8. 8 Functional Requirements for NM  Fault Management  detection, isolation and correction of abnormal operations  Configuration Management  identify managed resources and their connectivity, discovery  Accounting Management  keep track of usage for charging  Performance Management  monitor and evaluate the behavior of managed resources  Security Management  allow only authorized access and control FCAPS

9. 9 Standard Management Frameworks  OSI Network Management Framework  CMIP (X.700 Series)  Internet Network Management Framework  SNMPv1  SNMPv2  SNMPv3  TeleManagement Forum  SID, eTOM, NGOSS  Distributed Management Task Force  CIM, WBEM  Open Mobile Alliance  OMA DM

10. 10

11. 11 Manageability for the current Internet has been developed as an afterthought! Do we need a revolutionary approach or an evolutionary approach? FCAPS ? THINK about Manageability of Future Internet

12. 12  Autonomic Management/Self-Management  Self-managing frameworks and architecture  Knowledge engineering, including information modeling and ontology design  Policy analysis and modeling  Semantic analysis and reasoning technologies  Virtualization of resources  Orchestration techniques  Self-managed networks  Context-awareness  Adaptive management Management for Future Internet

13. Research Efforts for Management of FI  US NSF  Future Internet Design (FIND) Complexity Oblivious Network Management architecture (CONMan)  Global Environment for Networking Innovations (GENI) Operations, Management, Integration and Security (OMIS) WG  EU  Framework Program (FP) 7 4WARD In-network (INM) project Autonomic Internet (AutoI) project Autonomic Network Architecture (ANA) project 13

14. CONMan: Overview  Management interface should contain as little protocol-specific information as possible  Complexities of protocols should be masked from management  Goal  A generic abstraction of network entities (protocols & devices) for management purpose  A set of atomic management operations to work upon the abstraction  A way to translate high-level management objectives to low-level operations 14

15. 15 Research Efforts - EU http://www.4ward-project.eu  4WARD WP4: INM (In Network Management)  Autonomic self-management  Abstractions and a framework for a self- organizing management plane  Scheme, strategies, and protocols for collaborative monitoring, self-optimizing, and self-healing

16. 16 Research Efforts - USA  GENI OMIS WG (Operations, Management, Integration and Security)  Operations, management, integration and security processes in GENI  Experiment support, monitoring, and data storage  Security monitoring and incident response  Federation management and monitoring  Hardware release, maintenance and integration  Software release, maintenance and integration  Operations metric collection and analysis  http://www.geni.net/wg/omis-wg.html

17. 17 Research Efforts - Korea  CASFI (Collect, Analyze, and Share for Future Internet)  Goals Manageability of Future Internet Data Sharing Platform for Performance Measurement High-Precision Measurement and Analysis Human Behavior Analysis  Groups KHU, KAIST, POSTECH, CNU  Period 2008.03.01 ~ 2013.02.28  http://casfi.kaist.ac.kr

18. 18  Management Interface  Management Information Modeling & Operations  Instrumentation  Management Architecture  Centralized vs. Decentralized Management  Peer-to-Peer  Hybrid  Service Management  Customer-centric service  Service portability  SLA/QoS Management for Future Internet [1]

19. 19  Traffic Monitoring/Measurement and Analysis  Monitoring for large-scale and high-speed networks  Network/application-level monitoring  Global traffic data access/sharing  Fast and real time monitoring  Statistical sampling method  Storing method for large scale traffic data  Measurement and analysis of social networking Management for Future Internet [2]

20. GENI Working Groups related to Mgmt 20

21. Outline  GENI Working Groups  Control Framework  Experiment Workflow & Services  Instrumentation & Measurements  Operation, Management, Integration & Security (OMIS) GMOC GENI Meta Operation Center 21

22. GENI Working Groups  Control Framework WG  Logically stitching GENI components and user-level services into a coherent system  Design of how resources are described and allocated and how users are identified and authorized  Experiment Workflow and Services WG  Tools and mechanisms a researcher uses to design and perform experiments using GENI  Includes all user interfaces for researchers, as well as data collection and archiving  Instrumentation & Measurements WG  GIMS - GENI Instrumentation and Measurement Service  GENI researchers require extensive and reliable instrumentation and measurement capabilities to gather, analyze, present and archive Measurement Data To conduct useful and repeatable experiments  Operations, Management, Integration and Security (OMIS) WG  Designing, deploying, and overseeing the GENI infrastructure  Operation Framework 22

23. Control Framework  GENI control framework defines:  Interfaces between all entities  Message types including basic protocols and required functions  Message flows necessary to realize key experiment scenarios  GENI control framework includes the entities and the Control Plane for transporting messages between these entities  component control  slice control  access control within GENI  federation  key enablers such as identification, authentication and authorization 23

24. GENI Architecture - Control Framework The Control Framework WG focuses on component control, slice control, access control within GENI and federation and interaction between these GENI entities 24

25. Experiment Workflow & Services  Identify and specify tools and services needed to run experiments on GENI  Planning, scheduling, deploying, running, debugging, analyzing, growing/shrinking experiments  Collaboration Multiple researchers on an experiment Building on other experiments  Identify interfaces/ joint definition/ information-exchange needed across working groups  Provides Services  What resources are available to slices  What level of programmability is possible on different components and their associated resources 25

26. Relationship to GENI Architecture WG focuses on experimenter-users needs for planning, scheduling, running, debugging, analyzing and archiving experiments. 26

27. Instrumentations & Measurements  Discuss, develop and build consensus around the architectural framework for the instrumentation and measurement infrastructure that will be deployed and used in GENI  Create an architecture for measurement that enables GENI goals to be achieved  Facilitate dialog and coordination between teams focused on I&M  Identify key challenges in I&M that could otherwise inhibit the infrastructure  Solicit feedback from users  Deploy basic instrumentation and measurement capabilities  Services  Measurement Orchestration (MO)  Measurement Point (MP)  Measurement Collection (MC)  Measurement Analysis and Presentation (MAP)  Measurement Data Archive (MDA) 27

28. Relationship to GENI Architecture The Instrumentation and Measurement WG focuses on the instrumentation and measurement infrastructure that will be deployed and used in GENI. 28

29. GIMS – Protocols & Communication  Researcher via Experiment Control service (tools), including MO(Measurement Orchestration) service, manages the setup and running of I&M services  Protocols for researcher/experiment control tools to access APIs:  Xml-rpc  web services (SOAP, WSDL)  APIs for setting up and running I&M services  APIs for MP (Measurement Point) services  APIs for MC (Measurement Collection) services  APIs for MAP (Measurement Analysis and Presentation)services  APIs for MDA (Measurement for Data Archiving) service  All traffic is carried in the GENI Control Plane 29

30. GIMS Traffic Flow  Option 1:  Carry all MD (Measurement Data) traffic flows using a dedicated measurement VLAN  Option 2:  Carry all MD traffic flows using the same IP network that supports the Control Plane.  Option 3:  Carry most MD traffic flows using the same IP network that supports the Control Plane, but for high-rate MD traffic flows, define a dedicated measurement VLAN for the slice/experiment 30

31. Detailed Outline for OMIS  Operation, Management, Integration & Security (OMIS)  GMOC GENI Meta Operation Center Why Meta-Operation? Objective Architecture Operational Data Set Topology Operational Status Administrative Status Utilization Measurements Specialized Data Data Acquisition & Sharing Communication & Coordination Operations Use Case Notification Emergency Shutdown Functions 31

32. OMIS  Operation  GMOC (GENI Meta-Operation Center)  Management  Meta-Management System for GENI  Integration  Overlap & Interfaces with other WGs  Security  Policies, Authorization & Authentication 32

33. Overlaps with other WG  Control Framework WG  common interface for operations  Security lower levels of GENI & higher level should be consistent  Experiment Workflow and Services WG  Operation & Management Tools  Services Usage  Instrumentation & Measurements WG  Data Acquisition  Measurements for performance and management 33

34. Relationship to GENI Architecture OMIS WG focuses on GENI operations, management and GENI wide view of the projects and experiments 34

35. Questions  How will network operators exchange the data necessary to allow end-to-end troubleshooting of cross- domain circuits?  How will network operators exchange data to create a end-to-end view (user view or operator view) of cross- domain circuits?  How will network security concerns be taken into account?  It is believed that GMOC activity represents one possible path forwarding addressing to these complex cross-domain issues 35

36. Answer  Collect, Analyze and Share  Meta Operation Center  Federated Network Management Collect Analyze Share Integration Management Security Operations 36

37. GMOC  GENI Meta-Operation Center  Goal: To start to help develop the datasets, tools, formats, & protocols needed to share operational data among GENI constituents  Why “Meta?”  There will be lots of groups operating their own parts  This is no intention to change that  Interested in what kinds of data exchange and functions are useful to share among these groups, at a GENI-wide level  Operations is important  Reliability  Repeatability  User Opt-in 37

38. GMOC: Objective  Give GENI-wide view of operational status of the GENI system  maps & graphs  prototype other views, such as slice-by-slice views GENI-wide and Researcher specific  Need for a common operational dataset  Give Scientists access to their data  “What was going on during these 2 weeks I ran my test?”  Operations  Emergency Shutdown find out-of-control virtual slices and isolate or shut them down  Identify & Shutdown Misbehaving Slices  Protect Other Slices  Ensure Stability 38

39. Meta-Operations Cluster 2 Project D Project C Project A Project B Cluster 1 GMOC is not entirely a Centralized or a Distributed architecture GENI projects can best handle most operational tasks GMOC coordinates operations across projects to present a single interface to operators and users 39

40. GMOC - Architecture 40

41. Conceptual Design GMOC Translator - Translates information from other formats into consistent data format GMOC Repository - Central datastore for operational data from all GENI parts GMOC Exchanger - Polls and/or receives operational data from aggregates 41

42. Spiral 1  Deliverables  Define an Operational Dataset -  Choose a Dataset Format & Protocol  Build Functions 42

43. Spiral 2 1. GMOC contacts exemplar projects and starts a dialogue on what data they are collecting, how that data can be mapped to the operational data set and what issues the specific project has with the operational data set. 2. GMOC starts collecting as much data as possible from the exemplar projects on the format of their choosing importing it into RRD(Round Robin Database) files. 3. GMOC integrates all the data collection tools with the GMOC user interface to provide a unified interface to the diverse backend dataset. 4. GMOC works with the exemplar project to create and use a unified for operational data sharing. 5. GMOC works with other projects to determine effective mechanisms for exporting the operational data set. 43

44. Data Views  How do we look at Operations?  Aggregate view  Component view  Slice view  Sliver view 44

45. GENI Operational Data View 45

46. Operations’ Requirements  It will need to be a collaborative effort  Will be contacting anchors and related projects for input  Each project may share different kinds/amounts of operational data  Initially, concentrating on operational data about components/aggregates and their interconnections,  Additionally, may want to access information about the mapping of aggregates data to slice data  Balance between central visibility and decentralized autonomy will need to evolve (and continue evolving)  Use cases:  slice A needs emergency shutdown; which aggregate(s) need to act?  what slices were affected by the outage on component B?  what was the state of GENI during the life of my experiment on slice C? 46

47. GMOC: The Plan Set of things needed for GENI operations?  Step 1: what kinds of data is needed (need to get)?  Operational Data & Data formats  Step 2: how should that data be shared?  Data Acquisition & Sharing  Coordination (Communication)  Step 3: what should be done with the data once gets it?  Visualization  Monitoring  Operations Emergency Shutdown Function Event Notification 47

48. Step 1: Operational Data Potential Types of Operationally Significant Data 1. System-wide View (topology) 2. Operational Status 3. Administrative Status 4. Utilization Data (Measures) 5. Specialized Data 48

49. Data: Topology [1/2]  What exists at a given time on GENI, from an operational viewpoint  System Component/Aggregate perspective  Slice perspective  Requires data about topology of aggregates/components, and the mapping of slice to component.  Data might come from experiment tools, clearinghouses, or aggregate managers  Aggregates, Components, Resources, Interfaces, Circuits/links, Slivers & their relationship  Relationships are described by graphs 49

50. Data: Topology[2/2]  Topology Description  Network Description Language (NDL)  perfSONAR topology schema  GEANT2’s Common Network Information Service (cNIS)  OpenGring Forum’s NML (Network Markup Language)  Ontology based Topology Description  Shows the Topology and the relationships  Combination of RRDTool and SQL database RRDTool stores data about utilization, SQL database about GENI topology 50

51. Data: Operational Status  The operational status of a given component, sliver, aggregate, or slice, at a given time  Potential States Up Down Impaired  May include additional specific information  i.e. how is it impaired, or why is it down  Examples  Component Operational Status  Interconnection for operational status – linking  Sliver operational status (e.g. virtual machine running, Ethernet VLAN active, etc.) 51

52. Data: Administrative Status  The expected state of a given component, sliver, aggregate, or slice  Potential States Up Down Impaired  Used in conjunction with operational status to understand overall status  Any discrepancy means a misbehaving slice 52

53. Data: Utilization Measures  Time series measures of a resource in use by a GENI component, aggregate, slice etc.  Usefull for visualization of GENI-wide view  Link Utilization of resources  CPU utilization (component level)  Condition Measures  Critical to emergency shutdown  Determination to correct behavior  Analogous to Service level agreement (SLA)  Utilization Data - Data about the data flowing on GENI components, slices, backbones, etc  Some things might be fairly common  Link utilization  CPU utilization  Memory utilization 53

54. Data: Specialized Data  Data specific to the type of component  latency/jitter  signal strength  error counts (network links)  Data specific to a situation  Wireless propagation, virtual memory usage, page faults, etc  Disk cache performance  Not useful for GENI unified Interface, but to a user or researcher  There should be a way for aggregates/components to create their own types of this data 54

55. Data Format -ERD 55

56. Step 2: Data Acquisition & Sharing  GENI is made up of many loosely affiliated projects  Many projects have existing means to provide operations  Data Sharing is difficult as diverse data formats and tools are used  Possible Data Acquisition & Sharing tools ( & formats)  RRDTool & SQL Database  PerfSONAR  SNAPP (GRNOC SNMP Collector) 56

57. Communication  There are two possible ways for coordination between the Projects and GMOC  Interfaces (API) Define consistent messages to push or pull data  Reports sharing Projects submit performance or/and network description and utilization reports to the GMOC  A protocol for communication is needed to be standardized 57

58. Federation in GMOC  Proposal # 1  Local MOC for each project  Communicate with GMOC at GENI level Communication by Interfaces (APIs) or Protocol  Proposal # 2  Shareable Operational data with in a Federation ‘namespace’  Network Description & Measures Reports Reports needed to be consistent Use an adapter (translator) Standard reporting style (SNMP-based, RRDTool, PerfSONAR etc.)  E.g. ngeni.... = “BGP Router 1” 58

59. GMOC Translator Repository Exchanger xGENI MOC Monitoring Visualization Control/ Emergency Stop Operations nGENI Monitoring MOC Visualization Control/ Emergency Stop Operations Federated GMOC: P1  Proposal # 1  Local Meta-Operation Center for each project  Communication with GMOC Interfaces (APIs) 59

60. GMOC Translator Repository Exchanger Federated GMOC: P2  Proposal # 2  GMOC directly communicate with the Operational portal  Operational data with in Federation ‘namespace’  Shareable Data Using a translator Standard reporting SNMP-based, RRD, PerfSONAR etc.)  E.g. (at bottom) xGENI Monitoring Visualization Operational Portal Control/ Emergency Stop ngeni.... = “BGP Router 1” nGENI Monitoring Visualization Operational Portal Control/ Emergency Stop 60

61. Step 3: GMOC - Operations  Operations required by GMOC  Experiment support, monitoring, and data storage  Security monitoring and incident response (including incidents unrelated to security)  Federation management and monitoring  Hardware release, maintenance and integration  Software release, maintenance and integration  Operations metric collection and analysis  Event Notification  Emergency Shutdown 61

62. Control Framework: Event Notification 62

63. Notification & Data Sharing  Operational Data gathering done by each project locally by the NOC  Received from the aggregates, components, sliver etc  Private data: abstracted from the global view  Public data: directly visible for GENI wide view  Local NOC (event producer) creates an ‘Event Repository’  Events that can occur with in the resources  Event Repository is registered at the Clearinghouse along with the resources  Operator and Admin register the events that needed to be ‘consumed’ (received)  When an event occurs (Condition Measures inconsistency) the notification is made to the concerned parties (Admin, Component Manager, User, Researcher etc.) 63

64. Federation  Why federating?  Through federation it may:  Achieve better scaling capabilities  Access different resource types (E.G. Wireless, sensors)  Contribute to a richer environment offering to the user  Facilitate (new) standards definition, E.G. Resource description, protocols, monitoring  Federation should not make access more complex to the user, neither exclude unforeseen uses of the facilities 64

65. Federation Vision  Share user credentials and resource descriptions  Agree on slice management API and allocation policy  Allow experiments to run across facilities 65

66. Federation: Mechanism  Integrated  The facilities can be used as one infrastructure with a inter-domain common control plane  Partially integrated  Only part of the control is exchanged, e.g. schedule, AAA information  Overlay  Each facility just uses the services/resources of the other without a common control plane, just a data plane, there is an exchange of information related to monitoring, faults, and so on  In any case a common data plane and one or more information exchange protocols between them must exist.  What is the minimum common set for Federation  User Interface and related information exposed to the user 66

67. Federation: Requirements  Given that a Federation is based on two main characteristics:  It creates (virtual) resources and the relations between them only when they are needed  It must carefully map the virtual resources to the substrate to ensure the best reproducibility to researchers  The first step for project (like GENI) is to federate in the overlay model  It requires:  An agreed (standard) resource description set  A common AAI, data plane and information exchange protocol at the substrate level offering a slice, imposes less configuration complexities to other facilities. 67

68. GENI Federation 68 Federation with Non-GENI Infrastructures Federation among GENI Infrastructures Federation with Resources (Aggregates)

69. GENI Federation 69

70. Federation: Within GENI 70

71. Federation: GENI & non-GENI 71

72. Aggregate Federation 72

73. Federation between GENI Suite and Non-GENI Suite  Problems  Identity and authority management Manage identity and authority based on different local policy Use different mechanism for authentication and authorization  Control procedures Incompatibility between control procedures  Resource and experimentation description Use different scheme for resource and experimentation description  The following requirements should be considered in order to resolve the observed problems.  Common interfaces or adapters for different control framework  Common interfaces or adapter for authority service  Unified profile for certificate and authority management  Common resource and experimentation description language  Common data access interface 73

74. Problems for GENI Federation  Classification of federation problems  Different identity/authority management Identity allocation/authorization policy/mechanism Ex) GID, ABAC (SFA 2.0)  Different control procedures Control flows and interfaces/APIs Ex) GENI AM/CM/Slice APIs  Different resources and experiments description Resource description schemes (syntax, context, entity, …) Description of experiments, services, experimental results Ex) RSpec  Global standards/adapters 74 * ABAC(Attributed-Based Access Control)

75. Key Issues  Reproducibility of experiments, in particular the amount of variation of average values  Monitoring and combination of data  Virtualization use  How to combine physical resources and virtual resources in a seamless environment  Signaling between the (many) control planes and ensure the separation between the user control plane and the facility control plane, which is fundamental in case of failures  Standards for resource and topology description  Check pointing and error recovery/restart  AAI, scheduling and naming 75

76. Reference  http://gmoc.grnoc.iu.edu/gmoc/index.html http://gmoc.grnoc.iu.edu/gmoc/index.html 76

77. 77 Question and Discussion