1 / 77

Manageability of Future Internet

Explore the essential aspects and frameworks for managing the future of the Internet, including FCAPS methodology, autonomic management requirements, and research efforts in Europe, USA, and Korea.

hleach
Download Presentation

Manageability of Future Internet

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  5. Management of the Current Internet

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

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

  8. Functional Requirements for NM FCAPS • 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

  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. Towards Management of the Future Internet

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

  12. Management for Future Internet • 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

  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

  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

  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. 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. ResearchEfforts - 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. Management for Future Internet [1] • 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

  19. Management for Future Internet [2] • 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

  20. GENI Working Groups related to Mgmt

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

  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

  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

  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

  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

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

  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)

  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.

  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

  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

  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

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

  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

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

  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

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

  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

  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

  39. Project B Project D Project C Project A Cluster 1 Cluster 2 Meta-Operations • 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

  40. GMOC - Architecture

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

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

  43. Spiral 2 • 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. • 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. • GMOC integrates all the data collection tools with the GMOC user interface to provide a unified interface to the diverse backend dataset. • GMOC works with the exemplar project to create and use a unified for operational data sharing. • GMOC works with other projects to determine effective mechanisms for exporting the operational data set.

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

  45. GENI Operational Data View

  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?

  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

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

  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

  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

More Related