Internet2 which r le for europe
Download
1 / 37

Internet2: Which rôle for Europe? - PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on

Internet2: Which rôle for Europe?. Guy Almes, Internet2 Project <[email protected]> Dresden, Germany 6 October 1998. Outline. The challenge before us Technical developments Measurements Quality of Service Others Infrastructure Abilene, vBNS, gigaPoPs, and campuses International

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Internet2: Which rôle for Europe?' - halla-moss


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
Internet2 which r le for europe

Internet2:Which rôle for Europe?

Guy Almes, Internet2 Project

<[email protected]>

Dresden, Germany

6 October 1998


Outline
Outline

  • The challenge before us

  • Technical developments

    • Measurements

    • Quality of Service

    • Others

  • Infrastructure

    • Abilene, vBNS, gigaPoPs, and campuses

    • International

  • The rôle for Europe


The challenge before us
The challenge before us

  • Universities, by their nature,

    • mix teaching and research

    • collaborate with scholars at other universities

  • Thus, advanced applications for

    • conferencing

    • remote instrument access

    • digital libraries

  • What networks will these need?


Applications and engineering
Applications and engineering

Applications

Motivate

Enables

Engineering


Large delay bandwidth products
Large Delay-Bandwidth Products

  • As the delay-bandwidth product grows:

    • The number of unacknowledged packets grows

    • It becomes more difficult to sustain a steady stream of data from end to end

  • Several consequences:

    • Need for direct physical paths

    • Tradeoff between buffering and variation in delay


A pessimistic result from mathis et al
A pessimistic result from Mathis et al.

  • Mathis, Semke, Mahdavi, and Ott, "The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", Computer Communication Review, July 1997.

  • www.psc.edu/networking/papers/model_abstract.html

  • BW  C * packet-size / (delay *  packet-loss)


Example delay
Example: Delay

BW  C / delay

delay due to distance

original raw bandwidth


Example delay with fatter pipe
Example: Delay with fatter pipe

BW  C / delay

delay due to distance

more raw bandwidth


Technical developments measurements
Technical developments:Measurements

  • Motivation:

    • Need for understanding

    • Infrastructure at the cutting edge

    • Notoriously hard-to-please users

  • Relation to other challenges

    • Very wide area

    • Very high speed

    • Bursty applications


Three kinds of measurement
Three kinds of measurement

  • Traffic utilization

    • e.g., MRTG

  • IETF IPPM measures, including

    • one-way delay

    • packet loss

  • Passive observation of user flows

    • OC3MON .. OC12MON

    • RTFM


Loci of measurement

At university boundaries

Between key ‘clouds’

Within clouds also, but this can vary

At end-systems also, in support of application developers

Examples from the Internet2 infrastructure...

Loci of measurement


Backbone ‘A’

Backbone ‘B’


Backbone ‘A’

Backbone ‘B’


Backbone ‘A’

Backbone ‘B’


One example ippm measurements in abilene
One example:IPPM measurements in Abilene

Surveyor implementation of IPPM will be placed at each router node

This will permit understanding of one-way delay to within about 50 µsec

This will also support similar measurements for gigaPoPs and universities



Oc3mon a family of passive measurement tools

Developed for the NSF/MCI vBNS effort

Examines packet headers of user traffic

Examples:

nature of flows

distribution of sizes of packets

pattern of sources and destinations

all of above on a per-application basis

Work remains to be done here

OC3MON: a family of passive measurement tools


Technical developments quality of service

Motivation:

some advanced applications are intolerant of loss, variation if delay, and inconsistent bandwidth

generous provisioning is not always possible

Relation to other challenges:

diversity of infrastructure

high-speed, wide-area, bursty flows

Technical developments:Quality of Service


Consensus within internet2 qos working group

IETF diff-serv a key to scaling

Focus initially on “non-relative” services

Premium the initial specific focus

Other services later

Begin immediate testbed trials

Take an iterative approach

Consensus within Internet2 QoS Working Group


Diff serv architecture
diff-serv Architecture

Bandwidth Brokers

(perform admissions control, manage network resources,

configure leaf and edge devices)

Destination

Source

BB

BB

Core

routers

Core

routers

Ingress Edge Router (classify, police, mark aggregates)

Egress

Edge Router(shape aggregates)

Leaf Router (police, mark flows)


Initiation of the qbone effort

Goals:

Grow the set of interoperable diffserv clouds

Grow a community of participants

Foster pre-standards interoperability

Collaborate to solve problems

Participant Types

Networks

Network engineering

Applications and middleware developers

Corporate partners

Initiation of the QBone effort


Ccirn working groups

Measurements

Quality of Service

Meetings:

Geneva: June 1998

Chicago: August 1998

Orlando: December 1998

CCIRN Working Groups


Other key technical areas

Multicast

IPv6

Network Storage

Routing

Other key technical areas


Infrastructure abilene

Addresses growing needs of Internet2 for performance and functionality

Improves breadth of access

Tests notion of multiple ‘backbones’ within Internet2

Technical diversity:

Abilene: IP/Sonet

vBNS: IP/ATM

Infrastructure:Abilene


Abilene topology jan 99
Abilene Topology: Jan-99 functionality

Seattle

Eugene

Minneapolis

Westfield

Boston

New York

New Haven

Cleveland

Newark

Detroit

Trenton

Salt Lake City

Philadelphia

Wilmington

Pittsburgh

Lincoln

Columbus

Sacramento

Indianapolis

Washington

Oakland

Denver

Kansas City

Raleigh

Albuquerque

Oklahoma City

Nashville

Los Angeles

Atlanta

Anaheim

Phoenix

Dallas

Abilene

New Orleans

Router Node

Access Node

Directly Connected Participant

Houston

Miami

28 Total Access Nodes

17 Directly Connected Participants


Abilene engineering and goals

Very High Speed Connectivity functionality

Among Internet2 gigaPoPs, including vBNS

Other federal ‘NGI’ networks

Non-US advanced networks

Qualities Stressed:

Reliability

Low latency

Effective NOC and Engineering teamwork

Abilene Engineering and Goals


Abilene architecture core
Abilene Architecture: Core functionality

  • Router Nodes located at Qwest PoPs

    • Cisco 12008 GSR

    • ICS Unix PC: IPPM and Network Mgmt

    • Cisco 3640 Remote Access for NOC

    • 100BaseT LAN and ‘console port’ access

    • Remote 48v DC Power Controllers

  • Initially, ten Router Nodes:


Launch: Core Architecture functionality

Seattle

New York

Cleveland

Sacramento

Indianapolis

Denver

Kansas City

Los Angeles

Atlanta

Abilene

Router Node

Houston


Abilene architecture access
Abilene Architecture: Access functionality

  • Access Nodes

    • Located at Qwest PoPs

    • Sonet: Connects Local to Long-distance

  • Initially, about 120 Access Nodes:

    • This list grows as the Qwest Sonet plant grows


Launch: With Access Nodes functionality

Seattle

Boston

Eugene

Minneapolis

Westfield

New York

New Haven

Cleveland

Newark

Detroit

Trenton

Salt Lake City

Chicago

Philadelphia

Wilmington

Pittsburgh

Lincoln

Columbus

Sacramento

Indianapolis

Washington

Oakland

Denver

Kansas City

Raleigh

Albuquerque

Oklahoma City

Nashville

Los Angeles

Atlanta

Anaheim

Phoenix

Dallas

Abilene

New Orleans

Router Node

Access Node

Houston

Miami


Schedule
Schedule functionality

  • Design work: Mar-98 and ongoing

  • Rack design/built: May-98 to Aug-98

  • Demo network installed: Sep-98

  • Remainder installed: Oct-98

  • Beta Period: 1-Nov-98

  • Production begins: 1-Jan-99


Abilene Network functionality

Abilene Demo Network: September 1998

Seattle

Eugene

Minneapolis

Westfield

Boston

New York

New Haven

Cleveland

Newark

Detroit

Trenton

Salt Lake City

Philadelphia

Wilmington

Pittsburgh

Lincoln

Columbus

Sacramento

Indianapolis

Washington

Oakland

Denver

Kansas City

Raleigh

Albuquerque

Oklahoma City

Nashville

Los Angeles

Atlanta

Anaheim

Phoenix

Dallas

Abilene

New Orleans

Router Node

Access Node

Star Tap

Houston

Miami


Infrastructure other us developments

GigaPoPs functionality

CalREN2: northern and southern California

Great Plains Network

Pacific Northwest GigaPoP

vBNS: continuing improvement

planned OC-48 work

multicast leadership

federal agency networks

ESnet, NREN, etc.

Infrastructure:Other US Developments


Evolution of the ngix idea

Exchange points appropriate for NGI / Internet2 and related networks

Initially:

NASA Ames, Chicago (StarTap), and DC

Result of the JET: Joint Engineering Team

Evolution of the NGIX idea


Infrastructure international

Needs of applications: networks

Bandwidth

Latency

Measurements

Quality of Service

Multicast

MOUs

CANARIE

NORDUnet

SURFnet

Infrastructure:International


The r le for europe

Work with us on technical developments networks

Measurements

Quality of Service

Others

Build European Infrastructure

Support advanced applications

Test technical ideas

Evolve international infrastructure

The Rôle for Europe


ad