Manpage of DL_BIND_REQ

Description: Manual Page

Keywords: ss7 ss7/ip ss7 over ip ss7 mtp ss7 sccp ss7 tcap sigtran mtp sccp tcap openss7 acb56 linux telephony pstn linux telephony linux nebs linux compactpci

---

DL_BIND_REQ

Section: Data Link Provider Interface (DLPI) (7)
Updated: 2008-10-31
Index Return to Main Contents

---

NAME

DL_BIND_REQ (dl_bind_req_t) - requests the DLS provider bind a DLSAP to the stream.

INTERFACE

Data Link Provider Interface, DLPI[1].

SYNOPSIS

The message consists of one M_PROTO(9) message block, which contains the following structure.

#include <sys/dlpi.h>
typedef struct {
    t_uscalar_t  dl_primitive;
    t_uscalar_t  dl_sap;
    t_uscalar_t  dl_max_conind;
    ushort       dl_service_mode;
    ushort       dl_conn_mgmt;
    t_uscalar_t  dl_xidtest_flg;
} dl_bind_req_t;

DESCRIPTION

DL_BIND_REQ requests the DLS provider bind a DLSAP to the stream. The DLS user must identify the address of the DLSAP to be bound to the stream. Forconnection-mode service, the DLS user also indicates whether it will accept incoming connection requests on the stream. Finally, the request directs the DLS provider to activate the stream associated with the DLSAP.

A stream is viewed as active when the DLS provider may transmit and receive protocol data units destined to or originating from the stream. The PPA associated with each stream must be initialized upon completion of the processing of the DL_BIND_REQ (see PPA Initialization/De-initialization dlpi(7)). More specifically, the DLS user is ensured that the PPA is initialized when the DL_BIND_ACK(7) is received. If the PPA cannot be initialized, the DL_BIND_REQ will fail.

DLPI supports the ability to associate several Streams with a single DLSAP, where each Stream may be a unique data link connection endpoint. However, not all DLS providers can support such configurations because some DLS providers may have no mechanism beyond the DLSAP address for distinguishing multiple connections. In such cases, the provider will restrict the DLS user to one Stream per DLSAP.

In some instances it is expected that a given service may be accessed thorugh any one of several DLSAPs. To handle this scenario, a separate Stream would be required for each possible destination DLSAP, regardless of whether any DLS user actually requested a connection to that DLSAP. To obviate the need for tying up system resource for all possible destination DLSAPs, a "connection management stream" utility is defined in DLPI. A connection management Stream is one that receives any connect requests that are not destined for currently bound DLSAPs apable of receiving connect indications. With this mechanism, a special listener management Stream to the DLS provider that will retrieve all connect requests arriving through a particular PPA. In the model, then, there may be a connection management Stream per PPA.

A stream may be bound as a "connection management" stream, such that it will receive all connect requests that arrive through a given PPA (see Connection Management Stream dlpi(7)). In this case, the dl_sap will be ignored.

PARAMETERS

The dl_bind_req_t structure contains the following members:

dl_primitive

conveys DL_BIND_REQ.

dl_sap

conveys sufficient information to identify the DLSAP that will be bound to the DLPI stream (see DLPI Addressing dlpi(7) for a description of DLSAP addresses). The format of this information is specific to a given DLS provider, and may contain the full DLSAP address or some portion of that address sufficient to uniquely identify the DLSAP in question. The full address of the bound DLSAP will be returned in the DL_BIND_ACK(7).

The following rules are used by the DLS provider when binding a DLSAP address:

-

The DLS provider must define and manage its DLSAP address space.

-

DLPI allows the same DLSAP to be bound to multiple streams, but a given DLS provider may need to restrict its address space to allow one stream per DLSAP.

-

The DLS provider may not be able to bind the specified DLSAP address for one of the following reasons:

1.

the DLS provider may statically associate a specific DLSAP with each stream

2.

the DLS provider may only support one stream per DLSAP and the DLS user attempted to bind a DLSAP that was already bound to another stream.

In case of reason 1, the value of dl_sap is ignored by the DLS provider and the DL_BIND_ACK(7) returns the DLSAP address that is already associated with the stream. In case of reason 2, if the DLS provider cannot bind the given DLSAP to the stream, it may attempt to choose an alternate DLSAP and return that on the DL_BIND_ACK(7). If an alternate DLSAP cannot be chosen, the DLS provider will return a DL_ERROR_ACK(7) and set dl_errno to DL_NOADDR.

Because of the provider-specific nature of the DLSAP address, DLS user software that is to be protocol independent should avoid hard-coding this value. The DLS user should retrieve the necessary DLSAP address from some other entity (such as a management entity or higher layer protocol entity) and insert it without inspection into the DL_BIND_REQ.

dl_max_conind

conveys the maximum number of outstanding DL_CONNECT_IND(7) messages allowed on the DLPI stream. If the value is zero, the stream cannot accept any DL_CONNECT_IND(7) messages. If greater than zero, the DLS user will accept DL_CONNECT_IND(7) messages up to the given value before having to respond with a DL_CONNECT_RES(7) or a DL_DISCONNECT_REQ(7) (see Multi-threaded Connection Establishment dlpi(7) for details on how this value is used to support multi-threaded connect processing). The DLS provider may not be able to support the value supplied in dl_max_conind, as specified by the following rules:

-

If the provider cannot support the specified number of outstanding connect indications, it should set the value down to a number it can support.

-

Only one stream that is bound to the indicated DLSAP may have an allowed number of maximum outstanding connect indications greater than zero. If a DL_BIND_REQ(7) specifies a value greater than zero, but another stream has already bound itself to the DLSAP with a value greater than zero, the DLS provider will fail the request, setting dl_errno to DL_BOUND on the DL_ERROR_ACK(7).

-

If a stream with dl_max_conind greater than zero is used to accept a connection, the stream will be found busy during the duration of the connection, and no other streams may be bound to the same DLSAP with a value of dl_max_conind greater than zero. This restriction prevents more than one stream bound to the same DLSAP from receiving connect indications and accepting connections. Accepting a connection on such a stream is only allowed if there is just a single outstanding connect indication being processed.

-

A DLS user should always be able to request a dl_max_conind value of zero, since this indicates to the DLS provider that the stream will only be used to originate connect requests.

-

A stream with a negotiated value of dl_max_conind that is greater than zero may not originate connect requests. This field is ignored in connectionless-mode service.

dl_service_mode

conveys the desired mode of service for this stream, and may contain one of the following:

DL_CODLS

Selects connection-oriented data link service only. The connection-oriented mode primitives will be accepted. In addition, an arbitrary number of streams may bind to the same dl_sap on the same PPA provided the dl_max_conind is zero. Only one Stream may bind to the same dl_sap on the same PPA when the dl_max_conind is non-zero. No incoming connectionless traffic will be sent up this Stream, and will be routed to a DL_CLDLS Stream, or discarded.

DL_CLDLS

Selects connectionless data link service only. The connection-oriented mode primitives will not be accepted. This mode selects exclusive control of connectionless traffic. All connectionless traffic from any remote station address to this dl_sap even if another Stream is currently connected on the same dl_sap. Only one stream per PPA may bind DL_CLDLS.

DL_CLDLS|DL_CODLS

Selects the connection-oriented mode service augmented with connectionless mode service. An arbitrary number of Streams may bind to the same dl_sap on the same interface. This mode is mutually exclusive with Streams bound with DL_CLDLS.

DL_ACLDLS

Selects the acknowledged connectionless data link service only. The same restrictions that apply to the connectionless mode service apply to this service.

DL_ACLDLS|DL_CLDLS

Selects the acknowledged connectionless data link service augmented with the connectionless mode service. The same restrictions that apply to the connectionless mode service apply to this combined service.

DL_HP_RAWDLS

Selects raw-mode service.

If the DLS provider does not support the requested service mode, a DL_ERROR_ACK(7) will be generated, specifying DL_UNSUPPORTED.

dl_conn_mgmt

if non-zero, indicates that the stream is the "connection management" stream for the PPA to which the stream is attached. When an incoming connect request arrives, the DLS provider will first look for a stream bound with dl_max_conind greater than zero that is associated with the destination DLSAP. If such a stream is found, the connect indication will be issued on that stream. Otherwise, the DLS provider will issue the connect indication on the "connection management" stream for that PPA, if one exists. Only one "connection management" stream is allowed per PPA, so an attempt to bind a second connection management stream on a PPA will fail with the DLPI error set to DL_BOUND. When dl_conn_mgmt is non-zero, the value of dl_sap will be ignored. In connectionless-mode service, dl_conn_mgmt is ignored by the DLS provider.

dl_xidtest_flg

indicates to the DLS Provider that XID and/or TEST responses for this stream are to be automatically generated by the DLS Provider. The DLS Provider will not generate DL_XID_IND(7) and/or DL_TEST_IND(7), and will error a DL_XID_REQ(7) and/or DL_TEST_REQ(7). If the DLS Provider does not support automatic handling of XID and/or TEST responses, a DL_ERROR_ACK(7) will be generated, specifying DL_NOAUTO, DL_NOXIDAUTO or DL_NOTESTAUTO. If the Provider receives an XID or TEST request from the DLS User, a DL_ERROR_ACK(7) will be generated specifying DL_XIDAUTO or DL_TESTAUTO respectively.

The dl_xidtest_flg contains a bit-mask specifying zero or more of the following values:

DL_AUTO_XID

automatically respond to XID commands

DL_AUTO_TEST

automatically respond to TEST commands.

MODE

This primitive is valid in any mode.

STATE

The message is valid in state DL_UNBOUND.

NEW STATE

The resulting state is DL_BIND_PENDING.

RESPONSE

If the bind request is successful, DL_BIND_ACK(7) is sent to the DLS user resulting in state DL_IDLE.

If the request fails, message DL_ERROR_ACK(7) is returned and the resulting state is unchanged.

ERRORS

The DLPI error returned in a DL_ERROR_ACK(7) primitive may be one of the following:

DL_ACCESS

The DLS user did not have proper permission to use the requested DLSAP address.

DL_BADADDR

The DLSAP address information was invalid or was in an incorrect format.

DL_BOUND

The DLS user attempted to bind a second stream to a DLSAP with dl_max_conind greater than zero, or the DLS user attempted to bind a second "connectionmanagement" stream to a PPA.

DL_INITFAILED

Automatic initialization of the PPA failed.

DL_NOTINIT

The PPA had not been initialized prior to this request.

DL_NOADDR

The DLS provider could not allocate a DLSAP address for this stream.

DL_NOAUTO

Automatic handling of XID and TEST responses not supported.

DL_NOTESTAUTO

Automatic handling of TEST response not supported.

DL_NOXIDAUTO

Automatic handling of XID response not supported.

DL_OUTSTATE

The primitive was issued from an invalid state.

DL_SYSERR

A system error has occurred and the Linux system error is indicated in the DL_ERROR_ACK(7).

DL_UNSUPPORTED

The DLS provider does not support requested service mode on this stream.

See DL_ERROR_ACK(7) for a description of specific Linux error codes applicable to DLPI.

COMPATIBILITY

The DL_BIND_REQ primitive is compatible with implementations based on DLPI Revision 2[1], such as AIX®[2,3], HP-UX®[4], Solaris®[5], Solstice®[6], and UnixWare®[7], with the following portability considerations:

---

The DL_HP_RAWDLS value for the dl_service_mode field is HP-UX®-specific[4], and will be ignored by portable DLS Users.

---

When specified, the DL_HP_RAWDLS value for the dl_service_mode field requests that the DLS Provider place the Stream in a raw mode of operation. See also, DL_HP_RAWDATA_REQ(7) and DL_HP_RAWDATA_IND(7).

---

DL_HP_RAWDLS is provided by OpenSS7 XNS Networking for source compatibility with DLS Providers and Users written for use with HP-UX®, and for porting DLS Providers and Users from HP-UX® to Linux®. Binary compatibility is not attempted. Any binary compatibility experienced may be removed from the next release.

---

HP-UX®[4] documents the UNIX error codes (listed as Linux error codes above). Other implementations do not document these codes. Portable programs will not rely upon the specific value of a Linux error code for proper operation.

---

Solaris®[5] provides a connectionless-only DLPI driver for LAN classes, and for this provider the dl_service_mode must be set to DL_CLDLS. Solstice®[6] provides a connection-oriented only DLPI driver for LLC2 and LAPB classes, and for this provider the dl_service_mode must be set to DL_CODLS.

---

AIX®[2] and HP-UX®[4] provide a combined connectionless and connection-oriented DLPI driver for LAN, LLC2 and LAPB classes. OpenSS7 XNS Networking provides a connectionless only DLPI driver for LAN classes, ldl(4), a combined connectionless and connection-oriented DLPI driver for LLC2 and LAPB, llc2(4) and lapb(4), and is, therefore, compatible with all three implementations.

---

Solstice®[6] specifies that the dl_sap field contains a one-byte, non-zero, individual SSAP for LLC2, and zero (0) for LAPB. Also, it notes that multiple Streams may be bound to the same SAP, but only one listening Stream is allowed per SAP. AIX®[8] documents that for LLC2 operation, this is an LSAP an cannot be the null SAP (0x00), a group SAP (B'XXXXXXX1'), the name discovery SAP (0xFC), nor the gloabl SAP (0xFF). Also that the value is 0 for master and 1 for slave for SDLC operation. OpenSS7 XNS Networking supports a one-byte, non-zero, individual LSAP for LLC2, and any LSAP for LLC1. Also supported is a two-byte Ethertype (>1536 decimal) for DL_CLDS on LAN media. Portable applications will set this value to zero (0) when LSAP addressing is not required.

---

AIX®[2] specifies that the dl_conn_mgmt field is ignored. OpenSS7 XNS Networking honors the setting of this field. When porting applications from AIX®, care should be taken that this field is always set to zero (0).

---

AIX®[2] expands on the description of combined service modes as described for the dl_service_mode field above. HP-UX®[4], Solstice®[6], and DLPI[1], document that service mode field, dl_service_mode may only be single-valued. OpenSS7 XNS Networking supports multiple values in the dl_service_mode field in support for porting applications from AIX®. Programs ported from Solstice®, HP-UX® and other implementations strictly based on DLPI will simply not set multiple values in this field.

---

Solstice®[6] states that the dl_xidtest_flg is only valid for LLC2. Under OpenSS7 XNS Networking, the dl_xidtest_flg field is valid for all providers and service modes.

---

AIX®[3], states that for LAPB the dl_sap byte 1 is 1 for master station and 0 for slave station and byte 2 contains the logical line number, and bytes 3 and 4 contain zero (0), where byte 1 is the most significant byte of the ulong and byte 4 is the least significant. It also indicates that dl_max_conind, dl_service_mode, dl_conn_mgmt and dl_xidtest_flg must all be set to zero.

To support porting of AIX® applications to Linux®, OpenSS7 XNS Networking also support this SAP addressing (as well as supporting the value zero (0) in the dl_service_mode for LAPB).

See dlpi(7), dlpi_ioctl(4), STREAMS(9), for additional compatibility information.

CONFORMANCE

This interface conforms to DLPI Revision 2[1].

HISTORY

The Data Link Provider Interface first appeared in SVR 4[9].

REFERENCES

[1]

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>

[2]

AIX Version 6.1, AIX Version 6.1 Technical Reference: Communications, Volume 1, First Edition, November 2007, (Boulder, Colorado), Internatonal Business Machines Corp., IBM. [SC23-6610-00] <http://publib.boulder.ibm.com/>

[3]

AIXlink/X.25, AIXlink/X.25 Version 2.1 for AIX: Guide and Reference, Eigth Edition, September 2005, (Boulder, Colorado), Internatonal Business Machines Corp., IBM. [SC23-2520-07] <http://publibn.boulder.ibm.com/>

[4]

HP-UX DLPI, HP DLPI Programmer's Guide -- HP-UX 11i v3, February 2007, (Palo Alto, California), Hewlett-Packard Development Company L.P., HP. [Part No: 5991-7498] <http://docs.hp.com/>

[5]

Solaris® 11, Solaris 11 Docmentation, 2008, (Santa Clara, California), Sun Microsystems, Inc., Sun. <http://docs.sun.com/>

[6]

Solstice® X.25, Solstice® X.25 9.2 Programming Guide, October 1999, (Palo Alto, California), Sun Microsystems, Inc., Sun. [Part No: 806-1235-10] <http://docs-pdf.sun.com/>

[7]

UnixWare® 7.1.3, UnixWare 7.1.3 (OpenUnix 8) Documentation, 2002, (Lindon, Utah), Caldera International, Inc., Caldera. <http://uw713doc.sco.com/>

[8]

AIX Version 6.1, AIX Version 6.1 --- Communications Programming Concepts, First Edition, November 2007, (Boulder, Colorado), Internatonal Business Machines Corp., IBM. [SC23-5258-00] <http://publibn.boulder.ibm.com/>

[9]

SVR 4, UNIX® System V Release 4 Programmer's Manual, 1990, (Englewood Cliffs, New Jersey), AT&T UNIX System Laboratories, Inc., Prentice Hall.

[10]

Magic Garden, The Magic Garden Explained: The Internals of UNIX® System V Release 4 / An Open Systems Design, 1994, (Australia), B. Goodheart, J. Cox, Prentice Hall. [ISBN 0-13-098138-9]

[11]

Advanced Programming in the UNIX®Environment, 15th edition, December 1997, (Reading, Massachusetts), W. R. Stevens, Addison Wesley. [ISBN 0-201-56317-7]

TRADEMARKS

OpenSS7tm

is a trademark of OpenSS7 Corporation.

Linux®

is a registered trademark of Linus Torvalds.

UNIX®

is a registered trademark of The Open Group.

Solaris®

is a registered trademark of Sun Microsystems.

Other trademarks are the property of their respective owners.

IDENTIFICATION

OpenSS7 XNS Networking: Package strxns version 0.9.2.7 released 2008-10-31.

Copyright©1992UNIX International, Inc.
Copyright©1997-2008OpenSS7 Corp. All Rights Reserved.
(See roff source for permission notice.)

---

Index

NAME

INTERFACE

SYNOPSIS

DESCRIPTION

PARAMETERS

MODE

STATE

NEW STATE

RESPONSE

ERRORS

COMPATIBILITY

CONFORMANCE

HISTORY

REFERENCES

TRADEMARKS

IDENTIFICATION

---

This document was created by man2html, using the manual pages.
Time: 12:47:08 GMT, May 24, 2013