skip the i-GuideIllinois State UniversityAdmissions at ISUAcademics at ISUEvents at ISUMap of ISUISU A to Z ListingISU AccessibilityISU 150th Anniversary
Telecommunications and Networking

ISUnet Services

Computer Support Professionals

Bandwidth Management

Proxy and Caching
Quality of Service
IP Multicast

Proxy and Caching

In an effort to reduce bandwidth competition on Internet circuits and improve performance for those clients requesting services remotely, caching and proxy servers are used on ISUnet. At this time, the University is experimenting web caching products. This service is not yet in production.

Back to top

Quality of Service

In an effort to protect electronic services that support the mission of the University, Internet applications have been categorized into three groups on ISUnet - 1) mission critical, 2) unsupported, and 3) blocked. Only those applications that are defined as mission critical are supported by Telecommunications and Networking. This practice allows the University to deliver quality support to those services that are fundamental to our users. 

Definitions:

Mission Critical Applications
A mission critical application is defined as an application that supports the needs and services of the University. This includes but is not limited to such applications as email clients (ex: Eudora), web browsers (ex: NetScape and Internet Explorer), terminal emulation (ex: telnet and tn3270), file transfer (ex: FTP), and so on. Telecommunications and Networking will work with the University Helpdesk to help resolve network connectivity problems surrounding these types of applications.

Unsupported Applications
An unsupported application is defined as an application that is not blocked from Internet access but is also unsupported by Telecommunications and Networking. This includes but is not limited to such applications as instant messaging, peer to peer file transfer applications (ex: Napster, Scour, iMesh, ICAST, Gnutella, etc), network gaming, streaming audio and video, multicast enabled applications, and so on.

Blocked Applications
A blocked application is defined as an application that is blocked from Internet access. This includes but is not limited to such applications as those used to hack against network infrastructure or those applications that overconsume limited network resources. Any application can be immediately blocked at any time in response to these two needs.

In an effort to manage traffic volume on Internet circuits for the classes of applications defined above, QoS (Quality of Service) has been introduced on ISUnet. This technology allows policies to be applied to specific applications in order to guarantee adequate bandwidth for mission critical applications and limit bandwidth for unsupported applications. This configuration helps to insure that adequate bandwidth is available between the campus network and our Internet service providers.

At this time, we are developing plans to introduce other QoS techniques to enhance the reliability of select services on campus. These changes will be described in upcoming revisions of this document.

Back to top

IP Multicast

In an effort to optimize applications that are broadcast based, an architecture known as IP multicast has emerged. This architecture minimizes the volume of generated by broadcast oriented applications while maximizing the flexibility of the service to end users.

The IP multicast model is based upon PIM (Protocol Independent Multicast) v2. With PIM, multicast routes are exchanged between peer routers on campus. To provide connectivity between sender and receivers, two RP (Rendezvous Points) will be used. This configuration allows multiple RPs to be active in the same multicast domain at the same time for load balancing and redundancy. MSDP (Multicast Source Discovery Protocol) will be used to exchange multicast sources between them.

When a receiver wants to listen to a sender, it issues an IGMP (Internet Group Maintenance Protocol). The PIM router directs the request to the RP looking for the sender. Once found, a path is constructed between sender and receiver through the RP. Once the end nodes are communicating, then a direct multicast path is constructed between sender and receiver and the path through the RP is torn down.

This complete model is still being tested and is expected to be released into production by the summer of 2001. The actual schedule will be made available in the spring of 2001.

Back to top