Towards management of future internet
Sponsored Links
This presentation is the property of its rightful owner.
1 / 31

Towards Management of Future Internet PowerPoint PPT Presentation


  • 63 Views
  • Uploaded on
  • Presentation posted in: General

Towards Management of Future Internet. Mi-jung Choi, Sungsu Kim DP&NM Lab. Dept. of Computer Science & Engineering POSTECH, Korea Email : [email protected], [email protected] Outline. Why Future Internet? What is Future Internet? Status of Current Internet

Download Presentation

Towards Management 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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Towards Management of Future Internet

Mi-jung Choi, Sungsu Kim

DP&NM Lab.

Dept. of Computer Science & Engineering

POSTECH, Korea

Email : [email protected], [email protected]


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


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


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


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


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


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


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


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


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]


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)


Research Roadmaps of Future Internet

  • Roadmaps of Future Internet in EU, US and JAPAN


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


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


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


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


SOA (1) – FIND’s SILOS

  • Define layer’s functions as services and converge the services to support the network operations


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


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


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


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


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


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


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-*)


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


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


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?


Question and Discussion

Question??


Example GENI Substrate


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


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


  • Login