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

							Overview
Issue  6 June 1997
7-7
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    
busied-out or not 
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-8Issue  6 June 1997 
6
Heartbeat 
This message can be 
used to determine the 
health of an 
ASAI-Ethernet connection. 
Upon receipt it must 
immediately be 
responded to with a 
‘‘heartbeat reply’’ 
message.0-255Invoke ID 
This value is repeated by 
the 
Heartbeat Reply to 
allow correlating the 
response to the request.0
No additional data.
7
Heartbeat Reply
0-255
Invoke ID 
This value should be set to 
the same value as the 
Heartbeat Invoke ID 
received in the 
Heartbeat 
message.0
No additional data.
8
ASAI Data 
Used by both client and 
server to send ASAI data. 
The ASAI data must 
immediately follow this 
header. One and only one 
ASAI message should be 
sent with each 
ASAI Data 
message type.0
Not used.1-260
The actual ASAI message 
starts at Octet 5. One and 
only one ASAI message 
should be sent with each 
ASAI Data message 
header.
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 
						

							Tunnel Protocol Procedure
Issue  6 June 1997
7-9
Tunnel Protocol Procedure
The method by which the messages in Table 7-2 are exchanged in order to 
establish an ASAI-Ethernet connection for ASAI messages is as follows:
1. The client opens a TCP connection to port 5678 on host 
definity.
2. The brouter accepts the connection, and either retains it or sends an 
Error 
Notification
 message and closes the connection.   The normal case is to 
retain the connection. The 
Error Notification message may be sent at this 
point for any one of three cases: if the client does not send the 
Connection 
Request
 message within 30 seconds, if the client is invalid because it was 
not administered in the brouter, or if there is a server condition that 
prevents any connections from being made.
3. The client sends a 
Connection Request message type with octet 5 set to 
the client’s link number and octet 6 set to 1, the client’s TCP tunnel protocol 
version number.
4. The brouter responds with the 
Connection Accepted, Connection Rejected, 
or 
Error Notification Message. The normal case is to accept the 
connection. If the connection is accepted, then a link-up/down indication is 
provided. If the link is down, the reason for being down is provided, and 
exchange of ASAI data is deferred until a 
Link Status - Link Up message is 
received. The connection may be rejected because of an invalid client-link 
pair, because the assigned virtual BRI port is out of service (either on 
DEFINITY ECS or on the DEFINITY LAN Gateway system assembly), or 
because an unsupported version of the tunnel protocol was requested.   
The 
Error Notification message may also be sent at this point because the 
Connection Request was not received within 30 seconds after the client 
connected.
5. The client and server have now established an ASAI-Ethernet connection. 
If the connection was established with a 
Link Up cause, or if a subsequent 
Link Status message is received with a Link Up cause, then the link is up. 
When this is the case, either side may initiate the sending of 
ASAI Data 
messages and both sides should be prepared to receive them.   Each 
piece of ASAI data that is sent must be prefixed by the 
ASAI Data message 
header with octets 3 and 4 set to the octet count of the ASAI data. The 
actual ASAI data must immediately follow the message header. One, and 
only one, ASAI message should be sent with each 
ASAI Data message 
header.   The initial 
ASAI Data messages transport the Q.931 RESTart 
messages. For more information on the ASAI Q.931 protocol, refer to the 
earlier chapters in this guide.
6. While the ASAI-Ethernet connection is established, the client may be sent 
various messages. If an 
Error Notification message is sent, a cause is 
provided and the TCP connection is closed.   If a 
Link Status message is 
sent indicating that the ASAI link is down, the client may either wait for 
another 
Link Status message that indicates that the ASAI link is up once 
again, or it may abort the connection. There is diagnostic information 
provided in octet 5 of the 
Link Down message that can help an application  
						

							TCP Tunnel Protocol
7-10Issue  6 June 1997 
decide whether to wait or to abort the connection. Finally, a Heartbeat 
message may be sent, and should be replied to immediately with a 
Heartbeat Reply message. Additional information about Heartbeat 
messages follows in this chapter.
7. When the client decides to terminate the connection, it should send a 
Disconnect Notification message. The client is free to immediately close its 
TCP connection after sending this message.
8. Upon receipt of the 
Disconnect Notification message, the server 
immediately closes the TCP connection and listens for a new one.
Sample Message Exchange Scenarios
This section provides examples of message exchange scenarios. For each 
scenario, the protocol interaction is presented, followed by a table showing the 
messages exchanged, their sequence, and their direction. Within each table, the 
TCP Tunnel Protocol Messages are provided both as text and as an octet 
sequence.
Successful Connection Scenario
An example of a typical successful connection scenario is as follows:
nThe client opens a TCP connection to port 5678 on host definity.
nThe client sends a Connection Request message with octet 5 set to the 
client’s link number (3) and octet 6 set to the client’s TCP tunnel protocol 
version number (1).
nThe brouter responds with a Connection Accepted message with the cause 
set to 
Link Up.
nThe client and server have now established an ASAI-Ethernet connection. 
Either side may initiate the sending of 
ASAI Data messages in order to 
restart Q.931 layer 3 and bring up ASAI, and both sides should be 
prepared to receive them. Each piece of ASAI data that is sent must be 
prefixed by the 
ASAI Data message header with octets 3 and 4 set to the 
octet count of the ASAI data. The actual ASAI data must immediately follow 
the message header. One and only one ASAI message should be sent with 
each 
ASAI Data message header.
nWhen the client decides to terminate the connection it should send a 
Disconnect Notification message. The client is free to immediately close its 
TCP connection after sending this message.
nUpon receipt of the Disconnect Notification message, the server 
immediately closes the TCP connection and listens for a new one. 
						

							Tunnel Protocol Procedure
Issue  6 June 1997
7-11
Table 7-3. Typical Successful Connection Scenario
Client Connects While ASAI Link is Down
A typical scenario of a client connecting while its ASAI link is down follows:
nThe client opens a TCP connection to port 5678 on host definity.
nClient sends server a Connection Request message with octet 5 set to the 
client’s link number (3) and octet 6 set to the client’s TCP Tunnel protocol 
version number (1).
nServer responds with a Connection Accepted message with the cause set 
to 
Link Down. Octet 5 indicates that the entire DEFINITY ECS switch is 
down (101). After the client receives this message it does not send any 
ASAI Data to the server until it receives a Link Status message with the 
cause set to 
Link Up.
nThe client receives a Link Status - Link Up message. Client
CTI-host, link 3, version 1 DirectionDEFINITY LAN Gateway
Definity, version 1
TCP Open to definity
Connection Request
1,0,0,2,3,1
Connection Accepted, Link Up
2,10,0,0
ASAI Data
 (Q.931 Msg.)
8,0,X,X,8,2...
ASAI Data (Q.931 Msg.)
8,0,X,X,8,2...
Disconnect Notification
4,0,0,0
Close (TCP) Close (TCP) 
						

							TCP Tunnel Protocol
7-12Issue  6 June 1997 
nThe client and server are now connected and bring up ASAI.
nEventually the client decides to terminate the connection and sends a 
Disconnect Notification message.
nBoth client and server close the TCP.
Table 7-4. ASAI-Link Down Scenario
Client
CTI-host, link 3, version 1 DirectionDEFINITY LAN Gateway
definity, version 1
TCP open to definity
Connection Request
1,0,0,2,3,1
Connection Accepted
Link Down
2,11,0,1,101
Link Status, Link Up
5,10,0,0
ASAI Data (Q.931 Msg.)
8,0,X,X,8,2....
ASAI Data (Q.931 Msg.)
8,0,X,X,8,2 ...
Disconnect Notification
4,0,0,0
Close (TCP) Close (TCP) 
						

							Tunnel Protocol Procedure
Issue  6 June 1997
7-13
Invalid TCP Tunnel Protocol Version Scenario
A typical scenario where a client connect request is rejected because of an 
unsupported tunnel protocol version follows:
nThe client opens a TCP connection to port 5678 on host definity.
nClient sends server a Connection Request message with octet 5 set to the 
client’s link number (3) and octet 6 set to the client’s TCP Tunnel protocol 
version number (2).
nServer responds with a Connection Rejected message with a cause of 
unsupported TCP Tunnel Protocol version, and closes the TCP connection.   
The client should also close the TCP connection. The cause indicates that 
the server does not support the client’s version of the TCP Tunnel protocol.
The server also returns the supported version of the TCP Tunnel protocol 
as octet 5 of the 
Connection Rejected message. The client should try 
reconnecting using this version of the protocol.
nThe client and server are not connected, so they close TCP.
Table 7-5. Invalid TCP Tunnel Protocol Version Scenario
Client
CTI-host, link 3, version 2 DirectionDEFINITY LAN Gateway
definity, version 1
TCP Open to definity
Connection Request
1,0,0,2,3,2
Connection Rejected, 
unsupported TCP Tunnel 
Protocol version
(1 is Supported)
3,3,0,1,1
Close (TCP) Close (TCP) 
						

							TCP Tunnel Protocol
7-14Issue  6 June 1997 
Error Notification Scenario
The server may send an Error Notification message and then close the 
connection at any time. The client should immediately close its TCP connection 
whenever it receives this message.
Table 7-6. Error Notification Scenario
Client
CTI-host, link 3, version 1 DirectionDEFINITY LAN Gateway
definity, version 1
ASAI Data (Q.931 Msg.)
8,0,X,X,8,2 ...
ASAI Data (Q.931 Msg.)
8,0,X,X,8,2 ...
Error Notification
0,2,0,0
Close (TCP) Close (TCP) 
						

							Tunnel Protocol Procedure
Issue  6 June 1997
7-15
ASAI Link Status Scenario
A typical scenario depicting changes in link status follows. Links may be 
unadministered or busied out at any time on DEFINITY ECS. Layer 2 may also be 
brought down on a hyperactive link by DEFINITY ECS.   To relay this change in 
link status, the server sends 
Link Status messages, which clients may receive at 
any time.
When a message arrives with the cause set to 
Link Down, the client should stop 
sending 
ASAI Data to the server. Any ASAI Data received by the server after it 
sends a 
Link Status message with the cause set to Link Down is discarded. When 
the link is brought back up, the server sends the client a 
Link Status message with 
the cause set to 
Link Up. At this time the client may again send/receive ASAI 
Data
, and either the client or e DEFINITY ECS must restart the ASAI Q.931 
protocol.
Table 7-7. ASAI Link Status Scenario
Client
CTI-host, link 3, version 1 DirectionDEFINITY LAN Gateway
definity, version 1
ASAI Data (Q.931 Msg.)
8,0,X,X,8,2 ...
ASAI Data (Q.931 Msg.)
8,0,X,X,8,2 ...
Link Status, Link Down, L2 
down
5,2,1,0,103
Link Status, Link Up
5,1,0,0
ASAI Data (Q.931 Msg.)
8,0,X,X,8,2 ...
ASAI Data (Q.931 Msg.)
8,0,X,X,8,2 ... 
						

							TCP Tunnel Protocol
7-16Issue  6 June 1997 
Network Outages
It is possible for an established TCP connection to be unable to pass data from 
client to server (or vice versa). A number of problems, including the following, can 
cause this situation:
nA router failure between client and server
nA physical media failure between client an server
nA failure in either the client or server
TCP can detect such conditions and close down the connection; however, this 
may take up to 15 minutes. 
CallVisor ASAI over the DEFINITY LAN Gateway is used to support real-time 
applications that cannot tolerate such delay in determining network outages. o 
compensate for TCP limitations, the TCP tunnel protocol uses a heartbeat 
procedure when message activity is low, and a reconnect procedure that favors 
new connections over existing ones.
Heartbeat Messages
The tunnel protocol defines a Heartbeat and a Heartbeat Reply message. These 
are in addition to the ASAI Q.931 
Heartbeat messages, which are transported 
using an 
ASAI Data Message that contains the ASAI Q.931 Heartbeat in its 
Additional Data. Both client and brouter may issue a 
Heartbeat message. The 
peer responds with a 
Heartbeat Reply message. Each Heartbeat message 
contains an 
Invoke ID, which must be repeated in its Heartbeat Reply message.
Heartbeat Message Procedure
The brouter employs the following strategy on each active ASAI-Ethernet 
connection to detect network or client outages:
nIf no messages are received on an ASAI-Ethernet connection in a 
20-second period, the brouter sends a 
Heartbeat message.
nIf the brouter does not receive a Heartbeat Reply (or other) message within 
10 seconds, it sends an 
Error Notification message, closes the TCP 
connection, and begins listening for a new connection.
NOTE:
The brouter will not close a connection if the Heartbeat Reply Invoke 
ID
 does not match that sent in the Heartbeat, nor does it close a 
connection if a message of any type is sent from the client in the 
10-second window. This behavior prevents ‘‘busy’’ clients from 
assuming additional overhead to support the heartbeat message 
procedure.