|
|
The AtmDirector software is an application in the CWSI Campus suite of network management applications. The CWSI Campus package allows you to configure, monitor, and manage a switched internetwork. The CWSI Campus package includes the following applications:
This chapter describes the AtmDirector application and how you can use it to manage Asynchronous Transfer Mode (ATM) networks. Information about ATM networks and the AtmDirector application is provided in the following sections:
You can use the AtmDirector application to perform the following tasks:
An ATM fabric is a group of interconnected switches comprised of all the ATM switches that can be discovered with the Interim Local Management Interface (ILMI) neighbor discovery mechanism, starting at the seed address. A fabric also contains the ATM end hosts connected to these switches. Switches within the ATM network must support AToM MIB (RFC 1695).
For further information on seeding, see the Getting Started with CWSI Campus publication.
You begin the discovery process by providing the IP address and community string of an ATM switch in each fabric you want to discover. These IP addresses are called seeds, and the process is called seeding. The discovery process uses the seeds as starting points to find other ATM devices and their connections. It adds the information about the discovered ATM fabrics to the CWSI Campus database and then displays the ATM network in tabular form in the AtmDirector main window (Figure 2-2). You must provide at least one seed for the discovery process to discover any devices or fabrics.
For further information on seeding, see the Getting Started with CWSI Campus publication.
The discovery process requires the supported devices to be preconfigured as follows:
For specific information about setting up any of these features, refer to the documentation for your device.
An ATM-VLAN is an implementation of virtual LANs (VLANs) for an ATM network. The ATM-VLAN uses LANE to enable existing applications to access an ATM network as if it were operating over a traditional LAN, such as Ethernet or Token Ring.
An overview of LANE (including its components), how the LANE components communicate, and the ATM-VLAN discovery process is described in the following sections:
LAN Emulation (LANE) enables existing applications to access an ATM network as if they were operating over traditional LANs, such as Ethernet or Token Ring. LANE allows LAN users to benefit from ATM without modifying end-system hardware or software. End systems on LANs can connect to other end systems on LANs, as well as to ATM-attached servers, routers, and switches.
LANE reconciles the differences between ATM and LAN protocols by masking the connection setup and handshaking functions required by the ATM switch. LANE basically bridges LAN traffic across ATM. LANE has specific hardware requirements. For details, refer to your switch or router documentation.
Each ATM-VLAN in an ATM cloud includes the following LANE components:
The LANE components communicate with each other using virtual channel connections (VCCs). The LANE components use the following VCC types:
The VCCs are used for connection setup and data transfer in three stages:
For detailed descriptions of VCCs and LANE call setup, refer to the CiscoView application and your hardware documentation.
The AtmDirector application, in conjunction with the VlanDirector application, provides discovery for the following:
The Private Network Node Interface (PNNI) protocol provides dynamic source routing for ATM internetworks that provides routing between ATM switches and groups of switches. Cisco's implementation of PNNI routing on the LightStream 1010 switch is based on the ATM Forum PNNI 1.0 specification.
The following sections provide an overview of the PNNI routing protocol for ATM networks, gives definitions for key terms used in the PNNI protocol, and describes the AtmDirector features for managing PNNI routing:
The PNNI routing protocol was designed for the following functions:
The following sections describe the main features of the PNNI protocol:
PNNI routing is based on switched virtual connections (SVCs). SVC routing requires that the signaling establish a path to a destination before the originating system sends any data on that path.
PNNI is a dynamic (not a static) routing protocol. While static routing protocols require operator intervention to accommodate network changes, dynamic routing protocols can adapt to changing network conditions by advertising their reachability and other topology state information. Cisco's implementation of PNNI on the LightStream 1010 switch can operate with the Interim Inter-switch Signaling Protocol (IISP), a static routing protocol, to provide routing among multiple peer groups.
Hop-by-hop routing computes a path using a table of "next" hops and the destination node address provided by the source node. Source routing used by PNNI uses a different method. The whole path is specified by the source node, the path information is included in the call setup message, and signaling follows the path accordingly.
PNNI supports QoS routing, which allows selection of network routes or paths based on parameters requested for the connection. Parameters such as maximum cell delay, maximum cell delay variation, and maximum cell loss ratio are combined with a user-assigned administrative weight to calculate route selection.
A PNNI topology consists of the following basic elements:
To implement dynamic source routing on ATM networks with support for QoS route selection, PNNI uses the following unique mechanisms:
These mechanisms are primarily responsible for learning, disseminating, and maintaining information about topology state, reachability, and routing metrics.
The PNNI Hello Protocol, modeled on the OSPF protocol, supports the hierarchical organization of network nodes. To discover the identity of an adjacent switch, hello packets are exchanged containing the appropriate information. If the switches discover they are members of the same peer group, they form an inside link. If they discover they are members of different peer groups, they exchange additional information and create an outside link.
After the Hello Protocol establishes that a link is functional, the adjacent switches exchange summary packets containing header information for all PNNI Topology State Elements (PTSEs) in their respective databases. Synchronizing the databases enables the switches to maintain the same view of the topology.
PNNI Topology State Packets (PTSPs) disseminate information by using the flooding mechanism. PTSPs contain the reachability, link status, and node status information needed to calculate QoS paths.
Reachability information is the first step in routing a PNNI request for a connection. The call setup message is directed to a node that advertises a prefix that matches the leading portion of the destination address. The longest matching reachable address prefix is always used. Reachable addresses can be internal or external. Internal addresses are known to PNNI to be local, for example, summary end systems attached to the switch. External addresses receive the reachability information from another source. A link to an IISP network is one example of an external address.
In addition to topological reachability information, PNNI also advertises detailed information about metrics and attributes for links. Table 1-1 describes these metrics and attributes.
| Parameter | Type | Description |
|---|---|---|
Metric | The primary metric used to compute paths. On the LightStream 1010 switch, administrative weight can be configured with two different methods: linespeed or uniform. For details, see your LightStream 1010 documentation. | |
Attribute | The amount of equivalent bandwidth currently available on the link. AvCR is the most dynamic metric. | |
Metric | The sum of the fixed-delay component across the link or node and the maximum CDV. | |
Metric | The maximum delay variation objective across a link or node for a specified service category. | |
Attribute | Ratio of the number of lost cells to the total number of cells transmitted on a link or node. | |
Attribute | Amount of bandwidth assigned to a specific traffic class on a link. |
PNNI supports scalability through a hierarchical organization of nodes into peer groups. A peer group is represented at the next level of the hierarchy as a logical group node by aggregated topology information. This information is summarized and advertised to higher and lower levels by a specially elected node called the peer group leader.
The AtmDirector application displays PNNI topologies based on the discovery of PNNI nodes and links. PNNI discovery proceeds in two phases:
Posted: Thu Sep 30 11:25:33 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.