HP 3000 Manuals HP 3000 Manuals
Direct Access to Level 3 (X.25)
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, anopt 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 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 describes the order of NetIPC calls used for a
server program.
NOTE Note that Figures 1-10 through 1-11 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 of this
manual for programmatic examples of a server and requestor using
access to the X.25 protocol.
SVC Requestor Example. Figure 1-10 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 perform the following
functions:
1. Create a call socket with IPCCREATE. The call socket descriptor (
calldesc) is returned.
2. Create a destination descriptor socket ( destdesc) with IPCDEST.
You must specify a remote protocol relative address ( protoaddr)
to be associated with the destination descriptor.
3. Establish the virtual circuit socket with IPCCONNECT, supplying
the calldesc and destdesc created by the previous two calls.
4. Receive a response to the connection request with IPCRECV, setting
the data length parameter ( dlen) equal to zero.
5. Send a message over the connection with IPCSEND.
6. Receive a message over the connection with IPCRECV.
7. 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.
![[X25REQ]](../../pic3k/M010427/X25REQ.gif)
Figure 1-10. SVC Requestor Processing Example
SVC Server Example. Figure 1-11 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 perform the following functions:
1. 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.
2. 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).
3. As IPCRECVCN completes and returns a vcdesc, X.25 sends the
requestor process a call accepted packet.
4. Receive a message over the connection with IPCRECV.
5. Send a message over the connection with IPCSEND.
6. Since the server (IPCRECV) in this example waits to receive a
message, you may decide to set a timer to handle the inactivity.
7. (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.
![[X25SERV]](../../pic3k/M010427/X25SERV.gif)
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:
1. Create a call socket with IPCCREATE. The call socket descriptor (
calldesc) is returned.
2. Create a destination descriptor socket ( destdesc) with IPCDEST.
3. Establish the virtual circuit socket with IPCCONNECT, supplying
the calldesc and destdesc created by the previous two calls.
4. Send a reset packet (to the DCE) by setting the reset request in
IPCCONTROL.
5. Send an interrupt packet to the remote process by setting the
interrupt request in IPCCONTROL.
6. Send data over the connection with IPCSEND.
7. Receive data over the connection with IPCRECV.
8. Send a reset packet by setting the reset request in IPCCONTROL
when all data has been sent/received.
9. 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 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, 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.
![[X25CUD]](../../pic3k/M010427/X25CUD.gif)
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 is an example of the sequence of calls used with 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 is an example
using fast select with restriction.
LOCAL NETWORK REMOTE
IPCCONNECT CALL IPCRECVCN
(fast select no ----------> (defer conn.)
restriction) 128 bytes CUD (Returns CUD,
(128 bytes of facilities, address)
CUD)
IPCRECV CALL Conf. IPCCONTROL
(Returns CUD) <----------- (accept)
128 bytes CUD (128 bytes of CUD)
Connection is now established, either side can close:
IPCSHUTDOWN CLEAR IPCRECV
(128 bytes of -----------> (Completes in
CUD) 128 bytes CUD error)
IPCCONTROL
(reason)
(Returns CUD)
IPCSHUTDOWN
Figure 1-13. Fast Select No Restriction
LOCAL NETWORK REMOTE
IPCCONNECT CALL
(fast select ------------->
with restriction 128 bytes CUD
128 bytes of
CUD)
IPCRECVCN (defer conn.)
(Returns CUD,
facilities, address)
IPCCONTROL
(reject)
(128 bytes of CUD)
IPCRECV CLEAR
(returns error) <-------------
128 bytes CUD
IPCCONTROL
(reason)
(returns CUD)
IPCSHUTDOWN
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 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.