Publisher's Letter The Achilles Heel of ATM Service: OSS
Dr. Jerry Lucas
05/01/1999
With the massive investment the telcos have made in ATM infrastructure, why are they moving full speed ahead with IP as the network backbone choice for the 21st century? The simplistic answer is, IP won the desktop battle against ATM. While true, there's also an equally valid answer: OSS readiness. Here are my top 10 reasons why OSS is the Achilles' heel of ATM services, plus some recommended solutions.
1. OSS as an ATM Afterthought
The pioneers of ATM were the same voice switching system engineers who created ISDN. They wanted to create something that would deliver voice, data and video (e.g., broadband ISDN) that was not achievable by the original narrowband ISDN. The heart of B-ISDN was the switching and multiplexing technology-ATM. However, three marketplace waves hit in the early 1990s, which knocked B-ISDN off its mark. First, N-ISDN was quickly viewed as a marketplace bomb; thus B-ISDN was dropped as the banner name, and the standards effort just became known as ATM. At this point, university computer science departments recognized the complexity of ATM and the network requirements in offering integrated multimedia services. Each service has its own bandwidth and quality of service (QoS) needs. This complex challenge generated many research projects, telco research grants and Ph.D. thesis topics. Also, university computer science departments began to buy first-generation ATM switches for research purposes.
The second wave, fortunately for ATM, was the Internet and its exploding capacity requirements. The only multiplexing and switching technology able to support 45 Mbps backbone networking at the time was ATM. So enter the Internet community's Internet Engineering Task Force (IETF) as another voice to be heard in shaping ATM. Plus network equipment manufacturers smelling new marketplace dollars entered the picture under the ATM Forum banner.
So during the creation of ATM wave two, the telco engineer, IETF, ATM Forum and lots of academic types were in the ATM definition process. No one with an OSS hat on was in the room questioning, Can we provision this service? How do we provision to an end user vs. a carrier? Or inform the customer on service performance, let alone gather data for usage-based billing?
A third wave and another marketplace break-the demand for frame relay service, via ATM networking. Frame relay basically allows for IP packet encapsulation from, and end user routers to, the Internet, or for LAN-to-LAN interconnection. It makes a T-1 circuit more efficient. In short, a company previously using dedicated T-1, or 1.5 Mbps, service could save money with frame relay. Also routers (i.e., IP packet switches) using T-1 access could be updated with the necessary frame relay software basically for free.
Frame relay service exploded along with the demand for frame relay switches. The good news for ATM vendors was that ATM switches were great for frame relay access and IP customer interfacing. As frame relay grew, so did the carrier's geographic points of presence that used ATM technology as edge switches, as well as ATM in the backbone network. In addition, carriers used ATM backbone networks to support internal DS-1 (1.5 Mbps) or DS-3 (45 Mbps) links and private DS-1 and DS-3 services.
Finally, corporate users who were looking for high-speed LANs in building and campus environments found that ATM technology fit the bill. Note that in many cases the fiber used to interconnect the ATM devices was owned by the customer and not the carriers. As such, no transmission fees entered the ATM cost justification equation.
So what about OSSs for ATM? In the early startup days of the 1990s, carrier-class OSSs weren't needed. ATM multiplexers and switches were simply supported manually; other carrier OSSs supported SONET, frame relay and private DS-1/DS-3 services that met the carrier needs. University, medical and corporate enterprise ATM networks had no need for OSSs, either, since they weren't providing service to others outside their organizations.
2. OSS ATM Standards
When ATM hype (voice, data, video and everything else over ATM) reached its peak in the mid-1990s, all the major standards groups had ATM OSS committees, each with its own agenda. The ITU and the European vendors were determined to see that ATM OSSs would be TMN- or OSI-compliant, which most North American carriers view as too complicated to deploy. The Internet community and the IETF saw ATM only as a necessary evil (the only multiplexing technology existing at this time to create high-speed backbone networks)-much like today's Internet-centric carrier's view, which is, "Whenever gigabit routers are ready, you won't need ATM, period, let alone OSSs for ATM!"
Finally the TeleManagement Forum (formerly the Network Management Forum, or NMF), with its 600 members at the time, found it hard to keep any aspect of ATM simple, including OSS.
The net result: no useful OSS standard for ATM. Each ATM product vendor had its own proprietary OSS components that were uniquely integrated into major ATM carriers' networks. Worse yet was the fact that every ATM carrier became its own OSS ATM software developer. The options of off-the-shelf, turnkey OSS products for ATM or outsourcing OSS to a third party did not exist.
3. No Inter-Carrier OSS Interconnectivity
Today carriers cannot fully interconnect their ATM networks, largely due to the fact there are no meaningful OSS ATM standards. Yes, a carrier can send ATM packets (cells) between ATM networks, because the ATM standards groups have defined what's called Network to Network Interface (NNI). It's meaningless, however, unless a carrier can order, provision or maintain an ATM link using someone else's ATM network. Yes, AT&T, MCI WorldCom and Sprint provide ATM service on their own network. But what if one ATM location served by one carrier and another location served by someone else's require ATM interconnection? You're out of luck, except for the very basic services requiring little network reconfiguration, low speeds (e.g. T-1) and only if you have few sites to connect.
4. ATM's Too Complicated to Support
Why do today's academic computer science departments embrace IP and reject ATM? Simple: it's very complicated to create an ATM network servicing multiple sites.
In this regard ATM is like quantum physics. In theory quantum mechanics is great, but in practice it's too complicated to explain all events observed in nature. For example, quantum theory can predict every aspect of an experiment involving a hydrogen atom because hydrogen atoms are simple-one proton and one electron. Go to the next element-helium, two protons, two neutrons and two electrons-and quantum theory can't predict every aspect of behavior in an experiment. Not that quantum physics is wrong; it's just too difficult to totally apply to all but the simplest cases. That's why we still have chemists.
OK. So why is ATM too complicated to create OSSs? One characteristic example-ATM packet or cell numbers. The phone network was, relatively speaking, easy to create, because a user was assigned a phone number that identified a phone line, serving switch and geographic area. That number was also used for billing, trouble ticketing, etc. The same could be said about the Internet in the start-up days. An IP address identified a user and the network they were on.
ATM, on the other hand, has a limited set of numbers that identify locations, called virtual path identifiers (VPIs). Applications are assigned virtual channels identifiers (VCIs) on those virtual paths. The problem is that there aren't enough numbers to assign users permanent VPIs/VCIs. Instead the VPI/VCI pair only has meaning local to the switch; thus, a network manager system looking at an internal core link can't determine whose traffic it is, or where it is going. This would require an OSS query. Still worse is the fact that there can be a different QoS for these paths!
Bottom line: ATM networks are so complicated that they must be provisioned manually. Just like it took computer technology and programmers nearly half a century to defeat a chess grandmaster like Gary Kasparov, computer programmers are not yet advanced enough to allow for people-less ATM network provisioning.
5. ATM Unbundled
Because ATM operation support is performed manually and ATM applications were limited to supporting private-line, frame relay and Internet backbone transmission, it's said that ATM has become unbundled: the parts of ATM are used, but not the whole.
The ATM OSS requirements have been supported by other OSSs, specifically by combining SONET OSS (layer 1 below ATM in the IP platform) and router OSS (layer 3 above ATM). If a network needs reconfiguring due to a fiber cut, SONET OSS is in charge. If there's a software glitch in the ATM core network, routers raise a trouble flag.
This decentralization is a result of the lack of network tools to look inside an operational ATM network. Yes, engineers can analyze things in a simplified ATM network or in a laboratory simulation, but not in an operational network from one vantage point. Again, this lack of ATM OSS limits its scalability and inter-carrier interconnectivity.
6. Customer Performance Reporting?
The number one selling point of ATM over the leading backbone alternative-IP-is QoS. With QoS as a selling point, the customers surely want to know what they are paying for. So carriers have got to measure ATM QoS and report it to their customers.
There are ways to measure performance within the core of an ATM network via special transmission of ATM operations and maintenance packets, or OAM cells. This provides the network operator a good view of a network between two points. The user, however, has broken up this virtual path into many virtual channels supporting different applications. Users see the network at a higher or virtual channel connection layer. It's nearly impossible for the carriers viewing the network from the ATM core to monitor and report QoS at the user or channel level because of the lack of OSS tools.
7. Dumb Customers Need Not Call
If computer science students and faculty find ATM too complicated, what about customers or corporate telecom managers? If you have doubts about the arduous nature of ATM, pick up a text on it. Now, could a typical end user learn what they need to know to characterize their traffic, configure an ATM network, buy the necessary ATM customer premises equipment and place an order? With time and a large human resource budget, yes. Will they? Probably not. The OSS barrier here is that the end users need simple OSS tools as badly as the carriers do. Otherwise the carriers will have to do lots of ongoing user handholding to create ATM services for the masses.
8. Decentralized ATM Traffic Management
ATM promises bandwidth on demand-the ability to send a high-volume burst of data at a given instant with a QoS guarantee on cell loss, latency, etc., at ultrahigh access speeds (OC-3/OC-12, or 155 Mbps/622 Mbps).
The problem is, while carriers serve locations with fiber access to support 155 Mbps/622 Mbps service, their fiber access penetration equals only about 3 percent of U.S. office buildings with fiber access. There are many more locations that only have copper loop access supporting DS-1 or 1.5 Mbps services. While inverse multiplexing can increase the 1.5 Mbps restriction by combining two or more T-1s, the ability to accept bursts of very high-speed data at small bandwidth sites is limited.
Bottom line: before a carrier can sell upscale ATM services (high burst rate on demand), let alone provision it, the carrier has to know whether the network (ATM switches, interconnection circuits and end user access links) can handle the new customer traffic, given the other customers and services (frame relay or private line) already running. To do this you need centralized ATM management to get an overall network view in real time. That's the only way a carrier can execute traffic admission control, capacity reservation and network policing in order to ensure QoS. But because of the lack of ATM OSSs and manual operation procedures, most ATM networks are run with distributed OSSs at the edges of the ATM core network, instead of a central view with centralized management. And of course, if a carrier is looking for a bigger OSS ATM challenge, try provisioning upscale ATM service across two different carriers' networks. One ATM network operator must know what's on the other carrier's network, traffic-wise and resource-wise, in real time.
9. ATM OSS Training
ATM has a problem that circuit switched voice/TDM, frame relay and IP didn't when they were created: There's no dominant player in ATM. The Bell System and particularly Bell Labs defined circuit switching and TDM transmission (T-1s, digital cross-connect systems, etc.). Western Electric manufactured it, and the BOCs and AT&T Long Lines deployed it. If a vendor wanted to sell to the Bell System or compete for their customers, it used Bell System pseudo-standards.
Regarding IP, the Department of Defense (DoD) commissioned its creation in order to replace the ARPANET. In the old days, if a vendor wanted to sell to the DoD, products had to be IP-compatible, and if someone wanted to send data, IP platforms were a good choice, because no one owned IP. It was an open standard with the IETF supporting it. Finally, Cisco pioneered frame relay with support from Sprint, Nortel and others. Since virtually no IP packet transported over the Internet at the time failed to pass through a Cisco router at least once, and Cisco virtually gave away frame relay software upgrades for their routers, frame relay was defined for all, period.
ATM, however, has a problem. No vendor dominates the equipment marketplace, and there are too many fingers in the standards pie for a single view to surface. Not only does this stagnate the OSS standards making process, it creates an environment where lots of different ATM boxes are manufactured by entities creating their own OSSs.
Today's marketplace has potential customers with different ATM CPE, supported by an ATM carrier with distributed OSSs vs. centralized OSSs, and these customers want to see ATM services over multiple carriers. If a carrier with customers or partner carriers works with a spectrum of ATM boxes, its field support team must understand dozens of ATM products and provide customer care 24 x 7. At this point the training cost of required personnel alone exceeds the cost of ATM hardware, and begins to rival the cost of transmission.
For example, if a carrier wants its field support engineers to support a Cisco ATM switch, the engineer must be sent to Cisco's training center in San Jose or Telecordia's (formerly Bellcore's) training center near Chicago to be certified. These are the only two certification centers in the world, and this training experience is in the $20K-$30K range per engineer, including travel and per diem! Due to the lack of a centralized ATM OSS, carriers must multiply costs by the number of ATM products to support and by the number of field engineers needed to be trained by the number regional centers-we are talking about big bucks. Throw in international field service, and the bean counters go wild. It's worse than this, because after training the field engineers, the carriers must raise their salaries or they will leave to take a better offer from a competitor.
10. End-to-End ATM
Finally, the customer wants end-to-end ATM service. This means going beyond what's called the user-to-network interface (UNI) and taking over the CPE as well. As usual, it's worse than this-because the customer is going to want to plug desktop ATM devices into the ATM/CPE mix to create ATM desktop-to-anything applications and expect carriers to support it! I haven't heard of any ATM OSS capable of supporting end-to-end and desktop-to-any applications.
Eliminating the ATM OSS Achilles' Heel
Not to end on a totally negative ATM note, there are three solutions to the ATM OSS problem, but none will be easy to pull off. Here are the solutions and their individual problems.
1. Go It Alone
Carriers could follow the MCI WorldCom model: total end-to-end ATM with fiber access into its backbone network. Yes, MCI WorldCom probably has access to 50,000 buildings worldwide with their own or leased fiber. But their customers are in many more than just the 50,000 buildings to which they have fiber access. To continue their high-rate growth they will have to acquire CLECs in the United States and around the world. Then they will have to either replace all existing ATM equipment and go with one vendor and OSS solution, or live with the ATM OSS problems identified. Moreover, the carrier interconnection problems for geographic areas not served by MCI WorldCom or for customers wishing to connect with other carriers still remain.
2. Carrier Alliances
The second approach is to create carrier alliances to solve the ATM OSS carrier interconnection problems. This sounds reasonable in theory, but this approach has failed in practice to date. Sprint last year approached the RBOCs with its Integrated on-Demand (ION) ATM partnering proposal and apparently was rejected. Also, Sprint's joint venture with France Telecom and Deutsche Telekom is reportedly unraveling. AT&T's Unisource venture with the European PTTs and others fell apart. Finally MCI's and British Telecom's much publicized Concert alliance came to its end when WorldCom acquired MCI. Maybe BT and AT&T can make ATM via Concert work!
3. ATM OSS Gateways and/or Outsourcing
My favorite solution for OSS interconnection and compatibility problems in general is OSS gateways (see Billing World November 1996). Unfortunately neither OSS gateways nor outsourcing has yet solved the ILEC-CLEC OSS interconnection problem for circuit switched networks, so there's not much hope here for ATM OSS interconnection gateways or third-party ATM OSS outsourcing in the near term.
ATM Outlook
On one hand, even though OSS is an albatross around ATM's neck, the technology and resulting services are not going away any time soon. ATM's savior is frame relay service and dedicated circuit emulation for voice. The world depends on both, and today these services run over ATM backbones. The only way to economically expand frame relay above T-1/E-1 1.5/2 Mbps service rate is with ATM technology. There is tremendous user demand for frame relay to ATM service internetworking, frame relay serving small user sites with seamless interconnection to ATM serving large user sites. Regarding voice, IP can't match the QoS ATM delivers. Frame relay and dedicated circuits created, and will sustain, the need for ATM technology for years to come.
That's the good news. ATM cannot be phased out of carrier networks any time soon, so the ATM OSS issues will have to be addressed by carriers. The bad news is, not only is IP a simpler backbone platform than ATM and IP has won the desktop war, but IP OSS is much simpler to pull off.
Why IP OSS is simpler will be addressed in a future issue of Billing World. But if you have to know now, you can attend TeleStrategies' Understanding IP Networking for Non-Engineers seminar. Check out www.telestrategies.com for agenda and schedule information or call (703) 734-7050.
Email this article
Add a comment
Printer version
Order reprints
RSS Feed
Bookmark article