1. Towards Management of Future Internet
Our topic of project is Management of future internet
Our team members are Mi-jung Choi, research professor, and Sungsu Kim, Phd student
Mi-jung Choi, Sungsu Kim
DP&NM Lab.
Dept. of Computer Science & Engineering
POSTECH, Korea

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
There will be problem with scalability. For example Devices will outnumber humans by several orders of magnitude,
Mobile IP is not effective, overhead
Security: how to embed it, how to cope with heterogeneous networks

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)
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 ( )
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
In 1985, the NSF began funding the creation of five new supercomputer centers: the John von Neumann Center at Princeton University, the San Diego Supercomputer Center on the campus of the University of California at San Diego, the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign, the Cornell Theory Center at Cornell University and the Pittsburgh Supercomputing Center

7. History of Internet Growth (2)
Stage Two: Early Public Internet ( )
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, , 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 ( )
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
Recently freed from regulation of broadband facilities by a Supreme court decision, assert that their large investments in fiber-optic broadband facilities give them the right to recover these investments in any manner they see fit

10. Merits & Demerits of Current Internet
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)
Euro-NGI : December 1, November 30, 2006 Euro-FGI : December 1, May 31, 2008
EuroNGI's main target : To create and maintain the most prominent European centre of excellence in Next Generation Internet design and engineering, leading towards a leadership in this domain.
Research Goal for Future Internet
Performing research for Future Internet and designing new network architectures
Building an experimental facility

12. Research Roadmaps of Future Internet
Roadmaps of Future Internet in EU, US and JAPAN
Euro-NGI : December 1, November 30, 2006 Euro-FGI : December 1, May 31, 2008

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. Virtualization - GENI Aggregate
Virtualize network resources and provide customer-specific services
Resource Controller
Aggregate
Slice Coordination CM
Virtualization SW
Substrate HW

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

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

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

20. 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
Reliable transmission
In-order delivery
Error detection …
Transport Layer
Flow control
Segmentation
Layer Functionalities 
Service Definition
IP + α
Header
error detection
Encapsulation
IP Layer
Forwarding
QoS-guaranteed
Routing …
Underlay Network
Photonic NW, Mobile NW, Sensor NW, etc.  Resource Virtualization
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
Euro-NGI : December 1, November 30, 2006 Euro-FGI : December 1, May 31, 2008
(AutoMon starts from 2005.)
EMANICS addresses the scalability, dynamics, security and automation challenges that emerge towards the management plane of the future Internet and complex services running on top of it.
Work package 7, 8, 9
EMANICS WP Meeting Days Tuesday, 11 April 2006 (15-17 March 2006, Zurich, Switzerland) Event Web Site (restricted to members)   EMANICS Kickoff Meeting Tuesday, 11 April 2006 (26-27 January 2006, Munich, Germany) The EMANICS project kickoff meeting was hosted by the University of Federal Armed Forces in Munich. Event Web Site (restricted to members)

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-*)
advertise the management capabilities

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

29. Example GENI Substrate

30. Abstractions (1) Three major abstractions that the GMC defines Sliver
Components
Slices
Aggregates
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 Aggregates
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