Ready for VoIP: Stocking the Toolbox for the Upper Layers

Part 9: The tools for monitoring and managing the upper layers all derive from the protocol analyzers of yesteryear.

By Mark A. Miller | Posted Feb 1, 2008
Page of   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn

Our last tutorial looked at some tools that are useful for managing the lower layers of a VoIP networking infrastructure. We now continue that discussion and consider more complex network management systems that can also handle the challenges of the upper protocol layers.

Protocol Analyzers: A protocol is simply a set of rules, and the protocol analyzer determines if the data that was transmitted adheres to the rules that were developed for that system.

Going back 25 years or so, the first protocol analyzers were called datascopes, and were used to decode a Data Link layer protocol, such as IBM's SDLC on a serial line such as a WAN. Those early devices had several limitations: They were typically single-protocol, single-use (such as decoding DECNET over an Ethernet LAN); they displayed the results in ASCII or hexadecimal encoding, not English, requiring further user interpretation; and they typically operated on only one protocol layer, without the ability to interpret end user application data. The advent of the PC changed the protocol analyzer market from a hardware to a software business, and also dramatically improved the capabilities of these devices.

Now, multi-protocol, multi-layer functionality is the norm&emdash;which gives the user the ability to examine each layer of the protocol stack (for example, physical connection, Ethernet frames, Internet Protocol (IP) packets, User Datagram Protocol (UDP) datagrams, Real Time Protocol (RTP) voice samples, and so on). Furthermore, many of these devices have embedded expert analysis engines that provide the user with specific details that describe the nature of a problem (e.g., a duplicate IP address), and may also point toward a solution (the hardware&emdash;or Ethernet&emdash;addresses that identify the offending stations).

Examples of companies that are active in this area include: Agilent Technologies, Clearsight Networks, GL Communications www.gl.com, Network General (recently acquired by Netscout), and RADCOM.

Enterprise Network Management Systems and Remote Probes: In the early 1990s, as network architectures were evolving from host-based, centralized systems to distributed routers and servers, the Internet Engineering Task Force (IETF) developed a network framework system and protocol to address this changing environment. That protocol is the Simple Network Management Protocol (SNMP), now in its third generation of release (SNMPv3), and defined in RFCs 3410-3418 (see ftp://ftp.rfc-editor.org/in-notes/rfc3410.txt).

SNMP-based network management systems entered enterprise environments in the late 1990s, and have become one of the most fundamental network management tools since that time. An outgrowth of that research is called RMON, which stands for remote monitoring.

With RMON systems, probes are placed at strategic locations within the network, or embedded into those devices, such as routers. The probes then monitor various network parameters and operational characteristics, and report that information back to the network management console.

These concepts are beginning to move into converged networking, with embedded probes that can monitor the health of a VoIP network, reporting information such as MOS scores, call performance statistics, and so on&emdash;some of which can also be integrated into existing SNMP-based systems. Examples of companies that market remote probes of one kind or another include: Telchemy, Tektronix, and RADCOM.

Network Design and Optimization Tools: As we have discussed many times in the course of these tutorials, the concept of combining voice and data into a common networking infrastructure has a number of inherent challenges, including variations in the amount of traffic sent during a call, the call holding times, the WAN circuits needed to complete the end-to-end connection, and so on. As a result of these differences, the design and optimization of a converged network from a pure engineering point of view is quite difficult&emdash;if not impossible&emdash;to accomplish using typical analytical tools such as spreadsheets.

Over the years, many firms have attempted to develop software solutions to address this challenge, and a few have survived. Also in this category are hardware products that stress-test the network, applying simulated loads on the networking components, and then determine how it will perform under such conditions. Examples of companies that are active in the design and optimization area include: Fluke Networks, Ixia, OPNET Technologies, Spirent Communications, and Westbay Engineers.

One caveat: The categories enumerated above are somewhat general, and many products may fit into more than one area. But we'll save that discussion for another day.

Our next tutorial will begin our examination of specific vendors' products, and show how these products can meet specific VoIP network management challenges.


Author's Biography
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.

Article courtesy of EnterpriseVoIPplanet.com, © DigiNet Corporation, all rights reserved.

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter