html5-img
1 / 37

Internet2: Which rôle for Europe?

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

paley
Download Presentation

Internet2: Which rôle for Europe?

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. Internet2:Which rôle for Europe? Guy Almes, Internet2 Project <almes@internet2.edu> Dresden, Germany 6 October 1998

  2. Outline • The challenge before us • Technical developments • Measurements • Quality of Service • Others • Infrastructure • Abilene, vBNS, gigaPoPs, and campuses • International • The rôle for Europe

  3. 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?

  4. Applications and engineering Applications Motivate Enables Engineering

  5. 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

  6. 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)

  7. Example: Delay BW  C / delay delay due to distance original raw bandwidth

  8. Example: Delay with fatter pipe BW  C / delay delay due to distance more raw bandwidth

  9. 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

  10. 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

  11. 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

  12. Backbone ‘A’ Backbone ‘B’

  13. Backbone ‘A’ Backbone ‘B’

  14. Backbone ‘A’ Backbone ‘B’

  15. 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

  16. Example One-way delay display

  17. 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

  18. 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

  19. 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

  20. 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)

  21. 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

  22. Measurements Quality of Service Meetings: Geneva: June 1998 Chicago: August 1998 Orlando: December 1998 CCIRN Working Groups

  23. Multicast IPv6 Network Storage Routing Other key technical areas

  24. 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

  25. Abilene Topology: Jan-99 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

  26. Very High Speed Connectivity 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

  27. Abilene Architecture: Core • 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:

  28. Launch: Core Architecture Seattle New York Cleveland Sacramento Indianapolis Denver Kansas City Los Angeles Atlanta Abilene Router Node Houston

  29. Abilene Architecture: Access • 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

  30. Launch: With Access Nodes 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

  31. Schedule • 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

  32. Abilene Network 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

  33. GigaPoPs 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

  34. 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

  35. Needs of applications: Bandwidth Latency Measurements Quality of Service Multicast MOUs CANARIE NORDUnet SURFnet Infrastructure:International

  36. Work with us on technical developments Measurements Quality of Service Others Build European Infrastructure Support advanced applications Test technical ideas Evolve international infrastructure The Rôle for Europe

More Related