Browse By...  Technology/Topic  Vendor  Issue  Visitors Center  FAQs  Contact the Editors  Registration  Subscriptions  Content  VIEWPOINT  TECH TUTORIALS  ATM  Carrier-Class Gear  Internet/Intranets  IP Tools/Issues  Network Software  Net Management/SLAs  QOS  Remote Access  Routers/Switches  Security  Servers/Peripherals  Services/Outsourcing  Workgroup Networks  NEW PUBLIC NETWORK  LAB TEST CENTER  GLOBAL NETWORKS  PRODUCT LEADERS  OPINIONS/COLUMN  Lippis on Internetworking  Sound Byte  Marketing Services  T99 Media Services  Industry Front & Center  Reader Service  Custom Publishing  Vendor Strategies  Sponsorships  Byte.com  CMPmetrics  Data Communications  File Mine  InformationWeek  InternetWeek  Network Computing  Planet IT  TechShopper  TechWeb News  Tele.com  WebTools  Winmag.com

September 1995 By Peter Alexander and Kacey Carpenter, Stratacom Inc. ATM Net Management: A Status Report Building a manageme nt framework won't be easy, but the ATM Forum's five-layer model could be a step in the right direction For all the talk about platform integration, network management remains mainly a collection of discrete procedures aimed at handling specific problems. The tools and techniques used to monitor and control data traffic on the LAN side aren't very helpful when it comes to managing activity on the wide area. Likewise, connections handling delay-sensitive traffic require special attention that simply isn't needed for asynchronous data applications. This kind of fragmented approach to net management isn't going to cut it for ATM, which uses one technology for transmitting diverse traffic types and running different applications across both LANs and WANs. Net managers need an end-to-end overview of a variety of conditions-from throughput to cell delay to jitter-for tens of thousands of virtual connections. They also must be able to monitor and control the physical switching infrastructure. None o f the major SNMP-based platforms offer the bulk protocol capabilities needed to manage a large-scale ATM network. What's needed is an ATM management framework. Building one won't be so easy. It involves coming up with new approaches to such management functions as service provisioning, fault and performance monitoring, resource planning, and billing. Net managers can't take these initial steps until standards are in place. To that end, the ATM Forum is developing a five-layer ATM management model and an OAM (operations, administration, and maintenance) facility. The model will define interfaces for managing hybrid network environments that consist of both private and public networks and extend from LAN to WAN. It also will define the specialized OAM cells that automatically distribute management information throughout the ATM network. If there is a problem with the forum's net management effort, it's that a final version could still be years away. So the organization has established a temporary model that will give net managers at least a taste of ATM management capability. Known as the ILMI (Interim Local Management Interface), the temporary model is included as part of the forum's UNI (user-network interface) 3.1. ILMI uses a prespecified ATM virtual connection on the ATM UNI to communicate switch to switch and with a management application via SNMP messages (see "Interim Intelligence" ). However, ILMI is limited to managing the interfaces between networks, and it does not distribute management intelligence through the net. THINKING ATM SNMP-based management platforms like Openview from Hewlett-Packard Co. (HP, Palo Alto, Calif.) basically can't handle the end-to-end management of ATM networks. The challenge facing net managers is how to migrate from these systems to an ATM-based management model-which will help them meet the goal of providing seamless, end-to-end switched connectivity for tens of thousands of users across LANs and WANs. A seamless architecture, however, presents problems and raises challenges in just about every area of network management. Service provisioning is one of those areas. Without the proper tools, ATM network configuration can easily become a nightmare. There are currently four major classes of service to choose from: available bit rate (ABR), constant bit rate (CBR), unspecified bit rate (UBR), and variable bit rate (VBR). Guaranteeing the desired service level involves configuring optimal connection parameters on each switch in the network-which in turn requires setting traffic priorities, choosing routes, and taking into account trunk availability and other factors describing the current network state. Fault and performance management are also affected. ATM's high speed and ability to handle vast amounts of different data types add another dimension to network monitoring. For a net manager to keep tabs on what's happening, the ATM management architecture must enable the collection of thou sands-if not millions-of statistics per hour, pertaining to class of service, fault, performance, and usage. In addition, carriers and end-user organizations alike need a fault management module that provides multiple views of the network and helps administrators analyze fault conditions rapidly. Because ATM is more complex than conventional TDM (time-division multiplexing) networks or LANs, network managers must have both a physical and logical (virtual) view of the network service. For example, it is imperative that administrators have the data they need for understanding the conditions that led to the fault and how the network handled it. What's more, ATM will require dynamic visualization tools instead of the static topology views of the physical network that are a feature of today's management platforms. An end-to-end architecture also will change the nature of cost allocation and billing. The complexity of these procedures in an ATM WAN makes a powerful, reliable management plan all the more critical. The billing system must give carriers and corporate networkers a way to identify the appropriate class of service for each connection and then measure usage. If it doesn't, then service providers can't charge or allocate costs fairly. Usage-based billing is key. It will drive the cost of ATM down and make the service affordable for end-users, for whom the opportunity to buy ATM bandwidth according to actual usage rather than at a flat rate is quite attractive. In addition, organizations with private networks need to determine how much traffic comes from one department and how much from another. For carriers, usage-based pricing makes it possible to operate the network at much higher levels while keeping administration costs down. Finally, the area of resource planning will have to be addressed. ATM networks require intelligent design tools capable of intricate network modeling. If design applications are optimized to leverage management data provided by the specific types of swi tches constituting the network fabric, the carriers and end-user organizations deploying those switches will benefit. These applications can run "what if" scenarios based on such parameters as line cost, bandwidth availability, and service outages-allowing customers to prototype new services and get a handle on how growth will affect what's already in place. Careful planning is the only way to avoid management problems later on. DIAL M FOR MANAGEMENT The Network Management Working Group of the ATM Forum is now developing an end-to-end management model that includes both private networks and public network services and that lays out standards for interworking between the two. The model also will define gateways between SNMP and CMIP (common management information protocol) systems, and between standards-based and proprietary systems. Five key management interfaces are defined in this framework; they are labeled M1 through M5 (see Figure 1). All are essential to end-to-end monitoring a nd control. But managers of enterprise networks will be particularly interested in M1 and M2-they define the interface between the net management system at the customer site and an ATM end-station or network switch. Figure 1: Management Modules Five key management interfaces are defined in the ATM management framework. M1 and M2 define the interface between the management system at the customer site and the ATM end-station. M3 is the Customer Network Management interface. The merger of private and public networking technologies begins at M4, while M5 is the management interface between a carrier's own network management systems. Because SNMP is so widely deployed by end-user organizations, M1 and M2 embrace SNMP-based specifications defined by the Internet Engineering Task Force (IETF). These include MIB II and relevant standard MIBs (management information bases) for DS-1, DS-3, and Sonet connections. Also included is the experimental AToM MIB (RFC 1695), which in particular is expected to reduce the proliferation of widely varying vendor-specific ATM MIBs (see "Up and AToM" ). Also encompassing these MIBs is M3, the Customer Network Management (CNM) interface. M3 describes the interface between the customer and carrier management systems that gives the customer a view into the carrier's network. Ultimately, carriers plan to extend their CNM offerings so that network managers will have real-time control over the services they use. The merger of public and private networking technologies begins at M4. It's the management interface enabling Network Management Level (NML) views and Element Management Level (EML) views to the carrier's network management system and the public ATM network. Consequently, this is where the differing approaches to management must converge, since both the private network manager and the carrier want to be able to monitor the service. The manager of the private enterprise wishes to take advantage of public services yet retain control over them to guarantee quality. The carrier, on the other hand, wants oversight of customers' networks (with customers' permission, of course)-which would then give it the ability to offer network management as a value-added service. M5 is the management interface between a carrier's own network management systems, and the forum's Network Management Working Group is currently working on customer requirements for the interface. M5 is the most complicated of the management model's interfaces, and so far, no target dates for finalizing it have been set. The forum is aware that private and public network management systems will continue to maintain separate views into the network, each with unique levels of functionality. Implementing a net management scheme that wi ll enable both views involves the building of gateways between SNMP systems at customer sites and the CMIP and proprietary protocol systems used by carriers. Other groups, including the Network Management Forum and the International Telecommunication Union (ITU), have been working with the ATM Forum to negotiate interworking standards acceptable to both sides. Admittedly, it will take some time to finalize specifications defining interworking between SNMP and CMIP. Progress has been made, however, toward establishing a protocol-independent MIB for M4. The MIB will support SNMP objects defined in accordance with the SNMP structure of management information (SMI), as well as CMIP objects that conform to GDMO (Guidelines for Development of Managed Objects). CELLS OF INTELLIGENCE Within the next few years, there will be a lot more in terms of management that ATM networks can offer-but only with OAM cells, not with SNMP or CMIP. For example, dynamic reconfiguration in the event of failure to meet service requirements will be possible. Also, network devices and end-stations should be able to negotiate and reconfigure themselves to achieve service-level objectives. These architectures will be highly distributed, in the sense that more management intelligence-including monitoring and configuration capabilities-will be distributed throughout the network infrastructure itself. The forum is now in the process of specifying three types of 53-byte OAM cells. They will have specialized identification and field tags that indicate their functions: fault management, performance management, and activation/deactivation (for starting and terminating fault and performance management functions). OAM cells will ultimately give ATM network devices the ability to gather information about end-to-end connections, reduce the need to distribute MIBs throughout the network, and cut the amount of management-related traffic. So far, the working group has specified several OAM cells targeting fault manag ement, including alarm indication signal (AIS) cells and far end reporting failure (FERF) cells, which communicate failure information throughout the network. The working group also has specified an OAM loopback capability, which uses a special loopback cell, for verifying connectivity and diagnostic problems that AIS or FERF cells cannot. There will also be a continuity check cell that ascertains whether idle connections are still up or have failed. Whenever an ATM switch fails and a virtual path or virtual connection is interrupted, each adjacent switch in the network automatically generates an AIS cell and sends it to all downstream switches. The AIS cell alerts the other switches in the network of the failure and gives them the opportunity to devise alternate routes for virtual connections that would normally cross the failed switch. FERF cells are generated when failure disrupts only one-half of the full-duplex ATM connection that traverses several switches. If there's a failure of this k ind, traffic can still move through the network, but only in one direction. In this instance, the switch closest to the failure will generate an AIS cell and transmit it back down the network to alert the source of the failure. Then the source switch sends a FERF cell to the destination via the remaining half of the connection. This alerts the destination that its traffic is no longer getting through and an alternate connection route should be set up (see Figure 2). Figure 2: FERF's Up FERF cells are generated when failure disrupts one-half of the full-duplex ATM connection. The source switch sends a cell to the destination via the remaining half of the connection, which allows the destination to set up an alternate connection route. Another type of OAM fault management cell is used to perform a loopback verification that a VC (virtual connection) is reaching its appropriate destination. This is used in fault situations where an AIS or FERF cell would not indicate a problem, such as when a VC has been misconfigured. In this case, there would be no actual failure in the network, and traffic would get through to both source and destination-but the connection would not be between the right end points. The loopback cell, however, goes from source to destination and requires that the destination switch or end-station mark the cell and return it. The ATM Forum also has defined a fault management cell for continuity checking. When a VC is idle for a certain period of time, end-stations or switches involved in the connection can send a continuity check cell to verify that the connection is still up. Performance management cells are still being defined. Once they're ready to be used, however, they can be activated via activation/deactivation OAM cells to enable the ATM networ k to monitor its own performance. PROPRIETARY POSSIBILITIES Although it could take a few years for in-band OAM capabilities to be developed, net managers who need ATM management functions now don't necessarily have to wait for the finalization of standards. Plenty of vendors are rolling out management applications and switch capabilities that are aligned with current proposals and interim specs. Even once standards are in place, some vendor-specific management might be necessary to cover areas not addressed (such as application management and interfaces between ATM and legacy technology). Thus it's important for net managers to follow the usual rules before investing in ATM networking services or gear: Evaluate the vendor's net management strategy critically and thoroughly. There are switch vendors that now offer applications for automatically provisioning the optimal end-to-end network route throughout all intermediate segments-based on selected parameters. These application s are available on customer premises equipment (CPE), as well as in switches used in carrier networks. Peter Alexander is director of enterprise networks at Stratacom Inc. (Santa Clara, Calif.), where he oversees the enterprise ATM and network manamement product lines. Kacey Carpenter is product manager for network management products at Stratacom and is a memger of the network Management Forum. [ Home ] [ Registration | Subscriptions ] [ Contact Us | E-Mail ] Home Contact Editors Lab Tests Registration Tech Tutorials Buyer's Guide Global Networks Opinion / Columns FAQs Subscriptions