Chapter 2. Data Structures
Prev |  | Next

## Chapter 2. Data Structures

This chapter contains the following sections:

- “Addresses”

- “Quality of Service and X.25 Facilities”

This chapter describes the data structures used by NLI primitives to specify X.25 addresses and facilities. These data structures are defined in the file <`sys/snet/x25_proto.h`>. (This file is included in the subsystem `eoe2.sw.dlpi`, which is a prerequisite for IRIS SX.25.)

## Addresses

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

- the subnetwork on which outgoing Connect Requests are to be sent and on which Connect Indications arrive

- NSAPs (Network Service Access Points) and SNPAs (Subnetwork Point of Attachments), or DTE (Data Terminal Equipment) addresses and LSAPs (Link Service Access Points)

- options in encoding of addresses (NSAPs)

The addressing format is:

    #define        NSAPMAXSIZE           20
    struct xaddrf {
        unsigned long         sn_id;
        unsigned char         aflags;
        struct lsapformat     DTE_MAC;
        unsigned char         nsap_len;
        unsigned char         NSAP[NSAPMAXSIZE];
    }

The fields in this structure are:

sn_id |  | The subnetwork identifier, selected by the system administrator. It identifies the subnetwork required for a Connect Request, or on which a Connect Indication arrived. The sn_id field holds a representation of the one byte string subnetwork identifier as an unsigned long. The X.25 library routine snidtox25 can be used to convert the character subnetwork identifier to an unsigned long.
aflags |  | Specifies the options required (or used) by the subnetwork to encode and interpret addresses. When there is a value in the NSAP field, aflags takes one of the three values listed in Table 2-1. When the NSAP field is empty, aflags has the value 0. See the `x25addr`(5), `stox25`(3N), `x25tos`(3N), and `getxhostent`(3N) reference pages for details about the X.25 address format. Table 2-1. aflags Values
Value | Meaning
--- | ---
0 | NSAP field contains an OSI (Open Systems Interconnection) encoded NSAP address
1 | NSAP field contains a non-OSI encoded extended address
2 | DTE_MAC field contains the logical channel identifier (LCI) of a permanent virtual circuit (PVC)
DTE_MAC |  | Holds the DTE address, the MAC+SAP (medium access control+service access point) address or the LCI. This is binary. The lsapformat structure is described below.
nsap_len |  | This indicates the length of the NSAP, if any (and where appropriate), in semi-octets.
NSAP |  | This carries the NSAP or address extension (see field aflags) when present as indicated by nsap_len. This is binary.

The format of the lsapformat structure is as follows:

    #define    LSAPMAXSIZE    9
    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) plus SAP (2). The SAP always follows the MAC address. The DTE can be up to 15 decimal digits unless X.25(88) and TOA/NPI (Type Of Address/Numbering Plan Identification) addressing is being used, when it can be up to 17 decimal digits. For an LCI the length is 3.
lsap_add |  | This holds the DTE, MAC+SAP or LCI, when present, as indicated by lsap_len. This is binary.

## Quality of Service and X.25 Facilities

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. Refer to the SX.25 Administrator's Guide for details on the options selected for a particular subnetwork. The facility set can be broken down into two main groups—those required for Connection-Oriented Network Service (CONS) support and those for non-OSI procedures (X.29, for example).

| Note: CONS can also use the non-OSI procedures.

### CONS Quality of Service Parameters

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

- Priority

- Receipt Acknowledgment

CONS-related quality of service parameters are defined in this 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 fields in this structure are defined as follows:

Throughput Class |  | reqtclass is nonzero if the throughput negotiation parameter is selected. The fields locthroughput and remthroughput contain the four-bit throughput encoding for local-to-remote and remote-to-local, respectively.
Minimum Throughput Class |  | reqminthruput is nonzero if the minimum throughput negotiation parameter is selected. In this case, the fields locminthru and remminthru contain the four-bit throughput encoding for the directions local-to-remote and remote-to-local, respectively.
Target Transit Delay |  | In Connect Requests and Indications, reqtransitdelay is nonzero if the transit delay parameter is selected. In this case transitdelay contains the 16-bit value. In a Connect Confirmation, the value of the selected transit delay is placed in the transitdelay field and is nonzero.
Maximum Acceptable Transit Delay |  | If the calling NLI application specifies a maximum acceptable value for the transit delay parameter (lowest quality acceptable), the field reqmaxtransitdelay is nonzero and acceptable contains the 16-bit value of the maximum acceptable.
| Note: Transit delay selection applies only to Connect Requests. There is no transit delay 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.
Priority |  | The reqpriority field is used to request/indicate priority on a connection. The mandatory field prty_data contains the 8-bit value for the priority of data on the connection. The reqprtygain and reqprtykeep fields can be optionally set to indicate that the fields prty_gain and prty_keep contain, respectively, the 8-bit values for the priority to gain and keep a connection. On N-CONNECT requests, the calling NS_user can also specify a lowest acceptable value for priority. The fields reqlowprtydata, reqlowprtygain, and reqlowprtykeep can be set to indicate that the fields lowprtydata, lowprtygain, and lowprtykeep contain, respectively, the 8-bit values for the lowest acceptable priority of data on connection, to gain a connection, and to keep a connection.
Protection |  | If the protection negotiation parameter is selected, the protection_type is nonzero and indicates the type of protection required. In this case the mandatory fields prot_len and protection contain, respectively, the length and value for the target protection. On N-CONNECT requests, the calling NS_user can optionally specify a lowest acceptable protection. In this case, the fields lowprot_len and lowprotection contain, respectively, the length and value for the lowest acceptable protection. Values for protection_type are listed in Table 2-2. Table 2-2. protection_type Values
Value | Name | Meaning
--- | --- | ---
1 | PRT_SRC | Source address specific
2 | PRT_DST | Destination address specific
3 | PRT_GLB | Globally unique
Use of Expedited Data |  | If Expedited Data is required/selected, the field reqexpedited is non- zero. 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.
| 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 the sections “Connect Request/Indication” and “Connect Response/Confirmation” in Chapter 4.
For incoming or outgoing non-CONS calls (denoted by the CONS_call flag 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 Connect Requests and Responses for non-CONS calls.
Receipt Acknowledgment Service |  | If the receipt acknowledgment service is to be used, the field reqackservice is nonzero. 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 acknowledgments 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 acknowledgments, with one data acknowledgment being received or sent for each D-bit data packet sent or received over the X.25 interface.

### Non-OSI Facilities

| Note: The non-OSI facilities are also negotiable by 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 request/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

- X.25 programmable facilities

Facilities and QOS parameters are defined in the following structure:

    #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_TARIFFS * 4
    #define MAX_SC_LEN     MAX_TARIFFS * 8
    #define MAX_MU_LEN     16
    struct extraformat {
        unsigned char     fastselreq;
        unsigned char     restrictresponse, 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 fields in this structure are:

Fast Select |  | For non-OSI services like X.29, if the X.25 facility fast select is to be requested or indicated, the field fastselreq is nonzero.
| Note: For CONS, the use of fast select need not be requested.
Fast Select with Restricted Response |  | If the response to a Connect Request or Indication is to be a Disconnect Indication, the field restrictresponse is nonzero.
Reverse Charging |  | If reverse charging is requested or indicated for a connection, the field reversecharges is non-zero.
| Note: The configuration mode bit SUB_REVCHARGE—see the SX.25 Administrator's Guide—has an impact on whether reverse charging is indicated, since it is possible to select a “per subnetwork status” for receipt of reverse charging.
Packet Concatenation, Packet Size, and Window Size Negotiation |  | The pwoptions field is used to indicate per circuit options. The field is a bit map interpreted as shown in Table 2-3. Table 2-3. pwoptions Values
Bit | Values | Meaning
--- | --- | ---
bit 0 | 0 | Packet size negotiation NOT permitted
| 1 | Packet size negotiation permitted
bit 1 | 0 | Window size negotiation NOT permitted
| 1 | Window size negotiation permitted
bit 2 | 0 | No concatenation limit asserted
| 1 | Assert concatenation limit
The field is defined as follows:
    #define NEGOT_PKT 0x01  /* packet size is
                               negotiable */
    #define NEGOT_WIN 0x02  /* window size is
                               negotiable */
    #define ASSERT_HWM 0x04 /* assert concatenation
                               limit */
This field is used for two reasons: 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. In Connect Requests and Connect Responses, the NLI user can set nsdulimit, the limit value for packet concatenation 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.
Packet Size |  | If the fields locpacket and rempacket are nonzero, locpacket contains indicated or negotiated encoded packet sizes for the direction local-to-remote and rempacket contains indicated or negotiated encoded packet sizes for the direction remote-to-local.
| Note: Actual packet size is 2 to the power of the value.
    #define DEF_X25_PKT 7 /* the standard default
                             X.25 packetsize */
Window Size |  | If the fields locwsize and remwsize are nonzero, they contain indicated or negotiated window sizes for the directions local-to-remote and remote-to-local, respectively.
    #define DEF_X25_WIN 2 /* the standard default
                             X.25 windowsize */
Packet Concatenation |  | If the field nsdulimit is nonzero and the appropriate bit is set in the pwoptions field described above, the nsdulimit specified is used as the concatenation limit.
Network User Identification |  | The network user identification (NUI) is used in Connect Requests and Responses. It is not available on X.25(80) networks. If the field nui_len is nonzero, the network user identification is supplied in nui_field and is of length nui_len octets.
RPOA Selection |  | Recognized private operating agency (RPOA), used in Connect Requests only. If the field rpoa_len is nonzero, the RPOA DNIC information is supplied in rpoa_field and is of length rpoa_len semi-octets. For an X.25(80) network, this is restricted to one RPOA of length 4 semi-octets. The basic format encoding is used for the RPOA selected. For an X.25(84) or X.25(88) network, one or more RPOAs can be selected. The extended format encoding is used only if the number of RPOAs selected is greater than 1. The maximum number of RPOAs selected is restricted to 4. Valid values for rpoa_len are 0, 4, 8, 12, and 16.
Closed User Groups |  | This field is used in Connect Requests and Indications only. If the field cug_type is nonzero, the CUG information is supplied right-justified in cug_field. Values for cug_type are: CUG—closed user group, up to four semi-octets BCUG—bilateral CUG (two members only), four semi-octets
| Note: Incoming CUG facilities are assumed to have been validated by the network. No further checking is performed.
Charging Information |  | If the field reqcharging is nonzero in a Connect Request or Connect Indication, Call Charging is requested. In a Disconnect Indication or Disconnect Confirmation, the following three fields give the lengths of the charging information: chg_cd_len is the length of chg_cd_field—call duration chg_sc_len is the length of chg_sc_field—segment count chg_mu_len is the length of chg_mu_field—monetary unit A zero length field means no charging information is supplied for the relevant charging category.
Called Address Modification |  | A nonzero called_add_mod field holds the reason for any address modification.
Call Redirection |  | A nonzero call_redirect field holds the reason for the call redirection. The field called supplies the originally-called DTE address.
Call Deflection |  | A nonzero call_deflection field holds the reason for the call deflection. The deflected field in the Disconnect Request contains the DTE address, and if required, the NSAP address that the call is to be deflected to.
Programmable X.25 Facilities |  | This field is used in Connect Requests and Connect Indications only. Provision is made for the passing of explicit facility encoded strings for X.25 facilities, and non-X.25 facilities for calling and called networks. The fields x_fac_len, cg_fac_len, and cd_fac_len denote the lengths of the facilities in the field fac_field relating to, respectively, X.25 facilities, non-X.25 facilities for the calling network, and non-X.25 facilities for the called network. If a length field is zero, this denotes that no facilities are supplied for the corresponding facility category.
| 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/window sizes). If any non-X.25 facilities are supplied, the appropriate marker is inserted before the supplied facilities.

Prev | Table of Contents | Next
Chapter 1. Introduction to NLI |  | Chapter 3. Listens