Do You Hear What I Hear?�Part V: Integrated Services
Continuing with our series on VoIP Quality of Service (QoS), our previous installments have looked at some of the key factors surrounding the quality of the voice connection:
Part I: Defining QoS
Part II: Key Transmission Impairments
Part III: Dealing with Latency
Part IV: Measuring "Toll Quality"
Having thus looked at some of the QoS challenges, in this, and in the next few tutorials, we will look at some of the solutions that the IP networking industry has proposed. It should be noted, however, that most vendors have a preferred solution, and may go to great lengths to convince you that their solution is the solution. Knowledge is a good thing, and arming yourself with information regarding all the alternatives will broaden the choices that you have available, and hopefully guide you to a system that is the best match for your enterprise. We will begin with the oldest solution, known as Integrated Services, or intserv.
Integrated Services was a project of the Internet Engineering Task Force (IETF), with the intserv working group chartered for the purpose of "defining a minimal set of global requirements which transition the Internet into a robust integrated-service communications infrastructure." This work began in the early 1990s, which speaks highly of the IETF's foresight in acknowledging that real-time streams of audio and video would need to coexist with more traditional data traffic such as file transfers. The working group focused on three problems:
- Defining the services to be provided with an enhanced Internet
- Defining the interfaces for end-to-end, routing, and subnet technologies
- Defining any additional router requirements to enable the Internet to support the new service model
With those objectives in mind, the intserv working group published three key RFC documents:
- RFC 1633: Integrated Services in the Internet Architecture: an Overview (June 1994)
- RFC 2212: Specification of Guaranteed Quality of Service (September 1997)
- RFC 2215: General Characterization Parameters for Integrated Service Network Elements (September 1997)
RFC 1633 is the foundation document that details the integrated services model, which requires that network bandwidth must be managed in order to meet application requirements. Those requirements result from user activity, and generate flows, which are distinguishable streams of related datagrams. For example, a single voice or video stream would constitute one flow, which would then be distinguishable from other applications and their respective streams of information. In other words, these datagrams would have consistent source and destination addresses, protocols employed, and so on. Note that a flow is a simplex (uni-directional) path of information, from a single source to one or more destinations.
The two building blocks of this service are resource reservations, which reserve network bandwidth on behalf of an application, and admission controls, which determine if additional flows can be allowed within the network without impacting earlier network commitments. And if you are defining such a flow-based architecture, you must also determine mechanisms to keep track of these flows within the routers or other network elements. Those mechanisms are embedded within the four components of the framework of this architecture: the packet scheduler, the admission control routine, the classifier, and the reservation setup protocol.
The packet scheduler manages the forwarding of packet streams using mechanisms such as queues and timers. The classifier maps packets into a particular class, based upon criteria such as the packet header contents or other distinguishing factor. For example, all of the video packets may belong to the same class. The admission control element runs a decision algorithm that enables a router or host to determine if a new flow can be added to the network without impacting the existing flows. Finally, the reservation setup protocol creates and maintains the flow state information along the path of the flow. For intserv, the protocol defined is the Resource Reservation Protocol, or RSVP, which will be the subject of our next tutorial.
Copyright Acknowledgement: © 2005 DigiNet ® Corporation, All Rights Reserved
Mark A. Miller, P.E. is President of DigiNet ® Corporation, a Denver-based consulting engineering firm. He is the author of many books on networking technologies, including Voice over IP Technologies, and Internet Technologies Handbook, both published by John Wiley & Sons.