NetIPC 3000/XL Programmer's Reference Manual:
HP 3000 MPE/iX Computer Systems > Chapter 1 NetIPC Fundamentals

Direct Access to Level 3 (X.25)

	MPE documents
	Complete PDF

	Table of Contents
	Glossary
	Index

⇓ Page Bottom

⇑ Page Top

Features

The following features of direct access to level 3 (X.25) with NetIPC are described in this section:

Supports switched virtual circuits (SVCs) and permanent virtual circuits (PVCs).

Provides access to the call user data (CUD) field in call packets.

Provides access to X.25 addresses in call packets.

Creation of a catch-all socket which can be used to accept data packets with no CUD or unrecognized CUD.

Provides ability to send up to 128 bytes of call user data using the fast select facility.

Provides ability to append, generate and examine the facility field in call packets.

Provides access to X.25 protocol features.

Allows direct specification of the target X.25 address or PVC number.

Limitations

Limitations using direct access to level 3 (X.25) are:

Intranet use only (level 4 provides internet and intranet connections)

One virtual connection socket accesses one X.25 virtual circuit for data transfers over X.25. Multiplexing of connections over a virtual circuit is not supported.

IPCNAME, IPCNAMERASE and IPCLOOKUP are not supported.

Switched Virtual Circuits (SVCs)

Switched virtual circuits are defined as a logical association that only exists as long as the connection does. Both processes create their own local call sockets using IPCCREATE that can be associated with protocol relative addresses. To establish a connection with a specific server process, a request process must include a server protocol relative address in the IPCDEST intrinsic. Alternatively, an opt parameter in IPCCREATE can be used to create a catch-all socket where any incoming request for a connection can be accepted (whether or not the server protocol relative address exists). A catch-all socket receives incoming call requests that do not match any other given protocol relative address. One catch-all socket can be defined for each X.25 network.

As an example, two programs communicating over an SVC can be designated as the requester and server. Both programs need to be running in order for communication to occur. Figure 1-10 "SVC Requestor Processing Example" shows the order of NetIPC calls used for a requestor program and the X.25 packets generated as a result of the calls. Figure 1-11 "SVC Server Processing Example" describes the order of NetIPC calls used for a server program.

NOTE: Note that Figure 1-10 "SVC Requestor Processing Example" and Figure 1-11 "SVC Server Processing Example" do not show synchronization of data transfer between the two programs, and do not include error checking, or the intrinsic calls required for adding options and special user capabilities. See example 3 in Chapter 4 "NetIPC Examples" of this manual for programmatic examples of a server and requestor using access to the X.25 protocol.

SVC Requestor Example

Figure 1-10 "SVC Requestor Processing Example" shows the order of NetIPC calls used for a requestor program and the X.25 packets generated as a result of the calls. The calls outlined in Figure 1-10 "SVC Requestor Processing Example" perform the following functions:

Create a call socket with IPCCREATE. The call socket descriptor (calldesc) is returned.

Create a destination descriptor socket (destdesc) with IPCDEST. You must specify a remote protocol relative address (protoaddr) to be associated with the destination descriptor.

Establish the virtual circuit socket with IPCCONNECT, supplying the calldesc and destdesc created by the previous two calls.

Receive a response to the connection request with IPCRECV, setting the data length parameter (dlen) equal to zero.

Send a message over the connection with IPCSEND.

Receive a message over the connection with IPCRECV.

Shutdown the connection with IPCSHUTDOWN. Cause and diagnostic values and/or clear user data can be entered that will be included in an X.25 clear packet sent as a result of this call.

Figure 1-10 SVC Requestor Processing Example

SVC Server Example

Figure 1-11 "SVC Server Processing Example" shows the order of NetIPC calls used for a server program and the X.25 packets generated as a result of the calls. The calls outlined in Figure 1-11 "SVC Server Processing Example" perform the following functions:

Create a call socket with IPCCREATE. The call socket descriptor (calldesc) is returned. The socket could be created as a catch-all and/or bound to a particular protocol relative address.

Call IPCRECVCN and wait for an incoming call request packet. IPCRECVCN will return a VC descriptor (vcdesc) when it is established that the incoming protocol relative address defined in (1) matches the incoming protocol relative address, or a catch-all socket was created in (1).

As IPCRECVCN completes and returns a vcdesc, X.25 sends the requestor process a call accepted packet.

Receive a message over the connection with IPCRECV.

Send a message over the connection with IPCSEND.

Since the server (IPCRECV) in this example waits to receive a message, you may decide to set a timer to handle the inactivity.

(Optional step.) Shutdown the connection with IPCSHUTDOWN after data has not been received for a period of time. (For example, after a timeout has occurred.) Note that the X.25 protocol implicitly handles the incoming clear request by sending a clear confirmation packet.

Figure 1-11 SVC Server Processing Example

Permanent Virtual Circuits (PVCs)

Permanent virtual circuits are defined as two DTEs with a logical association permanently held by the network. Since the connection is permanent, both processes must initiate the connection using the IPCCREATE intrinsic. Both processes must specify the destination of a connection request with the IPCDEST intrinsic which requires a node name corresponding to a configured PVC number.

The possible ordering of intrinsic calls to communicate over a PVC could be as follows:

Create a call socket with IPCCREATE. The call socket descriptor (calldesc) is returned.

Create a destination descriptor socket (destdesc) with IPCDEST.

Establish the virtual circuit socket with IPCCONNECT, supplying the calldesc and destdesc created by the previous two calls.

Send a reset packet (to the DCE) by setting the reset request in IPCCONTROL.

Send an interrupt packet to the remote process by setting the interrupt request in IPCCONTROL.

Send data over the connection with IPCSEND.

Receive data over the connection with IPCRECV.

Send a reset packet by setting the reset request in IPCCONTROL when all data has been sent/received.

Shutdown the connection with IPCSHUTDOWN. Note that a PVC is a permanent connection, and the shutdown process releases the resources associated with the connection.

Note that these steps do not show how to synchronize data transfer between the two programs, and do not include error checking, or the intrinsic calls required for adding options and special user capabilities.

Access to the Call User Data (CUD) Field

The NetIPC intrinsics IPCCONNECT, IPCRECVCN, IPCCONTROL, IPCRECV (on connection establishment), and IPCSHUTDOWN (with fast select) provide access to the call user data (CUD) field in call packets as follows:

Specifying a protocol relative address in the CUD.
This field may be present in X.25 call request and incoming call packets which you can access with IPCCONNECT and IPCRECVCN. The call user data field can only be accessed over an SVC. The maximum length of the call user data (CUD) field is normally 16 bytes. The CUD can be up to 128 bytes if the fast select facility is available. For NS X.25, the first four bytes of the CUD are reserved for protocol relative addressing. Figure 1-12 "NS X.25 Call User Data Field (four bytes)" shows the contents of the first four bytes of the HP 3000 X.25 CUD. The first two bytes, as shown in Figure 1-12 "NS X.25 Call User Data Field (four bytes)", indicate that the source of the call request packet is an HP 3000 node using direct access to level 3. Optionally, the last two bytes contain the protocol relative address that the call request expects to find (if any).
To access the entire CUD (16 bytes without fast select or 128 bytes with fast select), the opt parameter protocol flags bit 17 can be set in IPCCONNECT. This option is useful for communication with non-HP nodes.
See the discussion of the Fast Select Facility for examples using NetIPC intrinsics to send and/or receive call user data using fast select.

Figure 1-12 NS X.25 Call User Data Field (four bytes)

Connecting to a catch-all socket.
Using IPCCREATE, you can identify a socket as a catch-all socket. All incoming calls with a protocol relative address specified in the CUD that does not match any given protocol relative address are routed to the catch-all socket. Only one catch-all socket may be defined for each X.25 network on each node.
For an incoming call with a protocol relative address specified, NetIPC checks if the address matches one created. If it matches, the call is accepted. If it does not match, NetIPC checks for the existence of a catch-all socket. If no catch-all socket has been created, the call is rejected and a clear packet is sent by X.25. If a catch-all socket has been created, the call is accepted.
If no protocol address is specified in the incoming call, NetIPC checks for the existence of a catch-all socket. If no catch-all socket has been defined, the call is rejected. If there is a catch-all socket, the call is accepted.

Defer connection requests.
Using IPCRECVCN with the deferred flag set allows you to examine the call user data, facilities, and calling node address before accepting or rejecting the connection.
The IPCCONTROL intrinsic provides you with the capability to accept or reject a connection request that is in the deferred state.

Fast Select Facility

The fast select facility, a datagram service, is available over an X.25 network. Fast select is configured as a parameter in the X.25 User Facility Set Parameters screen during NMMGR configuration of X.25 on the HP 3000. (See the X.25 XL System Access Configuration Guide for more information.) When you use the fast select facility, up to 128 bytes of call user data may be sent in a X.25 call packet using NetIPC intrinsics.

Fast Select Options

Fast select has two options:

No restriction on response: allows the receiver of the connection request the choice of either accepting or rejecting the connection.

Restriction on response: the receiver must always reject the connection.

Using Fast Select

The receiver of the connection can use IPCRECVCN to examine the call user data, facilities or calling node's address before deciding to accept or reject the connection.

If the connection is accepted, up to 128 bytes of call user data may be placed in the call confirmation packet using IPCRECVCN. Once accepted, the virtual circuit is open and can be used as a virtual circuit that does not have fast select. The side that closes the connection can send 128 bytes of clear user data in the clear packet using the IPCSHUTDOWN call. Figure 1-13 "Fast Select No Restriction" is an example of the sequence of calls used with fast select, no restriction.

Figure 1-13 Fast Select No Restriction

If the connection is rejected, up to 128 bytes of clear user data may be put in the clear packet using IPCSHUTDOWN. Figure 1-14 "Fast Select Restricted" is an example using fast select with restriction.

Figure 1-14 Fast Select Restricted

Facility Field

The X.25 facility field is built from the facility set configured with NMMGR. With direct access to X.25 level 3, the facility field can be appended with facilities specified in the opt parameter of the IPCCONNECT intrinsic. The values for the facilities used must follow the X.25 recommendation.

For example, a user wants to use a facility set with packet size and window size negotiation and wants to append the CCITT-specified DTE facilities to that facility set. In NMMGR, the user has verified the facility set contains packet size and window size negotiation. The facility field generated from the facility set would contain the following (in octal):


 Facility length                           : %6
 Packet size neg code field                : %102
 Packet size in                            : %10
 Packet size out                           : %10
 Window size net code field                : %103
 Window size in                            : %7
 Window size out                           : %7

To add the DTE facilities, the user must specify all the bytes required by the X.25 recommendation in the IPCCONNECT request. In this example, to add the DTE facilities (calling address extension, called address extension and QOS end-to-end delay) the following values must be entered in the option field buffer (shown in octal):


 CCITT-specified DTE fac marker            : %17
 Calling add extension code                : %313
 Calling add extension length              : %3
 Calling add extension                     : %5
                                           : %5
 Called add extension code                 : %312
 Called add extension length               : %3
 Called add extension                      : %6
                                           : %6
 QOS minimum throughput                    : %12
 QOS throughput in/out                     : %314

NetIPC appends this to the facility-set generated field, and updates the "facility length". In this example, the facility length would be %21.

When a connection is received, the user can examine the entire facility field (see IPCRECV).

Access to X.25 Protocol Features

The NetIPC intrinsics provide access to the following X.25 protocol features:

Send and receive interrupt and reset packets.
You can request the X.25 protocol to send an interrupt or reset packet with IPCCONTROL. When used in this way, the IPCCONTROL intrinsic will not return until the appropriate confirmation packet is received by X.25.

Set no activity timeout.
You can set a no activity timeout value with the IPCCONTROL intrinsic. This option clears the connection after the specified time if no data packets are exchanged on the virtual circuit.

Qualifying X.25 data packets.
The Q bit in the general format identifier field in an X.25 data packet can be set using the IPCSEND intrinsic. The status of the Q bit in incoming data packets is returned in the IPCRECV intrinsic. The Q bit status can be used to indicate whether the data is a user message (Q bit=0) or a device control message (Q bit=1) from or to a remote PAD.

Set end-to-end acknowledgment.
The D bit in the general format identifier field in an X.25 data packet can be set using the IPCSEND intrinsic. The status of the D bit in incoming data packets is returned in the IPCRECV intrinsic.
Setting the D bit locally specifies end-to-end acknowledgment of data packets. IPCSEND does not complete until it receives acknowledgment that the entire message has been received. For HP 3000 to HP 3000 communication, IPCRECV initiates the acknowledgment when the remote HP 3000 process has received the entire message.

Set cause and diagnostic codes.
Using IPCSHUTDOWN, you can enter a reason code that will be included in X.25 clear packets as cause and diagnostic values. This option is only used with SVCs. Reasons for events or errors are returned by IPCCONTROL. See Appendix B "Cause and Diagnostic Codes" for a list of diagnostic codes used with X.25 protocol access. Note that when the DTE sends the clear packet, the cause code is always set to zero.