Previous section.

Networking Services (XNS) Issue 5
Copyright © 1997 The Open Group

ATM Transport Protocol Information for Sockets

General

This appendix is a Preliminary Specification. It describes the protocol-specific information that is relevant for ATM transport providers.

The following general notes apply:

Existing Functions

accept()

The parameter address, if non-null, points to the ATM network address of the peer connecting socket. The ATM protocol address of the peer connecting socket is unavailable.

Note that the transport protocol must queue data sent via send(), sendmsg(), or sendto() until the end-to-end data path is operational.

bind()

When a transport user wishes to passively wait for incoming connections through a socket, the following additional restrictions apply for ATM transports:

When a transport user wishes to initiate outgoing connections through a socket, then bind() should not be called.

close()

If the transport user wishes to convey the cause of the disconnection to the peer socket, then socket option T_ATM_CAUSE must be set before function close() is invoked.

connect()

Parameter address specifies the ATM protocol address of the destination transport user. This ATM protocol address must conform to the ATM Forum guidelines (referenced document ATMNAS) for the specification of a SAP address. The SAP address is a vector that includes fields for the ATM network address (with selector byte), identification of a layer-2 protocol, identification of a layer-3 protocol, and identification of an application.

getpeername()

The parameter address, if meaningful, points to one of the following:

getsockname()

The parameter address, if meaningful, points to one of the following:

getsockopt()

ATM transport protocol options use T_ATM_SIGNALING for the parameter level. The ATM-specific options are listed in the table below. Most of these options are defined in ATM Transport Protocol Information for XTI in this specification. Option T_ATM_LEAF_IND is defined in Point-to-Multipoint Connections .

Option Name Type of Option Value Meaning
T_ATM_AAL5 struct t_atm_aal5 ATM adaptation layer 5
T_ATM_TRAFFIC struct t_atm_traffic data traffic descriptor
T_ATM_BEARER_CAP struct t_atm_bearer ATM service capabilities
T_ATM_BHLI struct t_atm_bhli higher-layer protocol
T_ATM_BLLI struct t_atm_blli lower-layer protocol (1st choice)
T_ATM_DEST_ADDR struct t_atm_addr call responder’s network address
T_ATM_DEST_SUB struct t_atm_addr call responder's subaddress
T_ATM_ORIG_ADDR struct t_atm_addr call initiator’s network address
T_ATM_ORIG_SUB struct t_atm_addr call initiator's subaddress
T_ATM_CALLER_ID struct t_atm_caller_id caller's identification attributes
T_ATM_CAUSE struct t_atm_cause cause of disconnection
T_ATM_QOS struct t_atm_qos desired quality of service
T_ATM_TRANSIT struct t_atm_transit public carrier transit network
T_ATM_LEAF_IND struct t_atm_leaf_ind indication of leaf status change

recv()

The parameter flags must equal a value of 0 or MSG_PEEK.

recvfrom()

Note that ATM protocol supports only connection-oriented sockets.

recvmsg()

Note that ATM protocol supports only connection-oriented sockets.

send()

The parameter flags must equal a value of 0.

When the connection present at the socket is a leaf on a point-to-multipoint connection, any invocation of function send()
results in [EOPNOTSUPP].

sendmsg()

Note that ATM protocol supports only connection-oriented sockets.

sendto()

Note that ATM protocol supports only connection-oriented sockets.

setsockopt()

ATM transport protocol options use SOL_ATM_SIGNALING for the parameter level. The ATM-specific options are listed in the table below. Most of these options are defined in ATM Transport Protocol Information for XTI . Options T_ATM_ADD_LEAF and T_ATM_DROP_LEAF are defined in Point-to-Multipoint Connections .

Option Name Type of Option Value Meaning
T_ATM_AAL5 struct t_atm_aal5 ATM adaptation layer 5
T_ATM_TRAFFIC struct t_atm_traffic data traffic descriptor
T_ATM_BEARER_CAP struct t_atm_bearer ATM service capabilities
T_ATM_BHLI struct t_atm_bhli higher-layer protocol
T_ATM_BLLI struct t_atm_blli lower-layer protocol (1st choice)
T_ATM_DEST_ADDR struct t_atm_addr call responder’s network address
T_ATM_DEST_SUB struct t_atm_addr call responder's subaddress
T_ATM_ORIG_ADDR struct t_atm_addr call initiator’s network address
T_ATM_ORIG_SUB struct t_atm_addr call initiator's subaddress
T_ATM_CALLER_ID struct t_atm_caller_id caller's identification attributes
T_ATM_CAUSE struct t_atm_cause cause of disconnection
T_ATM_QOS struct t_atm_qos desired quality of service
T_ATM_TRANSIT struct t_atm_transit public carrier transit network
T_ATM_ADD_LEAF struct t_atm_add_leaf add a leaf to a connection
T_ATM_DROP_LEAF struct t_atm_drop_leaf remove a leaf from a connection

shutdown()

This function has a local scope only; no control information is transferred across the ATM network.

socket()

The following parameter values should be used for ATM protocol transports:

If parameter protocol signifies use of the SSCOP protocol, it is recommended that the transport provider use the default of T_ATM_SSCS_SSCOP_REL in field SSCS_type of option T_ATM_AAL5.

socketpair()

This function is not supported by an ATM domain. If the function is invoked, the transport provider returns [EOPNOTSUPP].

Point-to-Multipoint Connections

To support point-to-multipoint connections, procedures are defined for the addition and removal of other parties (called leafs in this specification) to the connection. These procedures are performed only by the root of the connection. This section specifies how socket options are used within X/Sockets to accomplish these functions. For more information, see section 4.2 ("SVC Provisioning") of referenced document ATMNAS.

Adding a Leaf

T_ATM_ADD_LEAF

This option is used to request that a leaf be added to an existing point-to-multipoint connection. Note that this option is "write-only"; it is a valid parameter of setsockopt(), but not getsockopt().

The option value consists of a structure t_atm_add_leaf declared as:

struct t_atm_add_leaf { int32_t leaf_ID; struct t_atm_addr leaf_address; }

The field leaf_ID is a unique identifier for the leaf on the point-to-multipoint connection. When the connection is initially setup via connect(), the remote device is implicitly assigned a leaf identifier of zero. Other leafs added to the connection are assigned a non-zero value by the transport user. The leaf identifier is used as a correlator for the following subsequent operations:

The values used for leaf_ID may be used simultaneously on point-to-multipoint connections other than the connection indicated by parameter socket.

Legal values for the field leaf_ID are 1 thru (2**15 - 1). This field is mapped to octets 6 thru 6.1 of the ATM Forum's "Endpoint Reference" information element, defined in section 5.4.8.1 in referenced document ATMNAS.

The field leaf_address specifies the network address of the device being added as a leaf of the connection. Legal values for the field leaf_address are the same as those defined for option T_ATM_DEST_ADDR in ATM Transport Protocol Information for XTI (ATM Transport Protocol Information for XTI).

A successful return of this function does not imply that the leaf has been successfully added; rather, it means that the leaf addition request is being processed by the network. Completion (success or failure) of the leaf addition is indicated at a later time. An unsuccessful return of this function with errno set to [EINVAL] is additionally used to indicate the following error conditions:

Removing a Leaf

T_ATM_DROP_LEAF

This option is used to initiate an abortive removal of a leaf from an already established point-to-multipoint connection. When this option is invoked, data previously sent via send() may not be received by the leaf. Note that this option is "write-only"; it is a valid parameter of setsockopt(), but not getsockopt().

The option value consists of a structure t_atm_drop_leaf declared as:

struct t_atm_drop_leaf { int32_t leaf_ID; int32_t reason; }

The field leaf_ID identifies the leaf that is being removed from the connection. When the connection is initially setup via connect(), the remote device is implicitly assigned a leaf identifier of zero. Other leafs added to the connection are assigned a non-zero value by the transport user when the leaf is added to the connection.

Legal values for the field leaf_ID are 0 thru (2**15 - 1). This field is mapped to octets 6 thru 6.1 of the ATM Forum's "Endpoint Reference" information element, defined in section 5.4.8.1 in the referenced document ATMNAS.

The field reason specifies the reason for the leaf removal. This field is mapped to octet 6 of the Q.2931 Cause information element.

A successful return of this function does not imply that the leaf has been completely removed; rather, it means that the leaf removal request is being processed by the network. Eventual completion of the leaf removal is assumed. An unsuccessful return of this function with errno set to [EINVAL] is additionally used to indicate the following error conditions:

Receiving Indication of a Change in Leaf Status

There must exist an operating system-specific method of notifying the transport user that a status change has occurred for at least one leaf on a given point-to-multipoint connection. When the transport user detects that such a change has occurred for socket, the transport user invokes getsockopt() with option parameter T_ATM_LEAF_IND . This action should be repeated until field status of the returned option value has a value of T_LEAF_NOCHANGE.

T_ATM_LEAF_IND

This option is used to receive indications of status changes for leafs on an already established point-to-multipoint connection. Note that this option is "read-only"; it is a valid parameter of getsockopt(), but not setsockopt().

The option value consists of a structure t_atm_leaf_ind declared as:

struct t_atm_leaf_ind { int32_t status; int32_t leaf_ID; int32_t reason; }

The field status will contain one of these values:

The field leaf_ID identifies the leaf whose status has changed. When the connection is initially setup via connect(), the remote device is implicitly assigned a leaf identifier of zero. Other leafs added to the connection are assigned a non-zero value by the transport user when the leaf is added to the connection.

Legal values for the field leaf_ID are 0 thru (2**15 - 1). This field is mapped to octets 6 thru 6.1 of the ATM Forum's "Endpoint Reference" information element, defined in section 5.4.8.1 of referenced document ATMNAS.

When field status has a value of T_LEAF_DISCONNECTED, the field reason specifies the reason for the leaf removal. This field is mapped to octet 6 of the Q.2931 Cause information element.

An unsuccessful return of this function with errno set to [EINVAL] is additionally used to indicate the following error conditions:

Implementation Notes

This section maps the functions of X/Sockets onto the primitives specified in referenced document ATMNAS. This mapping is provided as guidance for the design and development of ATM transport providers.

accept()

The successful return of this function can be mapped to the following ATM Forum primitives:

bind()

For transport users passively waiting for incoming connections, this function implements the ATM Forum's ATM_prepare_incoming_call primitive. Note that parameter queue_size of the ATM Forum's ATM_prepare_incoming_call primitive is provided via X/Socket's listen() function.

close()

The invocation of this function implements the ATM Forum's ATM_abort_connection or ATM_call_release (request) primitive.

connect()

The invocation of this function implements the ATM Forum's ATM_connect_outgoing_call primitive. Additionally, the successful return of this function can be mapped to the following ATM Forum primitives:

getpeername()

This function implements the ATM Forum's ATM_query_connection_attributes primitive.

getsockname()

This function implements the ATM Forum's ATM_query_connection_attributes primitive.

getsockopt()

This function implements the ATM Forum's ATM_query_connection_attributes primitive. For point-to-multipoint connections, this function also function implements the ATM Forum's ATM_add_party_success, ATM_add_party_reject and ATM_drop_party (Indication) primitives.

listen()

The invocation of this function partially implements the ATM Forum's ATM_wait_on_incoming_call primitive, since the queue is enabled. Note that the ATM Forum's primitive can be further classified in this case as a "polling implementation".

recv()

The invocation of this function implements the ATM Forum's ATM_receive_data primitive.

recvfrom()

The invocation of this function implements the ATM Forum's ATM_receive_data primitive.

recvmsg()

The invocation of this function implements the ATM Forum's ATM_receive_data primitive.

send()

The invocation of this function implements the ATM Forum's ATM_send_data primitive.

sendmsg()

The invocation of this function implements the ATM Forum's ATM_send_data primitive.

sendto()

The invocation of this function implements the ATM Forum's ATM_send_data primitive.

setsockopt()

This function implements the ATM Forum's ATM_set_connection_attributes primitive. For point-to-multipoint connections, this function also function implements the ATM Forum's ATM_add_party and ATM_drop_party (Request) primitives.

socket()

This function implements the ATM Forum's ATM_associate_endpoint primitive.


Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index