|
Site Map
|
|
|
|
|
 |
|
|
|
|
|
|
Archive 19 June 2006 #52
How to Get to High Availability?
Practice, Practice, Practice
By William A. Flanagan, Publisher
Same advice as in the old joke about getting to Carnegie Hall applies to achieving HA in communications--it's practice, not the theory.
Had a discussion recently with a group of enterprise comms managers about the practice of HA for voice on a data network. Specifically, how do network technicians and engineers approach HA from voice and data backgrounds? Quite differently, they agreed, as we have experienced for some time.
The early practices of "The Telephone Company" were driven to HA by several forces. Late in the 19th century, telcos realized their business customers didn't really trust the phone, routinely sending a messenger to the other party before placing a call. Telephones would have a limited market until proven more reliable than a messenger.
In the 20th century there were economic incentives for a vertically integrated monopoly to seek HA. The rates for calls were regulated, based on ROI, but the profit on equipment was something else. Designing and making better equipment justified upgrades that generated additional profits on the manufacturing side (paying for Bell Labs) as well as increased the rate base on the operating side. The job was done so well that by the 1960's all but the most remote telephone subscribers in the US became accustomed to getting service every time they picked up a phone. That expectation still applies, supported by telco people ("Bells") applying standard Bell System Practices.
Data services are much younger. Most adults can remember when the Internet swept into the public consciousness--operated by a wild and wooly bunch of proud geeks who got the job done but seldom documented how. Data networks are now more reliable than messengers, or at least faster to most locations for most information. Data networking's much shorter history hasn't allowed enough time for customer expectations to approach "five nines," so data network people ("Rooters") don't have that expectation either.
The Bells get heartburn when told that voice will be moving from TDM switches to packet networks. To them "routing" is handled by the Class 5 switch dealing with the E.164 address space and the national 800 data base.
Rooters are happy to carry voice as another form of traffic on the data network, as long as they:
-- don't have to deal with it as an application,
-- still get their regularly scheduled maintenance windows every week and month, and
-- can power-cycle or reboot a device at any time.
To Rooters, scheduled maintenance and reboots don't count as downtime--which is Cisco's position--even though one reboot of a large router can exceed the annual downtime allowance for 99.999% uptime (about 5 minutes). Of course redundancy and careful procedures (practices) can minimize service outages during maintenance.
Can this marriage of voice and data be saved? It will have to be, because that's the future.
Q from the audience: Is it better to train voice people on data or data people on voice?
Theoretically, both groups are smart people and can learn whatever is needed. In practice, the group of comms managers seem to agree that the Bells have the advantage of being more customer oriented, accustomed to delivering a service that people use easily. Most Rooters like working in the network equipment rooms and are not eager to move up the protocol stack to applications, much less to Level 8--customer service.
Forecast from this writer: voice and data will converge, probably sooner than we think. After V&D merge, we'll still need most of the elements of the two skill sets (such as an understanding of both IP routing protocols and analog signaling). With some luck, most people will be able to specialize in the area they prefer. To make it all work, however, everyone will have to have some understanding of the full range technologies.
A few bright stars will emerge, learning enough of both sides to be able to isolate voice quality faults when the data network is still passing packets, or set up SIP signaling through a firewall with NAT and RADIUS authentication. Identify these candidates, start cross training them, buy them lunch once in a while--hope they stick around at least until after your VoIP deployment.
The other key issue in VoIP is what level of quality and availability will be "good enough" to be acceptable by your users (and your boss). Gresham's Law (copper coins of equal value drive silver coins from circulation) hasn't been repealed. If VoIP is cheap enough and offers additional features and services, we (as a civilization) may accept lower sound quality and more outages. We'll see what emerges, in practice.
============= + ====== + ====== + ====== + =============
Commercial Message from Flanagan Consulting
We currently support several Federal procurements, a
detailed network design for secure video, and several
product management and marketing assignments.
How may we help you? Ph: +1.703.242.8381
============= + ====== + ====== + ====== + =============
Special thanks for supporting ViewsLetter to www.webtorials.com,
your best source for communications tutorials and white papers.
"Flanagan
Consulting" and "ViewsLetter" are Service Marks of W. A. Flanagan, Inc.