Towards Management of Future Internet

1. Towards Management of Future Internet Mi-jung Choi, Sungsu Kim DP&NM Lab. Dept. of Computer Science & Engineering POSTECH, Korea Email : mjchoi@postech.ac.kr, kiss@postech.ac.kr

2. Outline • Why Future Internet? • What is Future Internet? • Status of Current Internet • History of Internet Growth • Merits and Demerits of Future Internet • Summary of research effort of Future Internet • FIND, GENI, FIRE, JGN2, etc. • Challenges & Requirements of Future Internet • Architecture of Future Internet • Management Issues of Future Internet • Management Requirements • Management Operations • Concluding Remarks

3. Why Future Internet? • A growing and changing demand • For increasing user control of contents/services • For interconnecting ‘things’-TV/PC/phone/sensor… • For convergence: networks/devices/services (video/audio/data/voice) • Mobility • Security • Current technologies can be, and need to be improved significantly • For scaling up and more flexibility • For better security • For higher performance and more functionality

4. What is Future Internet? (1) • Need to resolve the challenges facing today’s Internet by rethinking the fundamental assumptions and design decisions underlying its current architecture • Two principal ways in which to evolve or change a system • Evolutionary approach (Incremental) • A system is moved from one state to another with incremental patches • Revolutionary approach (Clean-slate) • The system is redesigned from scratch to offer improved abstractions and/or performance, while providing similar functionality based on new core principles • It is time to explore a clean-slate approach • In the past 30 years, the Internet has been very successful using an incremental approach • Reaching a point where people are unwilling or unable to experiment on the current architecture

5. What is Future Internet? (2) • Future Internet? • Clean Slate design of the Internet’s architecture to satisfy the growing demands • Management issues of Future Internet also need to be considered from the stage of design • Research Goal for Future Internet • Performing research for Future Internet and designing new network architectures • Building an experimental facility

6. History of Internet Growth (1) • Stage One: Research and Academic Focus (1980-1991) • Debate about which protocols will be used (TCP/IP) • The National Science Foundation (NSF) took a leading role in research networking • NSFNet1: “supercomputer net” • NSFNet2: a generalized Internet (thousands of Internet nodes on U.S campus) • The Internet Engineering Task Force (IETF) created open standards for the use of the Internet • Request for Comments (RFC) standards documents

7. History of Internet Growth (2) • Stage Two: Early Public Internet (1992-1997) • Federal Networking Council (FNC) made a decision to allow ISP to interconnect with federally supported Internets • The National Center for Supercomputing Applications (NCSA) adopted Tim Berners-Lee’s work on the World Wide Web • Mosaic, Netscape started us down the path to the browser environment today • It was watershed development that shifted the Internet from a command-line, e-mail, and file-transfer kind of user interface to the browser world of full-screen applications • In the fall of 1996, a group of more than thirty University Corporation for Advanced Internet Development (UCAID) • Subsequently become known as Internet2

8. History of Internet Growth (3) • Stage Three: International Public Internet (1998-2005) • The Internet achieved both domestic and international critical mass of growth • Fueled by giant bubble in Internet stocks that peaked in 2000 and then collapsed • Fiber-optic bandwidth Improvements to gigabit-per-second levels, and price-performance improvements in personal computers • The “bubble” years laid the foundation for broadband Internet applications and integration of voice, data, and video services on one network base • In 1996, a group of more than thirty universities formed the University Corporation for Advanced Internet Development (UCAID)-became known as Internet2

9. History of Internet Growth (4) • Stage Four: Challenges for the Future Internet (2006-?) • The Internet has become a maturing, worldwide, universal network • Currently debated policy issues: net neutrality • Two of the few surviving U.S. telcos intended to levy special surcharges on broadband Internet traffic based on the application and on the company • Millions of Internet users • Growth in functionality and value of the net could never happened if there had been discrimination in managing packet flow • If the telco’s well funded campaign succeeds • Then Progress toward universal and affordable broadband access will be further delayed

10. Merits & Demerits of Current Internet • Merits • The original Internet design goal of robustness • Network architecture must not mandate recovery from multiple failures, but provide the service for those users who require it • Openness: low barrier to entry, freedom of expression, and ubiquitous access • Demerits • “Nothing wrong – just not enough right” • Pervasive and diversified nature of network applications require many functionalities • Current network architecture doesn’t support • E.g., TCP variants for high bandwidth delay product networks [1], earlier work on TCP over wireless networks [2], and current effort towards cross-layer optimization [3]

11. Research Institute for Future Internet • US NSF • Future Internet Design (FIND) • Global Environment for Networking Innovations (GENI) • European Commission • Future Internet Research and Experimentation (FIRE) • EIFFEL’s Future Internet Initiative • EuroNGI & EuroFGI • JAPAN • NICT’s NeW Generation Network (NWGN) • Japan Gigabit Network II (JGN2) • KOREA • Future Internet Forum (FIF)

12. Research Roadmaps of Future Internet • Roadmaps of Future Internet in EU, US and JAPAN

13. Challenges of the Internet • Security • Worrisome to everyone (user, application developers, operators) • Mobility • Little support for mobile applications and services • Reliability and Availability • ISPs face the task of providing a service which meets user expectations • Problem analysis • Toolset for debugging the Internet is limited • Scalability • E.g., routing system • Quality of Service • It is unclear how and where to integrate different levels of QoS • Economics • How network and service operators continue to make a profit

14. Requirements of Future Internet • Highly available information delivery • Verifiably secure information delivery • Support for mobility • Interworking flexibility and extensibility • Support for a scalable, unified network • Explicit facilitation of cross-layer interactions • Distribution of data and control

15. Architecture • Keywords • Virtualization • Virtualize network resources and provide customer-specific services • Service-oriented architecture (SOA) • Define layer’s functions as services and converge the services to support the network operations • Register services, discover services in repository and acquire necessary services • Cross-layer design • Divide network layers and support a cross-layer mechanism

16. Aggregate Resource Controller Slice Coordination CM CM CM Virtualization SW Virtualization SW Virtualization SW Substrate HW Substrate HW Substrate HW Virtualization - GENI • Virtualize network resources and provide customer-specific services

17. SOA (1) – FIND’s SILOS • Define layer’s functions as services and converge the services to support the network operations

18. Service Description Discovery Agencies Service Repository 1. Publish 2. Find Service Provider Service Service Requester Client 3. Interact Service Description 3.1 Invoke 3.2 Receive Service Description 3.3 Reply SOA (2) • Register services, discover services in repository and acquire necessary services

19. Application Cross-layerControl Mechanism Overlay Network (IP + α) NW / Post IP NW Underlay Network Photonic NW Mobile NW Sensor NW Cross-Layer Design – JGN2 • Divide network layers and support a cross-layer mechanism

20. Underlay Network Photonic NW, Mobile NW, Sensor NW, etc.  Resource Virtualization Integrated Architecture End Application (Content) F End Application Layer A C D G E B Overlay Network User-based QoS Content-based routing … Application Layer Cross-layer Control Mechanism (Control Agent) Service-Coordination Layer(SOA) TCP + Service + Application Layer Service Repository In-order delivery Error detection Reliable transmission Transport Layer … Flow control Segmentation Layer Functionalities  Service Definition IP + α Header error detection Encapsulation IP Layer Forwarding QoS-guaranteed Routing … Physical + MAC Layer

21. Research in Management (1) • Research Efforts in USA • Two FIND Projects • Towards Complexity-Oblivious Network Management • Current management architecture has two fundamental flaws • The management plane depends on the data plane • The complexity of the ever-evolving data plane disturbs the management plane • Propose an architecture that the management plane is irrelevant to the data plane, and all data-plane protocols expose a generic management interface • Design for Manageability in the Next Generation Internet • Automated management • Intrinsic management support • Real-time change detection • Pervasive data sharing • Network management evaluation test-bed and methodology

22. Research in Management (2) • Research Efforts in Europe • EuroNGI WP.JRA.1.5 Network Management: New trends and Architectures • Location management • Mobility management • Management architecture • Special Joint Specific Research Project (JRA.S.06): Design and Evaluation of Distributed, Self-Organized QoS Monitoring for Autonomous Network Operation (AutoMon) • Specify a distributed, self-organizing and autonomic IP QoS monitoring framework which is based on Distributed Hash Tables • Evaluate the performance of the peer-to-peer mechanisms for maintaining the monitoring overlay • European network on MANagement solutions for the Internet and Complex Services (EMANICS) • Joint Research: Scalable management, Economic management, Autonomic management

23. Management Requirements (1) • Information Model • Need to define high-level, goal-directed specification of network properties & policies • Need to specify the management objects (from HW resources to business goals) and management functionalities • Must be extensible • Communication Model • Basic management operations: get, set, create, add, delete, action, notify • Need to define a unified, generic management interface for all data plane protocols  simple, interoperable, and scalable • Must be interoperable

24. Management Requirements (2) • Functional Model • Basic management functionality: FCAPS • Management functionalities are also defined as services based on SOA • Network nodes such as terminal, intermediate, core need to be programmable • Perform management functions operationally independent of data plane • Support network discovery and selection • Guarantee QoS • Support generalized mobility • Non-functional Requirements • Robustness (primary and backup NMs) = Reliable • Scalability • Flexibility • Interoperability • Autonomic (Automatic & Intelligent & Self-*)

25. Management Operations (1) • Fault Management • Various & numerous network devices  scalable fault management solution • A possible solution: autonomic (self-detection, self-healing, …) • Configuration Management • Automatically configured • Self bootstrapping without pre-configuration • Accounting Management • Authentication, Authorization and Accounting (AAA), charging, and billing • Performance Management • At a lower level: network performance monitoring is required • At an upper level: service quality management is required • Security Management • Ensure the integrity, authenticity, confidentiality of communication with any given peer

26. Management Operations (2) • Mobility Management • Horizontal and vertical handoffs, and roaming • Identity & Addressing Management • Provide seamless ubiquitous support to various services in a larger service provider environment • Terminal Management • Terminal location & trace management • Service Management • Dynamic service registration & fast discovery • Resource Virtualization Management • Common, well published, interoperable interfaces • Easier integration of mgmt interfaces across virtualized resources • Abstraction independent of underlying topology • Cross-domain Control Management • Define cross-domain interfaces • Provide management capabilities based on SOA

27. Concluding Remarks • Future Internet • Clean slate design of Internet architecture considering security, scalability, mobility, robustness, identity, manageability, etc. • Summarize current research efforts for Future Internet • Summarize challenges & requirements of Future Internet • Propose an integrated architecture of Future Internet • Propose management requirements & operations of Future Internet • Investigate possible research topics towards management of Future Internet • In a design phase, we can imagine all possible mechanisms to solve the drawbacks of current Internet • How can we validate our proposed architecture and management issues? • What topic can we focus on?

28. Question and Discussion Question??

29. Example GENI Substrate

30. Abstractions (1) • Three major abstractions that the GMC defines • Components • Slices • Aggregates • Components • A collection of resources • Physical resources (e.g., CPU, memory, disk, bandwidth) • Logical resources (e.g., file descriptors, port numbers) • E.g., Programmable edge node (PEN) (i.e., a conventional compute server), Programmable core node (PCN) (a customizable router, i.e., a backbone router), Programmable access point (PAP) (e.g., for wireless connectivity) • Uniquely identified using GGIDs (GENI global identifiers) • E.g., geni.us.backbone.nyc • Each component is controlled via a component manager (CM), the entity responsible for allocating resources at a component • Sliver • A distinct partition of the component’s resources • Each component must include HW or SW mechanisms that isolate sliver from each other • E.g., virtual server, virtual router, virtual switch, virtual access point

31. Abstractions (2) • Slices • A distributed, named collection of slivers that collectively provides the execution context for an experiment, service, or network architecture • Slices are uniquely identified by GGIDs (GENI global identifiers) • E.g., geni.us.princeton.codeen • Aggregates • A GMC object representing a group of components, where a given component can belong to zero, one, or more aggregates • Example aggregate might correspond to a physical location (components co-located at the same site), a cluster (components that share a physical interconnect), an authority (a group of components managed by a single authority), a network (a group of components that collectively implement a backbone network or a wireless subnet) • Researcher portal • Coordinate resource allocation • Manage set of components