Chapter 6 NLI Commands and Structures
Solstice X.25 NLI provides a set of NLI commands. These are contained within C structures, which determine the format of the control parts of putmsg and getmsg. The NLI commands correspond to X.25 packet types. NLI commands are used to communicate with the network. For example, when an application passes down the NLI command N_CI to a stream using putmsg, this is translated into an X.25 Call Request by the PLP module. When the PLP module receives a Connect Indication, it translates it into an N_CI message which is passed up to the application using a getmsg system call.
The header files used by the NLI commands and structures are contained in the /usr/include/netx25 directory.
6.1 Commands and Structures Tables
Table 6-1 summarizes the NLI commands and their corresponding Packet Types and C structures:
Table 6-1 NLI Commands and Structures
These commands and structures in do not correspond to X.25 packet types:
Table 6-2 PVC and Listening Commands and Structures|
NLI Command |
NLI Structure |
Description |
|---|---|---|
|
N_PVC_ATTACH |
pvcattf |
Specify X.25 service to use with PVC |
|
N_PVC_DETACH |
pvcdetf |
Specify X.25 service to stop using with PVC |
|
N_Xcanlis |
xcanlisf |
Cancel listening |
|
N_Xlisten |
xlistenf |
Listen for incoming calls |
All of the structures listed in Table 6-1 and Table 6-2 are defined in the x25_primitives C union.
In addition to the structures that have a one-to-one mapping with NLI commands, Solstice X.25 provides a number of structures that are used by several of the commands. These are related to addressing and facilities, and are listed in Table 6-3:
Table 6-3 Generic Structures|
structure |
function |
|---|---|
|
xaddrf |
contains addressing information |
|
lsapformat |
defines the LSAP |
|
extraformat |
defines optional X.25 facilities |
|
qosformat |
defines OSI CONS Quality of Service (QOS) parameters |
6.2 x25_primitives C Union
The Solstice X.25 software provides a series of data structures that determine the control part of messages passed across the NLI. The format of the control part of messages passed across the NLI is defined by structures in the following C union.
union X25_primitives {
struct xcallf xcall; /* Connect Request/Indication */
struct xccnff xccnf; /* Connect Confirm/Response */
struct xdataf xdata; /* Normal, Q-bit, or D-bit data */
struct xdatacf xdatac; /* Data ack */
struct xedataf xedata; /* Expedited data */
struct xedatacf xedatac; /* Expedited data ack */
struct xrstf xrst; /* Reset Request/Indication */
struct xrscf xrscf; /* Reset Confirm/Response */
struct xdiscf xdisc; /* Disconnect Request/Indication */
struct xdcnff xdcnf; /* Disconnect Confirm */
struct xabortf abort; /* Abort Indication */
struct xlistenf xlisten; /* Listen Command/Response */
struct xcanlisf xcanlis; /* Cancel Command/Response */
struct pvcattf pvcatt; /* PVC Attach */
struct pvcdetf pvcdet; /* PVC Detach */
};
All structures begin with the same members, as shown below:
typedef struct xhdrf {
unsigned char xl_type; /* XL_CTL/XL_DAT */
unsigned char xl_command; /* Command */
} S_X25_HDR;
Messages to and from applications are classified as control messages or data messages. xl_type indicates whether a message is control or data using the values XL_CTL for control and XL_DAT for data. Within each classification, the message identity is indicated by the xl_command qualifier. The combination of xl_type and xl_command must be consistent.
When sending an NLI command to the x25 driver using putmsg, the size of the data structure is determined by the command, and clearly is known in advance. The .len member of the control buffer is used to hold this value, and the.maxlen member is not used.
When reading a message with the getmsg call, the type of message cannot be known before it is received, so a buffer large enough to hold any message should be supplied. Put the size of this buffer in the.maxlen member of the control buffer structure. The actual size of the message received will be placed in the.len member on return from the getmsg call. To ensure that the buffer will be large enough, declare it as being of type union X25_primitives.
Example 6-1 shows how a getmsg can be constructed.
Example 6-1 Constructing a getmsg
#include <stream.h>
#include <netx25/dx25_proto.h>
struct strbuf ctlb;
struct strbuf datab;
union X25_primitives buffer;
char data_buf[DATALEN];
.
.
.
ctlb.maxlen = sizeof (union X25_primitives);
ctlb.buf = (char *)buffer;
flag = MSG_ANY;
datab.maxlen = DATALEN;
datab.buf = data_buf;
getmsg (x25_fd, &ctlb, &datab, flag);
switch ((S_X25_HDR *)&buffer->xl_type) {
case N_Abort:
/* treat 'buffer' as an Abort message
* datab.len should be 0
*/
break;
case N_CI:
/* Treat 'buffer' as a Connect Indication
* data_buf[] contains Call User Data
* datab.len equals length of Call User Data
*/
break;
.
.
.
};
6.3 Generic Structures
The structures described in this section define addressing, facilities and QOS and are used by a number of the commands described in "6.4 NLI Commands".
6.3.1 xaddrf--Define Addressing
Addressing is defined by the xaddrf structure:
Example 6-2 xaddrf Structure
#define NSAPMAXSIZE 20
struct xaddrf {
uint32_t link_id;
unsigned char aflags;
struct lsapformat DTE_MAC;
unsigned char nsap_len;
unsigned char NSAP[NSAPMAXSIZE];
}
The members in the xaddrf structure are:
Table 6-4 Members of xaddrf Structure
6.3.2 lsapformat--Define an LSAP
The LSAP is defined by the lsapformat structure:
Example 6-3 lsapformat Structure
#define LSAPMAXSIZE 9
struct lsapformat {
uint8 lsap_len;
uint8 lsap_add[LSAPMAXSIZE];
};
The members of the lsapformat structure are:
Table 6-5 Members of lsapformat Structure
6.3.3 extraformat--Define Standard X.25 Facilities
Standard X.25 facilities are defined by the extraformat structure:
Example 6-4 extraformat Structure
#define MAX_NUI_LEN 64
#define MAX_RPOA_LEN 8
#define MAX_CUG_LEN 2
#define MAX_FAC_LEN 109
#define MAX_TARIFFS 4
#define MAX_CD_LEN MAX_TARIFFS * 4
#define MAX_SC_LEN MAX_TARIFFS * 8
#define MAX_MU_LEN 16
struct extraformat {
/* extraformat structure */
unsigned char fastselreq;
unsigned char restrictresponse;
unsigned char reversecharges
unsigned char pwoptions;
unsigned char locpacket, rempacket;
unsigned char locwsize , remwsize;
int nsdulimit;
unsigned char nui_len;
unsigned char nui_field[MAX_NUI_LEN];
unsigned char rpoa_len;
unsigned char rpoa_field[MAX_RPOA_LEN];
unsigned char cug_type;
unsigned char cug_field[MAX_CUG_LEN];
unsigned char reqcharging;
unsigned char chg_cd_len;
unsigned char chg_cd_field[MAX_CD_LEN];
unsigned char chg_sc_len;
unsigned char chg_sc_field[MAX_SC_LEN];
unsigned char chg_mu_len;
unsigned char chg_mu_field[MAX_MU_LEN];
unsigned char called_add_mod;
unsigned char call_redirect;
struct lsapformat called;
unsigned char call_deflect;
unsigned char x_fac_len;
unsigned char cg_fac_len;
unsigned char cd_fac_len;
unsigned char fac_field[MAX_FAC_LEN];
};
The members of this structure are defined as follows:
Table 6-6 Members of extraformat Structure
6.3.4 qosformat--Define OSI CONS QOS Parameters
OSI CONS-related quality-of-service parameters are defined in the quosformat structure:
#define MAX_PROT 32
struct qosformat {
unsigned char reqtclass;
unsigned char locthroughput, remthroughput;
unsigned char reqminthruput;
unsigned char locminthru, remminthru;
unsigned char reqtransitdelay;
unsigned short transitdelay;
unsigned char reqmaxtransitdelay;
unsigned short acceptable;
unsigned char reqpriority;
unsigned char reqprtygain;
unsigned char reqprtykeep;
unsigned char prtydata;
unsigned char prtygain;
unsigned char prtykeep;
unsigned char reqlowprtydata;
unsigned char reqlowprtygain;
unsigned char reqlowprtykeep;
unsigned char lowprtydata;
unsigned char lowprtygain;
unsigned char lowprtykeep;
unsigned char protection_type;
unsigned char prot_len;
unsigned char lowprot_len;
unsigned char protection[MAX_PROT];
unsigned char lowprotection[MAX_PROT];
unsigned char reqexpedited;
unsigned char reqackservice;
struct extraformat xtras;
};
The members of the qosformat structure are defined as follows:
Table 6-7 QOS Parameters|
Member |
Description |
|---|---|
|
reqtclass |
Indicates whether the throughput negotiation parameter is selected. 0 indicates that it is not selected. |
|
locthroughput |
Contains four-bit throughput encoding for local-to-remote calls. |
|
remthroughput |
Contains four-bit throughput encoding for remote-to-local calls. |
|
reqminthruput |
Indicates whether the minimum throughput negotiation parameter is selected. |
|
locminthru |
Contains four-bit throughput encoding for local to remote calls. |
|
remminthru |
Contains four-bit throughput encoding for remote to local calls. |
|
reqtransitdelay |
Indicates whether the transit delay parameter is selected. 0 indicates that it is not selected. |
|
transitdelay |
Contains the transit delay parameter as a 16-bit value. It is used in Call Requests and Indications and Confirms. |
|
reqmaxtransitdelay |
Indicates whether the calling NLI application specifies a maximum acceptable value for the transit delay parameter ("Lowest Quality Acceptable"). Note: The transit delay selection relates only to Call Requests and there is no transit delay QOS parameter in a Call Response primitive. The correct response when the indicated QOS is unattainable is to make a Clear Request. Also, in a Connect Confirm, the value of the selected transit delay will be placed in the transitdelay field when such negotiation takes place. |
|
acceptable |
Contains the maximum acceptable transit delay parameter, if this is specified by the calling NLI application. |
|
reqpriority |
Requests or indicates priority on a connection. 0 indicates that priority is not used. |
|
prtydata |
Contains the 8-bit value for the priority of data on the connection. |
|
reqprtygain |
Indicates that the field prtygain is used. |
|
reqprtykeep |
Indicates that the field prtykeep is used. |
|
prtygain |
Contains an 8-bit value for the priority to gain a connection. |
|
prtykeep |
Contains the 8-bit value priority to keep a connection. |
|
reqlowprtydata |
Indicates the field lowprtydata is used. |
|
reqlowprtygain |
Indicates the field lowprtygain is used. |
|
reqlowprtykeep |
Indicates the field lowprtykeep is used. |
|
lowprtydata |
Contains the lowest acceptable priority value. Used on N-CONNECT requests by the calling NS_user. |
|
lowprtygain |
Indicates the priority of data on a connection. Used on N-CONNECT requests by the calling NS_user. |
|
lowprtykeep |
Indicates priority for gaining a connection. Used on N-CONNECT requests by the calling NS_user. |
|
protection_type |
Indicates the type of protection required. Values are: PRT_SRC Source address specific PRT_DST Destination address specific PRT_GLB Globally unique 0 indicates that protection is not required. On N-CONNECT requests the calling NS_user may optionally specify a lowest acceptable level of protection. |
|
prot_len |
The length of the target protection. |
|
protection |
The value of target protection. |
|
lowprot_len |
The length of the lowest acceptable level of protection. |
|
lowprotection |
The lowest acceptable level of protection. |
|
reqexpedited |
Indicates whether expedited data is required/selected. For Connect Indications, a value of 1 implies that the expedited data negotiation facility was present in the Incoming Call packet, and that its use was requested. 0 indicates that expedited data is not used. Note: Negotiation is an OSI CONS procedure. When the facility is present and indicates non-use, use cannot be negotiated by Connect responses. See "6.4.3 N_CI--Call Request/Indication"and "6.4.2 N_CC--Call Response/Confirmation"for a description of the use of the CONS_call field in Call Requests and Call Responses. If the CONS_call flag is set to 0, Expedited Data Negotiation is not required--interrupt data is always available in X.25. This means that this field is ignored on Call Requests and Responses. |
|
reqackservice |
Indicates whether the acknowledgement service is to be used. Allowed values are: 0 indicates the service is not used. 1 signifies acknowledgment confirmation by the remote DTE. In the case of acknowledgment confirmation by the remote application, there is a one-to-one correspondence between D-bit data and acknowledgments with one data acknowledgment being received/sent for each D-bit data packet sent/received over the X.25 interface. 2 signifies acknowledgment confirmation by the remote application. In this case of acknowledgment confirmation by the remote DTE, no acknowledgments are expected or given over the X.25 interface. Any non-zero value causes negotiation in the call setup phase for use of the D-bit on the connection. |
6.4 NLI Commands
This section describes the available NLI commands in alphabetical order. Refer to Table 6-1 for a summary of the available commands and related structures.
6.4.1 N_Abort--Abort Indication
Description
N_Abort is used when the X.25 driver needs to send a Disconnect to the application, but there is no resource available in the system to construct a full Disconnect Indication message. For this reason, this message should rarely be received. The control part of an Abort Indication message has a format defined in the xabortf structure. There is no data part.
Note -
This message only appears in a getmsg, never in a putmsg. Example 6-1 shows how a getmsg can be constructed.
The xabortf structure is shown below:
struct xabortf {
unsigned char xl_type; /* Always XL_CTL */
unsigned char xl_command; /* Always N_Abort */
};
6.4.2 N_CC--Call Response/Confirmation
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct xccnff confirm; . . . ctlb.len = sizeof(struct xccnff); ctlb.buf = (char *)confirm; putmsg(x25_fd, &ctlb, NULL,0);
Description
N_CC is used when calls are being accepted. When used with putmsg, N_CC is a Call Response, when used with getmsg, it is a Call Confirmation. Example 6-1 shows how a getmsg can be constructed. When used with getmsg, ctlb.len is replaced by cltb.maxlen. The control part of the Call Request or Indication is defined by the xccnff structure. There is no data part.
The xccnff structure is shown below:
struct xccnff {
unsigned char xl_type; /* Always XL_CTL */
unsigned char xl_command; /* Always N_CC */
int conn_id; /* The connection id quoted on the associated
indication. */
unsigned char CONS_call; /* When set, indicates CONS call */
unsigned char negotiate_qos; /* When set, negotiate
facilities etc. else use
indicated values */
struct xaddrf responder; /* Responding address */
struct qosformat rqos; /* Facilities and CONS qos: if
negotiate_qos is set */
};
The members of the xccnff structure are:
Table 6-8 Call Response/Confirmation Message|
Member |
Description |
|---|---|
|
conn_id |
Connection identifier. conn_id must be returned in the Call Response so that listening operates properly. This must be the same connection identifier as was included in the Connection Request or Indication. |
|
CONS_call |
Indicates that OSI CONS procedures should be used for responses. If you are not using OSI CONS, this value should be 0. |
|
negotiate_qos |
A non-zero value shows that facilities and quality of service (QOS) are being negotiated. A zero value means the initiator is requesting all default values. |
|
responder |
The responding address. |
|
rqos |
Selected facilities and OSI CONS QOS parameters to be passed to the initiator. |
6.4.3 N_CI--Call Request/Indication
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct strbuf datab; struct xcallf call; char cud[MAX_LENGTH]; . . . ctlb.len = sizeof(struct xcallf); ctlb.buf = (char *)call; datab.len = cudlen; datab.buf = cud; putmsg(x25_fd, &ctlb, &datab, 0);
Description
N_CI is used when calls are requested or indicated across the X.25 interface. When used with putmsg, N_CI is a Call Request, when used with getmsg, it is a Connect Indication. Example 6-1shows how a getmsg can be constructed. The control part of the Call Request or Indication is defined by the xcallf structure. The data part of the message will contain any call user data.
The xcallf structure is shown below:
struct xcallf {
unsigned char xl_type; /* Always XL_CTL */
unsigned char xl_command; /* Always N_CI */
int conn_id; /*connection id returned in Call Response or
Disconnect */
unsigned char CONS_call; /*When set, indicates a CONS call*/
unsigned char negotiate_qos; /* When set, negotiate
facilities etc. or else use
defaults */
struct xaddrf calledaddr; /* The called address */
struct xaddrf callingaddr; /* The calling address */
struct qosformat qos; /* Facilities and CONS qos: if
negotiate_qos is set */
};
The members of the xcallf structure are:
Table 6-9 Call Request/Indication Message|
Member |
Description |
|---|---|
|
conn_id |
For incoming calls, an attempt is made to match the called address and call user data with that of one of the listening applications. If a match is found, then the indication is passed to that application with a conn_id identifier, which must be returned in the Call Response or Clear Request to accept or reject the connection. Leave this value as 0. |
|
CONS_call |
Indicates that OSI CONS procedures should be used for the call. |
|
negotiate_qos |
A non-zero value shows that facilities and quality of service (QOS) are being negotiated. A zero value means the initiator is requesting all default values. |
|
calledaddr |
Holds the called address. |
|
callingaddr |
The calling address. |
|
qos |
Any facilities requested or indicated. To use the qos member, you must set negotiate_qos. |
6.4.4 N_DAck--Data Ack Request/Indication
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct xdatacf dack; . . . ctlb.len = sizeof(struct xdatacf); ctlb.buf = (char *)dack; putmsg(x25_fd, &ctlb, NULL, 0);
Description
N_DAck acknowledges a previous Data Acknowledgment Request or Indication which had the D-bit set. The D-bit requests end-to-end, as opposed to local, acknowledgment. There is a one-to-one correspondence between D-bit data and acknowledgments, with one Data Acknowledgment being received/sent for each D-bit data packet sent/received. It is always the oldest outstanding D-bit packet that is being acknowledged.
Refer to "6.3.4 qosformat--Define OSI CONS QOS Parameters" for details of requesting acknowledgment using the reqackservice member of the qosformat structure. For OSI CONS calls, Data Acknowledgment must be negotiated on the connection.
When used with putmsg, N_DAck is a Data Acknowledgment Request, when used with getmsg, it is a Data Acknowledgment Indication. Example 6-1 shows how a getmsg can be constructed. The control part of the Data Acknowledgment Request or Indication is defined by the xdatacf structure. There is no data part.
The xdatacf structure is shown below:
struct xdatacf {
unsigned char xl_type; /* Always XL_DAT */
unsigned char xl_command; /* Always N_DAck */
};
6.4.5 N_Data--Data
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct strbuf datab; struct xdataf control; char data[MAX_LENGTH]; . . . ctlb.len = sizeof(struct xdataf); ctlb.buf = (char *)control; datab.len = MAX_LENGTH; datab.buf = data; putmsg(x25_fd, &ctlb, &datab, 0);
Description
N_Data is used to transfer data across the X.25 interface. The synopsis shows a putmsg. Example 6-1 shows how a getmsg can be constructed. The control part of the Data packet is defined by the xdataf structure. The data part of the message contains the user data.
The xdataf structure is shown below:
struct xdataf {
unsigned char xl_type; /* Always XL_DAT */
unsigned char xl_command; /* Always N_Data */
unsigned char More; /* Set when more data is required
to complete the nsdu */
unsigned char setDbit, /* Set when data carries X.25 D-bit */
unsigned char setQbit; /* Set when data carries X.25 Q-bit */
};
The members used by xdataf are.
Table 6-10 Data Message|
Member |
Description |
|---|---|
|
More |
Shows whether there is more of this network service data unit to be received/sent. |
|
setQbit |
Requests or indicates that the Q-bit is set when user data is transmitted/received. The Q-bit indicates that the data is intended for a device attached to the DTE and not for the DTE itself. |
|
setDbit |
Requests or indicates that the D-bit is set when user data is transmitted/received. The D-bit requests end-to-end acknowledgement. |
Note -
No acknowledgement for this data is given to, or expected from, the application unless the D-bit is set and application-to-application Receipt Confirmation is being used.
6.4.6 N_DC--Clear Confirm
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct strbuf datab; struct xdcnff disc; char cud[MAX_LENGTH]; . . . ctlb.len = sizeof(struct xdcnff); ctlb.buf = (char *)disc; datab.len = cudlen; datab.buf = cud; putmsg(x25_fd, &ctlb, NULL, 0);
Description
N_DC is used to confirm a previous clear indication (N_DI). The example shows a putmsg. Example 6-1 shows how a getmsg can be constructed. The control part of the Data packet is defined by the xdcnff structure. If Fast Select is in use, the data part of the message contains any clear user data.
The xdcnff structure is shown below:
struct xdcnff {
unsigned char xl_type; /* Always XL_CTL */
unsigned char xl_command; /* Always N_DC */
unsigned char indicated_qos; /* When set, facilities
indicated */
struct qosformat rqos; /* If indicated_qos is set, holds
facilities and CONS qos */
};
The members of the xdcnff structure are:
Table 6-11 Clear Confirm Parameters|
Member |
Description |
|---|---|
|
indicated_qos |
Non-zero value shows that facilities and QOS are being indicated. |
|
rqos |
Contains the facilities indicated. This is only used with the Charging Information facility. |
6.4.7 N_DI--Clear Request/Indication
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct strbuf datab; struct xdiscf disc; char cud[MAX_LENGTH]; . . . ctlb.len = sizeof(struct xdiscf); ctlb.buf = (char *)disc; datab.len = cudlen; datab.buf = cud; putmsg(x25_fd, &ctlb, &datab, 0);
Description
N_DI is used when a Clear Request/Indication crosses the X.25 interface. When used with putmsg, N_DI is a Clear Request, when used with getmsg, it is a Disconnect Indication. Example 6-1shows how a getmsg can be constructed. The control part of the Call Request or Indication is defined by the xdiscf structure. If Fast Select is in use, the data part of the message contains any clear user data.
The X.25 cause and diagnostic bytes, cause and diag, are presented, as well as the CONS originator and reason codes mapped from these. For a Clear Request the user can specify a non-zero cause code. This has no effect for an OSI CONS call; the value is set to zero by the system.
The Clear Request from an application is confirmed unless it is a rejection of a previous Connect Indication. When it is not a rejection, the X.25 driver sends a Clear Confirm to the application when the Clear Confirmation is received. This guarantees that once the Clear Confirm is read by the application no more messages are sent on this stream. For this reason, after requesting disconnection, the application should read and discard all messages from the stream until the Clear Confirm is received.
For call rejection, no acknowledgment is sent. However, the application must supply the connection identifier presented in the Connect Indication so that the appropriate circuit is cleared. In the case of a Disconnect Indication, all messages sent downstream except connect messages are discarded silently.
The xdiscf structure is shown below:
struct xdiscf {
unsigned char xl_type; /* Always XL_CTL */
unsigned char xl_command; /* Always N_DI */
unsigned char originator, /* Originator and Reason mapped
from */
reason, /* X.25 cause/diag in indications */
cause, /* X.25 cause byte */
diag; /* X.25 diagnostic byte */
int conn_id; /* The connection id (for reject only) */
unsigned char indicated_qos; /* When set, facilities
indicated */
struct xaddrf responder; /* CONS responder address */
struct xaddrf deflected; /* Deflected address */
struct qosformat qos; /* If indicated_qos is set, holds
facilities and CONS qos */
};
The members of the xdiscf structure are.
Table 6-12 Clear Request/Indication Parameters|
member |
Description |
|---|---|
|
originator |
OSI CONS mapping of the X.25 cause byte. |
|
reason |
OSI CONS mapping of the X.25 diagnostic byte. Refer to Chapter 9, Error Codes for further information. |
|
cause |
The X.25 cause byte. |
|
diag |
The X.25 diagnostic byte. |
|
indicated_qos |
Non-zero value shows that facilities and QOS are being indicated. |
|
responder |
Contains the responding address. |
|
deflected |
Used in conjunction with the call_deflect facility in the qos structure to convey the address of the remote DTE that the call is to be deflected to. |
|
qos |
Contains the facilities indicated. This is used with the Charging Information facility and the Call Deflection facility. |
Note -
If a disconnect collision occurs, acknowledgement is taken to be complete.
6.4.8 N_EAck--Expedited Data Acknowledgement
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct xedatacf eack; . . . ctlb.len = sizeof(struct xedatacf); ctlb.buf = (char *)eack; putmsg(x25_fd, &ctlb, NULL, 0);
Description
N_EAck is used to acknowledge expedited data, carried by an X.25 Interrupt packet. The example shows a putmsg. Example 6-1 shows how a getmsg can be constructed. The control part of the Interrupt packet is defined by the xedatacf structure. There is no data part. An acknowledgment must be sent immediately on receipt of an Interrupt packet.
The xedatacf structure is shown below:
struct xedatacf {
unsigned char xl_type; /* Always XL_DAT */
unsigned char xl_command; /* Always N_EAck */
};
6.4.9 N_EData--Expedited Data
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct strbuf datab; struct xedataf edata; char data[MAX_LENGTH]; . . . ctlb.len = sizeof(struct xedataf); ctlb.buf = (char *)edata; datab.len = cudlen; datab.buf = cud; putmsg(x25_fd, &ctlb, &datab, 0);
Description
N_EData is used when expedited data, carried by an X.25 Interrupt packet, crosses the X.25 interface. The example shows a putmsg. Example 6-1 shows how a getmsg can be constructed. The control part of the Interrupt packet is defined by the xedataf structure. The data part of the message contains the user data. The expedited data is a confirmed primitive and must be acknowledged (see "6.4.8 N_EAck--Expedited Data Acknowledgement") before another expedited data unit can be requested or indicated.
The xedataf structure is shown below:
struct xedataf {
unsigned char xl_type; /* Always XL_DAT */
unsigned char xl_command; /* Always N_EData */
};
6.4.10 N_PVC_ATTACH--PVC Attach
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct pvcattf attach; . . . ctlb.len = sizeof(struct pvcattf); ctlb.buf = (char *)attach; putmsg(x25_fd, &ctlb, NULL, 0);
Description
N_PVC_ATTCH is used when an application wants to attach to a PVC.The control part of the PVC Attach is defined by the pvcattf structure. The example shows a putmsg. Example 6-1 shows how a getmsg can be constructed.
The pvcattf structure is shown below:
struct pvcattf {
unsigned char xl_type; /* Always XL_CTL */
unsigned char xl_command; /* Always N_PVC_ATTACH */
unsigned short lci; /* Logical channel */
uint32_t link_id; /* Link # */
/* 0 for next 3 parameters implies use of default */
unsigned char reqackservice;
unsigned char reqnsdulimit;
int nsdulimit;
int result_code; /* Non-zero - error */
};
The members used by pvcattf are:
Table 6-13 PVC Attach Parameters|
Member |
Description |
|---|---|
|
lci |
Contains the logical channel identifier of the required PVC. |
|
link_id |
Denotes the particular link identifier for the PVC. |
|
reqackservice |
If non-zero, denotes that the receipt acknowledgement service is requested by use of the D-bit. Setting reqackservice to 1 signifies receipt confirmation by the remote DTE. Setting reqackservice to 2 signifies receipt confirmation by the remote application. In the case of receipt confirmation by the remote DTE, no acknowledgements are expected or given over the X.25 interface. In the case of receipt confirmation by the remote application, there is a one-to-one correspondence between D-bit data and acknowledgements with one data acknowledgement being received/sent for each D-bit data packet sent/received over the X.25 interface. |
|
reqnsdulimit |
If this is non-zero, use value in nsdulimit. |
|
nsdulimit |
Specifies the packet concatenation limit for NSDUs. If you want to use this parameter, reqnsdulimit must be non-zero. (The X.25 driver does not look at reqnsdulimit if nsdulimit is zero.) |
|
result_code |
In the attach message sent to the user as acknowledgment, this member denotes whether the attach was successful. The possible values are defined in the netx25/x25_proto.h file. |
6.4.11 N_PVC_DETACH--PVC Detach
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct strbuf datab; struct pvcdetf detach; . . . ctlb.len = sizeof(struct pvcdetf); ctlb.buf = (char *)detach; datab.len = cudlen; datab.buf = cud; putmsg(x25_fd, &ctlb, &datab, 0);
Description
N_PVC_DETACH is used when an application wants to detach from a PVC. This allows the use of a stream to be changed. The control part of the PVC Detach is defined by the pvcdetf structure. The data part of the message contains any call user data. The synopsis shows a putmsg. Example 6-1 shows how a getmsg can be constructed.
The pvcdetf structure is shown below:
struct pvcdetf {
unsigned char xl_type; /* Always XL_CTL */
unsigned char xl_command; /* Always N_PVC_DETACH */
int reason_code; /* Reports why */
};
This structure has the following member:
Table 6-14 Listen Cancel Command/Response Parameters|
Member |
Description |
|---|---|
|
reason_code |
The reason for the detach, or a code indicating that a previous PVC Detach was successful. |
Note -
The PVC Detach message is acknowledged to the user by returning another PVC Detach message.
6.4.12 N_RC--Reset Response/Confirm
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct xrscf rc; . . . ctlb.len = sizeof(struct xrscf); ctlb.buf = (char *)rc; putmsg(x25_fd, &ctlb, NULL, 0);
Description
N_RC is used to respond to a previous reset. When used in a putmsg it is a Reset Response. In a getmsg it is a Reset Confirm. Example 6-1 shows how a getmsg can be constructed. The control part of the Reset Response or Confirm is defined by the xrscf structure. There is no data part.
The xrscf structure is shown below:
struct xrscf {
unsigned char xl_type; /* Always XL_CTL */
unsigned char xl_command; /* Always N_RC */
};
Note -
A Reset primitive is an acknowledged service (see the associated structure xrscf). A collision between a Reset Indication and a Reset Request is taken to acknowledge the Reset--no Reset Confirmation is then required before another Reset Request can be sent. Normally, Resets are handled by the application.
6.4.13 N_RI--Reset Request/Indication
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct xrstf reset; . . . ctlb.len = sizeof(struct xrstf); ctlb.buf = (char *)reset; putmsg(x25_fd, &ctlb, NULL, 0);
Description
N_RI is used for resets. When used in a putmsg it is a Reset Request. In a getmsg it is a Reset Indication. Example 6-1 shows how a getmsg can be constructed. The X.25 cause and diagnostic bytes, cause and diag, are presented as well as the CONS originator and reason codes that are mapped from these. Refer to Chapter 9, Error Codes for further information.
For a Reset Request, the user can specify a non-zero cause code. This has no effect for an OSI CONS call; the value is set to zero by the system.
The control part of the Reset Request or Indication is defined by the xrstf structure. There is no data part.
The xrstf structure is shown below:
struct xrstf {
unsigned char xl_type; /* Always XL_CTL */
unsigned char xl_command; /* Always N_RI */
unsigned char originator, /* Originator and Reason mapped */
reason, /* from X.25 cause/diag in indications */
cause, /* X.25 cause byte */
diag; /* X.25 diagnostic byte */
};
Note -
A Reset primitive is an acknowledged service. It must be acknowledged before another Reset can be requested. A collision between a Reset Indication and a Reset Request is taken to acknowledge the Reset--no Reset Confirmation is then required before another Reset Request can be sent. Normally, Resets are handled by the application.
6.4.14 N_Xcanlis--Listen Cancel Command/Response
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct xcanlisf canlis; . . . ctlb.len = sizeof(struct xcanlisf); ctlb.buf = (char *)canlis; putmsg(x25_fd, &ctlb, NULL, 0);
Description
N_Xcanlis is used to cancel an interest in incoming calls.
When used with putmsg, N_Xcanlis is a Listen Cancel Command, when used with getmsg, it is a Listen Cancel Response. Example 6-1 shows how a getmsg can be constructed. The control part of the Listen Command or Response is defined by the xcanlisf structure. There is no data part.
Note -
The Cancel Request removes all listen addresses from the stream. There is no way of cancelling a Listen on a particular address, for example, when the use of the stream is about to be changed by the application.
The control part of a Listen Cancel Command or Response message has a format defined in the xcanlisf structure:
struct xcanlisf {
unsigned char xl_type; /* Always XL_CTL */
unsigned char xl_command; /* Always N_Xcanlis */
int c_result; /* Result flag */
};
This structure has the following member:
Table 6-15 Listen Cancel Command/Response Parameters|
Member |
Description |
|---|---|
|
c_result |
A non-zero value of the c_result flag indicates failure of the operation to cancel a Listen. This may indicate that the Listen was not present or that some connect event is outstanding. The closure of a stream on which there is a Listen also cancels the Listen, but in the case of the cancel command message, the stream remains open. |
6.4.15 N_Xlisten--Listen Command/Response
Synopsis
#include <stream.h> #include <netx25/x25_proto.h > struct strbuf ctlb; struct strbuf datab; struct xlistenf listen; char lisbuf[MAXLIS]; . . . ctlb.len = sizeof(struct xlistenf); ctlb.buf = (char *)listen; datab.len = lislen; datab.buf = lisbuf; putmsg(x25_fd, &ctlb, &datab, 0);
Description
N_Xlisten is used to listen for incoming calls. When used with putmsg, N_Xlisten is a Listen Command, when used with getmsg, it is a Listen Response. Example 6-1 shows how a getmsg can be constructed. The control part of the Listen Command or Response is defined by the xlistenf structure.
The data part is treated as a byte stream of CUD and addresses conforming to the following definition:
unsigned char l_cumode; unsigned char l_culength; unsigned char l_cubytes [l_culength]; unsigned char l_mode; unsigned char l_type; unsigned char l_length; unsigned char l_add[(l_length+1)>>1];
Not all variables need be present. Refer to the individual variable descriptions below for more details.
The fields l_cumode, l_culength and l_cubytes are used to match the CUD field of the incoming call against that specified in the Listen request.
Table 6-16 Variables for CUD matching|
Variable Name |
Description |
|---|---|
|
l_cumode |
Defines the type of matching: X25_DONTCARE The listener ignores the CUD; l_culength and l_cubytes are omitted. X25_IDENTITY The listener match is only made if all bytes of the CUD field are the same as the supplied l_cubytes. X25_STARTSWITH The listener match is only made if the leading bytes of the CUD Field are the same as the supplied l_cubytes. |
|
l_culength |
Length of the CUD in octets for an X25_IDENTITY or X25_STARTSWITH CUD Field match. If l_culength is zero, the l_cubytes are omitted. The range for l_culength is zero to 16 inclusive. If more than 16 bytes are present, the application still has to check the full CUD Field. |
|
l_cubytes |
String of bytes sought in the call user data field when l_cumode is X25_IDENTITY or X25_STARTSWITH. |
The fields l_mode, l_type, l_length and l_add are used to match the called address field(s) of the incoming call against that specified in the Listen request.
Table 6-17 Variables for address matching|
Variable Name |
Description |
|---|---|
|
l_mode |
Defines the type of matching: X25_DONTCARE The listener ignores the address; l_type, l_length, and l_add are omitted. X25_IDENTITY The listener match is only made if all digits of the address are the same as the supplied l_add. X25_STARTSWITH The listener match is only made if the leading digits of the address are the same as the supplied l_add. X25_PATTERN The listener match is made on partial addresses, allowing the use of wildcard digits. |
|
l_type |
The type of the address entry; l_type can have two values, X25_DTE or X25_NSAP. It denotes the important addressing quantity. For X.25 (84) and X.25 (88), for example, NSAP addresses (or extended addresses) are the important addresses, while for X.25 (80), where there is no NSAP address, the DTE address is the important quantity. Applications can be distinguished by X.25 DTE subaddress where necessary. On many X.25 (84) and X.25 (88) networks, it is possible to listen on either X25_DTE or X25_NSAP addresses. This is not possible when running X.25 (84) or X.25 (88) over LLC2 on the LAN. In this case, the DTE address field is NULL and the X25_NSAP field is used. |
|
l_length |
Length of the address l_add in BCD digits--the common format for X.25 DTE and NSAP addresses. If l_length is zero, then l_add is omitted. The maximum values for l_length are 15 for X25_DTE and 40 for X25_NSAP. |
|
l_add |
Contains the address to be compared with the called address field of the incoming call packet. l_add is omitted when l_length is zero. |
Note -
To use wildcards, represent * by 0x0F and ? by 0x0E. * represents 0 or more characters. ? represents a single character.
The xlistenf structure is shown below:
struct xlistenf {
unsigned char xl_type; /* Always XL_CTL */
unsigned char xl_command; /* Always N_Xlisten */
int lmax; /* Maximum number of CI's at a time */
int l_result; /* Result flag */
};
The members of the xlistenf structure are.
Table 6-18 Listen Command/Response Parameters|
Member |
Description |
|---|---|
|
lmax |
Maximum number of Connect Indications that the listener can handle at one time. Note: listen requests are cumulative but the lmax value (number of simultaneously handled Connect Indications) is not. This means that several listen requests can be made on a single stream, in which case the lmax value contained in the last listen message specifies the number of simultaneously handled Connect Indications. |
|
l_result |
The result of the listen request is acknowledged upstream with the same message. An error in the parameters or a lack of resources to set up the listen causes this flag to be set to a non-zero value. |
Note -
For example code using listening, refer to Chapter 4, Listening for Calls.
- © 2010, Oracle Corporation and/or its affiliates