Table of Contents

Connection Management

Introduction
IPX 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
Priority Bumping/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

Introduction

This chapter is provided for users who wish to have an in-depth knowledge of the IPX and BPX connection management functions. Reading this chapter is not required in order to use the systems. 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.

IPX Packet Queuing

As previously discussed, packets may be created in an IPX node 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.

In the NTC Model C or later, trunk cards, the queue service algorithm:

• Supports the two frame relay packet types (bursty data A and bursty data B).
  

• Gives high priority packets unrestricted bandwidth access.
  

• Guarantees that every packet type is provided some minimum bandwidth access regardless of the load of any queue.
  

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.

As an example, assume that a trunk has the following load:

• 2000 voice packets per second.
  

• 1000 timestamped packets per second.
  

• 4000 non-timestamped packets per second.
  

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

Table 13-1 : Credit Accumulation

Frame	1	2	3	4	5	6	7	8	9	10	11	12	13	14
Voice Credits	X				X				X				X
Timestamped Credits			X								X
Non-timestamped Credits		X		X		X		X		X		X		X

At every opportunity to send a packet, the NTC Model C runs the following queue service algorithm to determine which packet to send.

Step 1 If there is a high priority packet, send it.

Step 2 If there is no high priority packet, then examine each other queue in order of highest to lowest configured bandwidth. If a queue has a packet and a credit, send the packet.

Step 3 If no queue has a credit, then use the following priority to send a packet.

• Non-timestamped data.
  

• Timestamped data.
  

• Voice and bursty data in a round-robin fashion.
  

Step 4 If there is no packet to send, send a 4-byte idle packet.

This scheme allows every queue to use at least some minimum configured bandwidth. Any packets that exceed the configured bandwidth are handled in the order described, which gives a slight edge to non-timestamped, then timestamped data.

Delay in a Cell Network

The overall delay of information through the network includes:

• Packetization delay.
  

• Queuing delay.
  

• Transmission delay.
  

• Depacketization and null-timing delay.
  

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 IPX 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 IPX 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 IPX 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 13-2 or Table 13-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
  

Table 13-2 : Calculation of Non-Timestamped Data Packet Overall Delay

Source	Delay (ms.)
Transmitting SDP packetizing	1--3
Transmission delay (terrestrial, per mile)	0.01
Transmission delay (satellite, per hop)	300
Miscellaneous dejitter delays (per hop)	0.25
Receiving SDP null timing buffer (per hop) 1	2.5--5.0
Receiving SDP processing delays	4.0
Receiving SDP isochronous buffer delay 2	10.0
Minimum delay (one-hop, colocated nodes)	7.75

¹ Includes trunk queuing delays
² Isochronous connections only

Table 13-3 : Calculation of Timestamped Data Packet Overall Delay

Source	Delay (ms.)
Transmitting SDP packetizing	3--33
Transmission delay (terrestrial, per mile)	0.01
Transmission delay (satellite, per hop)	300
Miscellaneous dejitter delays (per hop)	0.25
Receiving SDP null-timing buffer	40
Receiving SDP processing delay	4.0
Receiving SDP isochronous buffer delay 1	10.0
Minimum delay (one hop, colocated nodes)	47.25

¹ Isochronous connections only2.Ages timestamp to 40 (default).

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 13-4 can be used to calculate delay for the four types of voice connections.

Table 13-4 : Sources of Delay in Voice Connections

Delay Source	t & p	v	a16	a24	a32	c16	c24	c32
Circuit T1 transmitter dejitter	0.25	0.25	0.25	0.25	0.25	0.25	0.25	0.25
Transmitting CDP sample input delay	0.5	0.5	0.5	0.5	0.5	0.5	0.5	0.5
Transmitting CDP packetization	2.6	2.6	10.5	7.0	5.25	10.5	7.0	5.25
Transmitting TXR queuing (per hop)	< 2.5	< 2.5	< 2.5	< 2.5	< 2.5	< 2.5	< 2.5	< 2.5
Transmission delay (terrestrial, per mile)	0.01	0.01	0.01	0.01	0.01	0.01	0.01	0.01
Transmission delay (satellite, per hop)	300	300	300	300	300	300	300	300
Miscellaneous dejitter delays (per hop)	0.5	0.5	0.5	0.5	0.5	0.5	0.5	0.5

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

Table 13-5 : Typical Voice Connection Delays

Expected Delay (ms.)	t or p	v	a	c
1-hop, colocated nodes1	9	30	14	35
2-hops, colocated nodes1	12	33	17	38
3-hops, colocated nodes1	15	36	20	41
4-hops, colocated nodes1	17	38	23	43
5-hops, colocated nodes1	20	41	25	45

¹ For nodes that are not colocated nodes, add 0.01 ms./mile.

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 IPX determines the route each circuit takes when added to the network and the algorithms and considerations involved when the IPX must automatically reroute circuits because of a failure(s) detected in the network.

Load Model

The IPX 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 IPX 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 IPX 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 IPX 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 IPX 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.
  

When a node has to find routes for a number of connections at the same time, it uses the rules above to determine the order in which it considers them. They are hierarchical. Bundle size will only be considered if there are a number of bundles of connections of the same type and COS. If a route cannot be found for a particular connection, the owning node will leave it failed and go on to the next. This is why the "largest first" rule is important. The network cannot reroute some connections to make room for others. Rerouting only occurs as the result of the failure of routed connections.

When a group of connections is failed, a timer is started at the node owning the connections. COS 0 connections may be rerouted immediately, and there is a 250 millisecond delay before each subsequent COS may be rerouted. This is to allow COS to have a network-wide effect. Therefore, COS 8 connections will be rerouted after a pause of 2 seconds although there may still be COS 0 connections awaiting rerouting. The low COS gives a "head start" rather than absolute priority.

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 13-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.

Table 13-6 : Priority for Rerouting

Priority	Connection Type
1	high speed data connections (>64 Kbps)
2	"p" or "d" connections
3	"a" connections
4	"v" connections
5	"c" connections
6	low speed data connections (< 9.6 Kbps)

Priority Bumping/Courtesy Downing

The process of Priority Bumping controls several components. When bumping is invoked, it first looks for any locally owned connections that are currently not routable. If no connections are found, then this process is complete. When connections are found, the database that holds remote nodes' owned connections is searched to locate any other connections that need to be routed.

When remote nodes own connections that need to be routed with higher COS than the local node's connections, a 45 second wait period is started. This gives the remote nodes time to bump and route their connections before the local node attempts to bump. If no higher COS connections need to be routed, then the first node may proceed without waiting.

When the first node proceeds, it builds a list of up to N connections at this COS, including connections owned by other nodes. It then starts the background network load analysis process to find connections to deroute to make room for the connections on this list. It then starts a slow background timer to watch for excessively long processing.

If the timer expires before the background process completes, an error is logged, and the background process is aborted to be run again later. If the background process completes, then it returns a list of any connections to be derouted (bumped) to make room. This list of connections is used to send bump messages to each node that masters those connections. A broadcast message is sent to all nodes with the COS of the bumping connections to prevent lower COS connections from routing when bumping frees bandwidth.

The background process also returns a list of the local connections that could be routed. When any of the local connections cannot be routed, their connection state is changed to indicate they failed as a result of being bumped This indicates that they should be analyzed for bump routing at a less frequent rate than other non-routable connections.

If there were connections owned locally that now should be routable, then a 15 second wait timer is set to allow the derouted connections time to send out updates. Finally at the end of this period of time, the rerouting process is started to allow it to route the connections.

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.

The criteria used to select a route between two controller cards are as follows.

1. The network selects the route with the fewest trunks that restrict controller traffic. A user may want to restrict a trunk that uses almost all of its bandwidth for customer traffic from carrying inter-node traffic to free up the bandwidth. This is done with the Restrict CC Traffic parameter in the Configure Trunk (cnftrk) command.
   

2. The network then considers the route with the fewest satellite trunks. A satellite trunk is entered in the Link type option of the Configure Trunk (cnftrk) command. The network has no way of determining whether a trunk actually uses a satellite.
   

3. The network then selects the route with the biggest "choke point." The network determines for every route, a "choke point", which is the trunk that has the least total bandwidth capacity. The network then selects the route with the least restrictive choke point.
   

4. The network then selects the route with the least total number of hops.
   

5. If there are still choices available, internode communication will travel over the lowest numbered trunk (of the choices being considered) on the node that has the lowest number of the two nodes.
   

Every packet or cell that is sent between node controllers is acknowledged by the recipient. The maximum time that a controller will wait for an acknowledgment is 1.7 seconds. If no acknowledgment is received in time, the node will retransmit the packet/cell and wait another 1.7 seconds.

The maximum number of attempts, 5 or 7, depending on whether there are satellite trunks in the communication path between the nodes or not. If acknowledgment is received after the maximum allowed attempts, the far node is declared unreachable. This represents a communication break condition.

Bandwidth Allocation

One of the benefits of the IPX 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 IPX network is somewhat difficult to predict, StrataCom has developed a software Network Modeling Tool (NMT). This allows the user to analyze his proposed network 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 IPX nodes 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.
  

E1 Framed:

• 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.
  

E1 Unframed:

• The available bandwidth is 2.048 Mbps.
  

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

Subrate:

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

Table 13-7 : Subrate Packet Line Bandwidth

DS0s	BW	DS0s	BW	DS0s	BW	DS0s	BW
1	n/a	9	3000	17	5666	25	8333
2	n/a	10	3333	18	6000	26	8666
3	n/a	11	3666	19	6333	27	9000
4	1333	12	4000	20	6666	28	9333
5	1666	13	4333	21	7000	29	9666
6	2000	14	4666	22	7333	30	10000
7	2333	15	5000	23	7666	31	10333
8	2666	16	5333	24	8000	32	10666