Table of Contents

Basic ATM Connection Procedure
Traffic Management Overview

Standard Available Bit Rate
VSVD Description
BXM Connections
ForeSight Congestion Control

ATM Connection Requirements

Overview of Procedure to add ATM Connections
Connection Routing
addcon Command Syntax

addcon Example

ATM Connection Flow

ATM Connection Flow through the BPX
Advanced CoS Management
Connection Flow Example

Ingress from CPE 1 to BXM 3
Egress to Network via BXM 10
Ingress from Network via BXM 5
Egress from BXM 11 to CPE 2

Traffic Shaping for CBR, rt-VBR, nrt-VBR, and UBR

Traffic Shaping Rates
Configuration

rt-VBR and nrt-VBR Connections

Configuring VBR connections
Connection Criteria
Configuring Connection Policing
Configuring Resources

Trunk Queues for rt-VBR and nrt-VBR
Port Queues for rt-VBR and nrt-VBR

Related Switch Software Commands

ATM Connection Configuration

Adjust Minimum SCR and PCR
Constant Bit Rate Connections
Variable Bit Rate Connections

Connection Criteria for real-time VBR and non-real-time VBR Connections

Available Bit Rate Connections
Available Bit Rate Standard Connections
Available Bit Rate Foresight Connections
Unspecified Bit Rate Connections
Network and Service Interworking Notes
ATM-to-Frame Relay Network Interworking Connections
Frame Relay-to-ATM Foresight Network Interworking Connection
Frame Relay-to-ATM Transparent Service Interworking Connections
Frame Relay-to-ATM Foresight Transparent Service Interworking Connections
Frame Relay-to-ATM Translational Service Interworking Connections
Frame Relay-to-ATM Foresight Translational Service Interworking Connections

Traffic Policing Examples

Dual-Leaky Bucket (An Analogy)
CBR Traffic Policing Examples
Variable Bit Rate Dual-Leaky Bucket Policing Examples

Leaky Bucket 1
Leaky Bucket 2
Examples

ABR Connection Policing
UBR Connection Policing

Leaky Bucket 1
Leaky Bucket 2

Local Management Interface and Integrated Local Management Interface Parameters

Early Abit Notification with Configurable Timer on ILMI/LMI Interface
Configuring Early Abit Notification

Recommended Settings
Behavior with Previous Releases
Performance Considerations

ATM Command List

Configuring ATM Connections

This chapter explains how to establish ATM connection services by adding ATM connections between ATM service interface ports in the network using ATM standard UNI 3.1 and Traffic Management 4.0:

• ATM Connection Services

• Basic ATM Connection Procedure

• Traffic Management Overview

You establish ATM connection services by adding ATM connections between ATM service interface ports in the network.

Figure 21-1 depicts ATM connections over a BPX switch network, via BXM-T3/E3, BXM-155, BXM-622, as well as over MGX 8220 switches. It also shows Frame Relay to ATM interworking connections over the MGX 8220 and IGX shelves.

Basic ATM Connection Procedure

To set up an ATM connection, perform these steps:

Step 2   Activate the ATM port by using the upport X.X command, where
X.X is the slot and port of the ATM card set.

Step 3   Use the cnfport command to establish the characteristics for the ATM port.

Step 4   If a suitable class is already configured, note its number and use this class when adding the ATM connection by using the addcon command. (The dspcls command displays the parameters for each connection class. The cnfcls command allows you to modify an individual class.)

Step 5   Use the vt command to log in to the node at the remote end of the proposed ATM connection.

Step 6   At the remote node, use the upln, upport, and cnfport commands, as listed in steps 1 and 2, to activate and configure the remote port.

Step 7   Use the addcon command at one end of the connection to activate the ATM connection.

Traffic Management Overview

The ATM Forum Traffic Management 4.0 Specification defines five basic traffic classes:

• CBR (Constant Bit Rate)

• rt-VBR (Real-Time Variable Bit Rate)

• nrt-VBR (Non-Real Time Variable Bit Rate)

• UBR (Unspecified Bit Rate)

• ABR (Available Bit Rate)

Table 21-1 summarizes the major attributes of each of the traffic management classes:

Standard Available Bit Rate

Standard ABR uses RM (Resource Management) cells to carry feedback information back to the connection's source from the connection's destination.

ABR sources periodically interleave RM cells into the data they are transmitting. These RM cells are called forward RM cells because they travel in the same direction as the data. At the destination these cells are turned around and sent back to the source as Backward RM cells.

The RM cells contain fields to increase or decrease the rate (the CI and NI fields) or set it at a particular value (the explicit rate ER field). The intervening switches may adjust these fields according to network conditions. When the source receives an RM cell it must adjust its rate in response to the setting of these fields.

VSVD Description

ABR sources and destinations are linked via bi-directional connections, and each connection termination point is both a source and a destination; a source for data that it is transmitting, and a destination for data that it is receiving. The forward direction is defined as from source to destination, and the backward direction is defined as from destination to source.

Figure 21-2 shows the data cell flow in the forward direction from a source to its destination along with its associated control loop. The control loop consists of two RM cell flows, one in the forward direction (from source to destination) and the other in the backward direction (from destination to source).

The data cell flow in the backward direction from destination to source is not shown, nor are the associated RM cell flows. However, these flows are just the opposite of that shown in the diagram for forward data cell flows.

A source generates forward RM cells which are turned around by the destination and returned to the source as backward RM-cells. These backward RM-cells may carry feedback information from the network elements and/or the destination back to the source.

The parameter Nrm is defined as the maximum number of cells a source may send for each forward RM cell, that is, one RM cell must be sent for every Nrm-1 data cells. Also, in the absence of Nrm-1 data cells, as an upper bound on the time between forward RM cells for an active source, an RM cell must be sent at least once every Trm msecs.

BXM Connections

The BXM-T3/E3, BXM-155, and BXM-622 cards support ATM Traffic Management 4.0.

The BXM cards are designed to support all the following service classes:

• Constant Bit Rate (CBR)

• real time Variable Bit Rate (rt-VBR)

• non-real time Variable Bit Rate (nrt-VBR)

• Available Bit Rate (ABR with VSVD

• ABR without VSVD, and ABR using ForeSight)

• Unspecified Bit Rate (UBR)

ABR with VSVD supports explicit rate marking and Congestion Indication (CI) control.

ForeSight Congestion Control

The ForeSight feature is a proprietary dynamic closed-loop, rate-based, congestion management feature that yields bandwidth savings compared to non-ForeSight equipped trunks when transmitting bursty data across cell-based networks.

ATM Connection Requirements

Two connection addressing modes are supported:

• You may enter a unique VPI/VCI address in which case the BPX switch functions as a virtual circuit switch.

• You may enter only a VPI address in which case all circuits are switched to the same destination port and the BPX switch functions as a virtual path switch in this case.

The full ATM address range for VPI and VCI is supported.Virtual Path Connections are identified by an * in the VCI field. Virtual Circuit Connections specify both the VPI and VCI fields.

The VPI and VCI fields have significance only to the local BPX switch, and are translated by tables in the BPX switch to route the connection. Connections are automatically routed by the AutoRoute feature once the connection endpoints are specified.

You can add ATM connections by using either the Cisco WAN Manager Connection Manager or a node's command line interface (CLI). Typically, the Cisco WAN Manager Connection Manager is the preferred method because it has an easy to use GUI interface. The CLI may be the method of choice in some special cases or during initial node setup for local nodes.

Overview of Procedure to add ATM Connections

In general, to add ATM connections:

Step 2   Configure the trunks across the network appropriately for the type of connection.

Step 3   Use the addcon command to add a connection, first specifying the service type and then the appropriate parameters for the connection.

For example, when configuring a BXM for CPE connections:

Step 2   Up a line by using the upln command

Step 3   Configure the line by using the cnfln command.

Step 4   Configure the associated port by using the cnfport command

Step 5   Up the associated port by using the upport command.

Step 6   Then add the ATM connections by using the addcon command.

Connection Routing

ATM connections for a BXM card are identified by these numbers:

• slot number (in the BPX switch shelf where the BXM is located)

• port number (one of the ATM ports on the BXM)

• Virtual Path Identifier (VPI)

• Virtual Circuit Identifier (VCI) - (* for virtual path connections)

The slot and port are related to the BPX switch hardware.

Virtual path connections (VPCs) are identified by a "*" for the VCI field.

Virtual circuit connections (VCCs) are identified by both a VPI and VCI field.

Connections added to the network are automatically routed once the end points are specified. This AutoRoute feature is standard with all BPX and IGX switches. The network automatically detects trunk failures and routes connections around the failures.

addcon Command Syntax

Enter the following parameters for the BXM addcon command. Depending upon the connection type, you are prompted for the appropriate parameters as shown:

Note   The range of VPIs and VCIs reserved for PVC traffic and SVC traffic is configurable using the cnfport command. While adding connections, the system checks the entered VPI/VPC against the range reserved for SVC traffic. If there is a conflict, the addcon command fails with the message "VPI/VCI on selected port is reserved at local/remote end".

addcon Example

The following example shows the initial steps in adding a connection with the addcon command, and the addcon prompt requesting the user to enter the ATM type of service.

Instead of entering a class of service, you can instead enter a class number to select a pre-configured template, for example, class 4 for NTR-VBR, and class 3 for RT-VBR. You can modify the class of service templates as required by using the cnfcls/cnfatmcls command and displaying them by using the dspcls/dspatmcls command.

Note   For a new node running 9.2.20 or later, the rt-VBR connection class number is 3. An upgraded node will retain existing connection classes. Therefore, it won't have the rt-VBR connection class 3. However, the user can configure the connection classes to whatever service and parameters they want using the cnfcls/cnfatmcls command.

An example of a cnfcls/cnfatmcls command and response is shown in the following example:

ATM Connection Flow

ATM Connection Flow through the BPX

The BPX supports the standard ATM service types, CBR, rt-VBR, nrt-VBR, ABR, and UBR. When adding a connection by using the addcon command, you select these service types by entering one of the CLI service type entries shown in Table 21-2 when prompted:

The BPX also supports ATM to Frame Relay Network Interworking and Service Interworking connections. When adding a connection by using the addcon command, you select these service types by entering one of the CLI service type entries shown in Table 21-3 when prompted:

Advanced CoS Management

Advanced CoS management provides per-VC queueing and per-VC scheduling. CoS management provides fairness between connections and firewalls between connections. Firewalls prevent a single non-compliant connection from affecting the QoS of compliant connections. The non-compliant connection simply overflows its own buffer.

The cells received by a port are not automatically transmitted by that port out to the network trunks at the port access rate. Each VC is assigned its own ingress queue that buffers the connection at the entry to the network. With ABR with VSVD or with Optimized Bandwidth Management (ForeSight), the service rate can be adjusted up and down depending on network congestion.

Network queues buffer the data at the trunk interfaces throughout the network according to the connection's class of service. Service classes are defined by standards-based QoS. Classes can consist of the five service classes defined in the ATM standards as well as multiple sub-classes to each of these classes. Classes can range from constant bit rate services with minimal cell delay variation to variable bit rates with less stringent cell delay.

When cells are received from the network for transmission out a port, egress queues at that port provide additional buffering based on the service class of the connection.

CoS Management provides an effective means of managing the quality of service defined for various types of traffic. It permits network operators to segregate traffic to provide more control over the way that network capacity is divided among users. This is especially important when there are multiple user services on one network.

Rather than limiting the user to the five broad classes of service defined by the ATM standards committees, CoS management can provide up to 16 classes of service (service subclasses) that can be further defined by the user and assigned to connections. Some of the CoS parameters that may be assigned include:

• Minimum bandwidth guarantee per subclass to assure that one type of traffic will not be preempted by another

• Maximum bandwidth ceiling to limit the percentage of the total network bandwidth that any one class can utilize

• Queue depths to limit the delay

• Discard threshold per subclass

These class of service parameters are based on the standards-based Quality of Service parameters and are software programmable by the user. The BPX switch provides separate queues for each traffic class.

Connection Flow Example

The example shown in Figure 21-3 shows the general ATM connection flow through BXM cards in BPX switches. The cnfport, cnfportq, cnfln, cnftrk, and cnftrkparm commands are used to configure resources affecting the traffic flow of a connection. Examples are described in Traffic Shaping for CBR, rt-VBR, nrt-VBR, and UBR.

Ingress from CPE 1 to BXM 3

ATM cells from CPE 1 that are applied to BXM 3, Figure 21-3, are processed at the physical level, policed per individual VC based on ATM header payload type, and routed to the applicable one of 15 per card slot servers, each of which contains 16 CoS service queues, including ATM service types CBR, rt-VBR, nrt-VBR, ABR, and UBR.

ATM cells undergoing traffic shaping, for example, ABR cells are applied to traffic shaping queues before going to one of the 15 per card slot servers. ATM cells applied to the traffic shaping queues receive additional processing, including congestion control by means of VSVD or ForeSight and virtual connection queuing.

Cells are served out from the slot servers via the BPX backplane to the BCC crosspoint switch. The cells are served out on a fair basis with priority based on class of service, time in queue, bandwidth requirements, and so on.

Note   For a description of traffic shaping on CBR, rt-VBR, nrt-VBR, and UBR connections, refer to the section later in this chapter, Traffic Shaping for CBR, rt-VBR, nrt-VBR, and UBR.

Egress to Network via BXM 10

In this example, ATM cells destined for BPX 2 are applied via the BCC crosspoint switch and BPX backplane to BXM 10 and out to the network. The cells are served out to the network via the appropriate trunk qbin, CBR, rt-VBR, nrt-VBR, ABR, or UBR.

Ingress from Network via BXM 5

ATM cells from the network that are applied to BXM 5 in BPX 2 are processed at the physical level and routed to one of 15 per card slot servers, each of which contains 16 CoS service queues, including ATM service types CBR, rt-VBR, nrt-VBR, ABR, and UBR.

Cells are served out from the slot servers via the BPX backplane to the BCC crosspoint switch. The cells are served out on a fair basis with priority based on class of service, time in queue, bandwidth requirements, etc.

Egress from BXM 11 to CPE 2

In this example, ATM cells destined for CPE 2 are applied via the BCC crosspoint switch and BPX backplane to BXM 11 and out to CPE 2. The cells are served out to CPE 2 via the appropriate port qbin, CBR, rt-VBR, nrt-VBR, or ABR/UBR.

ATM cells undergoing traffic shaping, for example ABR cells are applied to traffic shaping queues before going to one of the 15 per card slot servers. ATM cells applied to the traffic shaping queues receive additional processing, including congestion control by means of VSVD or ForeSight and virtual connection queuing.

Traffic Shaping for CBR, rt-VBR, nrt-VBR, and UBR

With the introduction of traffic shaping for CBR, VBR, and UBR, you have the option to provide traffic shaping for these connections types on the BXM. Previously, only ABR utilized traffic shaping. Traffic shaping involves passing CBR, VBR, or UBR traffic streams through VC queues for scheduled rate shaping.

Traffic shaping is performed on a per port basis. When traffic shaping is enabled, all traffic exiting the port (out to the network) is subject to VC scheduling based on the parameters you configure for the connection.

Figure 21-4 shows an example of traffic shaping. In this example, port 1 is configured to perform traffic shaping.

Note that all the ATM cells regardless of class of service pass through the VC queues before leaving the card when traffic shaping is enabled. In the example, port 2 is not configured for traffic shaping, and only the ABR traffic with FCES (flow control external segment) passes through the VC queues.

Traffic Shaping Rates

Traffic shaping rates are listed in Table 21-4.

Configuration

Traffic shaping is disabled by default.

Use the cnfport and cnfln command to enable and disable the function on a per port basis.

Use the cnftrk command to enable traffic shaping on trunks.

No connections should be enabled on the port prior to changing the port traffic shaping parameter. If there are existing connections when the port is toggled, then these connections will not be updated unless the card is reset, connections are rerouted, a switchcc occurs, or you modify the connection parameters.

See the following examples of the cnfln, cnfport, and cnftrk commands:

Example of cnfln:

Example of cnfport:

Example of cnftrk:

rt-VBR and nrt-VBR Connections

VBR (variable bit rate) connections may be classified as either:

• real time (rt-VBR)
  This category is used for connections that transmit at a rate varying with time and that can be described as bursty, often requiring large amounts of bandwidth when active. The rt-VBR class is intended for applications that require tightly constrained delay and delay variation such as compressed voice video conferencing—for example, video conferencing which requires real-time data transfer with bandwidth requirements that can vary in proportion to the dynamics of the video image at any given time. The rt-VBR category is characterized in terms of PCR, SCR (sustained cell rate), and MBS (maximum burst size).

• non-real time (nrt-VBR)
  This category is used for connections that are bursty but are not constrained by delay and delay variation boundaries. For those cells in compliance with the traffic contract, a low cell loss is expected. Non-time critical data file transfers are an example of an nrt-VBR connection. A nrt-VBR connection is characterized by PCR, SCR, and MBS.

Configuring VBR connections

The characteristics of rt-VBR or nrt-VBR are supported by appropriately configuring the parameters of the VBR connection.

When configuring a rt-VBR connection, the trunk cell routing restriction prompt does not display, because rt-VBR connection routing is automatically restricted to ATM trunks.

With Rel. 9.2.20 and later,you specify rt-VBR and nrt-VBR connections separately when adding a connection by using the addcon command. To do this, enter either rt-vbr or nrt-vbr to select the rt-VBR or nrt-VBR connection class, respectively. Each connection is assigned the applicable associated default parameters for its type of service.

For rt-VBR an additional queue, referred to as the rt-VBR queue, is used at a BXM port. At BXM or BNI trunks, voice and rt-VBR traffic share a queue, referred to as the rt-VBR queue.

The rt-VBR and nrt-VBR service queues are configured differently from each other at both port ingress and port egress queues. The rt-VBR typically uses smaller queues for low delay, whereas the nrt-VBR queues are typically larger in size for more efficient bandwidth sharing with other non-real time service types.

The rt-VBR connections are configured per class 3 service parameters. The nrt-VBR connections are configured per class 2 service parameters.

You can configure the connection classes to whatever service and parameters you want by:

• Using the cnfcls and cnfatmcls commands.

• Or, you can enter the parameters individually for each connection by specifying `yes' to the extended parameters prompt of the addcon command.

For a new node running software release 9.2.20 or later, the rt-VBR connection class number is 3. However, an upgraded node will retain existing connection classes. Therefore, it won't have the rt-VBR connection class 3.

For nrt-VBR connections in a new node, running 9.2.20, a number of connection classes are pre-configured, including 2, 4, 5, and 6.

Examplef cnfcls 3, for rt-VBR

Example of cnfcls2, for NRT-VBR

Connection Criteria

• Default utilization for voice traffic is 100 percent.

• For rt-VBR connections, all nodes must be running at least Rel. 9.2.20. The user interface will block the addition of rt-VBR connections in a network running pre-9.2.20 SWSW.

• BXM and UXM (IGX switch) cards can terminate rt-VBR connections and support rt-VBR queues.

• On the BPX switch, BXM and BNI trunks support rt-VBR queues

• On the IGX switch, only UXM trunks support rt-VBR queues.

• You can add both rt-VBR and nrt-VBR connections.The parameter prompts are the same for both rt-VBR and nrt-VBR, except for Trunk Cell Routing Restriction prompt. (For rt-VBR connections, the "Trunk Cell Routing Restriction" prompt will not display because rt-VBR traffic should be routed over only ATM trunks; rt-VBR traffic should not be routed over FastPacket trunks.)

• With release 9.3, rt-vbr is supported on 2- and 3-segment connections, but only on IGX feeders and UXM endpoints. For example: the UXM card on the IGX switch (2 segment: CPE to IGX feeder UXM to BXM to BXM to CPE) or (3 segment: CPE to IGX feeder UXM to BXM to BXM to IGX feeder UXM to CPE).

Configuring Connection Policing

The BPX Command Line Interface (CLI) and Cisco WAN Manager accept the same connection policing and bandwidth parameters as in previous releases for both rt-VBR and nrt-VBR service.

The displayed addcon parameter prompts for both rt-VBR and nrt-VBR connections are the same:

• PCR

• %util

• CDVT

• FBTC flag

• SCR

• MBS

• Policing Type

There is no change in CDVT usage and the previous policing system.

When using the addcon command without the extended parameters, rt-VBR connections automatically use the parameters provided by connection class 3 which contains pre-determined values. Similarly, nrt-VBR connections use connection class 2.

To modify the values of a connection class, use the commands cnfcls and cnfatmcl.

To display these values, use the commands dspcls and dspatmcls.

Configuring Resources

Qbin values on both ports and trunks used by rt-VBR connections and nrt-VBR connections can be configured separately.

Trunk Queues for rt-VBR and nrt-VBR

A rt-VBR connection uses the rt-VBR queue on a trunk. It shares this queue with voice traffic. The rt-VBR and voice traffic shares the default or user configured parameters for the rt-VBR queue. These parameters are queue depth, queue CLP high and CLP low thresholds, EFCI threshold, and queue priority.

A nrt-VBR connection uses the nrt-VBR queue on a trunk. The configurable parameters are queue depth, queue CLP high and CLP low thresholds, EFCI threshold, and queue priority.

You can configure the qbin values separately for rt-VBR and nrt-VBR classes on trunks by using the cnftrkparm command.

• For rt-VBR, the cnftrkparm command configures Q-depth rt-VBR and Max Age rt-VBR.

• For nrt-VBR, the cnftrkparm command configures Q-depth nrt-VBR, Low CLP nrt-VBR, and High CLP nrt-VBR.

This example shows the cnftrkparm screen and the parameters that can be configured for the various service type queues:

Port Queues for rt-VBR and nrt-VBR

The rt-VBR and nrt-VBR connections use different queues on a port, these are the rt-VBR and nrt-VBR queues, respectively. You can configure these separately by using the cnfportq command.

The following example shows he configuration parameters available for a port queue.

Port Queue Parameters, cnfportq

Related Switch Software Commands

These commands are related to the process of adding and monitoring ATM connections:

• addcon

• dspload

• cnfcls

• cnfatmcls

• cnfcls

• cnfcon

• cnftrkparms

• dsptrkcnf

• dspatmcls

• dspcls

• dsconcls

• dspconcnf

• dspcon

• dspcons

• dlcon

• dcct

• dvcparms

• dvc

• cnfpre

• dsptrkcnf

• dspload

• chklm

• dsplm

• updates

• upport

• dspportq

• cnfportq

• dspblkfuncs

• dspchstats

• dspportstats

• dsptrkstats

• dsptrkerrs.

For additional information on CLI command usage, refer to the Cisco WAN Switching Command Reference and Cisco WAN Switching SuperUser Command Reference.

ATM Connection Configuration

These figures and tables describe the parameters used to configure ATM connections:

• Table 21-5, Traffic Policing Definitions

  • This table describes the policing options that may be selected for ATM connection types: CBR, UBR, rt-VBR. and nrt-VBR. The policing options for ABR are the same as for VBR.

• Table 21-6, Connection Parameters with Default Settings and Ranges

  • This table specifies the ATM connection parameter ranges and defaults. Not all the parameters are used for every connection type. When adding connections, you are prompted for the applicable parameters, as specified in the prompt sequence diagrams included in Figure 21-6 through Figure 21-11.

• Table 21-7, Connection Parameter Descriptions

  • This table defines the connection parameters listed in Table 21-6.

The following figures list the connection parameters in the same sequence as they are entered when a connection is added:

• Figure 21-6, CBR Connection Prompt Sequence

• Figure 21-7, rt-VBR and nrt-VBR Connection Prompt Sequence

• Figure 21-8, ABR Standard Connection Prompt Sequence

This figure shows the VSVD network segment and external segment options available when ABR Standard or ABR ForeSight is selected. ForeSight congestion control is useful when both ends of a connection do not terminate on BXM cards. At present, FCES (Flow Control External Segment) as shown in Figure 21-9 is not available for ABR with ForeSight.

• Figure 21-9, Meaning of VSVD and Flow Connection External Segments

These figures list the connection parameters in the same sequence as you would enter them when adding a connection:

• Figure 21-10, ABR ForeSight Connection Prompt Sequence

• Figure 21-11, UBR Connection Prompt Sequence

• Figure 21-14, ATFR Connection Prompt Sequence

• Figure 21-15, ATFST Connection Prompt Sequence

• Figure 21-16, ATFT Connection Prompt Sequence

• Figure 21-17, ATFTFST Connection Prompt Sequence

• Figure 21-18, ATFX Connection Prompt Sequence

• Figure 21-19, ATFXFST Connection Prompt Sequence

  ---

  Note   With DAX connections, the trunk cell routing restriction prompt is not displayed since there is no trunking involved.

  ---

Adjust Minimum SCR and PCR

Prior to Release 9.3.0, the minimum Sustainable Cell Rate (SCR) and Peak Cell Rate (PCR) of a connection supported by the BXM and UXM cards, including enhanced modes, was 50 cells per second (cps). These values were set to maintain a policing accuracy with 1% when policing is performed on a BXM or UXM card. Because of this limitation, it was impossible to offer and differentiate connection services on a UXM or BXM at speeds less than 19.2 Kbps.

In Release 9.3.0, the switch software supports connections with policing enabled and with SCR and PCR values as low as 12 cps on the BPX with certain card limitations.

Use the dspcd command to determine if this feature is supported on a given slot.

Use the addcon command to set the minimum SCR and PCR values. If these values are less than the minimum values supported on a given card, the command line interface will not allow you to set them until you have disabled policing. (A prompt will let you know about this limitation.)

Please refer to Table 21-1 for a list of cards that are supported by this feature and their performance specifications.

Constant Bit Rate Connections

The CBR (constant bit rate) category is a fixed bandwidth class. CBR traffic is more time dependent, less tolerant of delay, and generally more deterministic in bandwidth requirements.

The parameters for a CBR connection are shown in Figure 21-6 in the sequence in which they occur during the execution of the addcon command. The CBR policing definitions are summarized in Table 21-8.

Variable Bit Rate Connections

VBR (variable bit rate) connections may be classified as either:

• Real-Time Variable Bit Rate (rt-VBR)
  This category is used for connections that transmit at a rate varying with time and can be described as bursty, often requiring large amounts of bandwidth when active. It is intended for applications that require tightly constrained delay and delay variation such as compressed voice video conferencing.

For example, video conferencing requires real-time data transfer with bandwidth requirements that can vary in proportion to the dynamics of the video image at any given time. The rt-VBR category is characterized in terms of PCR, SCR (sustained cell rate), and MBS (maximum burst size).

• Non-Real Time Variable Bit Rate (nrt-VBR)
  This category is used for connections that are bursty but not constrained by delay and delay variation boundaries. For those cells in compliance with the traffic contract, a low cell loss is expected. Non-time critical data file transfers are an example of an nrt-VBR connection. A nrt-VBR connection is characterized by PCR, SCR, and MBS.

The characteristics of rt-VBR or nrt-VBR are supported by appropriately configuring the parameters of the VBR connection.

Note   When configuring a rt-VBR connection, the trunk cell routing restriction prompt does not occur, as rt-VBR connection routing is automatically restricted to ATM trunks.

Connection Criteria for real-time VBR and non-real-time VBR Connections

• Default utilization for voice traffic is 100 percent.

• For rt-VBR connections, all nodes must be running at least Rel. 9.2.20. The command line interface will block you from adding rt-VBR connections in a network running pre-9.2.20 switch software

• When upgrading to Rel. 9.2.20, all existing VBR connections are re-designated as nrt-VBR connections.

• BXM and UXM (IGX switch) cards can terminate rt-VBR connections and support rt-VBR queues.

• On the BPX switch, BXM and BNI trunks support rt-VBR queues

• On the IGX switch only, UXM trunks support rt-VBR queues.

• In Release 9.2.20, you can add both rt-VBR and nrt-VBR connections.The parameter prompts are the same for both rt-VBR and nrt-VBR, except for Trunk Cell Routing Restriction prompt. (For rt-VBR connections, the "Trunk Cell Routing Restriction" prompt will not display because rt-VBR traffic should only be routed over ATM trunks; rt-VBR traffic should not be routed over FastPacket trunks.)

• With Release 9.2.20, rt-vbr is supported only on single-segment connections (for example, CPE to BXM to BXM to CPE). Later releases will support 2 and 3 segment connections, for example with the UXM card on the IGX switch (2 segment: CPE to IGX feeder UXM to BXM to BXM to CPE) or (3 segment: CPE to IGX feeder UXM to BXM to BXM to IGX feeder UXM to CPE).

The parameters for a VBR connection are shown in Figure 21-7 in the sequence in which they occur during the execution of the addcon command. The VBR policing definitions are summarized in Table 21-9.

Available Bit Rate Connections

The ABR (available bit rate) category utilizes a congestion flow control mechanism to control congestion during busy periods and to take advantage of available bandwidth during less busy periods. The congestion flow control mechanism provides feedback to control the connections flow rate through the network in response to network bandwidth availability.

The ABR service is not restricted by bounding delay or delay variation and is not intended to support real-time connections. ABR is characterized by PCR and MCR.

The term ABR is used to specify one of the following:

• ABR standard without VSVD (This is ABR standard without congestion flow control.)

  • Supported by BXM cards.

• ABR standard with VSVD. (This is ABR standard with congestion flow control as specified by the ATM Traffic Management, Version 4.0)

  • Also, referred to as ABR.1

  • Supported only by BXM cards

  • Feature must be ordered

• ABR with ForeSight congestion control

  • Also, referred to as ABR.FST.

  • Supported by BXM cards

  • Feature must be ordered

Policing for ABR connections is the same as for VBR connections which are summarized in Table 21-9.

The ABR connections are configured as either ABR Standard (ABRSTD) connections or as ABR ForeSight (ABRFST) connections.

The parameters for an ABRSTD connection are shown in Figure 21-8 in the sequence in which they occur during the execution of the addcon command.

The ABRSTD connection supports all the features of ATM Standards Traffic Management 4.0 including VSVD congestion flow control.

VSVD and flow control with external segments are shown in Figure 21-9.

Available Bit Rate Standard Connections

The Available Bit Rate Standard (ABRSTD) connection uses VSVD congestion control.

The parameters for an ABRSTD connection are shown in Figure 21-10 in the sequence in which they occur during the execution of the addcon command

Available Bit Rate Foresight Connections

The Available Bit Rate Foresight (ABRFST) connection uses the propriety ForeSight congestion control and is useful when configuring connections on which both ends do not terminate on BXM cards.

The parameters for an ABRFST connection are shown in Figure 21-10 in the sequence in which they occur during the execution of the addcon command.

Unspecified Bit Rate Connections

The unspecified bit rate (UBR) connection service is similar to the ABR connection service for bursty data. However, UBR traffic is delivered only when there is spare bandwidth in the network. This is enforced by setting the CLP bit on UBR traffic when it enters a port.

Therefore, traffic is served out to the network only when no other traffic is waiting to be served first. The UBR traffic does not affect the trunk loading calculations performed by the switch software.

The parameters for a UBR connection are shown in Figure 21-11 in the sequence in which they occur during the execution of the addcon command.

The UBR policing definitions are summarized in Table 21-10.

Network and Service Interworking Notes

Frame Relay to ATM Interworking enables Frame Relay traffic to be connected across high-speed ATM trunks using ATM standard Network and Service Interworking (see Figure 21-12 and Figure 21-13).

Two types of Frame Relay to ATM interworking are supported:

• Network Interworking
  Performed by the BTM card on the IGX switch and the FRSM card on the MGX 8220

• Service Interworking
  Performed by the FRSM card on the MGX 8220

ATM-to-Frame Relay Network Interworking Connections

An ATM-to-Frame Relay (ATFR) connection is a Frame Relay to ATM connection and is configured as a VBR connection, with a number of the ATM and Frame Relay connection parameters being mapped between each side of the connection.

The parameters for an ATFR connection are shown in Figure 21-14 in the sequence in which they occur during the execution of the addcon command.

Frame Relay-to-ATM Foresight Network Interworking Connection

A Frame Relay-to-ATM Foresight (ATFST) connection is a that is configured as an ABR connection with ForeSight. ForeSight congestion control is automatically enabled when connection type ATFST is selected. A number of the ATM and Frame Relay connection parameters are mapped between each side of the connection.

The parameters for an ATFST connection are shown in Figure 21-15 in the sequence in which they occur during the execution of the addcon command.

Frame Relay-to-ATM Transparent Service Interworking Connections

A Frame Relay-to-ATM Transparent Service Interworking (ATFT) connection is configured as a VBR connection with a number of the ATM and Frame Relay connection parameters being mapped between each side of the connection..

The parameters for an ATFT connection are shown in Figure 21-16 in the sequence in which they occur during the execution of the addcon command.

Frame Relay-to-ATM Foresight Transparent Service Interworking Connections

A Frame Relay-to-ATM Foresight Transparent Service Interworking (ATFTFST) connection is configured as an ABR connection with ForeSight. ForeSight congestion control is automatically enabled when connection type ATFTFST is selected. A number of the ATM and Frame Relay connection parameters are mapped between each side of the connection.

The parameters for an ATFTFST connection are shown in Figure 21-17 in the sequence in which they occur during the execution of the addcon command.

Frame Relay-to-ATM Translational Service Interworking Connections

A Frame Relay-to-ATM Translational (ATFX) Service Interworking connection and is configured as a VBR connection, with a number of the ATM and Frame Relay connection parameters being mapped between each side of the connection.

The parameters for an ATFX connection are shown in Figure 21-18 in the sequence in which they occur during the execution of the addcon command.

Frame Relay-to-ATM Foresight Translational Service Interworking Connections

A Frame Relay-to-ATM Foresight (ATFXFST) Translational Service Interworking connection that is configured as an ABR connection with ForeSight. ForeSight congestion control is automatically enabled when connection type ATFXFST is selected. A number of the ATM and Frame Relay connection parameters are mapped between each side of the connection.

The parameters for an ATFXFST connection are shown in Figure 21-19 in the sequence in which they occur during the execution of the addcon command.

Traffic Policing Examples

Traffic Policing, also known as Usage Parameter Control (UPC), is implemented using either an ATM Forum single or dual-leaky bucket algorithm. The buckets represent a GCRA (Generic Cell Rate Algorithm) defined by two parameters:

Dual-Leaky Bucket (An Analogy)

A Generic Cell Rate Algorithm viewpoint is:

• For a stream of cells in an ATM connection, the cell compliance is based on the theoretical arrival time (TAT).

• The next TAT should be the time of arrival of the last compliant cell plus the expected arrival interval (I) where I = 1/rate.

• If the next cell arrives before the new TAT, it must arrive no earlier than new TAT - CDVT to be compliant.

• If the next cell arrives after the new TAT, it is compliant, but there is no accrued credit.

CBR Traffic Policing Examples

CBR traffic is expected to be at a constant bit rate, have low jitter, and is configured for a constant rate equal to Peak Cell Rate (PCR). The connection is expected to be always at peak rate.

When you add a connection, you assign a VPI.VCI address, and configure the UPC parameters for the connection. For each cell in an ATM stream seeking admission to the network, the VPI.VCI addresses are verified and each cell is checked for compliance with the UPC parameters. The CBR cells are not enqueued, but are processed by the policing function and then sent to the network unless discarded.

For CBR, traffic policing is based on:

• Bucket 1

  • PCR(0+1), Peak Cell Rate

  • CDVT(0+1), Cell Delay Variation

You may configure CBR connection with policing selected as either 4 or 5.

With policing set to 5, there is no policing.

With policing set to 4, there is single leaky bucket PCR policing as shown in Figure 21-20. The single leaky bucket polices the PCR compliance of all cells seeking admission to the network, both those with CLP = 0 and those with CLP =1. Cells seeking admission to the network with CLP set equal to 1 may have either encountered congestion along the user's network or may have lower importance to the user and have been designated as eligible for discard in the case congestion is encountered. If the bucket depth CDVT (0+1) limit is exceeded, it discards all cells seeking admission. It does not tag cells. If leaky bucket 1 is not full, all cells (CLP =0 and CLP=1) are admitted to the network.

Figure 21-21 shows a CBR.1 connection policing example, with policing set to 4, where the CDVT depth of the single leaky bucket is not exceeded, and all cells, CLP(0) and CLP(1) are admitted to the network.

Figure 21-22 shows a CBR connection policing example, with policing =4, where the CDVT(0+1) of the single leaky bucket is exceeded and non-compliant cells are discarded. The leaky bucket only discards cells; it does not tag them

Variable Bit Rate Dual-Leaky Bucket Policing Examples

The contract for a variable bit rate (VBR) connection is set up based on an agreed upon sustained cell rate (SCR) with allowance for occasional data bursts at a Peak Cell Rate (PCR) as specified by maximum burst size MBS.

When a connection is added, a VPI.VCI address is assigned, and UPC parameters are configured for the connection. For each cell in an ATM stream, the VPI.VCI addresses are verified and each cell is checked for compliance with the UPC parameters as shown in Figure 21-23.

The VBR cells are not enqueued, but are processed by the policing function and then sent to the network unless discarded.

For VBR, traffic policing, depending on selected policing option, is based on:

• Leaky bucket 1, PCR and CDVT

• Leaky bucket 2, SCR, CDVT, and MBS

The policing options for VBR connections, selected by entering 1-5 in response to the policing choice prompt, are shown in Table 21-12:

Leaky Bucket 1

Leaky bucket 1 polices for the PCR compliance of all cells seeking admission to the network, both those with CLP = 0 and those with CLP =1.

For example, cells seeking admission to the network with CLP set equal to 1 may have either encountered congestion along the user's network or may have lower importance to the user and have been designated as eligible for discard in the case congestion is encountered. If the bucket depth in the first bucket exceeds CDVT (0+1), it discards all cells seeking admission. It does not tag cells.

With policing set to 1 (VBR.1), all cells (CLP=0 and CLP=1) that are compliant with leaky bucket 1, are sent to leaky bucket 2.

With policing set to 2 (VBR.2) or to 3 (VBR.3), all CLP=1 cells compliant with leaky bucket 1 are admitted directly to the network, and all CLP=0 cells compliant with leaky bucket 1 are sent to leaky bucket 2.

Leaky Bucket 2

For VBR connections, the purpose of leaky bucket 2 is to police the cells passed from leaky bucket 1 for conformance with maximum burst size MBS as specified by BT and for compliance with the SCR sustained cell rate. The types of cells passed to leaky bucket 2 depend on how policing is set:

• For policing set to 5, cells bypass both buckets.

• For policing set to 4, leaky bucket 2 sees no traffic.

• For policing set to 2 or 3, the CLP(0) cells are admitted to the network if compliant with BT + CDVT of leaky bucket 2. If not compliant, cells may either be tagged (policing set to 3) or discarded (policing set to 2).

• For policing set to 1, the CLP(0) and CLP(1) cells are admitted to the network if compliant with BT + CDVT of leaky bucket 2. If not compliant, the cells are discarded. There is no tagging option.

Examples

Figure 21-24 shows a VBR connection policing example, with policing set to 4, leaky bucket 1 compliant, and all cells being admitted to the network.

Figure 21-25 shows a VBR connection policing example, with the policing set to 4, and leaky bucket 1 non-compliant which indicates that the connection has exceeded the PCR for a long enough interval to exceed the CDVT (0+1) limit. Non-compliant cells with respect to leaky bucket 1 are discarded.

Figure 21-26 shows a VBR.2 connection policing example, with policing = 2, and both buckets compliant. Leaky bucket two is policing the CLP(0) cell stream for conformance with maximum burst size MBS (as specified by BT), and for compliance with the SCR sustained cell rate.

Figure 21-27 shows a VBR.2 connection policing example, with policing set to 2, and leaky bucket 2 non-compliant. Leaky bucket 2 is shown policing the CLP(0) cell stream for conformance with maximum burst size MBS (as specified by BT), and for compliance with SCR (sustained cell rate).

In this example (policing set to 2), CLP tagging is not enabled, so that the cells that have exceeded the BT + CDVT limit are discarded. In the example, either the sustained cell rate could have been exceeded for an excessive interval, or a data burst could have exceeded the maximum allowed burst size.

Figure 21-28 shows a VBR.1 connection policing example, with policing set to 1, and both buckets compliant.

Leaky bucket 1 is policing the CLP (0+1) cell stream for conformance with the PCR limit.

Leaky bucket 2 is policing the CLP (0+1) cell stream for conformance with CDVT plus maximum burst size MBS (as specified by BT), and for compliance with SCR sustained cell rate.

Figure 21-29 shows a VBR.3 connection policing example, with policing set to 3, and Leaky bucket 2 shown as non-compliant.

Leaky bucket 2 is shown policing the CLP(0) cell stream for conformance with maximum burst size MBS (as specified by BT), and for compliance with SCR sustained cell rate.

For the policing = 3 selection, CLP tagging is enabled, so the cells that have exceeded the BT + CDVT(0+1) limit are tagged as CLP=1 cells and admitted to the network.

In this example, either the sustained cell rate could have been exceeded for an excessive interval, or a data burst could have exceeded the maximum burst size allowed.

ABR Connection Policing

Available Bit Rate (ABR) connections are policed the same as the VBR connections, but in addition use either the ABR Standard with VSVD congestion flow control method or the ForeSight option to take advantage of unused bandwidth when it is available.

UBR Connection Policing

The contract for a unspecified bit rate connection is similar to the ABR connection service for bursty data. However, UBR traffic is delivered only when there is spare bandwidth in the network.

When a connection is added, a VPI.VCI address is assigned, and UPC parameters are configured for the connection. For each cell in an ATM stream, the VPI.VCI addresses are verified and each cell is checked for compliance with the UPC parameters as shown in Figure 21-30.

Leaky Bucket 1

Leaky bucket 1 polices the UBR connection for PCR compliance. When CLP=No (UBR.1), all cells that are compliant with leaky bucket 1 are applied to the network. However, these cells are treated with low priority in the network with a percentage utilization default of 1 percent.

Leaky Bucket 2

When CLP=Yes (UBR.2), CLP(0) cells that are compliant with leaky bucket 1 are sent to leaky bucket 2. Because SCR=0 for leaky bucket 2, the bucket is essentially always full, and all the CLP(0) cells sent to leaky bucket 2 are therefore tagged with CLP being set to 1. This allows the network to recognize these UBR cells as lower priority cells and available for discard in the event of network congestion.

Local Management Interface and Integrated Local Management Interface Parameters

Local Management Interface (LMI) provides a protocol to monitor the status of permanent virtual connections between two communication devices.

Integrated Local Management Interface (ILMI) provides a means for configuration, status and control information between two ATM entities.

LMI and ILMI functions for the BXM card support virtual UNIs and trunk ports, a total of 256 sessions on different interfaces (ports, trunks, virtual UNIs) per BXM.

Here is a list of the LMI and ILMI parameters for the BXM:

For ILMI information, refer to Table 21-13

For the LMI information, refer to Table 21-14

.

Early Abit Notification with Configurable Timer on ILMI/LMI Interface

The time required to reroute connections varies depending on different parameters, such as the number of connections to reroute, reroute bundle size, and so on.

It is important to notify the customer premise equipment if a connection is derouted and fails to transport user data after a specified time interval. However, it is also desirable not to send out Abit = 0, then Abit =1 when a connection is derouted and rerouted quickly. Such notifictions might prematurely trigger the CPE backup facilities causing instabilities in an otherwise stable system.

The Early Abit Notification on ILMI/LMI Using Configurable Timer feature allows Abit notifications to be sent over the LMI/ILMI interface if a connection cannot be rerouted after a user-specified time. Abit = 0 will not be sent if the connection is rerouted successfully during that time.

The time period is configurable. The configurable time allows you the flexibility to synchronize the operation of the primary network and backup utilities, such as dialed backup over the ISDN or PSTN network.

This feature is supported on both the BPX and IGX platforms. A Release 9.2 IGX or BPX node using this feature is compatible with Release 8.4 and Release 8.5 nodes or Release 9.1 IGX and BPX nodes so that all existing connection related functions will continue to work. However, the timing in sending out the Abit notifications at both ends of connections may behave differently, depending on how this feature is configured.

Configuring Early Abit Notification

You configure the timer delay period by setting cnfnodeparm parameters. You want to choose timer settings that give you the flexibility to synchronize the operation of the primary network and backup utilities, such as dialed backup over the ISDN or PSTN network.

Be aware of these guidelines when using the Early Abit feature:

• When you enable this feature by using the cnfnodeparm command, you can specify that Abit Notification be:

  • sent either on deroute

  • or a user-configurable time after deroute

• This feature can also be turned off

• It is recommended that this feature be set the same on all nodes. Otherwise, the Abit behavior can be different on different nodes.

• If this feature is turned off, switch software behaves the same as in previous releases. Existing functionality continues to function in a mixed release network (releases 8.4, 8.5, or 9.1 IGX or BPX network).

• If the cnfnodeparm parameter Abit Timer Multiplier M is set to 0, then switch software behaves the same way as in Release 9.1.07 (which supported the Send Abit on Deroute feature).

• To follow the general Release 9.2 interoperability guideline, it is not recommended that the Early Abit Notification on ILMI/LMI Using Configurable Timer feature be used when the standby control processor is in a locked state.

Recommended Settings

You should be aware of the dynamic relation between the two timer parameters:

• Abit Timer Granularity N
  The time period is referred to as N, which defines the granularity of the timers. You specify N by the value of the cnfnodeparm Abit Timer Granularity N parameter.
  The default value for N is 3sec.

• Parameter X
  The time to wait before Abit = 0 is sent out if the connection is in a derouted state.
  X, is set to be M*N

• Abit Timer Multiplier M
  M can be configured to be from 0 to 100. Default value for M (Abit Timer Multiplier M parameter) is 0, meaning Abit = 0 is sent out on deroute.

A connection that is derouted at a period of time between 0 and N will send out Abit = 0 at a time between X and X + N, if the connection continues to be in a derouted state. In cases where there are many Abit status changes to report to CPE, the last Abit updates may be delayed much longer because Abit updates process about 47 connections per second.

To make a compromise between performance and the granularity of timers, N can be configured to be from 3 to 255 seconds; the bigger the value of N, the better the system performance will be.

It is recommended that X (value of Abit Timer Multiplier M * the value of the Abit Timer Granularity N) be set such that when a trunk fails, the connections are given sufficient time to reroute successfully, avoiding the need to send out Abit = 0.

If the value of X (value of Abit Timer Multiplier M * value of Abit Timer Granularity N) is set to be smaller than the normal time to reroute connections when a trunk fails, the time it takes to finish rerouting them may take longer. This can happen for line cards and feeder trunks that have the LMI/ILMI protocol running on those cards, such as BXM on BPX and Frame Relay cards on IGX. Note that it takes time for those cards to process the Abit status information for each connection coming from the controller card.

The change in the Abit behavior is completely local to the node and is applicable to the master and slave ends of connections when the connections are derouted. When only one of the nodes connected by a connection has this feature turned on, the timing in sending the Abit notification at one end of the connection may be drastically different from the other end.

Therefore it is recommended that the Early Abit Notification on ILMI/LMI Using Configurable Timer feature be configured the same on all nodes.

Also, because timers on nodes are not in sync, there is a slight time difference (3 seconds maximum) in sending Abit from the two ends of a connection, even if the cnfnodeparm parameter settings on the nodes are the same.

Behavior with Previous Releases

A pre-Release 9.1.07 node or Release 9.1.07 node with the Send Abit on Deroute feature (cnfnodeparm Send Abit immediately parameter) turned off behaves the same way as a Release 9.2 node with the Early Abit Notification on ILMI/LMI Using Configurable Timer feature disabled.

A Release 9.1.07 node with the cnfnodeparm Send Abit immediately parameter set to yes behaves the same way as a Release 9.2 node with the Send Abit Early parameter set to yes and the Abit Timer Multiplier M set to 0.

To follow the general Release 9.2 interoperability guideline, it is not recommended that the Early Abit Notification on ILMI/LMI Using Configurable Timer feature be used when the standby control processor is in a locked state.

There is no impact on control processor switchover or trunk card redundancy switchover because connections are not rerouted.

In releases previous to Release 9.1.07, when connections are derouted, the CPE does not receive Abit notifications. In Release 9.1.07 on BPX, the Send Abit on Deroute feature was developed, which allowed the Abit = 0 to be sent immediately when a connection is derouted. (This was specified by the cnfnodeparm parameter Send Abit immediately parameter.)

To further enhance the Send Abit on Deroute feature in Release 9.1.07, the Early Abit Notification on ILMI/LMI Using Configurable Timer feature was implemented in Release 9.2 to allow the network administrator to configure the node as to when Abit = 0 is sent out if a connection is derouted and not rerouted quickly. This feature allows you to specify when Abit notifications will be sent at Frame Relay and ATM ports, and at feeder trunks in a tiered network architecture that supports the ILMI/LMI interface. In a tiered network, the Abit information is used by the feeder nodes such as MGX 8220 (AXIS) which then relays the Abit information to the CPE.

Performance Considerations

The status update messages are throttled at the rate of one message per second. Each message can be used to specify the conditioning information on a maximum of 47 connections. It may take on the order of minutes for the ILMI/LMI manager to process the Abit status when there is a large number of connections.

There are two factors in performance:

• System performance
  System performance is affected by the value of the time interval. In a network where connections are normally derouted and rerouted quickly before the bucket timer expires, the performance impact is very small. Only when the timer expires, then looping through all LCONs and sending update messages will take up some CPU time which is estimated to be smaller than 1 percent.

• Reroute time
  Reroute time is not affected if LMI/ILMI is running on the controller card. When the protocol is implemented on the line cards and feeder trunk cards, some additional Abit status communication between them and controller card may delay the reroute process.

Specifically, on the BPX, if the BXM runs LMI/ILMI, the BCC has to send Abit update to the card. These messages will be throttled. When this happens, the estimated time to reroute all 12K connections increases no more than 5 percent.

For the IGX, enabling the Sending Abit Notification using Configurable Timer feature may impact performance if many connections end at Frame Relay cards. This is due to the restricted format of interface between NPM and Frame Relay cards.

ATM Command List

Posted: Fri Jul 27 16:18:50 PDT 2001
All contents are Copyright © 1992--2001 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.