Internet2: A Tutorial Part 3 of 4

Internet2: A TutorialPart 3 of 4

17th Brazilian Symposiumon

Computer Networks

Paul Love, Internet2Chair, I2 Topology WG

[email protected]

Working Groups

25-28 May 99SBRC99 Salvador, Bahia, Brazil

Working Groups

• IPv6

• Measurement

• Multicast

• Network Management

• Network Storage

• Quality of Service

• Routing

• Security

• Topology


IPv6• Chair: Dale Finkelson,

Univ Nebraska, Lincoln• Focus:

• Explore the rôle that IPv6 will play in the Internet2 project• Work with those interested in IPv6 to build IPv6 testbeds

across the Internet2 structure, including vBNS and Abilene• Must be coordinated across backbones, gigaPoPs, and

campuses• Must be interoperable among above and between

vendors


Measurement• Chairs: David Wasley, Univ California and

Matt Zekauskas, Internet2 staff

• Focus:• Places to measure:

• At campuses, at gigaPoPs, within interconnect(s)

• Things to measure:• Traffic utilization• Performance: delay and packet loss• Traffic characterization


Multicast

• Chair: Kevin Almeroth,Univ California at Santa Barbara

• Focus: Make native IP multicast scalable and operationally effective• Must be coordinated across backbones,

gigaPoPs, and campuses• Must be coordinated with unicast routing


Network Management

• Chair: Mark Johnson,North Carolina Networking Initiative

• Focus:• Common trouble ticket system• How can all our interconnects and gigaPoPs

and universities appear to be a seamless whole?


Network Storage

• Chair: Micah Beck, Univ of Tennessee, Knoxville

• Focus: Develop and deploy a reliable, scalable, high performance network storage capability enabling broad access to stored video, very large data sets, etc.


Quality of Service

• Chair: Ben Teitelbaum, Internet2 staff

• Focus: Multi-network IP-based QoS• Relevant to advanced applications• Interoperability: carriers and kit• Architecture• Qbone: distributed testbed


A B

The QoS Big Problems

• Understanding Application Requirements

• Scalability

• Interoperability


Routing

• Chair: Steve Corbato, Univ Washington

• Focus: Internal & External routing• Critical issues

• gigaPoP internal routing design• Explicit routing requirement (the “fish

problem”)• gigaPoP external routing recommendations

• Subscribers (Internet2 campuses) • National interconnects (vBNS,

Abilene, and NGI networks)


Nature of Explicit Routing

• Fish problem• C1 routes via NSP1 and C2 routes via NSP2

C1

C2

GPNSP1

NSP2

D

• One potential solution - MPLS


Security

• Chair: Peter Berger, Carniege Mellon Univ

• Focus: • Authentication • Application to QoS • Application to Digital Libraries


Topology

• Chair: Paul Love, Internet2 staff

• Focus: Topology of Internet2• Internal Internet2 connections

• Between I2 backbones• Internet2 with other Advanced Research

Networks• NGI• International R&E


Working Group Summary

• Internet2’s WGs focused on project’s needs

• Complement IETF WGs

• Membership by invitation of the chair

IPv6

Internet2 & Abilene IPv6 Networking

with thanks toDale Finkelson, Univ of Nebraska,

Lincoln


Project Goals

• Deploying an IPv6 testbed• Both in the vBNS and Abilene

• Understanding what IPv6 can contribute to the research agenda of the Internet 2 project.


Abilene IPv6 Description

• IP over Sonet backbone• This effectively blocks deploying IPv6 in

Native Mode within the backbone until• Code becomes available for Cisco12000• It is stable• It doesn’t block multicast & QoS

• IPv6 will be tunneled through Abilene


Equipment and Protocols

• The initial deployment will be with routers donated by Bay Networks

• Routing will be done with BGP4+

• Some gigapops will implement tunnel servers for local connectivity

• Gigapops with ATM connectivity will be open to native IPv6 connections, others will use tunnels• Details still TBD


Peering arrangements• The IPv6 version of Abilene will peer with

the vBNS at two or more points• MREN (Chicago switch)• NCNE (Pittsburgh gigapop)

• AbileneV6 will peer with other providers at the 6TAP (Chicago switch)• ESnet• CAnet3• European networks

• AbileneV6 will be available at both of the NGIX’s (3rd still TBD)


Schedule

• vBNS network was in place by the end of June 98

• Backbone deployment of IPv6 routers in Abilene in the summer of 1999

• By the end of summer• Initial connectivity to gigapops • Connectivity to other IPv6 networks


Working Group Agenda• Preparing “Good Practices” document

for gigapop operators.• Addressing options• Configuration samples

• Working with the Abilene engineering staff to implement the IPv6 network

• Design an addressing plan for Abilene


Gigapop Issues

• Obtaining Addresses

• Multi-homing Hosts• This is specifically a problem for multihomed

gigapops

• Providing DNS services for IPv6

• Providing either Native IPv6 or tunnels to the backbones

• Providing IPv6 connectivity to their customers


Addressing Questions

• Who gets PTLA’s.• Abilene, vBNS, gigapops?

• How do campus address relate to the TLA’s?

• Can you do multiple addresses within a v6 host?

• For multiply attached gigapops• Do you draw NLA’s from each provider?• Do you do private addressing at the campus

• Some sort of translation at the edge?


Possible Abilene IPv6Backbone & Peering Points

Seattle

Kansas City

Denver

ClevelandNew York

Atlanta

Houston

IndianapolisSacramento

Los Angeles

v6 Peering Point

nb v6 will be in v4 tunnelsinside Abilene

STAR TAP& NGIX

NGIX NGIX


Pointers

• General Information sites• WWW.6ren.net• www.ipv6.org• www.6bone.net

• Site for implementations• All of the above sites have links to sites where

implementation information can be found


Pointers

• IETF Documentation• www.6bone.net has a link to IETF information• draft-iab-nat-implications-04.txt• draft-carpenter-transparency-01.txt

• The Case for IPv6• draft-ietf-iab-case-for-ipv6-04.txt

Network Storage

Internet2 Distributed Storage Infrastructure Update

with thanks toMicah Beck; Univ. of Tennessee,

KnoxvilleBert Dempsey; Univ. of North Carolina,

Chapel Hill

http://dsi.internet2.edu


I2-DSI Participants

• UT Knoxville

• Micah Beck• Terry Moore• Martin Swany• Judi Talley

• UNC Chapel Hill

• Bert Dempsey • Paul Jones (MetaLab)• Debra Weiss • Zhiwei Xiao

• GigaPOP and Campus Site Managers

• UCAID/Internet2• Network Storage

Working Group• Ted Hanss

Applications Director

• NC Networking Initiative• Digital Library Federation


A Word From the Sponsors

• Cisco DNS redirection • Ellemtel engineering effort• IBM large storage & DCE servers• Novell storage & directory servers• Starburst reliable multicast software• StorageTek large storage servers• Sun design collaboration


Single Server Model

• High performance locally

• Unacceptable performance across commodity backbone


Relying on Wide Area QoS

• High performance access with reserved bandwidth

• Essential for real-time communication

• Technically difficult, expensive, not generally available


I2-DSI Model: Replicated Services

• Clients access nearby server

• Everyone gets performance

• Local resources implement a global service


I2-DSI Service Architecture

• Replication • Rsynch+, Omnicast,

AFS/DFS

Novell Replication

• Resolution• Sonar DNS, Distributed

Director

• Delegation• Cache prefetch

generalusers

replicated core

delegated server

local users


Internet Content Channels

• A channel is a collection of content which can be transparently delivered to end user communities at a chosen (price,performance) point through a flexible, policy-based application of resources


Server Channel Examples

• Replicated Web Servers• APIs: Standard HTML, Active Server Pages• Channels: Web sites

• Streaming Media• APIs: MPEG-2, proprietary file formats• Channels: collections of multimedia

presentations• Executable content

• APIs: Java byte code, Tcl, Perl• Channels: CGI programs


Current Server Deployment


IBM Web Cache Manager

RS/6000 AIX Server1 GB RAM72 GB Disk / 900 GB TapeADSM Hierarchical Storage Mgt.


Infrastructure Expansion

• StorageTek• 2 PC/Linux Servers• 700GB disk, tape backup

• Novell• 6 PC/NetWare Servers• 100GB disk• Smaller institutions or departments


I2-DSI Applications Workshop Chapel Hill, NC March 4 &5, 1999

• 4 technologies• Minnesota: Scalable Video • IBM Research: Multicast, Filter and Store• Moscow Ctr. for New Info. Tech. in Med.

Ed.: Semantic Text Analysis• IBM Research: Narwhal Resolution Proxy

• http://dsi.internet2.edu/apps99.html

• Special issue of the Journal of Network and Computer Applications (Academic Press)


Application Strategy

• Chose initial applications• Available or easily ported services• Low update demands

• Port to an I2-DSI server • Our development effort is limited• App developers can have access to the

servers

• Distribute to homogeneous core

• Derive service abstractions


I2-DSI Applications

• Digital libraries• Video• Digitized originals

• Large data sets• Medical imaging• CERN instruments• Satellite images & GIS

• Technical Archives• Netlib/NHSR

Scientific software• Red Hat Linux

Source code• Viagenie

Net. Eng. Documents


Replication Performance and Scalability Issues

• Server placement

• Server resources

• Server description (metadata)

• Server Channel description (metadata)

• Object representation

• Characterization of replication mechanisms

• Channel-to-server mapping (subscription)


NetStore ‘99 Workshop

• Network Storage Technical Workshop• Knoxville, TN, October 1999• http://dsi.internet2.edu/netstore99

• Scope• I2-DSI implementation• I2-DSI applications• Related networking projects• Storage technology


Conclusions

• A server platform is in place

• Infrastructure development• Service abstractions (search, computation)• Publication and replication protocols• Portable representation and API• Heterogeneous servers

• Six months to show results from initial application development efforts

Multicast

Multicast Update

with thanks toKevin Almeroth, Univ of California,

Santa Barbara

http://www.internet2.edu/multicast/


1999: A key year for multicast

• In the past, multicast has meant ‘MBone’• Core set of committed users and engineers• ‘Legacy’ non-scalable approaches to routing

• Our hope for 1999:• Needed, new protocols deployed• Enable scalable use of high-speed multicast

flows throughout the Internet2 structure


Inter-Domain Guidelines

• All backbones will use MBGP/MSDP/PIM-SM• MBGP: exchange multicast routing information.• MSDP: connect SM clouds (source advertising).• PIM-SM: shared tree routing protocol.

• Join/graft: only deliver traffic on links with active sources.

• Backbones actively discussing/deploying multicast peering:• Abilene, vBNS, NREN, DREN, CA*Net2/3,

ESnet, NORDUnet, and SURFnet.


Latest Status

• Abilene tested multicast code: stable code version found.

• NREN has successfully deployed PIM-SM.• MSDP peering with vBNS and MIX at NASA-

Ames.• Recently switched to PIM-SM (for load reasons).

• vBNS has has also had success• Switched to PIM-SM recently.• MSDP peering with NREN, Merit (others soon).• MBGP w/ 8 groups + translation w/ 20 others.


Moving in the Right Direction

• Doing native multicast is the right way to move forward.• We are approaching the problem top down.

• Need to continue this effort into the Gigapops and to member institutions.• Economies-of-scale, in terms of manual

intervention, are significant.

• What does all this mean...

Requirements for Multicast• Raise the bar for Internet2.

• No tunnels: fully deploy native multicast.• Peering must be done with MBGP(& MSDP).

• Institutions who BGP peer should also MBGP peer.• Caveats:

• If no BGP peering (default), then the same for multicast.• If congruent unicast/multicast topology, MBGP translate

service may be available.• Not a complete prohibition of tunnels, but…

• Be careful about protecting low-capacity interfaces.• Don’t create routing loops.


The Challenges

• Where things break:• Multicast in multi-homed environments when…

• Switch-over of unicast to I2 but multicast is still via some other network AND connection is via PIM.

• RPF failures.

• Things are better when:• Multicast is a true I2 service and unicast/multicast

topologies are congruent… or,

• Network uses MBGP.


The Challenges, Part II

• Top two layers are key.• Need vendor support for inter-domain

multicast protocols.• Vendor support is coming.

• Need network operators to be aggressive.• Several have set the standard


Solution: Two Action Items

• Communicate with upstream service provider about how multicast will be delivered.• High confidence in backbones.• Abilene NOC (and WG) is educating Gigapops

(and members) about how to handle multicast.

• Members should be prepared to run MBGP/MSDP.• Pressure vendors to deploy these protocols.

• Many vendors have time tables for releases.• Can deploy/co-locate multicast in parallel to unicast.


Open Issues

• How does the I2 Multicast Working Group assist in deployment of multicast from the backbones all the way to member institutions?• Use the I2 multicast mailing list (subscribe by mailing

[email protected] - place in the body subscribe wg-multicast

• Collect experience and create guidelines.

• Protecting low-capacity multicast environments from high-capacity groups.• Replace dense-mode protocols with sparse mode.• Set administrative boundaries.


ChicagovBNS

Router

CALREN 2WANOC48

vBNSWANOC12

CALREN 2UCBvBNS

Router

ClientPC Host

ClientPC Host

NRENGRC

Router

ClientPC Host

ClientPC Host

ClientPC Host

NRENStanfordRouter

UCSC LANOC12

Stanford LANOC12

ESnet

ATM Switch

GRCNREN

ATM Switch

AbileneBerkleyRouter

ClientPC Host

ClientPC Host

NRENNavajoRouter

100BaseTXHub

UplinkGRC

Router

SBS-5

Navajo NationDownlink

GRCUplink

GRCUplink

ATM Switch

ATMdownlink

Switch

SatelliteModem

SatelliteModem

UCSCRouter

w2w PCServer

SGIServer

NREN/NASFast Ethernet Switches

DS3

DS3 DS3

OC3

ABILENEWANOC12

NGIX

ATM Switch

Sprint / NRENWANOC3 ARC

NRENATM Switch

NRENNAS

Router

Virtual Clinic Network Diagram

With thanks to Mark Foster, NASA Ames


The End