| |||||||||
|
The University of Michigan and Merit Internet2 Qbone Testbed Proposal
Contact information
The Center for Information Technology Integration (CITI), The University of Michigan
William A. (Andy) Adamson
1.734.764.9465
andros@umich.edu
519 W. William
Ann Arbor, Michigan 48103Merit Network
Susan Hares
1.734.936.2095
skh@merit.edu
4251 Plymouth Rd
Ann Arbor, Michigan 48103
Participant Type
Network
- campus - ATM - bring a map
- Michnet backbone
- Merit Gigapop
- Connect to the vBNS via the MREN Gigapop
Engineering/Advance technology
- Engineering support and expertise
- Measurement and Analysis
- We will supply application engineers from the University
of Michigan.Merit and the University of Michigan will supply network expertise
in routing, multicast routing, Internet routing and performance measurement.Professor
Kang Shin of the University of Michigan EECS department will aid in evaluating
QoS performance.
- Measurement of the QoS performance will be best done
at the application layer.The SDVC will provide end-to-end measurements
at the application layer.Trouble shooting measurements at each router will
be difficult. Another avenue is to use passive monitors of the ATM fabric
such as OC3MON. Merit will contribute expertise from the IPMA project.
Application and Middleware
- Application development
- GUI interfaces to middleware components
- Middleware development
- Multicast Group Protocol Security Key Exchange (LSGC development)
- RAPI implementation of I2 QoS API
- End-toEnd application performance evaluation
- packet loss
- bandwidth
- latency
- jitter
CITI is contributing development and use of its Secure Distributed Video Conferencing (SDVC) application demonstrated at the September Interne2 Members meeting. CITI will add RSVP functionality called through the proposed Internet2 QoS Working Groups QoS API. In the light of the experience gained at the September Internet2 Members meeting, CITI will modify portions of LSGC to enhance reliability and performance. CITI will instrument SDVC for measurement of end-to-end performance, and will work closely with Merit on all aspects of the project.
The University of Michigan is contributing the use of the experimental ATM Internet II network on the campus of the University of Michigan. This experimental ATM network will be used to evaluate the performance of the SDVC application in a campus infrastructure with unlimited ATM infrastructure. The secure video will be evaluated over the ATM infrastructure. The premium service within this infrastructure will by Cisco routers.
Merit is contributing the usage of the Michnet connection to the vBNS. Michnet, a statewide network connects Michnet to the vBNS via the MREN gigapop. Merit is also a gigapop in Michigan. Merit will provide engineering expertise in the area of multicast routing and the area Internet measurement and performance.
Experiment
Merit, CITI and the University of Michigan have allocated funding for phase 1 of this project, and will pursue funding for phase 2.
Phase 1 Goals - Measure and analyze the QoS performance of the SDVC application running over "premium service across the University of Michigan Campus experimental ATM Internet2 network and across the vBNS.
During the first six months of the Qbone experiment, we will
- Create a Secure Video (SDVC) application to run over the Qbone
- Instrument the SDVC application to provide End-to-End performance evaluation for QOS in terms of latency, jitter, bandwidth, and delay. (Month 1 and 2)
- Improve the performance of the LSGC key exchange mechanism and group join protocol. Experiment with running the GateD on the workstation to allow the workstation to participate directly in the multicast routing infrastructure. (Month 1 and 2)
CITI will add RSVP to the implementation of I2 QoS API in SDVC. The ability to add RSVP will allow this existing application to request premium service from a router. (Month 1)
Experiment with the QoS capable SDVC application over controlled environment of a campus ATM Internet2 network. (Months 2 through 4)
- "tpd" developed by the IPMA project to also check end-to-end paths through the network. "tpd" is an updated version of the "NPD" probe developed by Dr.Vern Paxson.
- QoS tools (created by Prof. Khan Shin and students)
- Pkt tool developed by ISI which can generate packet load
- Deploy up to 10 sites on the vBNS (Months 3-6)
- Measure end-to-end performance of SDVC application over premium service with minimal best-effort traffic on the vBNS (Months 3-6)
- Measure end-to-end performance of SDVC application over premium service with a large amount of best-effort traffic on the vBNS. (Months 3-6)
Using the Merit/University of Michigan/Michigan State connection to the vBNS, we will connect the application to the vBNS. The application will connect to a Cisco 7505, which will run a diff-serv capable routing code and multicast routing.
We will connect to up to 10 sites across the vBNS. During the I2 application experimentation, this application connected to several sites across the vBNS. These sites included Yale, Wisconsin, Ohio State and Penn State. To participate in these past demonstrations, each site received the SDVC software from the CITI group and set-up multicast connections to the vBNS.
We expect that many of these same sites would update to the new SDVC software which is QoS capable. Each of these sites would need to work with their network providers to provide premium paths to the network. We will need other sites to collaborate with us in connecting across the vBNS.
The initial end-to-end SDVC measurement experiments will measure application to application latency, jitter, bandwidth, and packet loss. These initial vBNS based experiments should be done with minimal best effort traffic. Each site deploying the SDVC application would run the SDVC's performance instrumentation package. The end-to-end results can be correlated with the minimal traffic results in step 4 of this experiment. The end-to-end performance results from the vBNS infrastructure will be compared with the end-to-end results of the University of Michigan campus ATM infrastructure.
Please note that the funding of phase 2 is not guaranteed at this time. We are pursuing obtaining funding for phase 2.
During the second phase of the Qbone experiment, the CITI/University of Michigan/Merit collaborative would refine the prototype implementation of the SDVC application to use the latest differential-services implementations. During phase 2, the SDVC application would be refined to:
- expand the premium service request via RSVP to include interactions with a bandwidth broker including user authorization,
- further improve the application's use of multicast communications, and
- add additional end-to-end performance QoS measurements to the application.
The diff-serv working group in the IETF is still refining the actual specification of the differential services model. We expect these premium service functions to be reflected in software changes to the Cisco routers. We will deploy the new diff-serv software in the Cisco routers in the Internet II ATM backbone at the University of Michigan and in the Merit Connection to the vBNS.
Michnet is currently awaiting additional bandwidth from the infrastructure carriers between Michigan State and the University of Michigan. This additional bandwidth scheduled to be delivered during the second 6 months. If the carriers actually deliver the bandwidth, Merit will expand the experiments to include sites at the University of Michigan as well as Michigan State University.
Merit is working on designing prototype bandwidth brokers
based on the diameter protocol. A bandwidth broker may require network
topology information and Authentication Authorization and Accounting (AAA)
services to allocate the QoS resources. The network topology information
required by the bandwidth broker must be both dynamic (via routing updates)
and static capacity numbers (total bandwidth per links). Bandwidth Brokers
must negotiate within a routing domain (network or campus) and between
domains. The bandwidth broker requirements are being discussed as part
of the IETF aaa-bof. Susan Hares (Merit) is co-chair of this requirements
BOF. As the requirements for AAA in the IETF specification solidifies,
Merit will complete the design of the bandwidth broker and begin implementation.
Work on this area is tentative due to
Application and Middleware
General Characterization
The SDVC project was developed at CITI in partnership with UCAID. A first step toward fully virtual meetings, SDVC experiments with the middleware components necessary to meet Internet2 application requirements. SDVC integrates multicast MPEG1 video and audio with a scaleable inter realm key exchange protocol (Globus) and secure multiparty group communication (LSGC) to provide authenticated, encrypted data streams to members of the multicast group. SDVC employs separate video and audio multicast data streams, each with its own QoS requirements.
Raw Bandwidth Requirements
SDVC currently transmits telephone quality (8 kHz, 8 bit) sound at 64Kbits per second. We are developing CD quality (44.1kHz, 16bit) stereo sound, which requires 1.5Mbits per second.
Video bandwidth depends on the quality setting of the capture device as well as the visual complexity of the video stream. At 30 frames per second, the MPEG1 stream generated by SDVC varies from 1.5Mbits per second at a low quality setting to 7Mbits per second for the highest quality setting.
QoS Requirements
Because the human ear is so sensitive to sound, audio delivered over the Internet requires extremely low packet loss. The human eye is much more forgiving and isn’t bothered by a few missed video frames.
Latency tolerance depends on the use to which SDVC is put. When performing a single source broadcast of a lecture, a fairly high latency is acceptable. When back channels are added, as for a videoconference, latency greater than a half-second becomes intolerable. When SDVC is used as a component of remote instrument control, or as a distributed music event tool, latency in the 20 to 50 ms range is required.
Development Platforms
The SDVC video MPEG1 source uses an Sbus SunVideo card, and runs on Solaris 2.5.1. SDVC receivers require no external hardware and currently run on Solaris 2.5.1, Solaris 2.6, Aix41, and OpenBSD. An NT port of the SDVC receiver is approaching completion.
Relevant Protocols and Codecs
Initial User Community
SDVC established a vBNS Internet2 member user community through the call for participation, testing, and eventual audio and video broadcast of the September Internet2 Meeting over the vBNS. During the testing phase, SDVC successfully delivered encrypted audio and video data to receivers at Internet2 Member locations. These schools and others have indicated an interest in further participation in SDVC work.
End-toEnd application performance evaluation
SDVC will be instrumented to log the necessary information to be able to calculate packet loss and bandwidth use. Latency measurements require a common clock available at the source and receiver. The most accurate method to date is to use GPS clocks. Guy Almes of Internet2 has installed such a device at Merit and other sites. Another possibility is to use xntp to synchronize source and receiver clocks, but this is not as accurate as the GPS clock solution. SDVC will be instrumented to log latency timings, which then can be used to calculate jitter.
Equipment Used
We will utilize 3 test labs prior to the University of Michigan backbone.
Merit's lab (ATM switch, Ethernet, 40 PC/workstations,
6 Cisco routers)
ITDCom’s lab
Citi's lab
Notes on Cisco configuration
Cisco implements differential services by combining the
Committed Access Rate (CAR) – a packet classifier and token bucket, class
based/priority/custom queuing, and WRED.
Cisco implements differential services by implementing AF by combining:
- Queuing and CAR
- Using IP Precedence as a DS codepoint look-alike.
Network Topology
Committed Resources
- University of Michigan Campus ATM Infrastructure
- IP infrastructure with diff-serv
- Michnet Connection in vBNS in Phase 1
- Remote Site Connection in vBNS Michnet long term solution
CITI
Personal
½ FTE for 6 months
New Equipment
One Sun Spark 20 workstation, One Sun Ultra-5 workstation.
Use of existing infrastructure
CITI test lab, ITD ATM cloud, and The University of Michigan’s
connection to the VBNS.
Funds
None
Merit
Personal
1/2 FTE for 6 months
New Equipment
Use of Existing Infrastructure
Merit Test GateD TestBed
(see appendix 1 for drawing)
Funds
None
Potential Availability of Further Resources
The University of Michigan has committed substantial resources towards the construction of an ATM backbone to deliver an Internet2 service to the local campus, and towards negotiating high-speed external Internet2 connections via the vBNS and Abilene. It is recognized that the University community will consume these resources and that some policy needs to be in place to regulate resource usage.
Merit has committed resources to deploy the external Internet2 connections to the vBNS and Internet2. In addition, Merit has committed engineering resources to guide the Internet2 activity by participation in the Internet2 Routing Working group and the QoS working group. Merit is investigating the development of administrative tools such as the bandwidth broker, route servers and a routing registry for Internet2.
Unresolved Issues
CITI/University of Michigan/Merit proposed to build the software and expertise needed to deploy the Secure Distributed Video Conferencing (SDVC) application over the Qbone. We will provide this technology up to 10 sites on the Qbone. This proposal requires that other sites be solicited to run the Qbone application in months 3 through 6 of phase 1. We anticipate active participation by past members, but did not solicit commitments to this work at this time.
Accurate measurement of end-to-end latency depends on the existence of a GPS clock at both the source and receiver.
 |
|
 |
