Table of Contents

Packet Queuing
Delay in a Cell Network

Delay in Packet Frame Relay Networks

Delay at the Source
Delay at the Sink

Synchronous Data Connection Delay
Ways to Reduce Data Connection Delays
Voice Connection Delay
Maximum Hops—Voice Connections

Routing and Rerouting

Load Model
Load Model and Routing for Frame Relay
Routing Algorithm
Causes of Rerouting
Reroute Priority and Order
Courtesy Downing
System Message Traffic Routing

Bandwidth Allocation

Network Trunk Bandwidth
Voice Compression Bandwidth Requirements
VAD and DFM Effects
Data Channel Packet Generation Rates

Traffic Statistics

Connection Management

This chapter is provided for users who wish to have an in-depth knowledge of the Cisco IPX narrowband connection management functions. It describes packet queuing and the various queue types. It also discusses circuit routing and rerouting, delay for various types of connections, and circuit bandwidth requirements and utilization.

The chapter contains the following:

• Packet Queuing

• Delay in a Cell Network

• Routing and Rerouting

• Bandwidth Allocation

• Traffic Statistics

Packet Queuing

As previously discussed, packets may be created in an Cisco IPX narrowband switch by any of the following cards: NPC, CDP, SDP, LDP, or FRP. Each of these cards creates one or more different types of packets, each of which is handled separately for purposes of packet queuing in the NTC cards.

Each NTC contains a routing table in RAM to determine which packets it should take from the system bus MUXBUS for transmission on its trunk. It checks the address on each MUXBUS packet against this table and, if a match is found, it reads the packet into one of its queues. The separate queues allow the NTC to set transmission priority for different packets depending on the type of information they carry.

Packets are removed from the system bus MUXBUS in the node and queued for transmission by a trunk card. Different types and models of trunk cards support different packet types. For example, the NTC Model B support only high priority, non-timestamped, timestamped, and voice packets. The NTC Model C support all six packet types.

This is accomplished using the Credit Manager as described in the section on frame relay. In these cards, high priority packets are not subject to the credit manager scheme. The other five packet types, however, are issued credits one by one at a rate equal to the configured load of that type of packets on the trunk. Furthermore, each packet type may not receive a credit if it has not used its previous credit.

Then, as frames go by, each of these packet types is eligible to accrue credits as indicated in Table 16-1.

Delay in a Cell Network

The overall delay of information through the network includes:

Delay in Packet Frame Relay Networks

Bursty data packets are built in the FRP card as the data is received from the port. Therefore, the packetization delay is inversely proportional to the speed of the port. Essentially, the time to fill a packet is the time it takes to assemble 160 bits at the bit rate of the port. This delay is only relevant if the connection is not throttled in the FRP due to the credit manager scheme implemented there to prevent network congestion.

When designing an Cisco IPX narrowband frame relay network, the goals are to minimize delay, congestion, data loss and cost and to maximize bandwidth utilization. Minimizing delay and maximizing bandwidth utilization are usually conflicting goals.

Minimizing delay in the FRP card minimizes congestion and data loss at the source (or destination) point. However, care must be taken not to shift these problems to the network trunks. Note that the frame relay parameters that reduce delay always increase bandwidth utilization and vice versa. For instance, increasing MIR to reduce delay also increases the trunk bandwidth allocated. Or, reducing %utilization to reduce the trunk bandwidth allocated to frame relay can cause congestion in the NTC or AIT trunk cards, resulting in greater delay.

The following are a couple of general suggestions that can be applied when setting up an Cisco IPX narrowband frame relay network.

• At any given setting for port speed and connection MIR, the average queuing latency will be somewhat less in the FRP than in an access device. So, settings that move queuing delay from the access device to the FRP will generally lead to an improvement.

• Frames broken up into FastPackets move more quickly through the NTC/AiT trunk queues and trunks than they do through the connection virtual circuit queue (VC Q). So settings that move data more quickly onto the trunks are preferred.

Delay at the Source

Delay in the most common devices sending frames to the FRP (e.g. bridges, routers, etc.) follow the standard store-and-forward model for simple queues. This delay is changed by changing the port speed parameter (configured clock in cnfrport command). For a given amount of traffic, increasing port speed reduces delay in the access device.

However, when modifying port speed, delay in the access device must be considered in conjunction with delay in the FRP. Increasing port speed and holding MIN constant will increase delay in the FRP for that connection. While this produces a small overall reduction in delay, it also moves delay to the FRP where there is more control over it.

Delay in the FRP can be controlled by modifying MIR, Cmax, and VC Q depth. For a given amount of traffic, the greater value for MIR, the less the delay in the source FRP. Likewise, if MIR is less than the setting for port speed, the larger Cmax is, the smaller the delay. Increasing Cmax has the same effect on delay as increasing MIR. However, large Cmax can cause occasional congestion on the trunks. The value for VC Q depth sets the maximum allowable delay in the source FRP. But reducing this may result in discarded frames, which is generally unacceptable.

Delay in the Network

There are two primary sources of frame relay connection delay in the Cisco IPX narrowband switch network:

• intermediate node delay

• propagation delay

Intermediate node delay consists of processing, queuing, and transmit delay and is generally one to two milliseconds per hop even in a heavily loaded network. Even on a 10-hop connection, this delay would be under 20 milliseconds. This is assuming that care has been taken to prevent data loss that can significantly increase overall delay.

Propagation delay is generally small except in international networks. At roughly one millisecond per 100 miles, propagation delay on a 2600 mile connection (e.g. San Francisco to Boston) would be about 26 milliseconds.

If several of the connections on a trunk have large values for Cmax (on the order of 100 or more), then the possibility of short-term congestion arises. If all connections burst at once, the bursty data queue in the NTC or AIT will get very long. However, this condition should normally be of a short duration.

The connection utilization parameter, %utl, controls bandwidth allocation for frame relay connections on the trunks. Oversubscription, where the bandwidth allocated is significantly less than the connection MIR values, can allow trunks to become overloaded. This can result in congestion and data loss over network trunks resulting in significant increases in end-user delays.

Delay at the Sink

The sink FRP is the card that sends frames to the destination access device. Generally, delay in the sink FRP follows the same model as delay in the access device. However, if the sink access device is attached to a LAN, then increasing port speed can significantly reduce delay in the sink FRP without significantly increasing delay in the access device.

Another method for decreasing delay at the terminating FRP for selected connections is to assign a high priority to these connections. Frames for high priority connections are assembled in a separate output port queue from low priority connections. All frames in the high priority queue are transmitted before any frames are transmitted from the low priority queue.

Care should be taken when reducing the Port Queue Depth parameter in the cnfrport command as this could result in unnecessarily dropping frames if this queue should overflow. Where the sink FRP receives traffic from only one source and has a port speed that is greater or equal to the MIR, the queuing delay does not follow the normal model and is very small.

Synchronous Data Connection Delay

For all time-stamped and non-timestamped data packets, the number of information bytes in a packet varies from 4 to 21 bytes depending on the type and speed of the connection. The packetization delay for the two types of data packets can be calculated by using Table 16-2 or Table 16-3 or looked up in the tables at the end of this chapter.

There is a delay from the first information byte clocked into the packet buffer to the last. The lower the bit rate of the channel, the longer the packetizing delay would become. To keep this time low, packets are formed from as few as 4 bytes of information for low-speed channels. This, and the time necessary for the card's firmware to add address, priority, DFM and timestamp information to the buffer, constitutes packetization delay. The packet is then placed on the system bus.

In the SDP, non-timestamped packets are received for a particular channel, the header is discarded and the information placed in a flexible buffer. When the connection is first set up, the buffer is half-filled. This allows variations in transmission delay to be accommodated until the buffer overflows or underflows. It also allows for short-term variations in the clocks at the transmitting and receiving interfaces.

Timestamped packets are buffered in the receiving SDP until the timestamp has reached the maximum age set in the Configure System Parameter (cnfsysparm) command, then clocked out. Therefore all timestamped connections have a one-way delay approximately equal to the "maximum timestamped packet age" set in the Configure System Parameter command plus packetization and transmission delays.

EIA lead information (non-interleaved) and clock-speed information (isochronous connections) is sent in supervisory packets, SDP to SDP. These packets appear to the network like the data packets of the same connection. Therefore, their delay through the network should be the same as the data stream. However, because they are sampled asynchronously and packetized and depacketized through different paths of the SDP, their changes are time-shifted with respect to the data.

Ways to Reduce Data Connection Delays

Normally, data circuit delay is not a problem. For some user data devices transmitting over large networks, the data delay may appear to cause some minor problems. The following are several suggestions for reducing the network delay.

• Make sure connections take the shortest route (number of hops trades off against transmission distance).

• If many connections are sharing a trunk, there may be queuing delays in the transmitting trunk card. Reroute connections to balance the load through the network.

• Raise the baud rate or configure interleaved EIA.

• Reduce the "maximum timestamped packet age" (trade-off against dropped packets).

• Increase the "preage" value (trade-off against dropped packets).

• For EIA leads, increase the update rate or configure the connection with interleaved EIA. This is affected by "maximum timestamped packet age" for the network, and "time-stamp preaging" for the connection

Voice Connection Delay

Non-VAD voice packets

For a voice channel without VAD ("p", "d" or "a"), the packetization delay is constant. It is the time for 21 bytes or 42 bytes to be processed by the CDP or 2.625 msecs for a "p" connection and
5.25 msecs for an "a32" connection.

VAD voice packets

For a voice channel with VAD ("v" or "c"), there is a VAD software parameter, sample input delay (SID) that defines the size of a serial register in the CDP. This adjusts "front end clipping" but increases the end-to-end delay of the connection by the amount of buffer delay.

Transmission delay across a trunk is generally a function of the distance travelled. For a terrestrial trunk, signals travel an average of about 100 miles per millisecond, or 0.01 msec/mile. For a satellite trunk, the propagation delay of the signal to the satellite and back adds approximately 300 msec per satellite hop. Table 16-4 can be used to calculate delay for the four types of voice connections.

Table 16-5 illustrates some typical expected delays for various number of terrestrial hops. The calculations do not include any PBX or channel bank delay.

Maximum Hops—Voice Connections

With the NTC, as the number of hops for a connection increases, the possible fluctuation in delay increases also. This is because each NTC in the path may add delay up to the maximum allowed by the queuing parameters, depending on the other traffic passing over that trunk. The CDP has a large buffer so the buffer size does not limit the maximum number of hops for a voice connection.

Routing and Rerouting

This section discusses how the Cisco IPX narrowband switch determines the route each circuit takes when added to the network and the algorithms and considerations involved when the Cisco IPX narrowband switch must automatically reroute circuits because of a failure(s) detected in the network.

Load Model

The Cisco IPX narrowband switch maintains a load model of the network and uses it to make decisions for routing and failing to route connections. The inputs to this model are the number and type of all connections routed on each trunk, and the configured utilization figures for VAD and DFM connections (measured as a percent of nominal connection bandwidth).

These utilization figures are set by the network administrator. Defaults are 40 percent for VAD and 100 percent for DFM and frame relay. It is these figures that are used to determine how many connections may be routed over a trunk, and when no more bandwidth is available. This is without reference to the "real world" performance of VAD and DFM and frame relay.

The challenge of network optimization is to make these configured utilizations reflect reality, in order to gain the maximum possible E1 or T1 pair gain, and to predict and influence the performance of the network in extreme cases of trunk failures or unfavorable statistics.

Load Model and Routing for Frame Relay

Frame relay connections differ from others because they have a greater range of instantaneous packet rates. A connection with a minimum rate of 512 Kbps may generate no packets for a long time, then suddenly generate 10 or 20 packets in a row (depending on the value of Cmax) at the frame relay port speed.

Since the connection has accepted data and processed it through the FRP card very quickly, and since the delay across the connection depends directly on the queuing delay of the last packet in the frame, it is important to ensure there are no unnecessary bottlenecks in the network trunking.

When the first frame relay connection is routed over the trunk, the load model in software allocates the entire bursty data peak bandwidth. This is important for networks mixing frame relay with other traffic, as it ensures that when a frame relay burst reaches the Cisco IPX narrowband trunk card, the bandwidth available is at least the bursty data peak.

As more frame relay connections are routed over the same trunk, the statistical addition of the different sources allows them to share bandwidth more efficiently. Because of this, the user can allocate only a portion of the trunk bandwidth required for each new frame relay connection added (the default is 121%, which equates to 100% usage for user data and the remainder for the overhead of encapsulating the frame relay data into FastPackets). This oversubscription of bandwidth is can also be extended to the Cisco IPX narrowband switch MUXBUS bandwidth reserved for each FRP. This factor can be decreased for slots where there are many PVCs transmitting at lower rates (e.g. 56 Kbps and less).

The routing algorithm (using frame relay optimization) allocates routes for new connections to minimize extra bandwidth allocation, and so tends to route frame relay connections over the same trunks that the earlier connection took. This results in good bandwidth efficiency.

A priority (high/low) can be assigned each ForeSight frame relay connection as it is added to the network. High priority connections are routed through a separate transmit queue in the FRP receiving the packets. The frames in the high priority queue are output before frames in the low priority queue. This reduces the queuing delay for these frames.

ForeSight is a closed-loop system that dynamically allocates trunk bandwidth based on the connection parameters set. If there is any excess bandwidth available after all the committed information rates have been satisfied, it will portion out the excess bandwidth based on each connection's CIR.

Routing Algorithm

Each node has, in a database, a representation of the network topology. This includes all trunks and their status, and all connections, their type and route. From this, the node calculates the load (packets/sec or cells/sec) on all trunks in the network.

When a connection is routed, the owner node determines the bandwidth requirements from lookup tables and the destination node and channel from the network database. If the connection has a preferred route (direct routing), it will attempt to comply if at all possible. The routing can also be specified by the operator to be restricted to a terrestrial route only or if a satellite route is acceptable.

The search for a circuit route is begun by first examining all trunks to adjacent nodes (in order of trunk number). If the route has enough bandwidth for the circuit (or bundle), and the terminating node is found to be the other end of the connection, the route has been found and the search is terminated. Otherwise, the search is continued.

When all single-hop routes have been examined but found lacking, the search is extended to nodes at a distance of two hops. The search radius is enlarged from the master node. Eventually, the search is successful, or completes without success, or the search times out without success. If a preferred route is specified and is unavailable for a connection that has directed routing, the connection will be marked immediately as failed.

When a search is successful, the route information (trunks and nodes on the path) is broadcast to all nodes on the chosen route so they can update their network topology models in their database.

The network does not continually look for new routes unless there are connections failed for lack of a route. If this is the case, the addition of trunks or deletion of connections is necessary. The network does not rearrange connections that are already routed to accommodate a connection that is not routed, even though the new connection may have a high priority Class of Service.

Likewise, if the statistical reserve on trunks is decreased, the network takes no action except to route any failed connections that can now be routed. However, if statistical reserve is increased, all connections in the network will be failed and rerouted as some previously used routes may no longer be available.

The Cisco IPX narrowband switch attempts to balance loads between trunks. This allows the adaptive voice feature to give better results, but affects all connections. The reroute algorithm finds all routes with the shortest hop count. It chooses the route where the current load on the most heavily loaded line of the route is a minimum. In order to force even balancing, the size of a routing bundle is restricted.

When a connection is first added to the network, software identifies the first route available in the usual way, finding the fewest hops given restrictions of trunk type (satellite/terrestrial) and current loading (there must be bandwidth available). It then finds all other routes of the same number of hops and chooses the route with the lowest loading factor.

Causes of Rerouting

The Cisco IPX narrowband switch does not move connections from existing routes unless one of the following conditions exists:

• The current route fails (i.e. trunk failure).

• Some other cause (i.e. card, circuit line) fails the connection, then clears.

• Parameters affecting permitted trunk loading (i.e. statistical reserve) are changed so as to reduce the bandwidth available for connections.

• The circuit has been "bumped" or preempted by a higher priority circuit where bandwidth is limited.

It is important to realize that the algorithm does not move working connections between trunks to balance load: the balancing occurs when a connection without a route is allocated one. A working connection is rerouted when its preferred route (when different from the current route) becomes available.

Reroute Priority and Order

For every connection, there is a master node (the owner). This node, where the connection was added is responsible for finding a route and rerouting the connection in the event of a failure. Master nodes act independently. If a trunk fails in a network, all nodes owning connections routed over that line recognize the failure since the information is broadcast to all nodes in the network. As each node recognizes the failure it attempts to reroute its connections without reference to the others.

For this reason, it is recommended that ownership of connections be concentrated in a small number of nodes. There will be fewer collisions in rerouting, and, since the class-of-service priority is followed within each node but not coordinated between nodes, performance will be more predictable and closer to that desired.

Within each node, the order of precedence for routing connections is determined by:

• COS—Connections with the lowest class-of-service (COS) are considered first. (Lowest number = highest priority.) There is a pause of 250 msec between each COS, to improve the network-wide effects of COS.

• Bandwidth—Connections with the highest bandwidth are considered first. When bandwidth on trunks is limited, it is easier to route a small bandwidth connection than a large one. Data connections vary in bandwidth, but the order is "p", "d", "a", "v", "c" for voice.

• Bundle size—Bundles are routed without being split, if possible. This makes the operation quicker, and fewer individual routes need to be found. If no route is available for the bundle, it will be split into single connections and the search repeated for each.

After the COS timer, priority is given to connections with the highest bandwidth (packets/second) of the group awaiting rerouting. This is because, as available bandwidth diminishes, it is more difficult to find routes for the higher bandwidth connections. The data block for each connection contains the packet/second requirement, so prioritizing is easy. The general rerouting priority order is given in Table 16-6.

When several similar connections have the same source and destination node, they can be routed as a bundle. This saves time, as only one route is found for several connections. Bundle size is the least important rerouting priority.

Courtesy Downing

Courtesy downing is the process of monitoring voice connections and downing those connections that are configured for downing when they go inactive. This frees up network bandwidth for other uses, generally for bandwidth reservation.

Only voice type connections can be monitored for inactivity, and then only when the on-hook status is configured by the user. All other connection types and voice types with no defined on-hook status are treated as active and cannot be courtesy downed.

System Message Traffic Routing

System messages are carried between node controller cards (NPC and BCC) in high priority packets called CC packets. The route used by any pair of controller cards to communicate is determined automatically by the network and is fixed as long as there are no changes to the network topology that affect the choice.

Bandwidth Allocation

One of the benefits of the Cisco IPX narrowband network is the compression of voice (VAD) and data (DFM) connections to allow cost savings through pair-gain. However, these features both depend on statistical properties of the data offered to the system. Therefore, their exact level of effectiveness is not easily predicted. VAD may result in a 0 percent to 70 percent bandwidth savings, for instance, whereas the effectiveness of ADPCM, (50 percent savings for 32 Kbps ADPCM), is predictable and unchanging.

Since the total traffic capacity of an Cisco IPX narrowband network is somewhat difficult to predict, Cisco has developed a Network Modeling Tool (NMT). This tool allows users to analyze their proposed networks to determine if there will be sufficient capacity available. For further information on the NMT, refer to the Network Modeling Tool User's Guide.

Network Trunk Bandwidth

The system calculates the available bandwidth of each network trunk as follows:

T3 Framed:

• The available T3 trunk bandwidth is 44.736 Mbps minus framing and overhead.

• Each PLCP frame carries 53 eight-bit cells that occur at an 8 Khz rate for a total of 40.704 Mbps of user data, equivalent to 96,000 cells/sec.

• Each cell can transport up to two FastPackets for a rate of 192,000 FastPackets/sec.

• T3 trunks terminating on Cisco IPX narrowband switches are limited to 80,000 FastPackets/sec. This allocation is half of the IPX MUXBUS capacity.

E3 Framed:

• The available E3 trunk bandwidth is 34.368 Mbps minus framing and overhead.

• Each ITU-T G.804 frame carries 530 payload octets that occur at an 8 Khz rate for a total of 33.920 Mbps of user data.

• The G.804 E3 frame can transmit 10 ATM cells per frame at 8000 frames/sec. or 80,000 cells per second.

T1 Framed:

• The available trunk bandwidth is 1.544 Mbps - 8 Kbps framing = 1.536 Mbps.

• Framed T1 lines can carry 1.536 Mbps / 192 bits/packet = 8,000 packets/sec.

• The available trunk bandwidth is 2.048 Mbps - 64 Kbps framing = 1.984 Mbps.

• Framed E1 lines can carry 1.984 Mbps / 192 = 10,333 packets/sec.

• The available bandwidth is 2.048 Mbps.

• Unframed E1 lines carry 2.048 Mbps / 192 = 10,666 packets/sec.

Depends on the number of DS0's available in the subrate trunk. See Table 16-7.

---

Note   It is recommended that a subrate trunk be configured with at least four DS0s to provide sufficient statistical reserve for inter-node communications traffic.

---

A packet slice on the TDM bus is 1000 packets/sec, therefore an E1 trunk requires 11 packet slices of TDM bandwidth for a total of 11,000 packets/sec per E1 trunk. The T1 trunk requires 8 packet slices for a total of 8,000 packets/sec. per T1 trunk.

The total bandwidth available on the Cisco IPX narrowband switch backplane MUXBUS, excluding NPC-reserved bandwidth, is 30.72 Mbps. This corresponds to 30.72 Mbps / 192 = 160,000 packets/sec. Therefore, the maximum number of E1 trunks in a node is 160,000 / 11,000 = 14. The maximum number of T1 trunks per node is 160,000 / 8,000 = 20. However, software limits this to 16 trunks.

Each 64 Kbps time slot, or DS0, provides 1/3 X 1000 or approximately 333 packets per second of available bandwidth on a trunk. Table 16-7 shows the packet bandwidth available on a subrate trunk as a function of the number of DS0s regardless of the trunk type.

Voice Compression Bandwidth Requirements

The bandwidth required on a trunk to carry the information on a DS0 circuit depends on which one of the five compression types is selected for the circuit as indicated in Table 16-8. The equivalent bit rate after compression is also listed in this table.

Compression is an effective means of reducing the network bandwidth requirements but does degrade the quality of the voice circuit. Note, however, that any circuit that may at times have a fast modem or FAX connection will automatically revert to a "p" connection during the transmission with attendant increase in bandwidth required.

VAD and DFM Effects

Voice activity detection takes place in the CDP card before speech is transmitted over a trunk. If speech is present, packets are sent. If speech is not present, no packets are sent and the trunk bandwidth may be used by other connections.

Similarly, DFM allows packets whose contents can be predicted by the receiving card, those containing repetitive patterns, to be suppressed. It should be noted that a DFM packet uses one more byte for control information (sequence byte) than the packet for a corresponding non-DFM connection. If the data cannot be compressed to less than 90 percent utilization by DFM, bandwidth savings will be made by disabling DFM for that connection.

Before the development at Cisco of statistical tools, VAD was assumed to save 60 percent of nominal bandwidth. Experience has shown this to be a good estimate in most cases. But if a connection is not off-hook all the time (less than 36 ccs/hr) this estimate may be too high. Likewise, if there is high background noise on the circuit, this estimate may be too low.

With new statistical tools provided by Cisco WAN Manager NMS, this utilization can now be measured on an active network. Voice and data compression can be treated in similar ways. For effective traffic studies, it is necessary to configure utilization figures for voice in the same way as data and this section treats both forms of compression similarly.

Data Channel Packet Generation Rates

The synchronous data channels use widely varying amounts of trunk bandwidth depending on whether they use timestamped data packets or not and how the control lead information is carried. Refer to Table 16-9 through Table 16-13 for bandwidth requirements or calculate as follows.

• Timestamped data packets, 8/8 coded, not fast EIA, have 160 data bits per packet.

• Timestamped data packets, 7/8 coded, not fast EIA, have 140 data bits per packet.

• Non-timestamped data packets, 8/8 coded, not fast EIA, have 168 data bits per packet.

• Non-timestamped data packets, 7/8 coded, not fast EIA, have 147 data bits per packet.

• Fast EIA packets, 8/8 coded, have 80 data bits per packet.

• Fast EIA packets, 7/8 coded, have 70 data bits per packet.

• DFM packets, 8/8 coded have 152 data bits per packet.

• DFM packets, 7/8 coded have 133 data bits per packet.

Exceptions are the low-speed connections listed in Table 16-11, Table 16-12, and Table 16-13, where partially-filled packets are used to reduce packetization delay. Divide the bit rate of the connection by the number of user bits per packet and the result is the number of packets/second.

For DFM connections, the actual packet generation rate will depend upon the actual utilization. The load model uses the user-configured utilization to calculate the expected number of packets/second. Add between 0 and 20 packets/second for EIA updates (an isochronous clock implies 20 packets/second in the direction the clock is propagated).

Traffic Statistics

The Cisco IGX multiband switch provides a number of statistical tools to assist in traffic studies. The object of such a study is to collect enough information so that an accurate figure for configured utilization may be chosen for each connection. The display of Cisco IGX multiband switch statistics requires a Cisco WAN Manager workstation connection to the Cisco IGX multiband switch network. The Cisco WAN Manager collects all of the operating statistics for a network and stores it in its database (usually on its own hard disk). Refer to the Cisco WAN Manager Operations publication for details of statistics displays and examples.

Posted: Tue Jan 16 11:03:22 PST 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.