ATM Transport Protocol Information for Sockets

General

The following general notes apply:

• This version of Sockets supports a subset of the functions specified by the ATM Forum as the User-Network Interface (see referenced document UNI), versions 3.0 and 3.1.

• Frequent reference is made to the ATM Forum's "Native ATM Services: Semantic Description, Version 1.0", identified as referenced document ATMNAS.

• ATM supports connection-oriented sockets only. Specifically, the socket type is SOCK_SEQPACKET. At the current time, only AAL-5 message mode is supported. Each sockets message is carried across the network in the payload field of a single AAL-5 PDU. AAL1 and User-defined AAL are not supported.

• ATM supports both reliable and unreliable data transport services. Reliable service is obtained by specifying ATM_PROTO_SSCOP as the protocol when calling socket(). Unreliable service is obtained by specifying ATM_PROTO_AAL5 as the protocol when calling socket().

• ATM addresses (both network and protocol) are defined in ATM Transport Protocol Information for XTI( ATM Transport Protocol Information for XTI) of this specification.

• When a transport user passively waits for incoming connect indications, the ATM protocol address bound to the socket must conform to the ATM Forum guidelines (see 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

• AAL and BLLI negotiation is not supported since accept() contains no provision for examining and modifying connection attributes.

• The ATM transport provider does not support ATM PVCs.

• The ATM transport provider does not support a mechanism to specify the congestion indication bit and the user-user byte in AAL5.

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:

• The ATM protocol address bound to a socket 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.

• The ATM Forum guidelines (referenced document ATMNAS) determines uniqueness of an ATM protocol address. If bind() is called with a protocol address considered equivalent to an existing bound address, then [EADDRINUSE] is returned.

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:

• an ATM network address, for sockets in which the transport user passively waits for an incoming connection

• an ATM protocol address, for sockets in which the transport user actively initiates an outgoing connection.

getsockname()

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

• an ATM protocol address, for sockets in which the transport user passively waits for an incoming connection

• an ATM network address, for sockets in which the transport user actively initiates an outgoing connection.

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:

• domain = AF_ATM

• type = SOCK_SEQPACKET

• protocol = ATM_PROTO_AAL5 or ATM_PROTO_SSCOP

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

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:

• receiving indications regarding changes in the leaf's status

• removing the leaf from the point-to-multipoint connection.

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:

• the socket type of the specified socket is not a point-to-multipoint connection

• the connection has been aborted

• the connection was forcibly closed by a peer.

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:

• the socket type of the specified socket is not a point-to-multipoint connection

• the connection has been aborted

• the connection was forcibly closed by a peer.

Receiving Indication of a Change in Leaf Status

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:

• T_LEAF_NOCHANGE
  no status change has occurred for any leaf associated with this socket.

• T_LEAF_CONNECTED
  a previous request to add a leaf has been successfully completed

• T_LEAF_DISCONNECTED
  signifies that one of these occurred:

  • a previous request to add a leaf was unsuccessful

  • the leaf has initiated a release from the connection

  • the network has dropped the leaf from the connection.

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:

• the socket type of the specified socket is not a point-to-multipoint connection

• the connection has been aborted

• the connection was forcibly closed by a peer.

Implementation Notes

accept()

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

• ATM_wait_on_incoming_call primitive

• ATM_arrival_of_incoming_call primitive

• ATM_accept_incoming_call primitive

• ATM_P2P_call_active primitive (for point-to-point connections)

• ATM_P2MP_call_active primitive (for point-to-multipoint connections)

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:

• ATM_P2P_call_active primitive (point-to-point connection)

• ATM_P2MP_call_active primitive (point-to-multipoint connection)

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.