Network Layer Interface

Network Layer Interface

1 Introduction

The Network Layer Interface (NLI) was developed by Spider Systems, Ltd., (now a division of Emerson Power), and is widely available on many platforms. For example, AIX AIXlink/X.25, HP-UX HP X.25/9000, Solaris Solstice X.25 and SunLink X.25, IRIX IRIS SX.25, PT X.25 and SBE X.25 implement the Network Layer Interface (NLI).

The Network Layer Interface (NLI) was designed to be used directly with standard STREAMS system calls and does not require the use of a cooperating user space shared library. Applications programs directly use the getmsg(2s), getpmsg(2), putmsg(2s), putpmsg(2) and ioctl(2) system calls.¹ Nevertheless, user shared object libraries can easily be constructed using this STREAMS service primitive interface.

The system header files that must be included when compiling user applications, or STREAMS drivers and modules that use the interface, are detailed in NLI Header Files.

A user library, libsx25, is provided, not for interfacing to the message primitive service interface, but for providing various helper functions when using the STREAMS service interface. This library is detailed in NLI Library.

1.1 History

The original UNIX® System V Release 3.2 with the Network Service Utilities (NSU) package, defined three levels of interface corresponding to boundaries of the OSI Model, as follows:

Transport Layer Inteface

This interface later turned into the Transport Provider Interface (TPI) that was standardized by UNIX International and later standardized by the Open Group. Two libraries existed in SVR 4 and X/Open: the Transport Layer Interface (TLI) library from SVR 4 and the X/Open Transport Interface (XTI) library from the Open Group. The Open Group also standardized the XTI interface for X.25.

Network Layer Interface

This interface later turned into the Network Provider Interface (NPI) that was standardized by UNIX International, but was not standardized by the Open Group. The NPI was used for X.25 as well as CONS in accordance with X.223. No library was provided by SVR 4 for this interface; however, GCOM specified an NPI API Library also provided by OpenSS7. For X.25, Spider Systems, Ltd. provided the Network Layer Interface (NLI) that is the subject of this specification.

Link Layer Interface

This interface later tunred into the Data Link Provider Inteface (DLPI) that was standardized by UNIX International and later standardized by the Open Group. No library was provided by SVR 4 for this interface; however, GCOM specifies a DLPI API Library also provided by OpenSS7. For X.25, Spider Systems, Ltd. provided the Link Layer Interface (LLI) that is the subject of a companion specification. Sun Microsystems has recently specified a DLPI Library for Solaris 11 that is also provided by OpenSS7.

Media Access Control

This interface was proposed by NCR Comten as the Communications Device Interface (CDI) that was not standardized. SVR 4 provided a Media Access Control (MAC) interface also supported by OpenSS7. Spider Systems, Ltd. X.25 does not directly use an interface at this level but, instead relies on access at the LLI.

Wide Area Network

This interface was proposed by NCR Comten as the Communications Device Interface (CDI) that was not standardized. For X.25, Spider Systems, Ltd. provided the Wide Area Network (WAN) Interface that is the subject of a companion specification.

The Network Layer Interface (NLI) specified by Spider Systems, Ltd. was the most widespread implementation of X.25 found on UNIX® and Unix-like systems.

1.2 Development

Although the Spider Systems, Ltd. Network Layer Interface (NLI) that is the subject of this specification was and is still in widespread use for the implementation of X.25 on UNIX® and Unix-like systems, it must be stressed that this is a legacy interface. It is provided by The OpenSS7 Project only for the purpose of porting legacy applications, drivers and modules to Linux. The following principles should be adhered to:

• The only formal standard interface for X.25 was specified by the Open Group using the X/Open Transport Interface library, specified in reference XX25. This interface is supported by OpenSS7 using the XX25 module described in XX25 Module.

  This interface alone should be used for new applications.

• For intermodule communications, the only industry standard interface for X.25 was specified by UNIX International as the Network Provider Interface (NPI) specified in reference NPI. This interface is supported by OpenSS7 directly and using the NPI module described in NPI Conversion Module.

  This interface alone should be used for new inter-module service interfaces.

• For applications interfaces and inter-module service interfaces for CONS (X.223), the only industry standard interface was specified by UNIX International as the Network Provider Interface (NPI) specified in reference NPI. This interface is supported by OpenSS7 directly and using the CON module described in CONS Module.

  This interface alone should be used by OSI applications, drivers and modules.

• When porting legacy applications, drivers and modules to Linux, the Network Layer Interface (NLI) as specified in this document may be used both for application interface and for inter-module service interfaces.

Note that when porting legacy NLI applications to Linux using the interface specified in this document, that there are many variations in implementation of the NLI as modified by licensors of the Spider Systems, Ltd. implementation. These modifications are ofter incompatible. Some of the incompatibilities are hidden by an X.25 utility library described in NLI Library.

2 Model of the X.25 Packet Layer

The X.25 Packet Layer provides the means to manage the operation of the X.25 network. It is responsible for the routing and management of data exchange between network-user entities.

The NLI defines the services provided by the X.25 packet layer to the X.25 user at the boundary between the X.25 packet layer and the X.25 user entity. The interface consists of a set of messages defined as STREAMS messages that provide access to the X.25 packet layer services, and are transferred between the X.25 user entity and the X.25 packet layer provider.

These messages are of two types: ones that originate from the X.25 user, and other that originate from the X.25 packet layer. The messages that originate from the X.25 user make requests to the X.25 packet layer, or respone to an event of the X.25 packet layer. The messages that originate from the X.25 packet layer, are either confirmations of a request or are indications to the X.25 user that the event has occured. Figure 1 shows the model of the NLI.

The NLI allows the X.25 packet layer (as a STREAMS driver) to be configured with an X.25 user (as a STREAMS module) that conforms to the NLI. An X.25 user can also be a user program that conforms to the NLI and accesses the X.25 packet layer using putmsg(2s), putpmsg(2), getmsg(2s), getpmsg(2), and ioctl(2) system calls.

3 NLI Services

The features of the NLI are defined in termsof the services provided by the X.25 packet layer, and the individual messages that may flow between the X.25 user and the X.25 packet layer.

The services supported by the NLI are based on three related modes of communication, X.25 mode, non-X.25 mode, and CONS mode.

3.1 NLI Modes

Packet Level Features

• permanent virtual circuits;
• extended packet sequence numbering;
• D-bit support;
• packet transmission;
• incoming calls barred;
• outgoing calls barred;
• one-way logical channel incoming;
• one-way logical channel outgoing;
• two-way logical channel;
• non-standard default packet sizes;
• non-standard default window sizes;
• default throughput class assignement;
• flow control parameter negotiation;
• throughput class negotiation;
• closed user group;
• bilateral closed user group;
• fast select;
• fast select acceptance;
• reverse charging;
• reverse charging acceptance;
• local charging prevention;
• network user identification selection;
• network user identification override;
• RPOA selection;
• called line address modification;
• call redirection;
• call deflection;
• transit delay;
• protection;
• priority;
• TOA/NPI addressing;
• programmable facilities.

X.25 Facilities

• fast select request;
• fast select with unrestricted response;
• fast select with restricted response;
• reverse charging;
• packet size negotiation;
• window size negotiation;
• closed user groups;
• bilateral closed user groups;
• network user identification;
• RPOA selection;
• called line address modification;
• call redirection;
• call charging;
• programmable facilities;
• DTE facility marker;
• extended address;
• throughput class;
• transit delay;
• expedited data;
• protection;
• priority;
• call user data;
• clear user data.

X.25 Operational Support

• Q-bit support for X.29 services;
• M-bit support for packet segmentation and reassembly;
• D-bit for data delivery confirmation;
• expedited data;
• call charging;
• called line address modification;
• call deflection;
• clear user data.

3.2 NLI Commands

3.3 NLI Data Structures

3.3.1 Addresses

In call requests and responses, it is necessary to specify the X.25 addresses associated with the connection. These addresses consist of the called, calling and responding addresses. A common structure is used for these addresses. The addressing format used by this stricture provides the following information:

• the subnetwork (data link) on which outgoing Connect Requests are to be sent and on which incoming Connect Indications arrive;
• Network Service Access Points (NSAP) and Subnetwork Point of Attachments (SNPA), or Data Terminal Equipment (DTE) addresses and Link Service Access Points (LSAP); and,
• optional formats for the encoding of addresses (NSAP).

3.3.1.1 X.25 Address Format

Addresses are represent using an xaddrf structure. The xaddrf structure is formatted as follows:

     #define NSAPMAXSIZE 20
     
     struct xaddrf {
         union {
             uint32_t link_id;
             uint32_t sn_id;
         };
         unsigned char aflags;
         struct lsapformat DTE_MAC;
         unsigned char nsap_len;
         unsigned char NSAP;
     };

The xaddrf structure contains the following members:

link_id

Holds the link number as a uint32_t. By default, link_id has a valud of ‘0xFF’. When link_id is ‘0xFF’, Solstice X.25 attempts to match the valled address with an entry in a routing configuration file. If it cannot find a match, it routes the call over the lowest numbered WAN link.

sn_id

Note that in some implementations, the sn_id field is declared as unsigned long; however, this causes complications for 32-bit applications running over a 64-bit kernel: i.e., it requires that the data model of the application be known to the kernel module and conversions be supported. Therefore, this field appears in the header file as the 32- vs. 64-bit agnostic uint32_t.

aflags

Specifies the options required (or used) by the subnetwork to encode and interpret addresses. It may have one of the following values:

NSAP_ADDR	‘0x00’	NSAP is OSI-encoded NSAP address.
EXT_ADDR	‘0x01’	NSAP is non-OSI-encoded extended address.
PVC_LCI	‘0x02’	NSAP is a PVC number.
PVC_LCI	‘0x02’	DTE_MAC is the LCI of a PVC.

When the NSAP field is empty, aflags takes the value zero (0).²

DTE_MAC

The DTE address, or LSAP as two BCD digits per byte, right justified, or the PVC_LCI as three BCD digits with two digits per byte, right justified. Holds the DTE address, the Medium Access Control plus Service Access Point (MAC+SAP) address or the LCI. This is binary. See lsapformat.

nsap_len

The length in semi-octets of the NSAP as two BCD digits per byte, right justified. This indicates the length of the NSAP, if any (and where appropriate), in semi-octets.

NSAP

The NSAP or address extension (see aflags) as two BCD digitis per byte, right justified. This carries the NSAP or address extension (see field aflags) when present as indicated by nsap_len. This is binary.

3.3.1.2 LSAP Address Format

The lsapformat structure is formatted as follows:.

     #define LSAPMAXSIZE
     
     struct lsapformat {
         unsigned char lsap_len;
         unsigned char lsap_add[LSAPMAXSIZE];
     };

The fields in this structure are defined as follows:

lsap_len

This gives the length of the DTE address, the MAC+SAP address, or the LCI in semi-octets. For example for Ethernet, the length is always 14 to indicate the MAC (12) plush SAP (2). The SAP always follows the MAC address. The DTE can be up to 15 decimal digits unless X.25(88) and Type Of Address/Numbering Plan Identification (TOA/NPI) addressing is being used, in which case, it can be up to 17 decimal digits. For an LCI, the length is 3. The length of the DTE address or LSAP as two BCD digits per byte, right justified. An LSAP is always 14 digits long. A DTE address can be up to 15 decimal digtis unless X.25(88) and TOA/NPI addressing is used, in which case it can be up to 17 decimal digits. A PVC_LCI is 3 digits long.

lsap_add

This holds the DTE, MAC+SAP or LCI, when present, as indicated by lsap_len. This is binary. The DTE address, LSAP or PVC_LCI as two BCD digits per byte, right justified.

For TOA/NPI the TOA is:

NPI for other than Alternative address is:

NPI when TOA is Alternative Address is:

3.3.2 CONS Quality of Service Parameters

Negotiable X.25 facilities are supported by the PLP driver. This section describes the request and negotiation of these facilities, and the data structures used by the NLI primitives.

The facilities are broken down into two groups:

• those required for Connection-Oriented Network Service (CONS) support, and
• those requried for non-OSI procedures (X.29, for example).

The CONS quality of service (QOS) parameters supported are the following:

• Throughput Class
• Minimum Throughput Class
• Target Transit Delay
• Maximum Acceptable Transit Delay
• Use of Expedited Data
• Protection
• Receipt Acknolwedgement

CONS-related quality of service parameters are defined in the qosformat structure. The qosformat structure is formatted as follows:

     #define MAX_PROT 32
     
     struct qosformat {
         unsigned char reqtclass;
         unsigned char locthroughput;
         unsigned char remthroughput;
         unsigned char reqminthruput;
         unsigned char locminthru;
         unsigned char remminthru;
         unsigned char reqtransitdelay;
         unsigned short transitdelay;
         unsigned char reqmaxtransitdelay;
         unsigned char 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 xstras;
     };

The qosformat structure has the following members:

reqtclass

When non-zero, conveys that throughput negotiation is selected.

locthroughput

Contains the four-bit throughput encoding for the local to remote direction.

remthroughput

Contains the four-bit throughput encoding for the remote to local direction.

reqminthruput

When non-zero, conveys that minimum throughput negotiation is selected.

locminthru

When reqminthruput is non-zero, conveys the four-bit throughput encoding for the local to remote direction.

remminthru

When reqminthruput is non-zero, conveys the four-bit throughput encoding for the remote to local direction.

reqtransitdelay

When non-zero, conveys that target transit delay negotiation is selected.

transitdelay

When reqtransitdelay is non-zero, conveys the 16-bit value. In a Connect Confirmation, the value of the selected transit delay is placed in this field and is non-zero.

reqmaxtransitdelay

When non-zero, conveys that maximum acceptable transit delay negotiation is selected.

acceptable

When reqmaxtransitdelay is non-zero, conveys the 16-bit value of the maximum acceptable transit delay.

Note: Transit delay selection applies only to Connect Requests. There is no transit dleay QOS parameter in a Connect Response. The correct response when the indicated QOS is unattainable is to make a Disconnect Request. In a Connect Confirmation, the value of the selected transit delay is placed in the transitdelay field when such negotiation takes place.

reqpriority

When non-zero, conveys that data priority negotiation is selected.

reqprtygain

When non-zero, conveys that gain priority negotiation is selected.

reqprtykeep

When non-zero, conveys that keep priority negotiation is selected.

prtydata

When reqpriority is non-zero, contains the 8-bit priority for sending data.

prtygain

When reqprtygain is non-zero, contains the 8-bit priority for gaining a connection.

prtykeep

When reqprtykeep is non-zero, contains the 8-bit priority for keeping a connection.

reqlowprtydata

When non-zero, conveys that data low priority negotiation is selected. This field is only valid on Connect Requests/Indications.

reqlowprtygain

When non-zero, conveys that gain low priority negotiation is selected. This field is only valid on Connect Requests/Indications.

reqlowprtykeep

When non-zero, conveys that keep low priority negotiation is selected. This field is only valid on Connect Requests/Indications.

lowprtydata

When reqlowprtydata is non-zero, contains the 8-bit priority for sending data. This field is only valid on Connect Requests/Indications.

lowprtygain

When reqlowprtygain is non-zero, contains the 8-bit priority to gain a connection. This field is only valid on Connect Requests/Indications.

lowprtykeep

When reqlowprtykeep is non-zero, contains the 8-bit priority to keep a connection. This field is only valid on Connect Requests/Indications.

protection_type

When non-zero, conveys that protection negotiation is selected. The field can be one of the following valuse:

Value	Name	Meaning
1	PRT_SRC	Source address specific.
2	PRT_DST	Destination address specific.
3	PRT_GLB	Globally unique.

prot_len

lowprot_len

This field is only valid on Connect Requests/Indications.

protection

lowprotection

This field is only valid on Connect Requests/Indications.

reqexpedited

When non-zero, conveys that expedited data negotiation is selected. For Connect Indications, a non-zero value implies that the Expedited Data negotiation facility was present in the incoming call packet, and that its use was requested.

Note: Negotiation is a CONS procedure. When the facility is present and indicates non-use, use cannot be negotiated by Connect Responses. For a description of the use of the CONS_call field in Connect Requests and Connect Responses, see Connect Request/Indication, and Connect Response/Confirmation.

For incoming or outgoing non-CONS calls (denoted by the CONS_call flag set to zero (0)), Expedited Data negotiation is not required: interrupt data is always available in X.25. This means that this field is ignored on Connect Requests and Responses for non-CONS calls.

reqackservice

When non-zero, conveys that receipt confirmation negotiation is selected. For Connect Indications, a non-zero value implies that the Receipt Confirmation negotiation facility was present in the incoming call packet, and that its use was requested. This field can have one of the following values:

Constant	Value	Description
-	0	No receipt confirmation.
RC_CONF_DTE	1	Confirmation by the remote terminal.
RC_CONF_APP	2	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 service interface. In the case of receipt confirmation by the remote application, there is a one-to-one corrrespondence between D-bit data and acknowledgements, with one data acknowlegement being received or sent for each D-bit data packet sent or received over the X.25 service interface.

xstras

3.3.3 Non-OSI X.25 Facilities

Although these are non-OSI facilities, they are also negotiable with CONS. For those NLI applications that require them, the non-OSI facilities supported are as follows:

• non-OSI extended addressing;
• X.25 fast select request/indication with no restriction on response;
• X.25 fast select reqeust/indication with restriction on response;
• X.25 reverse charging;
• X.25 packet size negotiation;
• X.25 window size negotiation;
• X.25 network user identification;
• X.25 recognized private operating agency selection;
• X.25 closed user groups;
• X.25 call deflection; and,
• X.25 programmable facilities.

Non-OSI X.25 Facilities are defined in the extraformat structure. The extraformat structure is formatted as follows:

     #define MAX_NUI_LEN  64
     #define MAX_RPOA_LEN  8
     #define MAX_CUG_LEN   2
     #define MAX_FAC_LEN  32
     #define MAX_TARIFFS   4
     #define MAX_CD_LEN   MAX_TARRIFS * 4
     #define MAX_SC_LEN   MAX_TARRIFS * 4
     #define MAX_MU_LEN   16

     
     struct extraformat {
         unsigned char fastselreq;
         unsigned char restrictresponse;
         unsigned char reversecharges;
         unsigned char pwoptions;
         unsigned char locpacket;
         unsigned char rempacket;
         unsigned char locwsize;
         unsigned char 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 extraformat structure has the following members:

fastselreq

For non-OSI services (e.g. X.29), if the X.25 facility fast select is to be requested or indicated, this field is non-zero. For CONS, the use of fast select is optional.

restrictresponse

If the resonse to a Connect Request or Indication is to be a Diconnect Indiciation, this filed is non-zero.

reversecharges

If reverse charging is requested or indicated for a connection, this field is non-zero. The configuration mod bit SUB_REVCHARGE has an impact on whether reverse charging is indicated, since it is possible to select a per-subnetwork policy for reciept of reverse charging.

pwoptions

This field is used to indicate per-circuit options. The field is a bitwise OR of zero or more of the following values:

Name	Value	Meaning when set.
NEGOT_PKT	0x01	Packet size negotiation permitted.
NEGOT_WIN	0x01	Window size negotiation permitted.
ASSWERN_HWM	0x01	Assert concatentaiton limit.

The field is defined as follows:

     
          #define NEGOT_PKT       0x01
          #define NEGOT_WIN       0x02
          #define ASSERT_HWM      0x04
     

The field is used for two reasons:

1. The X.25 software always indicates the values of the window and packet sizes operating on the virtual circuit. The field pwoptions for an incoming call indicates whether these values are negotiable.
2. In Connect Request/Response message, the NLI user can set nsdulimit, the limit value for packet concatentation by the X.25 level, to a value different from the limit in the subnetwork configuration database. It is not a negotiable option, so whatever the user requests is used.

locpacket

When non-zero, contains the local to remote direction packet size. The default value, DEF_X25_PKT, is seven (7).

rempacket

When non-zero, contains the remote to local direction packet size. The default value, DEF_X25_PKT, is seven (7).

locwsize

When non-zero, contains the local to remote direction window size. The default value, DEF_X25_WIN, is two (2).

remwsize

When non-zero, contains the remote to local direction window size. The default value, DEF_X25_WIN, is two (2).

nsdulimit

When non-zero, and the appropriate bit is set in the pwoptions field, this field is used as the specified concatentaiton limit.

nui_len

Valid in Connect Requests and Connect Responses, when non-zero, specifies the length of the nui_field in octets. The Network User Identification facility is not available on 1980 X.25 networks.

nui_field

Contains the Network User Identification (NUI) octets of length nui_len.

rpoa_len

Valid in Connect Requests only. When non-zero, the RPOA DNIC information is suppplied in the rpoa_field field and the semi-octets in the field are of this length.

rpoa_field

Contains the Recognized Private Operating Agency (RPOA) semi-octets of length rpoa_len.

cug_type

Valid in Connect Requests and Connect Indications only, this field, when non-zero, is 1 for Closed User Group (CUG) and 2 for Bilateral CUG (two members only).

Note: Incoming CUG facilities are assumed to have been validated by the network. No further cehcking is performed.

cug_field

Contains the Closed User Group (CUG) semi-octets of length up to four (4) semi-octets for CUG and four semi-octets (4) for BCUG (Bilateral CUG).

reqcharging

When non-zero in a Connect Request of Connect Indication, call charging is requested; in a Disconnect Indication of Disconnect Confirmation, the six fields below will give the charging information.

chg_cd_len

When non-zero, conveys the length of the chg_cd_field field.

chg_cd_field

Conveys the call duration.

chg_sc_len

When non-zero, conveys the length of the chg_sc_field field.

chg_sc_field

Conveys the segment count.

chg_mu_len

When non-zero, conveys the length of the chg_mu_field field.

chg_mu_field

Conveys the monetary unit.

called_add_mod

When non-zero, conveys the reason value for call modification.

call_redirect

When non-zero, conveys the reason for call redirection.

called

When call_redirect is non-zero, conveys the orignalling called DTE address.

call_deflect

Valid in the Disconnect Request and Disconnect Indication, when non-zero, conveys the reason for call deflection. The deflected field in the Disconnect Request or Indication conveys the DTE address, and if required, the NSAP address to which the call is to be deflected.

x_fac_len

Valid in Connect Requests and Connect Indications only, when non-zero, provides the length of the explicit facility ecnoded strings for X.25 facilities.

cg_fac_len

Valid in Connect Requests and Connect Indiciations only, when non-zero, provides the length of the explicit facility encoded strings for non-X.25 facilities for the calling network.

cd_fac_len

Valid in Connect Requests and Connect Indiciations only, when non-zero, provides the length of the explicit facility encoded strings for non-X.25 facilities for the called network.

fac_field

When x_fac_len, cg_fac_len or cd_fac_len are non-zero, contains the X.25 facilities, non-X.25 facilities for the calling network, and/or non-X.25 facilities for the called network.

Note: The contents of this field, if supplied, are not validated or acted upon by the code. The X.25 facilities are inserted at the end of any other X.25 facilities that are passed in the Connect Request/Indication (for example, packet or window sizes). If any non-X.25 facilities are supplied, the appropriate marker is inserted before the supplied facilities.

4 NLI Message Primitives

4.1 Connect Request/Indication

Format

The Connect Request and Connect Indication use the xcallf structure. The control part of the message consists of one M_PROTO message block containing the xcallf structure. The data part of the message consists of zero or one M_DATA message blocks containing the Call User Data (if any).

The xcallf structure is formatted as follows:

     struct xcallf {
         unsigned char xl_type;
         unsigned char xl_command;
         int conn_id;
         unsigned char CONS_call;
         unsigned char negotiate_qos;
         struct xaddrf calledaddr;
         struct xaddrf callingaddr;
         struct qosformat qos;
     };

Usage

The Connect Request or Indication message primitive, N_CI, is used by the NS user to request a outgoing connection, or by the NS provider to indicate an incoming connection. The control part of the message consists of one M_PROTO message block, and contains the xcallf structure. The data part of the message consists of zero or one M_DATA message blocks containing the Call User Data (CUD) when supplied.

Parameters

The xcallf structure contains the following members:

xl_type

Always XL_CTL.

xl_command

Always N_CI, for both Connect Requests and Connect Indications.

conn_id

This field is used only for Connect Indications. When an NS user Stream is listening, multiple incoming Connect Indications can be pending. This field indicates the connection identifier for the current Connect Indication for use by the NS user when responding to this Connection Indication with either a Connect Response or a Disconnect Request message.

CONS_call

Either X.25 or CONS procedures³ can be used for calls. When non-zero, this field indicates that CONS procedures are to be used. When zero, this field indicates that X.25 procedures are to be used.

negotiate_qos

QOS parameters can be negotiated by the peer or left at default values. When non-zero, this field specifies or indicates that QOS parameters are being negotiated by the NS user or NS user peer and the pertinent ranges are provided in the qos member. When zero, this field specifies and indicates that default values are to be used for the NS user or were indicated by the NS user peer.

calledaddr

Conveys the called address. For outgoing Connect Requests, this is the remote address to which the call is to be connected. For incoming Connect Indications, this is the local address to which the call was initiated.

callingaddr

Conveys the calling address. For outgoing Connect Requests, this is the local address from which the call is to be connected. For incoming Connect Indications, this is the remote address from which the call was initiated.

qos

Conveys the quality of service parameters and CONS an non-CONS facilities that are requested or indicated.

State

Response

When the Connect Request is issued by the NS user, the expected response from the NS provider is a Connect Conformation or a Disconnect Indication.

When the Connect Indication is issued by the NS provider, the expected response from the NS user is a Connect Response or a Disconnect Request.

Equivalence

The Connect Request message primitive is equivalent to the N_CONN_REQ primitive of the NPI; the Connect Indication, the N_CONN_IND.

4.2 Connect Response/Confirmation

Format

The Connect Response and Connect Confirmation use the xccnff structure. The control part of the message consists of one M_PROTO message block containing the xccnff structure. The data part of the message consists of zero or one M_DATA message blocks containing the Call User Data (if any).

The xccnff structure is formatted as follows:

     struct xccnff {
         unsigned char xl_type;
         unsigned char xl_command;
         int conn_id;
         unsigned char CONS_call;
         unsigned char negotiate_qos;
         struct xaddrf responder;
         struct qosformat rqos;
     };

Usage

The Connect Response or Confirmation message primitive, N_CC, is used by the NS user to response to an incoming connection, or by the NS provider to confirm an outgoing connection. The control part of the message consists of one M_PROTO message block, and contains the xccnff structure. The data part of the message consists of zero or one M_DATA message block containing the Call User Data (CUD) when supplied.

Parameters

The xccnff structure contains the following members:

xl_type

Always XL_CTL.

xl_command

Always N_CC, for both Connect Response and Connect Confirmation.

conn_id

This field is only used for Connect Responses. When an NS user Stream is listening, multiple incoming Connect Indications can be pending. This field specifies the connection identifier from the Connection Indication to which the NS user is responding.

CONS_call

Either X.25 or CONS procedures⁴ can be used for calls. When non-zero, this field indicates that CONS procedures are to be used. When zero, this field indicates that X.25 procedures are to be used.

negotiate_qos

QOS parameters can be negotiated by the peer or left at default values. When non-zero, this field specifies or indicates that QOS parameters are being negotiated by the NS user or NS user peer and the pertinent ranges are provided in the rqos member. When zero, this field specifies and indicates that default values are to be used for the NS user or were indicated by the NS user peer.

responder

Conveys the responding address. For Connect Responses, this is the local address that is responding to the incoming call. For Connect Confirmations, this is the remote address that responded to the outgoing call.

rqos

Conveys the negotiated quality of service parameters and CONS an non-CONS facilities in response or confirmation.

State

Response

No response is expected when either the NS user or NS provider issue this primitive.

Equivalence

The Connect Response message primitive is equivalent to the N_CONN_RES primitive of the NPI; the Connect Confirmation, the N_CONN_CON.

4.3 Data

Format

The Data message uses the xdataf structure. The control part of the message consists of one M_PROTO message block, and contains the xdataf structure. The data part of the message consists of one or more M_DATA message blocks containing the local or remote NS user data (NSDU).

The xdataf structure is formatted as follows:

     struct xdataf {
         unsigned char xl_type;
         unsigned char xl_command;
         unsigned char More;
         unsigned char setDbit;
         unsigned char setQbit;
     };

Usage

The Data message primitive, N_Data, is used to transfer NS user data to or from the NS user. The control part of the message consists of one M_PROTO message block, and contains the xdataf structure. The data part of the message consists of one or more M_DATA message blocks containing the local or remote NS user data (NSDU).

Parameters

The xdataf structure contains the following members:

xl_type

Always XL_DAT.

xl_command

Always N_Data, for both Data Request and Data Indication.

More

When non-zero, this field conveys that a subsequent N_Data message primitive will contain additional data belonging to the same NSDU. When zero, this field conveys that the data contained in the message primitive completes an NSDU.

setDbit

Conveys that the D-bit is to be (or was) associated with the NSDU. When the data portion represents part of an NSDU, the bit must be set or clear on each request or indication belonging to the same NSDU.

setQbit

Conveys that the Q-bit is to be (or was) associated with the NSDU. When the data portion represents part of an NSDU, the bit must be set or clear on each request or indication belonging to the same NSDU.

State

This message primitive is only valid during the data transfer phase.

Response

No response is expected when either the NS user or NS provider issue this primitive, unless the D-bit is set, in which case a Data Acknowledgement response is expected from the NS provider or NS user, respectively.

Equivalence

The Data message primitive is equivalent to the N_DATA_REQ and N_DATA_IND primitives of the NPI.

4.4 Data Acknowledgement

Format

The Data Acknowledgement message uses the xdatacf structure. The control part of the message consists of one M_PROTO message block, and contains the xdatacf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

The xdatacf structure is formatted as follows:

     struct xdatacf {
         unsigned char xl_type;
         unsigned char xl_command;
     };

Usage

The Data Acknowledgement message primitive, N_DAck, is used to request or indicate acknolwedgement of data. The control part of the message consists of one M_PROTO message block, and contains the xdatacf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

Parameters

The xdatacf structure contains the following members:

xl_type

Always XL_DAT.

xl_command

Always N_DAck.

State

This message primitive is only valid during the data transfer phase.

Response

When receipt confirmation from the remote application is active on a VC, this message primitive is used to acknowledge a previous N_DAck request or indication that had the D-bit set. There is a one-to-one correspondence between D-bit data and acknowledgements, with one Data Acknowledgement being conveyed for each Data message primitive conveyed. The Data message primitive acknowledged is always the oldest outstanding Data message primitive that requested acknowledgement.

For CONS calls, if receipt acknowledgement was negotiated on the connection, then an acknowledgement is pending for each Data primitive conveyed. However, to be compatible with previous releases of the NPI, the value of the reqackservice field in the qos structure can be set to request that the D-bit signifies receipt confirmation by the remote DTE only, thus ensuring that no acknowledgements are expected or given.

For non-CONS calls, only when the reqackservice field in the qos structure has been set to the appropriate value will the Data Acknolwedgement procedures apply for an D-bit Data requested or indicated. Otherwise, no acknowledgement is expected or given.

Equivalence

The Data Acknowledgement message primitive is equivalent to the N_DATACK_REQ and N_DATACK_IND primitives of the NPI.

4.5 Expedited Data

Format

The Expedited Data message uses the xedataf structure. The control part of the message consists of one M_PROTO message block, and contains the xedataf structure. The data part of the message consists of one or more M_DATA message blocks containing the local or remote expedited NS user data (ENSDU).

The xedataf structure is formatted as follows:

     struct xedataf {
         unsigned char xl_type;
         unsigned char xl_command;
     };

Usage

The Expedited Data message primitive, N_EData, is used to transfer expedited NS user data to or from the NS user. The control part of the message consists of one M_PROTO message block, and contains the xedataf structure. The data part of the message consists of one or more M_DATA message blocks containing the local or remote expedited NS user data (ENSDU).

The Expedited Data message primitive, N_EData, is used when expedited data, carried by an X.25 interrupt packet, corsses the X.25 NLI service interface from NS provider to user or NS user to provider. The Expedited Data message is a confirmed primitive and must be acknowledged before another expedited data unit can be requested or indicated.

Parameters

The xedataf structure contains the following members:

xl_type

Always XL_DAT.

xl_command

Always N_EData.

State

This message primitive is only valid during the data transfer phase.

Response

When NS user or provider issues this primtive it expectes an Expedited Data Acknowledgement message primitive in reponse. The Expedited Data message is a confirmed primitive and must be acknowledged before another expedited data unit can be requested or indicated.

Equivalence

The Expedited Data message primitive is equivalent to the N_EXDATA_REQ and N_EXDATA_IND primitives of the NPI.

4.6 Expedited Data Acknowledgement

Format

The Expedited Data Acknowledgement message uses the xedatacf structure. The control part of the message consists of one M_PROTO message block, and contains the xedatacf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

The xedatacf structure is formatted as follows:

     struct xedatacf {
         unsigned char xl_type;
         unsigned char xl_command;
     };

Usage

The Expedited Data Acknowledgement message primitive, N_EAck, is used to request or indicate acknolwedgement of expedited data. The control part of the message consists of one M_PROTO message block, and contains the xedatacf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

Parameters

The xedatacf structure contains the following members:

xl_type

Always XL_DAT.

xl_command

Always N_EAck.

State

This message primitive is only valid during the data transfer phase.

Response

The Expedited Data Acknolwedgement message primitive is issued only in confirmation to the Expedited Data message primitive. When an Expedited Data message primitive is delivered to the NS user or provider, the NS provider or user, respectively, must acknowledged the expedited data.

Equivalence

The Expedited Data Acknowledgement message primitive has no equivalent in the NPI.

4.7 Reset Request/Indication

Format

The Reset Request and Reset Indication use the xrstf structure. The control part of the message consists of one M_PROTO message block containing the xrstf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

The xrstf structure is formatted as follows:

     struct xrstf {
         unsigned char xl_type;
         unsigned char xl_command;
         unsigned char originator;
         unsigned char reason;
         unsigned char cause;
         unsigned char diag;
     };

Usage

The Reset Request or Indication message primitive, N_RI, is used by the NS user to request reset of the connection, or by the NS provider to indicate a remote reset. The control part of the message consists of one M_PROTO message block, and contains the xrstf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

The X.25 cause and diagnostic octets, cause and diag, are conveyrs, as well as the CONS originator and reason codes, which are mapped from the cause and diag. A Reset Request on a non-CONS call can specify a non-zero cause code. This has no effect for a CONS call.

Parameters

The xrstf structure contains the following members:

xl_type

Always XL_CTL.

xl_command

Always N_RI.

originator

For a CONS call, contains the CONS originator mapped from the X.25 cause and diagnostic. This field can have one of the following values:

Constant	Value	Description
NS_UNKNOWN	0	Originator is unknown.
NS_USER	1	Originator is the NS user.
NS_PROVIDER	2	Originator is the NS provider.

reason

For a CONS call, contains the CONS reason, mapped from the X.25 cause and diagnostic. This field can have one of the following values when the originator is NS_PROVIDER:

Constant	Value	Description
NS_RUNSPECIFIED	233	Unspecified reason.
NS_RCONGESTION	234	Congestion.

The field can have the following values when the originator is NS_USER:

Constant	Value	Description
NS_RESYNC	250	Resynchronization.

The field can have the following values when the originator is NS_UNKNOWN:

Constant	Value	Description
NS_UNKNOWN	0	Unspecified reason.

cause

Conveys the X.25 cause octet associated with the reset.

diag

Conveys the X.25 diagnostic octet associated with the reset.

State

This message primitive is valid in the data transfer phase.

Response

A Reset Request and Reset Indication message primitive is an acknowledged service. The NS user expects a Reset Confirmation primitive in response to a Reset Request; the NS provide, a Reset Response primitive in reesponse to a Reset Indication.

A collision between a Reset Indication and a Reset Request is taken to acknolwedge the Reset Request and no Reset Confirmation is then issued.

Equivalence

The Reset Request message primitive is equivalent to the N_RESET_REQ of the NPI; the Reset Indication, N_RESET_IND.

4.8 Reset Response/Confirmation

Format

The Reset Response and Reset Confirmation use the xrscf structure. The control part of the message consists of one M_PROTO message block containing the xrscf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

The xrscf structure is formatted as follows:

     struct xrscf {
         unsigned char xl_type;
         unsigned char xl_command;
     };

Usage

The Reset Response or Confirmation message primitive, N_RC, is used by the NS user to respond to a Reset Indication for the connection, or by the NS provider to confirm a Reset Request. The control part of the message consists of one M_PROTO message block, and contains the xrscf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

Parameters

The xrscf structure contains the following members:

xl_type

Always XL_CTL.

xl_command

Always N_RC.

State

This message primitive is valid in the data transfer phase.

Response

The Reset Response message primitive is used by the NS user to respond to and acknowledge a previous Reset Indication message primitive from the NS provider. The Reset Confirmation message primitive is used by the NS provider to respond to and acknowledge a previous Reset Request message primitive from the NS user.

Equivalence

The Reset Response message primitive is equivalent to the N_RESET_RES of the NPI; the Reset Confirmation, N_RESET_CON.

4.9 Disconnect Request/Indication

Format

The Disconnect Request and Disconnect Indication use the xdiscf structure. The control part of the message consists of one M_PROTO message block containing the xdiscf structure. The data part of the message consists of zero or one M_DATA message blocks containing the Clear User Data (if any).

The xdiscf structure is formatted as follows:

     struct xdiscf {
         unsigned char xl_type;
         unsigned char xl_command;
         unsigned char originator;
         unsigned char reason;
         unsigned char cause;
         unsigned char diag;
         int conn_id;
         unsigned char indicated_qos;
         struct xaddrf responder;
         struct xaddrf deflected;
         struct qosformat qos;
     };

Usage

The Disconnect Request or Indication message primitive, N_DI, is used by the NS user to reject an incoming connection or disconnect an existing connection, or by the NS provider to reject an outgoing connection or disconnect an existing connection. The control part of the message consists of one M_PROTO message block, and contains the xdiscf structure. The data part of the message consists of zero or one M_DATA message blocks containing the Clear User Data (CUD) when supplied.

The X.25 cause and diagnostic octets, cause and diag, are presented, as well as the CONS originator and reason codes mapped from the X.25 cause and diagnostic. A Disconnect Request for a non-CONS call can specify a non-zero cause code. This has no effect for a CONS call.

Parameters

The xdiscf structure contains the following members:

xl_type

Always XL_CTL.

xl_command

Always N_DI.

originator

For a CONS call, contains the CONS originator (NS user, NS provider, or unknown), mapped from the X.25 cause and diagnostic. This field can have one of the following values:

Constant	Value	Description
NS_UNKNOWN	0	Originator is unknown.
NS_USER	1	Originator is the NS user.
NS_PROVIDER	2	Originator is the NS provider.

reason

For a CONS call, contains the CONS reason, mapped from the X.25 cause and diagnostic. This field can have one of the following values when the originator is NS_PROVIDER:

Constant	Value	Description
NS_GENERIC	224	General.
NS_DTRANSIENT	225	Disconnect, transient.
NS_DPERMANENT	226	Disconnect, permanent.
NS_TUNSPECIFIED	227	Reject, unspecified, transient.
NS_PUNSPECIFIED	228	Reject, unspecified, permanent.
NS_QOSNATRANSIENT	229	Reject, QOS unavailable, transient.
NS_QOSNAPERMANENT	230	Reject, QOS unavailable, permanent.
NS_NSAPTUNREACHABLE	232	Reject, NSAP unreachable, transient.
NS_NSAPPUNREAHCABLE	235	Reject, NSAP unreachable, permanent.

The field can have the following values when the originator is NS_USER:

Constant	Value	Description
NU_GENERIC	240	General.
NU_DNORMAL	241	Disconnect, normal.
NU_DABNORMAL	242	Disconnect, abnormal.
NU_DINCOMPUSERDATA	243	Disconnect, incomprehensible user data.
NU_TRANSIENT	244	Reject, transient.
NU_PERMANENT	245	Reject, permanent.
NU_QOSNATRANSIENT	246	Reject, QOS unavailable, transient.
NU_QOSNAPERMANENT	247	Reject, QOS unavailable, permanent.
NU_INCOMPUSERDATA	248	Reject, Call User Data facility.
NU_BADPROTID	249	Reject, Bad protocol identifier.

cause

Conveys the X.25 cause octet associated with the disconnect.

diag

Conveys the X.25 diagnostic octet associated with the disconnect.

conn_id

When a Disconnect Request is used to refuse and incoming connection, this field contains the conn_id from the corresponding Connect Indication message primitive.

indicated_qos

When non-zero, conveys that facilities and quality of service paraemters are being indicated.

responder

Conveys the responding address. This is the local responding address in a Disconnect Request used to refuse an incoming call, and a remote responding address in a Disconnect Indication refusing an outgoing call.

deflected

When the call_deflect field of the associated qos structure is non-zero, this field conveys the deflected address. The deflected address is the address of the remote station to which the call is being deflected. This is set by the NS user when deflecting a call with a Disconnect Request refusing an incoming connection; and by the NS provider when an outgoing call has been deflected.

qos

Conveys the CONS quality of service parameters and non-OSI facilities associated with the disconnect. This is used currently for the charging information when an existing connection is disconnected, and for the deflection facility when an incoming or outgoing call is being deflected.

State

This primitive is valid in the data transfer phase; it is also valid in the incoming or outgoing connecting phase. The call moves to the disconnect phase.

Response

This primitive is valid in response to a previously sent Connect Request or received Connect Indication message primitive; or, to simply request or indicate disconnection of an existing connection.

When an existing connection is disconnect with a Disconnect Request by the NS user, the NS user expects a Disconnect Confirmation to acknowledge the disconnect. All other message should be discarded from the Stream until the Disconnect Confirmation is received.

When a Disconnect Indication is issued by the NS provider, all messages sent downstream except Connect Request or Connect Response messages are silently discarded.

A disconnect collision can occur, where Disconnect Request and a Disconnect Indication messages collide. In this case, the Disconnect Indication messages is taken as a confirmation and no Disconnect Confirmation message should be expected by the NS user.

Equivalence

The Disconnect Request message primitive is equivalent to the N_DISCON_REQ of the NPI; the Disconnect Indication, N_DISCON_IND.

4.10 Disconnect Confirmation

Format

The Disconnect Confirmation uses the xdcnff structure. The control part of the message consists of one M_PROTO message block, containing the xdcnff structure. There is no data part (M_DATA message blocks) associated with this message primitive.

The xdcnff structure is formatted as follows:

     struct xdcnff {
         unsigned char xl_type;
         unsigned char xl_command;
         unsigned char indicated_qos;
         struct qosformat qos;
     };

Usage

The Disconnect Confirmation message primitive, N_DC, is used to confirm a previous Disconnect Request and provide charging information facilities associated with a previously established call. The control part of the message consists of one M_PROTO message block, containing the xdcnff structure. There is no data part (M_DATA message blocks) associated with this message primitive.

Parameters

The xdcnff structure contains the following members:

xl_type

Always XL_CTL.

xl_command

Always N_DC.

indicated_qos

When non-zero, conveys that CONS quality of service parameters and non-OSI facilities are indicated.

qos

Conveys the facilities indicated. This is only used on a Disconnect Confirmation to indicate the charging information facility.

State

This primitive is valid in the disconnecting phase.

Response

This message primitive is only issued by the NS provider. No response is expected when the NS provider issues this primitive.

Equivalence

The Disconnect Confirmation message primitive has no equivalent in NPI.

4.11 Abort Indication

Format

The Abort Indication uses the xabortf structure. The control part of the message consists of one M_PROTO message block containing the xabortf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

The xabortf structure is formatted as follows:

     struct xabortf {
         unsigned char xl_type;
         unsigned char xl_command;
     };

Usage

The Abort Indication message primtiive is used by the X.25 driver in lieue of a Disconnect Indication, when there is insufficient resources to generate a Disconnect Indication. Therefore, some NS providers may never issue this message primitive. Nevertheless, the NS user must be prepared to receive this message primitive in liueue of a Disconnect Indication. The control part of the message consists of one M_PROTO message block containing the xabortf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

Parameters

The xabortf structure contains the following members:

xl_type

Always XL_CTL.

xl_command

Always N_Abort.

State

This message primitive is only valid in the data transfer phase. The call moves to the disconnected phase.

Response

This message primitive is only issued by the NS provider. No response is expected when the NS provider issues this primitive.

Equivalence

The Abort Indication message primitive is equivalent to the N_DISCON_IND of the NPI.

4.12 Listen Request/Response

Format

The Listen Request and Listen Response use the xlistenf structure. The control part of the message consists of one M_PROTO or M_PCPROTO message block, and contains the xlistenf structure. The data part of the message consists of one or more M_DATA message blocks containing the call user data and address of interest.

The xlistenf structure is formatted as follows:

     struct xlistenf {
         unsigned char xl_type;
         unsigned char xl_command;
         int lmax;
         int l_result;
     };

The M_DATA message blocks are formatted as follows:

     struct lcud {
         unsigned char l_cumode;
         unsigned char l_culength; /* octets */
         unsigned char l_cubytes[0];
         /* followed by l_culength bytes */
     };
     struct ladd {
         unsigned char l_mode;
         unsigned char l_type;
         unsigned char l_length; /* semi-octets */
         unsigned char l_add[0];
         /* followed by ((l_length+1)>>1) bytes
            containing l_length semi-octets. */
     };

Usage

The Listen Request or Response is used when an NS user wishes to register interest in incoming calls and the NS provider acknowledges the request. The control part of the message consists of one M_PROTO or M_PCPROTO message block, and contains the xlistenf structure. The data part of the message consists of one or more M_DATA message blocks containing the call user data and address of interest.

The Listen Request queue is ordered in terms of the amount of listen data supplied. The more a Listen Request asks for, the higher its place in the queue. Connect Indications are sent to the listener whose listening criteria are best matched.

Privileged users can ask for a Listen Request to be placed at the front of the queue, regardless of the amount of listen data supplied. To do this, the Listen Request should be sent as a M_PCPROTO message. This is achieved by setting the RS_HIPRI flag in putmsg(2s). Such requests are searched in the order in which they arrive.

The system adminstrator controls whether or not listening for incoming calls is a privileged operation. If listening is privileged, incoming calls will be sent only to on listen streams opened by a user with superuser privilege. This prevents other users accepting calls that may contain private information, passwords, and so on.

In systems where privileged and non-privileged listens are allowed:

• Privileged listens have priority.
• A matching but busy privileged listen prevents a search of any non-privileged listens.

Parameters

The xlistenf structure contains the following members:

xl_type

Always XL_CTL.

xl_command

Always N_Xlisten.

lmax

Conveys the maximum number of outstanding Connect Indications that the listening Stream is willing to accept, for the addresses conveyed in the attached M_DATA message blocks.

Listen requests are cummulated but this field is not. The maximum number of outstanding Connect Indications will be reflected by the value of this field for the last successful Listen Request issued by the NS user.

l_result

Conveys the result of the Listen Request in a Listen Response message primitive. An error in the parameters or a lack of resources results in this flag being set to a non-zero value.

The M_DATA portion of the message contains the following members:

l_cumode

Specifies the type of matching. This field can have one of the following values:

Constant	Value	Description
X25_DONTCARE	1	Represents a wildcard.
X25_STARTSWITTH	2	Contains a prefix.
X25_IDENTITY	3	Contains an identity match.

Notes:

1. When the l_cumode is set to X25_DONTCARE, the l_culength and l_cubytes fields are ommitted from the M_DATA message block.

l_culength

Specifies the length of the l_cubytes field in octets.

l_cubytes

Contains the bytes to be matched against the Call User Data (CUD).

l_mode

Specifies the type of matching. This field can have one of the following values:

Constant	Value	Description
X25_DONTCARE	1	Represents a wildcard.
X25_STARTSWITTH	2	Contains a prefix.
X25_IDENTITY	3	Contains an identity match.
X25_PATTERN	4	Contains a pattern.5

Notes:

1. When the l_mode is set to X25_DONTCARE, the l_type, l_length and l_add fields are ommitted from the M_DATA message block.
2. When the l_mode is set to X25_PATTERN, the l_add field can contain the wilcard digits ‘*’ and ‘?’ that have the same effect as these characters in regular expressions: that is, ‘*’ represents zero or more characters of any value, and ‘?’ represents single character of any value. The ‘*’ character is represented by the BCD digit 0xF and the ‘?’ character is represented by the BCD digit 0xE.

l_type

This field can have one of the following values:

Constant	Value	Description
X25_DTE	1	Contains an X.25 DTE (X.121) address.
X25_NSAP	2	Contains a CONS NSAP address.

l_length

Specifies the length of the l_add field in semi-octets. That is, the length of the l_add field in octets is: ‘((l_length+1)>>1)’. The maximum length for a DTE address is 15 or 17 semi-octets (that is, 8 or 9 octets) depending upon whether TOA/NPI addressing is used. The maximum length for an NSAP address is 20 semi-octets (that is, 10 octets).

l_add

Contains the bytes to be matched against the DTE address or the NSAP address.

Each semi-octet is a BCD representation. That is, digits in the range ‘0’ through ‘9’ are represented by 0x0 through 0x9 in the semi-octet position. The first digit occupies the high order nibble of the first octet; the second digit, the low order nibble of the first octet; the third digit, the high order nibble of the second octet; and so on. If l_length is odd, the low order nibble of the last octet is ignored.

When the l_mode field is X25_PATTERN, a semi-octet of 0xF represents a ‘*’ wildcard, and a semi-octet of 0xE represents a ‘?’ wildcard.

State

This message primitive is valid in the disconnected phase or during an incoming connecting phase.

Response

When an NS user issues a Listen Request, the NS user expects a Listen Response message primitive from the NS provider.

Equivalence

The Listen Request message primitive is equivalent to the N_BIND_REQ of the NPI; the Listen Response, N_BIND_ACK.

4.13 Extended Listen Request/Response

Format

The Extended Listen Request and Extended Listen Response use the xlistenf structure. The control part of the message consists of one M_PROTO or M_PCPROTO message block, and contains the xlistenf structure. The data part of the message consists of one or more M_DATA message blocks containing the call user data and address of interest.

The xlistenf structure is formatted as follows:

     struct xlistenf {
         unsigned char xl_type;
         unsigned char xl_command;
         int lmax;
         int l_result;
     };

The M_DATA message blocks are formatted as follows:

     struct lcud {
         unsigned char l_cumode;
         unsigned char l_culength; /* octets */
         unsigned char l_cubytes[0];
         /* followed by l_culength bytes */
     };
     struct lsn {
         unsigned char l_snmode;
         unsigned char l_snlen;
         unsigned char l_snid[0];
         /* followed by l_snlen bytes */
     };
     struct ladd {
         unsigned char l_mode;
         unsigned char l_type;
         unsigned char l_length; /* semi-octets */
         unsigned char l_add[0];
         /* followed by ((l_length+1)>>1) bytes
            containing l_length semi-octets. */
     };

Usage

The Extended Listen Request or Response is used when an NS user wishes to register interest in incoming calls and the NS provider acknowledges the request. The control part of the message consists of one M_PROTO or M_PCPROTO message block, and contains the xlistenf structure. The data part of the message consists of one or more M_DATA message blocks containing the call user data and address of interest.

Parameters

The xlistenf structure contains the following members:

xl_type

Always XL_CTL.

xl_command

Always N_Xelisten.

lmax

Conveys the maximum number of outstanding Connect Indications that the listening Stream is willing to accept, for the addresses conveyed in the attached M_DATA message blocks.

Listen requests are cummulated but this field is not. The maximum number of outstanding Connect Indications will be reflected by the value of this field for the last successful Listen Request issued by the NS user.

l_result

Conveys the result of the Listen Request in a Listen Response message primitive. An error in the parameters or a lack of resources results in this flag being set to a non-zero value.

The M_DATA portion of the message contains the following members:

l_cumode

Specifies the type of matching. This field can have one of the following values:

Constant	Value	Description
X25_DONTCARE	1	Represents a wildcard.
X25_MATCH	4	Contains a pattern match.6

Notes:

1. When the l_cumode is set to X25_DONTCARE, the l_culength and l_cubytes fields are ommitted from the M_DATA message block.

l_culength

Specifies the length of the l_cubytes field in octets.

l_cubytes

Contains the bytes to be matched against the Call User Data (CUD).

l_snmode

Specifies the matching mode. This field can have one of the following values:

Constant	Value	Description
X25_DONTCARE	1	Represents a wildcard.
X25_MATCH	4	Contains a pattern match.7

Notes:

1. When the l_mode is set to X25_DONTCARE, the l_snlen and l_snid fields are ommitted from the M_DATA message block.

l_snlen

l_snid

l_mode

Specifies the type of matching. This field can have one of the following values:

Constant	Value	Description
X25_DONTCARE	1	Represents a wildcard.
X25_MATCH	4	Contains a pattern match.8

Notes:

1. When the l_mode is set to X25_DONTCARE, the l_type, l_length and l_add fields are ommitted from the M_DATA message block.

l_type

This field can have one of the following values:

Constant	Value	Description
X25_DTE	1	Contains an X.25 DTE (X.121) address.
X25_NSAP	2	Contains a CONS NSAP address.

l_length

Specifies the length of the l_add field in semi-octets. That is, the length of the l_add field in octets is: ‘((l_length+1)>>1)’. The maximum length for a DTE address is 15 or 17 semi-octets (that is, 8 or 9 octets) depending upon whether TOA/NPI addressing is used. The maximum length for an NSAP address is 20 semi-octets (that is, 10 octets).

l_add

Contains the bytes to be matched against the DTE address or the NSAP address.

State

This message primitive is valid in the disconnected phase or during an incoming connecting phase.

Response

When an NS user issues a Listen Request, the NS user expects an Extended Listen Response message primitive from the NS provider.

Equivalence

The Extended Listen Request message primitive is equivalent to the N_BIND_REQ of the NPI; the Extended Listen Response, N_BIND_ACK.

4.14 Listen Cancel Request/Response

Format

The Listen Cancel Request and Listen Cancel Response use the xcanlisf structure. The control part of the message consists of one M_PROTO message block containing the xcanlisf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

The xcanlisf structure is formatted as follows:

     struct xcanlisf {
         unsigned char xl_type;
         unsigned char xl_command;
         int c_result;
     };

Usage

The Listen Cancel Request message primitive is used by the NS user to cancel listening on any address. The Listen Cancel Request removes all listen addresses from the Stream. There is no way of cancelling a Listen Request on a particular address; this message is probably used when the use of the Stream is about to be changed by the NS user. The control part of the message consists of one M_PROTO message block containing the xcanlisf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

Parameters

The xcanlisf structure contains the following members:

xl_type

Always XL_CTL.

xl_command

Always N_Xcanlis.

c_result

Conveys the result of the Listen Cancel Request in a Listen Cancel Response message primitive. An failure to cancel a listen request results in this flag being set to a non-zero value. A Listen Cancel Request may fail because no listen was in effect, or a Connect Indication is outstanding.

State

This message primitive is valid in the disconnected phase.

Response

When an NS user issues a Listen Cancel Request, the NS user expects a Listen Cancel Response message primitive from the NS provider.

Equivalence

The Listen Cancel Request message primitive is equivalent to the N_UNBIND_REQ of the NPI; the Listen Cancel Response, N_OK_ACK.

4.15 PVC Attach

Format

The PVC Attach uses the pvcattf structure. The control part of the message consists of one M_PROTO message block containing the pvcattf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

The pvcattf structure is formatted as follows:

     struct pvcattf {
         unsigned char xl_type;
         unsigned char xl_command;
         unsigned short lci;
         union {
             uint32_t link_id;
             uint32_t sn_id;
         };
         unsigned char reqackservice;
         unsigned char reqnsdulimit;
         int nsdulimit;
         int result_code;
     };

Usage

The PVC Attach message primitive is used by the NS user when requesting an attachment of the Stream to a PVC. The NS provider uses the PVC Attach message primitive to acknolwedge a previous PVC Attach message primitive issued by the NS user. The control part of the message consists of one M_PROTO message block containing the pvcattf structure. There is no data part (M_DATA message blocks) associated with this message primitive.

Parameters

The pvcattf structure contains the following members:

xl_type

Always XL_CTL.

xl_command

Always N_PVC_ATTACH.

lci

Conveys the logical channel identifier (LCI) of the PVC.

link_id

Conveys the link identifier for the PVC. This is a Solstice X.25 specific field.

The link_id and sn_id fields are equivalent, with a slightly different name and format for Solstice X.25.

sn_id

Conveys the subnetwork identifier for the PVC. This is the non-Solstice X.25 specific field.

This field is sometimes specified as a unsigned long. It has been declared as an uint32_t to support compatibility of 32-bit applications running over a 64-bit kernel.

reqackservice

When non-zero, conveys that the receipt confirmation service is requested by the use of the D-bit. This field can have one of the following values:

Constant	Value	Description
-	0	No receipt confirmation.
RC_CONF_DTE	1	Confirmation by the remote terminal.
RC_CONF_APP	2	Confirmation by the remote application.

In the case of receipt confirmation by the remote station, no acknowledgements are expected or given over the X.25 NLI service interface. For receipt confirmation by the remote application, there is a one-to-one correspondence between D-bit data and acknolwedgements passing in opposite directions. One data acknowledgement is received or sent for each D-bit data packet sent or received over the X.25 NLI service interface.

reqnsdulimit

When non-zero, conveys that an NSDU concantenation limit is asserted and the nsdulimit field is valid.

nsdulimit

When non-zero, conveys the packet concatenation limit for NSDUs when the reqnsdulimit field is also non-zero.

result_code

When the PVC Attach message primitive is used by the NS provider to acknowledge a previous PVC Attach message primitive issued by the NS user, this field is non-zero when an error has been encountered that prevents the attachment of the PVC.

This field can have one of the following values:

Constant	Value	Description
PVC_SUCCESS	0	Operation was successful.
PVC_NOSUCHSUBNET	1	Subnetwork not configured.
PVC_CFGERROR	2	LCI not in range, no PVCs.
PVC_NODBELEMENTS	3	No database available.
PVC_PARERROR	4	Error in request parameters.
PVC_BUSY	6	PVC in non-attach state.
PVC_CONGESTION	7	Resources unavailable.
PVC_WRONGSTATE	8	State wrong for function.
PVC_NOPERMISSION	9	Inadequate permissions.
PVC_LINKDOWN	10	The link has gone down.
PVC_RMTERROR	11	No reponse from remote.
PVC_USRERROR	12	User interface error detected.
PVC_INTERROR	13	Internal error.
PVC_NOATTACH	14	Not attached yet.
PVC_WAIT	15	Wait code, not to user.

State

This message primitive is valid in the disconnected phase.

Response

When an NS user issues a PVC Attach, the NS user expects a PVC Attach message primitive from the NS provider in response.

Equivalence

The PVC Attach message primitive is equivalent to the N_CONN_REQ and N_CONN_CON of the NPI.

4.16 PVC Detach

Format

The PVC Detach uses the pvcdetf structure. The control part of the message primitive consists of one M_PROTO message block containing the pvcdetf s