1 / 35

Internet2 and JGN2: possible areas for collaboration

Explore potential collaborations in network architectures and services development, including new hybrid infrastructure, performance measurement, and authentication systems. Learn about Internet2's Abilene Network history and upcoming projects.

stefanyj
Download Presentation

Internet2 and JGN2: possible areas for collaboration

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 and JGN2: possible areas for collaboration Heather Boyles heather@internet2.edu

  2. Some possible areas for collaboration • New network architectures/services • Hybrid network architecture and services: shared IP and dedicated circuits • Internet2 HOPI project and testbed • Performance Measurement and Monitoring Infrastructure • Interconnect our respective PM&M infrastructures • Architecture interoperability • Authentication and Authorization Infrastructure • Interconnecting national AAIs (e.g. US Internet2 InCommon Federation)

  3. Abilene Network – second generation

  4. Abilene timeline • Apr 1998 Network announced • Cisco Systems, Indiana Univ., Nortel Networks, and Qwest Communications initial partnership led by Internet2 • 2.5-Gbps national backbone (OC-48c SONET) • Jan 1999 Network went into production • Second generation network upgrade • Oct 2001 Qwest MoU (DWDM+SONET) extension (5 years) • Apr 2002 Routers from Juniper Networks added • Dec 2003 10-Gbps upgrade complete • Oct 2004 Transport agreement extended by one year • Oct 2007 Transport MoU with Qwest ends • The time frame for both next generation architecture finalization & decision on transport partner(s) is ~15 months from now early spring 2006.

  5. Abilene scaleSeptember 2004 • IPv4/v6-over-DWDM (OC-192c) backbone • 44 direct connections (OC-3c  10 GigE) • 2 (soon 3) 10-GigE connections (10 Gbps) • 6 OC-48c connections (2.5 Gbps) • 2 Gigabit Ethernet connections (1 Gbps) • 23 connections at OC-12c (622 Mbps) or higher • 230+ participants – research universities & labs • All 50 states, District of Columbia & Puerto Rico • Expanded access • 113 sponsored participants • 34 state education networks

  6. Abilene’s distinguishing features • Native advanced services – multicast & IPv6 • Ability to support large individual flows • Regular, routine testing: hourly 980+ Mbps TCP flows • Supporting multiple Internet2 Land Speed Records • Latest multi-stream TCP flow: 6.6 Gbps • Home for community’s advanced Internet initiatives • Middleware, for example • Cost recovery model • Pricing scales roughly logarithmically with bandwidth • Aim to is to encourage utilization and experimentation • Open measurement stance

  7. Applications End-to-end Performance Security Motivate Enable Middleware Services Networks Internet2 Today and Tomorrow

  8. Selection of activities/projects • Network Infrastructure • Abilene, Fiberco, Hybrid Optical Packet Infrastructure (HOPI), National Lambda Rail (NLR) support • Network Services • Abilene Observatory, IPv6, Multicast, Performance Measurement and Monitoring (end-to-end performance initiative) • International • Global coordination with NRENs around the world • Middleware • Authentication/Authorization tools (Shibboleth), Trust federation (InCommon) • Security • Security at Line Speed (SALSa) • Applications Collaboration environments (Internet2 Commons), Outreach to user communities (science & engineering; arts & humanities; health sciences)

  9. Collaborating on New Network Architectures and Services Development and Infrastructure Deployment

  10. HOPI Project - Summary • In the near future we will see a richer set of capabilities available to network designers and end users • Core IP packet switched networks • A set of optically switched waves available for dynamic provisioning • Fundamental Question: How will the core Internet architecture evolve? • Examine a hybrid of shared IP packet switching and dynamically provisioned optical lambdas • HOPI Project – Hybrid Optical and Packet Infrastructure • Have created a whitepaper – see http://hopi.internet2.edu • Immediate Goals • Implement testbed over the next year • Coordinate and experiment with other similar projects • Design Team, Corporate Advisory Team

  11. HOPI General Problem

  12. HOPI General Problem • How would one create a hybrid from these two infrastructures. The Nodes do switching and the links are point-to-point circuit like paths. Each link may have attributes – for example, bandwidth. Attributes may determine the ability to concatenate links. Examples include • Nodes are lambda switches with waves forming circuits – attributes include colors and bandwidth, etc. • Nodes are SONET switches with paths being SONET links – attributes include channels, etc. For example, OC-3, OC-12, etc. • Nodes are Ethernet switches with paths being point-to-point VLANS – attributes include bandwidth, etc. • HOPI will use this environment to examine different architectures • Nodes are routers on a packet infrastructure and the point-to-point paths are MPLS L2VPNs

  13. HOPI Questions • Examine how to build an architecture • A lot is known about how to do various pieces • The main question is how would one put it all together into a network • Problems to understand • When does a host use the circuit switched infrastructure and when does it use the packet infrastructure? • Temporal degree of dynamic provisioning • Temporal duration of dynamic paths and requirement for scheduling • Topological extent of deterministic provisioning • Examine backbone, RON, campus hierarchy – how will a RON interface with the core network? • Understand connectivity to other infrastructures – for example, international or federal networks? • Network operations, management, measurement, and control plane across administrative domains?

  14. HOPI Resources • The Abilene Network – MPLS tunnels and the packet switched network • The Internet2 Wave on the NLR footprint • MAN LAN Exchange Facility • TYCO/IEEAF 10 Gbps lambda NYC – Amsterdam • Cisco layer 2 and layer 1 switching gear • Significant addition of Nortel optical equipment to enhance layer 1 facilties • Collaborations with Regional Optical Networks (RONs) and other related efforts (GLIF, DRAGON, etc.)

  15. Abilene/NLR Map

  16. HOPI Basic Service • Given the available resources, we cannot use multiple waves to study new architectures – have only a single wave • Instead we’ll model waves using lower bandwidth “deterministic” paths – paths that resemble circuits – “lightpaths” • Basic service – A 1 or 10 GigE unidirectional point-to-point path with reasonable jitter, latency, and loss characteristics • Access – Direct to HOPI node or an MPLS L2VPN tunnel through Abilene

  17. HOPI Node • A fiber cross-connect switch (a white light switch) • Ability to switch the entire NLR wave to Abilene, to a RON, or to pass through the wave • An Ethernet switch device to partition the wave into 1 GigE paths when necessary • Control devices • Ad hoc control plane computer • Measurement computer • Experimental computer • Control and data planes must be disjoint • Out of band access

  18. Connector Interface • A 1 or 10 GigE connection to the FXC, either dark fiber or a provisioned service, including NLR • An MPLS L2VPN service through Abilene to the Ethernet switch or TDM device • Provides immediate connection to the Internet2 NLR wave from Abilene

  19. HOPI Deployment • Node locations • Los Angeles Equinix Facility – Support for CalTech and the HENP • The Pacific Northwest GigaPoP in Seattle • StarLight in Chicago • New York City – NYSERNet area in 32 AoA (Same location as MAN LAN, same building as Abilene Node) • Many thanks to NYSERNet for donating rack space and power to support the HOPI project • Washington, DC – Support for the Dragon Project • Hope to install in Seattle, Chicago and LA by end of calendar year. • New York and Washington, DC very early in January

  20. Collaborating on Performance Measurement & Monitoring Architecture and Infrastructure Deployment

  21. Internet2 E2E piPEs • Project: End-to-End Performance Initiative Performance Environment System (E2E piPEs) • Approach: Collaborative project combining the best work of many organizations, including DANTE/GEANT, Daresbury, EGEE, GGF NMWG, NLANR/DAST, UCL, Georgia Tech, etc. • NSF-sponsored workshop: http://e2epi.internet2.edu/WK03/index.html

  22. piPEs • Enable end-users & network operators to: • determine E2E performance capabilities • locate E2E problems • contact the right person to get an E2E problem resolved. • Enable remote initiation of partial path performance tests • Make partial path performance data publicly available • Interoperable with other performance measurement frameworks

  23. Measurement Infrastructure Components

  24. Project Phases • Phase 1: Tool Beacons • BWCTL (Complete), http://e2epi.internet2.edu/bwctl • OWAMP (Complete), http://e2epi.internet2.edu/owamp • NDT (Complete), http://e2epi.internet2.edu/ndt • Phase 2: Measurement Domain Support • General Measurement Infrastructure (Prototype) • Abilene Measurement Infrastructure Deployment (Complete), http://abilene.internet2.edu/observatory • Phase 3: Federation Support • AA (Prototype – optional AES key, policy file, limits file) • Discovery (Measurement Nodes, Databases) (Prototype – nearest NDT server, web page) • Test Request/Response Schema Support (Prototype – GGF NMWG Schema)

  25. piPEs Deployment

  26. American / European Collaboration Goals • Awareness of ongoing Measurement Framework Efforts / Sharing of Ideas (Good / Not Sufficient) • Interoperable Measurement Frameworks (Minimum) • Common means of data extraction • Partial path analysis possible along transatlantic paths • Open Source Shared Development (Possibility, In Whole or In Part) • End-to-end partial path analysis for transatlantic research communities • VLBI: Haystack, Mass.  Onsala, Sweden • HENP: Caltech, Calif. CERN, Switzerland

  27. Authentication and Authorization Infrastructure Development and Deployment

  28. Getting to a national AAI for inter-institutional collaboration • Internet2 Middleware Initiative launched 1999 • Focus on enterprise/campus • Focus on core middleware (that supports upperware e.g. grid middleware) • Focus on inter-institutional authentication and authorization; supporting collaboration, access to digital resources, virtual organizations • eduPerson attributes • Shibboleth authentication transport software • National Trust Federation (InCommon) initially built on institutions using Shibboleth

  29. Shibboleth Status • http://shibboleth.internet2.edu/ • Open source, privacy preserving federating software • Being very widely deployed in US and international universities • SWITCH (Switzerland has adopted) • JISC (UK) is adopting; funding development of complementary pieces • Growing development activities in several countries, providing resource manager tools, digital rights management, listprocs, etc.

  30. InCommon federation • Federation operations – Internet2 • Federating software – Shibboleth 1.1 and above • Federation data schema - eduPerson200210 or later and eduOrg200210 or later • Became operational April 5, with several early entrants to help shape the policy issues. • Precursor federation, InQueue, has been in operation for about six months and will feed into InCommon • http://incommon.internet2.edu

  31. International federation peering • Shibboleth-based federations being established in the UK, Netherlands, Finland, Switzerland, Australia, Spain, and others • International peering meeting held October 14-15 in Upper Slaughter, England • Issues include agreeing on policy framework, comparing policies, correlating app usage to trust level, aligning privacy needs, working with multinational service providers, scaling the WAYF function

  32. Why interconnect AAIs? • Support international collaborations between institutions • Researcher at Stanford working on a project with a Researcher at Keio University – utilizing a scientific instrument connected to the network at Stanford • Researcher at Keio authenticates to Keio U. system • Virtual organization (the researchers’ collaboration) authorizes locally authenticated users to access instrument

  33. The global league of AAIs • Expect we’ll utilize authentication and authorization services to: • Allow users to request, set-up ‘lightpath’ type services across our networks • Allow users and network managers to access performance measurement & monitoring data across PM&M infrastructure domains • Securely share security incident information between research network operators • Allow users to authenticate when making a video-conference call • Etc.

  34. AAI in Japan • Who sets up university campus-wide authentication systems? • Is there any coordination at national level in Japan toward national AAI to support inter-institutional collaboration? • If so, who is coordinating? • If not, how can we help get this going?

  35. What are JGN2 interests? • Are there other areas where Internet2 and JGN2 should be collaborating?

More Related