Lucent Technologies DEFINITY Enterprise Communications Server Release 5, CallVisor, ASAI Protocol Reference Instructions Manual

							The ECS Congestion and Flow Control on ASAI Links
Issue 6 June 1997
6-5
If the adjunct sends a STATUS ENQuiry message to the ECS, on a BRI ASAI 
interface, the ECS treats the STATUS ENQuiry as an unexpected message and 
responds as Chapter 5 describes.
Layer 3 Timers
The only layer 3 BRI Timer that the ECS ASAI uses is T316, the retry timer for 
RESTart. T316 has a value of 120 seconds. None of the BRI Management timers 
are used.
The ECS adjunct routing application also makes use of an application-level timer. 
Once this timer expires, a Cause with value ‘‘Timer Expiry’’ may be sent across 
the ASAI interface.
The ECS Congestion and Flow Control 
on ASAI Links
ECS Controls on Receive Traffic
This section describes the ECS congestion controls on incoming ASAI traffic (that 
is, from adjuncts to the ECS) in the following situations:
nTotal incoming traffic causes ECS Central Processing Unit (CPU) 
congestion
nLayer 2 Processor congestion
nSingle link congestion (hyperactivity)
ECS CPU Congestion on Received Data
The ECS automatically applies ECS congestion (overload) controls when the 
processor occupancy for call processing tasks exceeds a predefined threshold 
over a period of time. The measured call processing occupancy (which is 
compared to the threshold) is a collective measurement of the occupancy of all 
call processing-related ECS services, such as ASAI, telephone stations, and 
trunks. Therefore, while ASAI may not be a major contributor to the ECS 
congestion, the overload control affects ASAI interfaces.
The ECS congestion controls prevent new originations (that is, new calls and new 
ASAI associations). Established calls and ASAI associations are not affected by 
the overload controls.
During an overload control condition, the ECS denies requests for additional ASAI 
feature access as follows: 
						

							Maintenance
6-6Issue 6 June 1997 
nWhen the ECS receives an ASAI message that begins a new association 
(for example, REGister message), it is discarded and the ECS responds 
with a RELease COMplete Message containing Q.931 Cause Value 42 
(Coding Standard 0/Network Congestion).
nWhen the ECS receives a FACility message with a Domain Control 
Auto-Dial Request, it is discarded and the ECS responds with a FACility 
Message containing Q.931 Cause Value 42 (Coding Standard 0/Network 
Congestion). 
ASAI associations opened prior to the congestion event were processed normally.
Adjuncts should provide complementary overload controls. Instead of immediately 
requesting the same service or other services (which may further aggravate the 
ECS congestion), an adjunct could refrain from sending such requests to the ECS 
for a short period of time after receiving a message containing Cause 42.
Layer 2 Processor Congestion on Received Data
The layer 2 (L2) processor uses a common buffer pool for receiving frames from 
all active links (including ASAI). The availability of buffers determines whether the 
L2 processor is congested. The L2 processor compares buffer usage against a 
threshold. When the number of buffers in use reaches the threshold, the ECS 
CPU is informed, and this causes the ECS processor to activate the congestion 
control described above. The congestion control is released when the buffer level 
returns to a normal operating range.
Exhaustion of all buffers in the L2 processor receive buffer pool causes the L2 
processor to take additional flow control action on selected links. If total 
exhaustion occurs, the L2 processor sends a Receiver Not Ready (RNR) frame to 
each link over which it has received a frame. The L2 processor keeps track of the 
links to which to send an RNR. When the buffer level returns to a normal operating 
range, the L2 processor sends a Receiver Ready (RR) frame on these 
flow-controlled links.
Link Congestion (Hyperactivity) —
Received Data
The ECS enables link congestion controls when traffic is greater than expected on 
an individual link. These controls prevent a single link from taking an inequitable 
share of the ECS resources (that is, processing power or buffers).
The L2 processor monitors the number of frames (Info, Supervisory, UI) received 
over each active link in a per unit time period.   If the number of frames exceeds a 
specified threshold for the link, the L2 processor declares that link to be 
‘‘hyperactive.’’ 
						

							The ECS Congestion and Flow Control on ASAI Links
Issue 6 June 1997
6-7
For hyperactive ASAI links, the L2 processor takes two actions:
1. It flow controls the link by sending an RNR to the link endpoint each time a 
frame is received from the endpoint.
2. It reports the hyperactivity event to the ECS CPU.
The L2 processor continues to flow control the link until the ECS processor 
notifies it to withdraw hyperactivity control on that link. The ECS waits a 
designated period of time (in seconds) after a hyperactivity event before it notifies 
the L2 processor to resume normal processing on the link. The L2 processor 
transmits an RR frame on the link to resume normal link activity.
ASAI adjuncts must recognize and respect this control by suspending info frame 
transmission until receiving an RR across the link.
The ECS maintenance software keeps track of the frequency of hyperactivity 
events on each BRI link. ASAI hyperactivity is most likely due to fluctuations in 
adjunct traffic or under-engineering of the link traffic parameters rather than faulty 
hardware. The current hyperactivity strategy for ASAI is to monitor the frequency 
of hyperactivity on the links, and alarm links with persistent hyperactivity, but keep 
such links in service. ASAI link alarms for hyperactivity should alert technicians 
and system administrators that traffic re-engineering for that link is required.
Parameters controlling the hyperactivity strategy for ASAI are:
nPrior to G3V4, the L2 processor uses the threshold level of 80 frames per 
five seconds to detect hyperactivity for G3i, and 50 frames per second for 
G3r. Starting with Release
 G3V4, the frames (messages per second) are 
higher: 160 frames per five seconds for G3i, and 200 frames per second for 
G3r. For Ethernet, these numbers are the same.
nThe time for which hyperactivity controls (flow control of the link by sending 
RNRs) are applied by the L2 processor after detecting a hyperactive link is 
20 seconds. 
nThe frequency (rate) of hyperactive events for a link which triggers 
maintenance to raise an alarm is five events over a 15-minute period.
nThe length of time to retire a hyperactivity alarm on a link is approximately 
one hour.
n(R5 only) If an ASAI link is reestablished more than three times within a five 
second interval, then the link is considered hyperactive and is taken out of 
service.
NOTE:
These parameter values are not set on a per ASAI link basis; common 
values are defined for all ASAI links. 
						

							Maintenance
6-8Issue 6 June 1997 
Controls on Send Traffic
This section discusses the ECS congestion controls for traffic from the ECS 
toward the adjuncts (the transmit direction):
1. Over all links (that is, the ECS congestion).
2. Over a single link (that is, link congestion).
Layer 2 Processor Congestion on Send Traffic
L2 processor congestion in the transmit direction (toward adjuncts) is measured 
by the number of available transmit buffers. A common buffer pool is used by the 
L2 processor for transmitting frames to all links (including ASAI). Exhausting all 
the buffers in the L2 processor transmit buffer pool results in the ASAI software 
receiving an indication of the condition. If ASAI discards a frame, the ECS 
maintenance is notified and takes corrective action.
Link Congestion on Send Traffic
Congestion on a single link occurs when the number of L2 buffers queued for 
transmission over a link exceeds a threshold. A thresholding mechanism is used 
such that when a low water-mark is reached, all new initiating associations on that 
link are denied. Further, when a high water-mark is reached, the ECS is no longer 
able to buffer messages and they are dropped.
The congestion of a single link is likely NOT due to traffic overflow by the ECS, but 
occurs when the L2 processor stops frame transmission in response to adjunct 
flow control. The adjunct can withhold an L2 acknowledgment or transmit an RNR 
frame to cause such a situation.
The threshold parameters for link transmit queues are as follows: The value of the 
low water-mark is 25 (R5i) and 75 (R5r). The value of the high water-mark is 75 
(R5i) and 150 (R5r). These parameters are not individually set for each ASAI link; 
common values are defined for all ASAI links. 
						

							Issue  6 June 19977-1
7
TCP Tunnel Protocol
Overview
This chapter describes version 1 of the TCP tunnel protocol.
CallVisor ASAI over the DEFINITY LAN Gateway is a communications interface 
that provides the functionality of the Adjunct/Switch Application Interface (ASAI) 
using an Ethernet transport instead of a Basic Rate Interface (BRI) transport.
DEFINITY LAN Gateway uses a TCP tunnel protocol in addition to the protocols 
defined by ASAI for layer 3 Q.931/2. This tunnel protocol works as follows: Before 
a client connects, the DEFINITY LAN Gateway application or brouter
1 issues 
ICMP Echo Request packets (that is, ‘‘ping’’) to each administered client to 
determine whether the client can be reached. As long as the ICMP Echo Request 
packets are being answered (by ICMP Echo Reply packets), the brouter reports to 
DEFINITY ECS that layer 1 is up for a particular virtual BRI port. If ICMP Echo 
Request packets are not being answered, then layer 1 is reported as down.
The software used by CallVisor ASAI over the DEFINITY LAN Gateway is shipped 
from the factory with a default IP address of 192.168.25.10 and a default 
hostname ‘‘definity.’’ It is also shipped with a default client IP address of 
192.168.25.20 and hostname ‘‘client.’’ The brouter listens for connections from 
clients on TCP port number 5678.   The client must establish a TCP connection to 
the brouter at this port and IP address. The customer may change the IP address 
and/or hostname, but the TCP port is fixed.   
In addition to the normal TCP mechanism for establishing a connection, the 
brouter imposes its own protocol for all clients. Once the client has used the 
protocol to request service and the brouter has accepted the request, an 
1.The term “brouter” is synonymous with DEFINITY LAN Gateway application. For brevity, 
“brouter” is used throughout this chapter. 
						

							TCP Tunnel Protocol
7-2Issue  6 June 1997 
ASAI-Ethernet connection is established, and pinging of the client ceases for that 
link. It resumes when the ASAI-Ethernet connection is closed. Since the 
ASAI-Ethernet connection rides on top of the TCP connection, closing the TCP 
connection terminates the ASAI-Ethernet connection.
TCP only insures the reliable delivery of a data stream, yet ASAI protocol expects 
to interact in complete messages. To overcome this mismatch, both the client and 
brouter must ensure that an entire message is sent or received before processing 
a subsequent message.
All network communication between clients and the brouter is 
message-oriented.   A small number of messages are used in the TCP tunnel 
protocol, each of which is prefixed by a 4-octet header as shown in Table 7-1. All 
four octets of the header are always present on each message, even if they are 
not used. 
NOTE:
‘‘Brouter’’ and ‘‘server’’ are used interchangeably in this chapter.
These octets are explained as follows:
nOctet 1 contains the Message Type. Values are provided as an 8-bit 
unsigned integer.
nOctet 2 contains a Message Cause. Values are provided as an 8-bit 
unsigned integer.
nOctets 3 and 4 contain an Additional Data Size. This size represents the 
number of additional octets of data that are part of this Tunnel Protocol 
message. Octets 3 and 4 are used together to represent a 16-bit unsigned 
integer in network byte order.
nAdditional Data may follow the above four octets. There must be exactly the 
number of octets of Additional Data indicated in the Additional Data Size. 
All values for additional data are provided as single octet unsigned integers 
unless explicitly stated otherwise.
Table 7-1. TCP Tunnel Protocol Header Format
Octet 1 Octet 2 Octet 3 Octet 4Add’l Data...
Message Type Message CauseAdd’l Data Size
High OctetAdd’l Data Size
Low OctetAdd’l Data ...
(defined by type) 
						

							Overview
Issue  6 June 1997
7-3
Table 7-2 that follows lists the message types. A single asterisk (*) next to a 
message indicates that it is sent only by the server. A double asterisk (**) means 
that it is sent only by the client.
Table 7-2. TCP Tunnel Protocol Message Header Values 
Octet 1 value
Message Type
Value and DescriptionOctet 2 value
Message Cause
Value and DescriptionOctet 3 and 4 value
Additional Octet Count
Value and Description
0
Error Notification
The server will 
immediately close the 
TCP connection.1
Client too slow
The server established a 
TCP connection but did 
not receive the first TCP 
Tunnel Protocol message 
quickly enough.0
No additional data.
2
Out of service
A connected 
ASAI-Ethernet connection 
was taken out of service 
on the brouter.0
No additional data.
3
Invalid type
A message with an invalid 
type has arrived on this 
connection.1
Octet 5 contains the 
offending message type.
4
Invalid cause
A message with an invalid 
cause has arrived on this 
connection.2
Octet 5 contains the 
offending message type.
Octet 6 contains the 
offending message cause.
5
No reply to heartbeat
A ‘‘heartbeat reply’’ was 
not received within the 
allotted time.0
No additional data.
(Continued on next page) 
						

							TCP Tunnel Protocol
7-4Issue  6 June 1997 
6
Too much (or little) data
The octet count specified 
exceeds the maximum 
allowable for a particular 
message type/cause, or 
the size was not sufficient 
for the particular message 
type.6
Octet 5 contains the 
offending message type.
Octet 6 contains the 
offending message cause. 
Octets 7 and 8 contain the 
offending octet count as a 
16-bit unsigned integer in 
network byte order.
Octets 9 and 10 contain 
the maximum octet count 
as a 16-bit unsigned 
integer in network byte 
order.
7
Invalid client
The client is not 
administered on the 
brouter.0
No additional data.
8
New connection made
A new connection has 
been accepted for the 
same host/link as an 
existing ASAI-Ethernet 
connection. This 
message will be sent on 
the old ASAI-Ethernet 
connection.0
No additional data.
9
Invalid Context 
A TCP tunnel protocol 
message was received by 
the server at an 
inopportune time.2
Octet 5 contains the 
inopportune message 
type.
Octet 6 contains the 
inopportune message 
cause.
(Continued on next page)
Table 7-2. TCP Tunnel Protocol Message Header Values  — (Continued)
Octet 1 value
Message Type
Value and DescriptionOctet 2 value
Message Cause
Value and DescriptionOctet 3 and 4 value
Additional Octet Count
Value and Description 
						

							Overview
Issue  6 June 1997
7-5
255
Server error
The server experienced 
an internal error. 
Reconnecting may 
eliminate the error 
condition.0
No additional data.
1
Connection Request**
A client uses this message 
type to request an 
ASAI-Ethernet connection.0
Not used.2
Octet 5 contains the 
client’s link number.
Octet 6 contains the 
client’s TCP Tunnel 
protocol version number.
2
Connection Accepted*
The server has accepted 
the connection request.10
Link up
ASAI data messages can 
now be exchanged.0
No additional data.
11
Link Down
ASAI data messages 
cannot be exchanged.1
Octet 5 contains the link 
down reason.
Octet 5 Value and 
Description:
101 DEFINITY ECS is 
down.
102 Virtual BRI port    
administered.
103 DEFINITY ECS has 
taken layer 2 down.
104 Virtual BRI port 
busied-out on 
DEFINITY LAN 
Gateway system 
assembly.
(Continued on next page)
Table 7-2. TCP Tunnel Protocol Message Header Values  — (Continued)
Octet 1 value
Message Type
Value and DescriptionOctet 2 value
Message Cause
Value and DescriptionOctet 3 and 4 value
Additional Octet Count
Value and Description 
						

							TCP Tunnel Protocol
7-6Issue  6 June 1997 
3
Connection Rejected*
The server has rejected 
the connection request, 
and will close the TCP 
connection.12
Invalid link
The requesting client’s link 
number is unknown to the 
server.0
No additional data.
2
Out of service
The requested link 
number has been taken 
out of service on the 
brouter.0
No additional data.
13
Unsupported TCP Tunnel 
Protocol version
The client’s TCP Tunnel 
protocol version is not 
supported by the server.1
Octet 5 contains the 
server’s TCP Tunnel 
protocol version number.
4
Disconnect Notification**
Used to inform the server 
that the client no longer 
needs an ASAI-Ethernet 
connection. The server will 
immediately close the 
TCP connection upon 
receipt.0
Not used.0
No additional data.
5
Link Status*
The server sends this 
message any time the 
status of a link changes. 
The ASAI-Ethernet 
connection remains up.10
Link up
ASAI data messages can 
now be exchanged.0
No additional data.
(Continued on next page)
Table 7-2. TCP Tunnel Protocol Message Header Values  — (Continued)
Octet 1 value
Message Type
Value and DescriptionOctet 2 value
Message Cause
Value and DescriptionOctet 3 and 4 value
Additional Octet Count
Value and Description