NPI M-bit and D-bit Processing

Introduction

The Gcom® NPI STREAMS driver serves as the interface between the user's application program and the X.25, SNA and Bisync protocols. This interface is mediated by the Gcom NPI API library. Of the messages exchanged between the API Library and the NPI driver some of message types are used to communicate payload data. The NPI interface protocol makes provision for the case in which the user's message may be larger than the negotiated packet size at the protocol level.

This document describes how this case is treated in Gcom's NPI driver. The document is relative to Gcom software release 1.51 or later.

Header Files

The NPI message types and DATA_xfer_flags values are defined in the file <gcom/npi.h>. The NPI API functions and constants are defined in the file <gcom/npiapi.h>.

Inbound Messages

The NPI driver makes no attempt to consolidate incoming packets into larger messages for the user. If an incoming packet has neither the M-bit nor the D-bit set it is forwarded upstream to the user as a simple M_DATA STREAMS message.

If the incoming packet has either the M-bit or D-bit set it is forwarded upstream to the user as an M_PROTO STREAMS message containing an NPI N_DATA_IND message with the payload data attached in an M_DATA STREAMS message. In the NPI N_DATA_IND header, the DATA_xfer_flags field has the N_MORE_DATA_FLAG set if the incoming packet had the M-bit set. It has the N_RC_FLAG set if the incoming packet had the D-bit set.

When receiving such data using the npi_rcv API function the "flags out" parameter will be set to NPIAPI_MORE_DATA and/or NPIAPI_RC_FLAG corresponding to the flags present in the N_DATA_IND header.

Thus, the user's application has the full responsibility of concatenating partial messages into complete messages according to the "more data" indications.

Outbound Messages

The user application can write messages to NPI that are larger than the negotiated packet size of the underlying connection. NPI breaks these messages into packet sized segments and sets the "M-bit" according to a set of rules. The individual protocols treat these "M-bit" packets according to the dictates of the specifications for the protocol involved.

The appliation program will typically use the NPI API function npi_put_data_proto and pass some value for the "flags" argument. This argument can be zero, which results in a simple M_DATA STREAMS message being sent to NPI. If it is non-zero it can have the logical "or" of the values N_MORE_DATA_FLAG and N_RC_FLAG. This case leads to an M_PROTO STREAMS message with an attached M_DATA being sent to NPI. The M_PROTO will contain an N_DATA_REQ message with the DATA_xfer_flags field set to the "flags" argument passed to npi_put_data_proto.

The treatment of out bound messages by NPI breaks down into the following cases.

  • The message is less than or equal to a packet size in length and does not have the N_MORE_DATA_FLAG set. If NPI is consolidating M-bit messages then the data from this message are added. If there are leftover bytes after the full packet size is reached then the consolidated packet is forwarded to the protocol module with the M-bit set and the remaining bytes are forwarded with the M-bit reset. If NPI is not consolidating M-bit messages then NPI forwards the message to the protocol module with no further processing. This latter case is the most efficient method of sending data in terms of CPU utilization.

  • The message is less than or equal to a packet size in length and has the N_MORE_DATA_FLAG set, but does not have the N_RC_FLAG set. Such messages are consolidated until they reach a full packet size at which point the packet is forwarded to the protocol module with the M-bit set. If there are bytes left over after a full packet is forwarded they are retained by NPI for further consolidation.

  • The message is less than or equal to a packet size in length and has both the N_MORE_DATA_FLAG and the N_RC_FLAG set. This case is similar to case #1 in that NPI will forward something to the protocol module without delay. The final (or only) packet forwarded to the protocol module will have both the M-bit and D-bit set in this case, but otherwise the processing is the same as for case #1.

  • The message is greater than a packet size in length and does not have the N_MORE_DATA_FLAG set. This message will be broken into full packets and each will be sent to the protocol module with the M-bit set. Once the message has been reduced to less than or equal to a full packet it is processed as in case #1.

  • The message is greater than a packet size in length and has the N_MORE_DATA_FLAG set, but does not have the N_RC_FLAG set. This message will be broken into full packets and each will be sent to the protocol module with the M-bit set. Once the message has been reduced to less than or equal to a full packet it is processed as in case #2.

  • The message is greater than a packet size in length and has both the N_MORE_DATA_FLAG and the N_RC_FLAG set. This message will be broken into full packets and each will be sent to the protocol module with the M-bit set and the D-bit reset. Once the message has been reduced to less than or equal to a full packet it is processed as in case #3.

The packets that NPI forwards to the protocol module are subject to protocol level flow control. This means that it may take some time to "packetize" a long out bound message since it may be necessary to await protocol level acknowledgements from the remote peer protocol process.

In general, messages with the N_MORE_DATA_FLAG set are subject to delay in the NPI module pending further data to concatenate to fill a packet. It is unwise for an application to set the N_MORE_DATA_FLAG unless it intends to supply more data in a timely manner.

Receipt Confirmation

Gcom's NPI driver will allow the use of the N_RC_FLAG in an N_DATA_REQ message whether or not the connection was established using the receipt confirmation option. If the RC option was not specified then the acknowledgement via N_DATACK_IND will have local significance only and will occur when the remote protocol peer (X.25 or Bisync) acknowledges the data packet. The data packet itself will not carry the D-bit when it is transmitted. Note that without the RC option, some X.25 networks implement end-to-end acknowledgements anyway, and others use local DTE/DCE acknowledgements only.

If the connection is set up with the receipt confirmation option set then the X.25 data packet will have the D-bit set and the N_DATACK_IND should therefore have end-to-end significance.

In order to establish a connection with the receipt confirmation option set, the application program issues an outgoing connection using one of the variations of the API routine npi_connect, it must first assign the value REC_CONF_OPT (defined in <gcom/npi.h>) to the global variable npi_connect_flags (defined in <gcom/npiapi.h>).

The same global variable must be set when listening for incoming connections to enable this feature if it is requested by the incoming connection. If the npi_connect_flags variable is set and an incoming connection does not request receipt confirmation then the feature will not be enabled for the connection.

Protocol Considerations

The N_MORE_DATA_FLAG and the N_RC_FLAG map directly into the M-bit and D-bit of X.25. X.25 rules state that packets with the M-bit set must either be full packets or also have the D-bit set. This is why NPI saves up M-bit packets for consolidation.

In SNA one uses the SNA API rather than the NPI API to interface one's application. Considerations of "more data" at the NPI API level are not germane to an SNA application. The SNA API has its own methods and rules for segmenting data.

In Bisync the N_RC_FLAG has meaning only between the application and the NPI driver as described above. The N_MORE_DATA_FLAG will cause the Bisync block to be terminated with an ETB rather than an ETX.