Manpage of NPI-IP

NPI-IP

Section: Network Provider Interface (NPI) (7)
Updated: 2008-10-31
Index Return to Main Contents

NAME

npi_ip - Network Provider Interface (NPI) - Internet Protocol (IP) Corrigendum

SYNOPSIS

#include <sys/npi.h>
#include <sys/npi_ip.h>

DESCRIPTION

NPI-IP provides a Stream supporting the Network Provider Interface[1], npi(7), to the Internet Protocol, ip(7). This STREAMS(4) interface provides the ip(7) protocol service interface using the N-primitives of the npi(7). This interface is intended solely for use by user programs or protocol modules requiring the common npi(7) interface, such as the xti(3) and sockets(3) library.

Address Formats

For consistency with other protocol modules, the address format used by NPI-IP is a Internet Protocol socket address (sockaddr_in structure) in address family AF_INET or (sockaddr_in6 structure) in address family AF_INET6. The sockaddr_in structure is described in ip(7). The sockaddr_in6 structure is described in ipv6(7).

NPI-IP supports the notion of multi-homing in support of the Stream Control Transmission Protocol (SCTP)[2] described in sctp(4). SCTP requires that an association be bound to multiple IP or IPv6 addresses. In support of multi-homing, NPI-IP permits multiple addresses to be specified to bind. When multiple addresses are required, they are specified as a special packed list of sockaddr_in or sockaddr_in6 structures. The list forms the address specified using the ADDR_length and ADDR_offset fields in the N_INFO_ACK(7), N_BIND_REQ(7) and N_BIND_ACK(7) primitives.

For IPv4, the format of the address is a sockaddr_in structure followed by an array of sin_addr members. This is a sockaddr_ina structure defined as follows:

struct sockaddr_ina {
    unsigned short sin_family;
    unsigned short sin_port;
    struct in_addr sin_addr[];
};

QOS Parameters

NPI-IP provides Quality of Service parameters using IP-specific as described in the sections that follow. OSI conforming structures are not used.

N_QOS_SEL_INFO_IP

Used with the N_INFO_ACK(7) and N_OPTMGMT_REQ(7) primitives, it provides a selection of quality of service parameters for both connectionless and connection-oriented providers. The structure contains the following fields:

n_qos_type: Always N_QOS_SEL_INFO_IP indicating the N_qos_sel_info_ip structure.
protocol: Specifies or indicates the IP protocol number being used on the connection or for outgoing connectionless IP packets.
priority: Specifies or indicates the priority of IP packets. This priority is only used for queueing within the local system.
ttl: Specifies or indicates the IP time-to-live being used on the connection or for outgoing connectionless IP packets.
tos: Specifies or indicates the IP type-of-service being used on the connection or for outgoing connectionless IP packets. This is the TOS precedence and can have values: N_ROUTINE, N_PRIORITY, N_IMMEDIATE, N_FLASH, N_OVERRIDEFLASH, N_CRITIC_ECP, N_INETCONTROL, or N_NETCONTROL.
mtu: Specifies or indicates the maximum-transfer-unit being used on the connection or for outgoing connectionless IP packets. When used with multi-homed connections, this is the minimum of the maximum-transfer-unit values associated with each destination in the multi-homed connection.
saddr: Specifies or indicates the source address being used on the connection or for outgoing connectionless IP packets. If specified as INADDR_ANY, the source address associated with the outgoing route for a given packet will be used instead.
daddr: Specifies or indicates the destination address being used on the connection. This parameter is only significant for multi-homed connections and specifies to which of the list of destinations is currently being used as a primary destination for sending packets. This parameter has no effect on connectionless providers.

N_QOS_SEL_CONN_IP

Used with the N_CONN_REQ(7), N_CONN_IND(7), N_CONN_RES(7), N_CONN_CON(7) and N_OPTMGMT_REQ(7) primitives, it provide a selection of quality of service parameters for connection-oriented providers. The structure contains the following fields:

n_qos_type: Always N_QOS_SEL_CONN_IP indicating the N_qos_sel_conn_ip structure.
protocol: Specifies or indicates the IP protocol number being used or requested for the connection. This parameter is of end-to-end significance.
priority: Specifies or indicates the queueing priority of messages for the connection. This parameter is of local significance.
ttl: Specifies or indicates the IP header time-to-live being used or requested for the connection. This parameter is of local significance.
tos: Specifies or indicates the IP header type-of-service being used or requested for the connection. This parameter is of end-to-end significance. This is the TOS precedence and can have values: N_ROUTINE, N_PRIORITY, N_IMMEDIATE, N_FLASH, N_OVERRIDEFLASH, N_CRITIC_ECP, N_INETCONTROL, or N_NETCONTROL.
mtu: Specifies or indicates the maximum-transfer-unit being used for the connection. This parameter is of local significance.
saddr: Specifies or indicates the source address being used or requested for the connection. This parameter is of end-to-end significance.
daddr: Specifies or indicates the destination address being used or requested for the connection. This parameter is of local significance.

N_QOS_SEL_UD_IP

Used with the N_OPTMGMT_REQ(7) primitive, it provide a selection of quality of service parameters for connectionless providers. The structure contains the following fields:

n_qos_type: Always N_QOS_SEL_UD_IP indicating the N_qos_sel_ud_ip structure.
protocol: Specifies the IP protocol number requested for outgoing IP packets.
priority: Specifies the queueing priority for outgoing IP packets.
ttl: Specifies the IP header time-to-live parameter for outgoing IP packets.
tos: Specifies the IP header type-of-service parameter for outgoing IP packets. This is the TOS precedence and can have values: N_ROUTINE, N_PRIORITY, N_IMMEDIATE, N_FLASH, N_OVERRIDEFLASH, N_CRITIC_ECP, N_INETCONTROL, or N_NETCONTROL.
saddr: Specifies the IP header source address parameter for outgoing IP packets. If specifies as INADDR_ANY, the source address associated with the outgoing interface will be used for each given packet.

N_QOS_RANGE_INFO_IP

Used with the N_INFO_ACK(7) primitive, it provides a range of quality of service parameters available to connection-oriented and connectionless providers. The structure contains the following fields:

n_qos_type

Always N_QOS_RANGE_INFO_IP indicating the N_qos_range_info_ip structure.

priority

Indicates the acceptable range of the priority parameter. This field is a ip_priority_values_t structure containing the following members:

priority_min_value: Indicates the minimum acceptable priority value. This value is normally zero (0).
priority_max_value: Indicates the maximum acceptable priority value. This value is normally two hundred and fifty-five (255).

ttl

Indicates the acceptable range of the time-to-live parameter. This field is a ip_ttl_values_t structure containing the following members:

ttl_min_value: Indicates the minimum acceptable time-to-live value. This value is normally one (1).
ttl_max_value: Indicates the maximum acceptable time-to-live value. This value is normally one hundred and twenty-seven (127).

tos

Indicates the acceptable range of the type-of-service parameter. This field is a ip_tos_values_t structure containing the following members:

tos_min_value: Indicates the minimum acceptable type-of-service value. This value is normally N_ROUTINE.
tos_max_value: Indicates the maximum acceptable type-of-service value. This value is normally N_NETCONTROL.

mtu

Indicates the acceptable range of the maximum-transfer-unit parameter. This field is a ip_mtu_values_t structure containing the following members:

mtu_min_value: Indicates the minimum acceptable maximum-transfer-unit. This value is normally forty (40).
mtu_max_value: Indicates the maximum acceptable maximum-transfer-unit. This value is normally six thousand five hundred and thirty five (65535).

Local Management Interface

For the most part, the local management interface of the NPI operates for the NPI-IP provider in accordance with the Network Provider Interface Revision 2.0.0 specifications[1]. Some enhancements are provided to addressing in support of the Stream Control Transmission Protocol (SCTP)[2], sctp(4), and multi-homed associations.

The local management primitives are interpreted and issued as follows:

N_INFO_REQ(7)

This primitive is interpreted by the NPI-IP provider in accordance with the NPI specifications[1].

Fields of the primitive are intepreted as follows:

PRIM_type: Always N_INFO_REQ specifying the information request primitive.

N_INFO_ACK(7)

This primitive is issued by the NPI-IP provider in accordance with the NPI specifications[1] with the following considerations:

1.
2.

Fields of the primitive are interpreted as follows:

PRIM_type: Always N_INFO_ACK indicating the information acknowledgement primitive.
NSDU_size: This field reflects the current Maximum Transfer Unit (MTU) (minus the size of the IP header), times the number of IP packets that can be generated considering IP fragmentation, for the Stream given the protocol addresses to which the Stream is bound.
ENSDU_size: The NPI-IP provider, being a CLNS provider, has no concept of expedited data and this field is always set to zero (0).
CDATA_size: The NPI-IP provider, being a CLNS provider, has no concept of connection data and this field is always set to zero (0).
DDATA_size: The NPI-IP provider, being a CLNS provider, has no concept of connection data and this field is always set to zero (0).
ADDR_size: Specifies the maximum address size. For a device that supports IPv4, this is the size of the sockaddr_in structure. For an NPI-IP provider supporting multi-homing, this value will be an integer multiple of the size of the sockaddr_in structure. For a device that supports IPv6, the size of the sockaddr_in6 structure, or, supporting multi-homing, an integer multiple.
ADDR_length, ADDR_offset: The length and offset from the beginning of the message block of the bound protocol addresses. For an NPI-IP provider supporting multi-homing, the length and offset specify a list of address structures as described above under ``Address Formats''.
QOS_length, QOS_offset: The length and offset from the beginning of the message block of the current selected QOS parameters. This will be an N_QOS_SEL_INFO_IP structure completed as described above under ``QOS Parameters.'' It may be necessary to bind a Stream before a value will be returned in the information acknowledgement.
: In the connection-mode environment, when this primitive is invoked before the NC is established on the Stream, the values returned specify the default values provided by the NS provider. When this primitive is invoked after an NC has been established on the Stream, the values returns indicate negotiated values for the QOS parameters.
: In the connectionless-mode environment, these values represent the default of the selected QOS parameter values. In case of QOS parameter is not supported by the NS provider, a value of QOS_UNKNOWN will be returned in the corresponding field. In the case where no QOS parameters are supported by the NS provider, the QOS_length field will be zero (0).
QOS_range_length, QOS_range_offset: The length and offset from the beginning of the message block of the current range of QOS parameters. This will be an N_QOS_RANGE_INFO_IP structure completed as described above under ``QOS Parameters.'' It may be necessary to bind a Stream before a value will be returned in the information acknowledgement.
: These ranges are used by the NS user to select QOS parameter values that are valid with the NS provider. QOS parameter values are selected, or the default values altered via the N_OPTMGMT_REQ(7) primitive. In the connection-mode environment, the values for end-to-end QOS parameter may be specified with the N_CONN primitives for negotiation. If the NS provider does not support a certain QOS parameter, its value will be set to QOS_UNKNOWN. In the case where no QOS parameters are supported by the NS provider, the length of this field will be zero (0).
OPTIONS_flags: The NPI-IP provider sets no options flags and this field is always set to zero (0).
NIDU_size: The NPI-IP provider, being a CLNS provider, has no concept of interface data unit size and this field is always set to zero (0).
SERV_type: The NPI-IP provider always sets this field to N_CLNS for connectionless network service.
CURRENT_state: Indicates the current state of the NPI provider in accordance with the NPI specifications.
PROVIDER_type: The NPI-IP provider always sets this field to N_SNICFP for Subnetwork Independent Convergence Function/Protocol.
NODU_size: This field reflects the current Maximum Transfer Unit (MTU) (minus the size of the IP header) for the Stream given the protocol address to which the Stream is bound. Sending a packet using the N_UNITDATA_REQ primitive with a data payload of less than or equal to this size will not normally result in IP fragmentation.
PROTOID_length, PROTOID_offset: The length and offset from the beginning of the message block of the bound protocol identifiers.
NPI_version: The NPI-IP always sets this field to N_VERSION_2 to indicate Network Provider Interface Revision 2.0.0[1].

N_OPTMGMT_REQ(7)

This primitive is interpreted by the NPI-IP provider as specified in the NPI specification[1].

Fields of the primitive are interpreted as follows:

PRIM_type: Always N_OPTMGMT_REQ specifying the option management request primitive.
QOS_length, QOS_offset: The length and offset from the beginning of the message block of the protocol options. The NPI-IP provider will only recognize the N_QOS_SEL_INFO_IP, N_QOS_SEL_CONN_IP, N_QOS_SEL_UD_IP, structure types and will return NBADQOSTYPE for all other structures.
OPTMGMT_flags: The NPI-IP provider does not support receipt acknowledgement and will ignore the DEFAULT_RC_SEL flag because it is a CLNS provider as specified in the NPI[1].

N_BIND_REQ(7)

This primitive is interpreted by the NPI-IP provider as specified in the NPI specification[1], with the following considerations:

1.: When the DEFAULT_LISTENER flag is set, the Stream is always considered connection-oriented. Each protocol identifier and port number combination (whether the port number is zero or not) is permitted multiple DEFAULT_LISTENER Streams (one for each IP address, and one for the wildcard IP address). DEFAULT_LISTENER Streams are only considered when there is no match for any other listening Stream. It is ok unsed NPI-IP to set the DEFAULT_LISTENER flag, even though CONIND_number is set to zero, in which case, it merely specifies that the Stream is to be a pseudo-conenction-oriented Stream.
2.: When the DEFAULT_DEST flag is set, the Stream is always considered connectionless. Each protocol identifier is permitted multiple DEFAULT_DEST Streams (one for each IP address, and one for the wildcard IP address). DEFAULT_DEST Streams are only considered when there is no match for any other connectionless bound Stream that matches the destination address.
3.: If the number of connection indications, CONIND_number, is zero, the bind is performed and the service type set to connectionless (N_CLNS). If the number of connection indications, CONIND_number, is non-zero, the bind is performed and the service type set to connection-oriented (N_CONS). If, however, the TOKEN_REQUEST flag is set, then the bind is always considered connection-oriented, even if the number of connection indications, CONIND_number, is set to zero, as this is the typical case for an accepting Stream.

Fields of the primitive are interpreted as follows:

PRIM_type

Always N_BIND_REQ specifying the bind request primitive.

ADDR_length, ADDR_offset

Specifies the length in bytes of the network addresses to be bound to the Stream and the offset from the beginning of the M_PROTO(9) message block where the network addresses begin. Typically in NPI the network address consists of a single address. In support of the Stream Control Transmission Protocol (SCTP), sctp(4), the NPI-IP driver supports the specification of multiple addresses in the form of a list of addresses. See ``ADDRESS FORMAT,'' above.

CONIND_number

If CONIND_number is non-zero, the Stream is considered to be a CONS Stream. If zero, whether the Stream is considered a CONS or a CLNS stream is dependent upon other factors.

BIND_flags

The BIND_flags can be a bitwise OR of the following flags: (DEFAULT_LISTENER and TOKEN_REQUEST are mutually exclusive with DEFAULT_DEST.)

DEFAULT_LISTENER: When set, the Stream is considered to be a CONS Stream. When clear, whether the Stream is considered CONS or CLNS is dependent upon other factors.
TOKEN_REQUEST: When set, the Stream is considered to be a CONS Stream. When clear, whether the Stream is considered CONS or CLNS is dependent upon other factors.
DEFAULT_DEST: When set, the Stream is considered to be a CLNS Stream. When clear, whether the Stream is CONS or CLNS is dependent upon other factors.
: This flag is honoured by NPI-IP. When set, this flag indicates that this Stream is the ``default destination Stream.'' This Stream will receive all packets destined for the NSAP specified in the bind request. If no NSAP is specified in the bind request, then this Stream should receive all packets destined to an NSAP which is bound to no other Stream. Only one default destination Stream per NSAP is allowed per occurrence of NPI. An attempt to bind a default destination Stream to an NSAP when one is already bound should result in an error of type NBOUND.

PROTOID_length, PROTOID_offset

Specifies the length in bytes of the protocol identifiers and the offset from the beginning of the M_PROTO(9) message block where the protocol identifiers begin. Protocol identifiers for NPI-IP consist of IP protocol numbers. Typically only one IP protocol number is bound in a given bind request.

N_BIND_ACK(7)

The bind acknowledgement primitive is issued in accordance with the NPI specifications[1], with the following considerations:

1.: When a multi-homed address was specified to the bind, the ADDR_length and ADDR_offset fields may specify a bound address that consists of a list of addresses as indicated under ``ADDRESS FORMATS,'' above.
2.: If no address was specified to the bind, the NPI-IP provider will assume that all local addresses are to be bound. The NPI-IP provider also respects the INADDR_ANY value in the address, as well as the special port number zero (0).
3.: NPI-IP does not currently bind more than one protocol identifier and will always only return the first protocol identifier in the N_BIND_ACK(7) primitive.

Fields of the primitive are interpreted as follows:

PRIM_type: Always N_BIND_ACK indicating the bind acknowledgement primitive.
ADDR_length, ADDR_offset: Indicates the length and offset from the beginning of the M_PCPROTO(9) message block containing the bound address.
CONIND_number: Indicates the negotiated maximum number of connection indications.
TOKEN_value: Indicates the token value when requested on bind, zero otherwise.
PROTOID_length , PROTOID_offset: Indicates the length and offset from the beginning of the of the M_PCPROTO(9) message block containing the protocol identifiers that were bound.

N_UNBIND_REQ(7)

The unbind request primitive is interpreted by the NPI-IP provider in accordance with the NPI specifications[1], with the following considerations:

1.: If the user specified multiple addresses to the bind request, the unbind request is interpreted as unbinding all bound addresses and protocol identifiers.

Fields of the primitive are interpreted as follows:

PRIM_type: Always N_UNBIND_REQ specifying the unbind request primitive.

N_OK_ACK(7)

The NPI-IP provider issues this primitive in accordance with the NPI specifications[1]. Acknowledges the successful completion of primitives requiring positive acknowledgement.

Fields of the primitive are interpreted as follows:

PRIM_type: Always N_OK_ACK specifying the success acknowledgement primitive.
CORRECT_prim: The successful primitive that is being acknowledged.

N_ERROR_ACK(7)

The NPI-IP provider issues this primitive in accordance with the NPI specifications[1]. Provides negative acknowledgement for non-fatal errors for primitives requiring negative acknowledgement.

Fields of the primitive are interpreted as follows:

PRIM_type: Always N_ERROR_ACK specifying the error acknowledgement primitive.
ERROR_prim: The primitive that was in error.
NPI_error: The NPI error.
UNIX_error: When NPI_error is NSYSERR, the UNIX error number.

Connectionless Data Transfer

The NPI-IP provider is a CLNS (Connectionless Network Service) provider that uses the connectionless data transfer N-primitives to transfer data. For the most part, these primitives are used in strict accordance with the NPI specifications[1]. Some enhancements are provided to addressing in support of the Stream Control Transmission Protocol (SCTP)[2], sctp(4), and multi-homed associations.

The connectionless data transfer primitives are interpreted and issued as follows:

N_UNITDATA_REQ(7)

This primitive is interpreted by the NPI-IP provider as specified in the NPI specification[1], with the following considerations:

1.: For outgoing IP packets, the values of the various header fields other than the destination address are controlled using the quality-of-service selection for unit data for IP (see, QOSParameters , above).

Fields of the primitive are interpreted as follows:

PRIM_type: Always N_UNITDATA_REQ specifying that this is a unit data request primitive.
DEST_length, DEST_offset: These fields are interpreted as the destination address for the IP packet. The specified address must be a single address and cannot contain a list. A destination address must be specified (i.e. DEST_length cannot be zero).
RESERVED_Field[0] and RESERVED_field[1]: These fields are reserved for DLPI[3] compatibility and are set to zero.

N_UNITDATA_IND(7)

This primitive is issued by the NPI-IP provider in accordance with the NPI specification[1], with the following considerations:

1.: IP addresses, IP options and other IP particulars are available in the message block. The message body (attached M_DATA(9) message blocks) contains the entire IP packet including IP network and transport headers and payload. The base pointer of the first data block points to the IP header, although the read pointer of the first message block points to the transport header. This means that the IP information is available for inter-module use but is unavailable to a User-space user of the service interface.
2.: It is normally only necessary for the NPI provider to specify the destination address if it is not implicit to the receiving Stream: that is, if the receiving Stream is a default destination Stream. For NPI-IP, it is also necessary that the destination address be specified by the NPI-IP provider when the receiving Stream is bound to more than one address.
3.: The NPI-IP provider may indicate the N_UD_CONGESTION value in the ERROR_type field when the IP packet is marked for Explicit Congestion Notification or other congestion indication. Otherwise, the ERROR_type field is set to zero (0).

Fields of the primitive are interpreted as follows:

PRIM_type: Always N_UNITDATA_IND indicating that this is a unit data indication primitive.
DEST_length, DEST_offset: Populated by the NPI provider in accordance with the NPI specifications. These fields specify a single address.
SRC_length, SRC_offset: Populated by the NPI provider in accordance with the NPI specifications. These fields specify a single address.
ERROR_type: Populated by the NPI provider in accordance with the NPI specifications.

N_UDERROR_IND(7)

This primitive is issued by the NPI-IP provider in accordance with the NPI specification[1], with the following considerations:

1.: The original IP header, IP options and portion of the transport packet are available in the message body. The message body (attached M_DATA(9) message blocks) contains the entire IP packet including IP and ICMP headers and payload. The base pointer of the first data block points to the ICMP IP header, although the read pointer of the first message block points to the ICMP payload. This means that the ICMP IP information is available for inter-module use but is unavailable to a user-space user of the the service interface.

Fields of the primitive are interpreted as follows:

PRIM_type

Always N_UDERROR_IND indication that this is a unit data error indication primitive.

DEST_length, DEST_offset

Populated by the NPI-IP provider in accordance with the NPI specifications[1].

RESERVED_field

This field is set to zero (0) in accordance with NPI specifications[1].

ERROR_type

This field is populated by the NPI-IP provider in accordance with the NPI specifications. Some of the N_UDERROR_IND(7) reason codes have additional meaning when issued by the NPI-IP provider as follows:

N_UD_UNDEFINED: No reason was specified.
N_UD_TD_EXCEEDED: Transit delay exceeded. This can be generated by the NPI-IP provider in response to an ICMP message (ICMP_TIME_EXCEEDED/ICMP_EXC_FRAGTIME).
N_UD_CONGESTION: NS Provider congestion encountered. This can be generated by the NPI-IP provider in response to an ICMP message (ICMP_SOURCE_QUENCH).
N_UD_QOS_UNAVAIL: Requested QOS/service characteristic unavailable.
N_UD_LIFE_EXCEEDED: NSDU lifetime exceeded. This is an indication that the specified lifetime (TTL) was exceeded as detected to the NPI-IP provider in a returned ICMP message. This can be generated by the NPI-IP provider in response to an ICMP message (ICMP_TIME_EXCEEDED/ICMP_EXC_TTL).
N_UD_ROUTE_UNAVAIL: Suitable route unavailable. This is used by the NPI-IP provider to specify many separate error conditions as indicated by the received ICMP messages. This can be generated by the NPI-IP provider in response to an ICMP message (ICMP_DEST_UNREACH/ICMP_PROT_UNREACH, ICMP_PORT_UNREACH, ICMP_NET_UNKNOWN, ICMP_HOST_UNKNOWN, ICMP_HOST_ISOLATED, ICMP_NET_ANO, ICMP_HOST_ANO, ICMP_PKG_FILTERED, ICMP_PREC_VIOLATION, ICMP_PREC_CUTOFF).
N_UD_SEG_REQUIRED: Segmentation was required where none permitted. This error is used in conjunction the Path MTU Discovery and is used to indicate that a packet that was marked don't fragment encounter a path with an MTU less than the packet size. This can be generated by the NPI-IP provider in response to an ICMP message (ICMP_DEST_UNREACH/ICMP_FRAG_NEEDED).

Connection-Oriented Connection Establishment

The NPI-IP provider also provides a pseudo-CONS (Connection Oriented Network Service) provider that uses the connection mode data transfer N-primitives to transfer data. For the most part, these primitives are used in accordance with the NPI specifications[1]. Some enhancements are provided to addressing in support of the multi-homed nature of the Stream Control Transmission Protocol (SCTP)[2], sctp(4).

The connection establishment primitives are interpreted as follows:

N_CONN_REQ(7)

This primitive is interpreted by the NPI-IP provider in accordance with the NPI specification[1], npi(7), with the following considerations:

1.: The primitive can be issued on a Stream that has not yet been bound; i.e. that is in the NS_UNBND state. The NPI-IP provider will automatically bind the Stream to an IP address of INADDR_ANY, a dynamically assigned port number, and the UDP protocol number. The resulting Stream will be a pseudo-connection-oriented mode Stream. This is primarily for compatibility with the sockets(3) library. The NPI specification[1], npi(7), indicates that the response in this situation should be a N_ERROR_ACK(7) primitive with either a [NNOTSUPPORT] or [NOUTSTATE] error.
2.: The primitive can be issued on a Stream that has been bound, but which reports a SERV_type of N_CLNS in the T_INFO_ACK(7) primitive. This, again, is primarily for compatibility with the sockets(3) library. The NPI specification[1], npi(7), indicates that the response in this situation should be a N_ERROR_ACK(7) primitive with a [NNOTSUPPORT] error.

Fields of the primitive are interpreted as follows:

PRIM_type

DEST_length, DEST_offset

The length and offset from the beginning of the M_PROTO(9) message block of the memory extent containing the destination address(es), to which the connection is to be formed. This field can contain more than one IP address, but can only contain one port number.

CONN_flags

Specifies connection options flags associated with the connection request. The following connection flags are defined, but not supported:

REC_CONF_OPT: Specifies that receipt confirmation is to be used by default. The NPI-IP provider does not support receipt confirmation and setting this flag is invalid.
EX_DATA_OPT: Specifies that expedited data transfer is to be enabled by default. The NPI-IP provider does not support expedited data transfer and setting this flag is invalid.

QOS_length, QOS_offset

The length and offset from the beginning of the M_PROTO(9) message block of the memory extent containing the quality-of-service parameters to be associated with the connection. See QualityofService , above. The only QOS data type accepted in the N_CONN_REQ(7) by the NPI-IP provider is the N_QOS_SEL_CONN_IP data structure containing the following fields:

n_qos_type: Always N_QOS_SEL_CONN_IP.
protocol: Specifies the protocol field used for packets sent on the network connection.
priority: Specifies the priority of packets sent on the network connection.
ttl: Specifies the time-to-live field used for packets sent on the network connection.
tos: Specifies the type-of-service field used for packets sent on the network connection.
mtu: Specifies the maximum-transfer-unit to be used for packets sent on the network connection. If the MTU of the path upon which IP packets are sent is less than this value, the lower MTU will be used. If the MTU of the path on which IP packets are sent is greater than this value, the lower MTU will be used.
saddr: Specifies the default source address to be used in outgoing packets on the connection.
daddr: Specifies the default destination address to be used in outgoing packets on the connection. This parameter is only necessary if the connection is multi-homed.

N_CONN_IND(7)

This primitive is issued by the NPI-IP provider in accordance with the NPI specification[1], npi(7), with the following considerations:

1.: The NPI-IP provider does not provide true connection-oriented modes. In pseudo-connection-oriented mode, with a listening Stream, connection indications are synthesized from any received packet that matches the listening Stream and delivered as a connection indication (with data).

Fields of the primitive are interpreted as follows:

PRIM_type

DEST_length, DEST_offset

The length and offset from the beginning of the M_PROTO(9) message block of the memory extent containing the destination address of the IP packet causing the connection indication. This field will contain only one destination address and is structured as a sockaddr_in structure.

SRC_length, SRC_offset

The length and offset from the beginning of the M_PROTO(9) message block of the memory extent containing the source address of the IP packet causing the connection indication. This field will contain only one source address and is structured as a sockaddr_in structure.

SEQ_number

Indicates the sequence number for the connection indication to be used by the NS user in a subsequent N_DISCON_REQ(7) or N_CONN_RES(7) primitive.

CONN_flags

Indicates the connection options flags associated with the connection request. The following connection flags are defined, but not supported:

REC_CONF_OPT: Indicates that receipt confirmation is requested to be used on the connection by default. The NPI-IP provider does not support receipt confirmation and this flag will not be indicated.
EX_DATA_OPT: Indicates that expedited data transfer is requested to be enabled by default. The NPI-IP provider does not support expedited data transfer and this flag will not be indicated.

QOS_length, QOS_offset

The length and offset from the beginning of the M_PROTO(9) message block of the memory extent containing the quality-of-service parameters associated with the connection indication. See QualityofService , above. The only QOS data type indicated in the N_CONN_IND(7) primitive by the NPI-IP provider is the N_QOS_SEL_CONN_IP data structure containing the following information:

n_qos_type: Always N_QOS_SEL_CONN_IP.
protocol: Indicates the protocol of the received packet that invoked the connection indication.
priority: Indicates the priority of the received packet that invoked the connection indication.
ttl: Indicates the time-to-live field received in the packet that invoked the connection indication.
tos: Indicates the type-of-service field received in the packet that invoked the connection indicaiton.
mtu: Indicates the maximum-transfer-unit to be used for packets sent on the network connection toward the source address of the received packet that invoked the connection indiciation.
saddr: Specifies the default source address to be used in outgoing packets on the connection.
daddr: Specifies the default destination address to be used in outgoing packets on the connection. This parameter is only necessary if the connection is multi-homed.

N_CONN_RES(7)

This primitive is interpreted by the NPI-IP provider in accordance with the NPI specification[1], npi(7), with the following considerations:

1.

The NPI-IP provider does not support true connection-oriented modes; only a pseudo-connection-oriented mode. Accepting a connection indication with this primitive will deliver queued and any further received packets with the same source and destination addresses, port numbers and protocol number to the accepting Stream.

2.

Default quality-of-service parameters associated with the Stream are not negotiated end-to-end and are simply set as specified.

3.

The responding address(es) do no represent the local addresses that form the connection, but the remote addresses involved in a multi-homed association.

Fields of the primitive are interpreted as follows:

PRIM_type

TOKEN_value

Specifies the token value of the Stream onto which the connection is to be accepted. If the connection is to be accepted on the same Stream upon which the corresponding N_CONN_IND(7) was received, this field should be zero (0). It is an error to accept a connection on the listening Stream if there is more than one connection indication outstanding.

RES_length, RES_offset

The length and offset from the beginning of the M_PROTO(9) message block of the memory extent containing the responding address(es).

SEQ_number

Specifies the sequence number in the corresponding N_CONN_IND(7) primitive to which this primitive is responding.

CONN_flags

Specifies connection options flags for the resulting NS connection. The following flags are defined; but not supported:

REC_CONF_OPT: Specifies that receipt confirmation is to be used by default. The NPI-IP provider does not support receipt confirmation and setting this flag is invalid.
EX_DATA_OPT: Specifies that expedited data transfer is to be enabled by default. The NPI-IP provider does not support expedited data transfer and setting this flag is invalid.

QOS_length, QOS_offset

The length and offset from the beginning of the M_PROTO(9) message block of the memory extent containing the quality-of-service parameters to be used with the completed NS connection. See QualityofService , above. The only QOS data type allowed in the N_CONN_RES(7) primitive by the NPI-IP provider is the N_QOS_SEL_CONN_IP data structure containing the following information:

n_qos_type: Always N_QOS_SEL_CONN_IP.
protocol: Specifies the protocol to be used for packets sent on the network connection.
priority: Specifies the priority to be used for packets sent on the network connection.
ttl: Specifies the time-to-live field to be used in packets sent on the network connection.
tos: Specifies the type-of-service field to be used in packets sent on the network connection.
mtu: Specifies the maximum-transfer-unit to be used for packets sent on the network connection. If the underlying maximum-transfer-unit is different from this value, the smaller of the two will be used.
saddr: Specifies the default source address to be used in outgoing packets on the connection.
daddr: Specifies the default destination address to be used in outgoing packets on the connection. This parameter is only necessary if the connection is multi-homed.

N_CONN_CON(7)

This primitive is issued by the NPI-IP provider in accordance with the NPI specification[1], npi(7), with the following considerations:

1.: The NPI-IP provider does not provide true confirmation of a connection in pseudo-connection-oriented mode. The confirmation is issued automatically and locally by the NPI-IP provider upon receipt of a proper N_CONN_REQ(7) primitive.
2.: Quality of service values confirmed are the result of negotiation with the local provider only and are not the result of end-to-end negotiation in pseudo-connection-oriented mode.

Fields of the primitive are interpreted as follows:

PRIM_type

RES_length, RES_offset

The length and offset from the beginning of the M_PROTO(9) message block of the memory extent containing the responding address(es), which, in the case of the NPI-IP provider in pseudo-connection-oriented mode, is the same as the requested destination address(es).

CONN_flags

Indicates the connection options flags associated with the connection cofirmation. The following flags are defined; but not supported:

REC_CONF_OPT: Indicates that receipt confirmation is requested to be used on the connection by default. The NPI-IP provider does not support receipt confirmation and this flag will not be indicated.
EX_DATA_OPT: Indicates that expedited data transfer is requested to be enabled by default. The NPI-IP provider does not support expedited data transfer and this flag will not be indicated.

QOS_length, QOS_offset

The length and offset from the beginning of the M_PROTO(9) message block of the memory extent containing the quality-of-service parameters associated with the confirmed connection. The values represent negotiation with the local provider only, and are not the result of end-to-end negotiation. See QualityofService , above. The only QOS data type indicated in the N_CONN_CON(7) primitive by the NPI-IP provider is the N_QOS_SEL_CONN_IP data structure containing the following information:

n_qos_type: Always N_QOS_SEL_CONN_IP.
protocol: Confirms the protocol value to be used in outgoing packets on the network connection.
priority: Confirms the priority value to be used in outgoing packets on the network connection.
ttl: Confirms the time-to-live value to be used in outgoing packets on the network connection.
tos: Confirms the type-of-service value to be used in outgoing packets on the network connection.
mtu: Confirms the maximum-transfer-unit to be used for outgoing packets on the network connection. This is the minimum of the individual maximum-transfer-units of all the destinations for the network connection and the requested maximum-transfer-unit.
saddr: Specifies the default source address to be used in outgoing packets on the connection.
daddr: Specifies the default destination address to be used in outgoing packets on the connection. This parameter is only necessary if the connection is multi-homed.

Connection-Oriented Data Transfer

The established connection data transfer primitives are interpreted as follows:

N_DATA_REQ(7)

In pseudo-connection-oriented mode, the NPI-IP user transfers data using the N_DATA_REQ(7) primitive. When the destination host is multi-homed, the data will be sent to the primary destination address. The current primary destination address can be changed with the N_OPTMGMT_REQ(7) primitive. The source address on the IP packet will be one of the addresses associated with the route and the outgoing interface.

Fields of the primitive are interpreted as follows:

PRIM_type

Always N_DATA_REQ specifying the data transfer request primitive.

DATA_xfer_flags

N_MORE_DATA_FLAG: This flag may be set in accordance with the NPI specifications; however, as the NPI-IP provider performs segmentation and reassembly at the IP level, this flag is unused. Setting this flag will result in a fatal [EPROTO] error condition.
N_RC_FLAG: This flag may be set in accordance with the NPI specifications; however, as the NPI-IP provider does not support receipt verification, this flag is unused. Setting this flag will result in a fatal [EPROTO] error condition.

N_DATA_IND(7)

In pseudo-connection-oriented mode, the NPI-IP provider transfers data to the NPI-IP user with the N_DATA_IND(7) primitive. For multi-homed local or remote hosts, information concerning the source address and destination address of the packet is lost. For a service that provides this information, use the connectionless mode.

Fields of the primitive are interpreted as follows:

PRIM_type

Always N_DATA_IND indicating the data transfer indication primitive.

DATA_xfer_flags

N_MORE_DATA_FLAG: This flag is populated by the NPI-IP provider in accordance with the NPI specifications; however, because the NPI-IP provider performs segmentation and reassembly at the IP level, this flag is unused and is never set by the NPI-IP provider.
N_RC_FLAG: This flag is populated by the NPI-IP provider in accordance with the NPI specifications; however, because the NPI-IP provider does not support receipt verification, this flag is unused and is never set by the NPI-IP provider.

N_DATACK_REQ(7), N_DATACK_IND(7)

The NPI-IP provider does not support receipt confirmation because it is not provided by the underlying IP protocol.

N_RESET_REQ(7)

This primitive is interpreted by the NPI-IP provider in accordance with the NPI specification[1],

Fields of the primitive are interpreted as follows:

PRIM_type: Always N_RESET_REQ specifying the reset request primitive.
RESET_reason

N_RESET_RES(7)

This primitive is interpreted by the NPI-IP provider in accordance with the NPI specification[1],

Fields of the primitive are interpreted as follows:

PRIM_type: Always N_RESET_RES specifying the reset response primitive.

N_RESET_CON(7)

This primitive is issued by the NPI-IP provider in accordance with the NPI specification[1],

Fields of the primitive are interpreted as follows:

PRIM_type: Always N_RESET_CON indicating the reset confirmation primitive.

N_RESET_IND(7)

This primitive is issued by the NPI-IP provider in accordance with the NPI specification[1],

Fields of the primitive are interpreted as follows:

PRIM_type

Always N_RESET_CON indicating the reset indication primitive.

RESET_orig

N_PROVIDER: The origin of the reset is the NS provider.
N_USER: The origin of the reset is the peer NS user.
N_UNDEFINED: The origin of the reset is unknown.

RESET_reason

When RESET_orig is N_PROVIDER, the following reasons apply:

N_CONGESTION
N_RESET_UNSPECIFIED

When RESET_orig is N_USER, the following reasons apply:

N_USER_RESYNC

When RESET_orig is N_UNDEFINED, the following reasons apply:

N_REASON_UNDEFINED

Connection-Oriented Connection Termination

The connection release primitives are interpreted as follows:

N_DISCON_REQ(7)

Disconnect requests result in the abortive release of the pseudo-connection. The primitive is acknowledge in accordance with NPI specifications.

DISCON_reason
RES_length, RES_offset: The length and offset from the beginning of the M_PROTO(9) message block of the memory extent containing the responding address(es).
SEQ_number

N_DISCON_IND(7)

Because the NPI-IP provider is only a pseudo-connection-oriented provider, disconnect indications are not issued by the provider.

DISCON_orig

N_PROVIDER
N_USER
N_UNDEFINED

DISCON_reason

When the DISCON_orig is N_PROVIDER, the following reasons apply:

N_DISC_P
N_DISC_T
N_REJ_NSAP_UNKNOWN
N_REJ_NSAP_UNREACH_P
N_REJ_NSAP_UNREACH_T
N_REJ_QOS_UNAVAIL_P
N_REJ_QOS_UNAVAIL_T
N_REJ_UNSPECIFIED

When the DISCON_orig is N_USER, the following reasons apply:

N_DISC_NORMAL
N_DISC_ABNORMAL
N_REJ_P
N_REJ_T
N_REJ_INCOMPAT_INFO
N_REJ_QOS_UNAVAIL_P
N_REJ_QOS_UNAVAIL_T
N_REJ_UNSPECIFIED

When the DISCON_orig is N_UNDEFINED, the following reasons apply:

N_REASON_UNDEFINED

IOCTLS

The NPI specification[1] does not standardize on any input-output controls.

NOTICES

There are a number of purposes for this NPI-IP driver:

1.: The OpenSS7 Project has a need for a solution for providing a pseudo-device driver for RTP (Real-Time Transport Protocol)[4], rtp(4). Because RTP runs over UDP (User Datagram Protocol), it is necessary to intercept packets ahead of Linux' native UDP at the IP level to avoid the inefficiencies of opening Sockets from inside the kernel. This NPI-IP driver accomplishes that feat. It also permits a single Stream to be opened but which communicates on many RTP channels.
2.: The OpenSS7 Project has a need for a direct interface and interception (drop and insert) capabilities at the IP level for the purposes of testing both RTP (Real-Time Transport Protocol)[4], rtp(4), and SCTP (Stream Control Transmission Protocol)[2], sctp(4). This need is less critical because of the availability of Ferry-Clip testing, using STREAMS-based pipes, that can be rigged to RTP and SCTP to achieve the same effect.
3.: Although historically the STREAMS SCTP driver hooks directly to the Linux native IP subsystem at the driver-kernel level, it might be of some advantage to make SCTP a pushable module that simply pushes over one of these NPI-IP Streams, or a multiplexing driver under which one of these NPI-IP Streams is permanently linked at system initialization. The ability to bind multiple addresses is of use to SCTP.
4.: Although there is no prevailing standardized way of interfacing to the IP layer of various UNIX® operating systems, such as Solaris®[5], it might be possible to make the OpenSS7 Project RTP and SCTP drivers immediately portable to other operating systems with STREAMS such as Solaris®[6], pSOS®, VxWorks®[7], LynxOS®, etc. by simply porting the NPI-IP driver instead of each protocol driver.

VERSIONS

This is version 0.9.2.7 of the NPI-IP Corrigendum.

COMPATIBILITY

There is, in fact, no standard for using the Network Provider Interface (NPI)[1] with the Internet Protocol (IP) suite. Although historically some approaches may have been taken in various releases of the UNIX® operating system, none have been well documented nor can be considered the basis for a standard.

CONFORMANCE

This Corrigendum conforms where possible to the Network Provider Interface Revision 2.0.0[1] but its application to the Internet Protocol is implementation specific and not subject to standardization.

REFERENCES

[1]: NPI, Open Group CAE Specification: Network Provider Interface (NPI) Specification, Revision 2.0.0, Draft 2, August 17, 1992, (Parsippany, New Jersey), UNIXInternational,Inc., UNIX International Press. <http://www.openss7.org/docs/npi.pdf>
[2]: RFC 2960, Stream Control Transmission Protocol (SCTP), October 2000, Randall R. Stewart, ed., The Internet Society. (Obsoleted by RFC 4960) (Updated by RFC 3309) (Status: PROPOSED STANDARD) <http://www.ietf.org/rfc/rfc2960.txt>
[3]: DLPI, Data Link Provider Interface (DLPI) Specification, Revision 2.0.0, Draft 2, August 20, 1991, (Parsippany, New Jersey), UNIX. International,Inc., UNIX International Press. <http://www.openss7.org/doc/dlpi.pdf>
[4]: RFC 1889, RTP: A Transport Protocol for Real-Time Application, January 1996, Henry Shulzrinne, ed., The Internet Society. <http://www.ietf.org/rfc/rfc1889.txt>
[5]: Solaris® 11, Solaris 11 Docmentation, 2008, (Santa Clara, California), Sun Microsystems, Inc., Sun. <http://docs.sun.com/>
[6]: Solaris® 8, STREAMS Programming Guide, August 1999, (Palo Alto, California), Sun Microsystems, Inc., Sun. [Part No: 805-7478-05] <http://docs-pdf.sun.com/>
[7]: VxWorks® 5.4 Tornadotm II, WindNet STREAMS for Tornado, Component Release Supplement, 1998, (Almeda, California), Wind River Systems, Inc., Wind River. <http://www.windriver.com/>