| Perhaps the biggest reason for migrating to ATM is its ability to
handle various types of traffic while offering infinitely scalable
bandwidth. Question is, does ATM really come through on this front?
Whether it's a campus ATM network or keeping tabs on a WAN
service-level agreement (SLA) with an ATM provider, one of the main
goals is ensuring that ATM works as advertised.
Monitoring ATM performance poses special challenges. Unlike non-ATM
networks, there are really two networks to manage—a physical one
and a virtual one. Managing physical connections is straightforward:
Just make sure the link operates at the fastest rate it supports. A
key parameter here is link utilization rates.
But when virtual circuits (VCs) come into play, things get more
complicated. Be
cause the route taken by any VC may change in response
to network conditions, the network management system must follow the
VC and report on its performance—regardless of the physical links
it uses. There's more to getting a handle on traffic than tracking
such parameters as cells transmitted and received, delay, bandwidth
allocated, and bandwidth used; net managers need to do the same for
each VC used in the network.
Another key requirement is dealing with ATM's multiple traffic
types and QOS guarantees. It's up to the network management system to
instruct switches and other devices to give priority to
delay-sensitive traffic (such as voice or video) over non-real-time
traffic like bulk file transfers.
Even with QOS guarantees, it's imperative for net managers to
implement and monitor SLAs with their service providers. Services
typically covered in SLAs are constant bit rate (CBR), variable bit
rate (VBR), and available bit rate (ABR).
To ensure the net managers get their money'
s worth from these
services, the SLA should cover reconfiguration times for permanent
virtual circuits (PVCs), along with time to establish and tear down
switched virtual circuits (SVCs). Further, if the SLA outlines
quantified goals, then the management system can monitor statistics
over time to see if there are violations. For example, a net
management system can determine whether a provider responds to a
service failure within the time specified in the SLA. This allows SLAs
to deliver more than just "best effort" services; they also can spot
violations and help assess penalties (such as reduced tariff charges)
where applicable.
As with fault management, the biggest challenge in managing
performance lies with the network management console. The console has
a long list of tasks, chief among them monitoring performance
thresholds and rerouting VCs as necessary.
To make sure the network delivers the desired service level, the
console has to note any performance degradation across all the
differ
ent paths a VC might use. The key here? Event correlation. Say
two ATM end-stations set up a virtual connection across 10 switch
hops; the network management console then has to keep tabs on all
switches and all leased lines in between. It must be able to determine
whether the problem lies with one of the switches or with the leased
lines connecting them (both should report anomalies if the lines are
bad).
Tracking performance over time is another goal. With
circuit-switched technologies like ATM, it's essential for the network
management console to understand how physical circuits are likely to
behave at any given time. In the short term, the console can use such
data to reassign switches to set up future VCs on lightly loaded
circuits. It's also useful in the long term—since historical data
helps justify how much ATM bandwidth is actually needed.
As for interoperability: While such standards as private
network-to-network interface (PNNI) govern signaling between different
vendors' swit
ches, they cover basic communications only. Right now
it's impossible for a net management app from one vendor to set QOS on
a switch from another.
Configuration
Monitoring network devices and circuits is one thing. Configuring
them is another. The same can be said for ATM nets. Unfortunately,
standards are limited. Vendors have extended them for more complete
management capabilities, but that makes interoperability
impossible.
Configuration management covers both the network and the traffic
that flows through it. On the network side, devices like switches,
routers, and physical circuits all require that various parameters be
set before they can operate. As for network traffic, setting up or
tearing down PVCs and SVCs also is a part of configuration management.
The problem, both for switches and the traffic that flows through
them, is that every switch vendor handles these tasks in different
ways.
Most vendors furnish their own SNMP-based configuration
application, but manage
ment information base (MIB) support differs
from vendor to vendor. For example, some ATM switch vendors back the
standard MIB for ATM, IETF RFC 1695—the so-called AToM MIB. The
AToM MIB goes a long way toward delivering a uniform view of the ATM
network, offering up information on virtual links, alarm identifiers,
performance, and configuration. Trouble is, not every vendor supports
it—and even those that do have added so many "enterprise"
extensions (proprietary features) that integrating information from
multiple vendors' devices is a very difficult undertaking.
Configuration management is less of an issue for link-specific MIBs
like the DS-1/DS-3 MIB or the Sonet (synchronous optical network) MIB.
In addition, some MIBs cover specific types of interfaces. For
example, the ILMI (interim local management interface) MIB allows one
end of a user-to-network interface (UNI) to view configuration
information at the other end.
The IETF and ATM Forum may someday develop a standard that ex
tends
MIB information beyond RFC 1695. Until then, network management
consoles will have to be able to handle any enterprise MIB to see and
configure devices, links, and traffic in an ATM network.
Security
Although the ATM Forum is working on ATM security methods, there
aren't too many options when it comes to controlling access to ATM
networks. ATM switches don't have network access control facilities.
When a VC is established, there isn't any screening of the connection
source, destination, or the applications involved.
Ideally, an organization's security policies should simply be
extended to cover ATM networks. For this to happen, however, switches
(or security devices) would have to examine each cell traversing the
link to determine whether the user should have access to the network.
With ATM, this screening would have to occur at rates of 155 Mbit/s or
more.
Unfortunately, security devices like firewalls and virtual private
network (VPN) authentication/encryption boxes
are generally built to
operate on much slower links. Further, very few vendors of security
products explicitly support ATM interfaces.
And among products that do handle ATM, performance is a problem. A
few firewalls and VPN products operate at rates of up to about 60
Mbit/s with no performance degradation (see "Firewalls: Don't Get
Burned," March 21, 1997;
http://www.data.com/lab_tests/firewalls97.html). But not all these
products have been tested on ATM networks. Indeed, performance data on
ATM security devices is still scarce.
Yes, deploying a firewall and VPN device is better than no security
at all. But net managers who do so unfortunately risk losing some of
ATM's performance benefits.
Accounting Management
Service providers have an obvious interest in metering ATM traffic:
They need to bill their customers. But managers of private networks
also need accounting controls. They may want to charge individual
departments, for instance—and they definitely want to keep t
abs
on service providers.
The key metric in accounting management is the amount of ports and
VCs charged to each "customer." Typically, this information is
gathered by an agent at each ATM switch. Some element-management
systems also do it. More granular accounting information includes such
parameters as duration of each circuit, distance, and special rates
tied to time of day or other criteria. Something to keep in mind: One
ATM link can furnish different services to different users, and these
will need to be broken out in billing statements.
Vendors and users haven't yet reached consensus on how to
characterize, monitor, and control user traffic to support various
services. For PVCs, usage-based billing doesn't have much meaning:
Customers pay for a given connection at a given speed, whether it's
used or not. For SVCs, usage-based billing is possible. Obviously,
the network management system will need to be able to distinguish
among VBR, ABR, and CBR services.
As with other managem
ent functions, putting together accounting
data from multiple vendors' switches is a problem, as is correlation
of reports. Unfortunately, the state of the art is fairly
primitive—and accounting tends to be the last thing vendors of
net management gear turn their attention to.
Joe Abusamra is marketing manager for network management products and services at Stanford Telecom (Sunnyvale, Calif.). His e-mail address is jabusamra@sed.stel.com.
|
