ATM Data Structures

A new address family, AF_ATM, is introduced for native ATM services, and the corresponding "sockaddr" structure, sockaddr_atm, is defined below. To open a socket for native ATM services, parameters in socket should contain "AF_ATM", "SOCK_RAW", and "ATMPROTO_AAL5" or "ATMPROTO_AALUSER", respectively.

struct sockaddr_atm {
    u_short satm_family;        /* address family should be AF_ATM  */
    ATM_ADDRESS satm_number;    /* ATM address                      */
    ATM_BLLI satm_blli;         /* B-LLI                            */
    ATM_BHLI satm_bhli;         /* B-HLI                            */
};

Members

satm_family: Identifies the address family, which is AF_ATM in this case.
satm_number: Identifies the ATM address which could be either in E.164 or NSAP-style ATM End Systems Address format. See next section for more details about the ATM_ADDRESS structure. This field will be mapped to the Called Party Number IE(Information Element) if it is specified in bind/WSPBind for a listening socket, or in connect/WSAConnect/WSPConnect/WSAJoinLeaf/WSPJoinLeaf for a connecting socket. It will be mapped to the Calling Party Number IE if specified in bind/WSPBind for a connecting socket.
satm_blli: Identifies the fields in the B-LLI Information Element which are used along with satm_bhli to identify an application. See the section below for more details about the ATM_BLLI structure. Note that the BLLI layer 2 information is treated as not present if its Layer2Protocol field contains "SAP_FIELD_ABSENT", or wildcard if it contains "SAP_FIELD_ANY". Similarly, the BLLI layer 3 information is treated as not present if its Layer3Protocol field contains "SAP_FIELD_ABSENT", or wildcard if it contains "SAP_FIELD_ANY".
satm_bhli: Identifies the fields in the B-HLI Information Element which are used along with satm_blli to identify an application. See the section below for more details about the ATM_BHLI structure.
Note Satm_bhli is treated as not present if its HighLayerInfoType field contains "SAP_FIELD_ABSENT", or wildcard if it contains "SAP_FIELD_ANY".

For listening sockets, the sockaddr_atm structure is used in bind/WSPBind to register a Service Access Point (SAP) to receive incoming connection requests destined to this SAP. SAP registration is used to match against the SAP specified in an incoming connection request in order to determine which listening socket to receive this request. In current version of this specification, overlapping registration is not allowed. Overlapping registration is defined as having more than one registered SAP to potentially match the SAP specified in any incoming connection request. listen/WSPListen will return the error code WSAEADDRINUSE if the SAP associated with the listening socket overlaps with any currently registered SAPs in the system.

The fields in a SAP to be registered must contain either a valid value, or one of two special manifest constants: "SAP_FIELD_ABSENT", or "SAP_FIELD_ANY". "SAP_FIELD_ABSENT" simply means that this field is not presented as part of a SAP. "SAP_FIELD_ANY" means wildcarding. Note that the requirement of non-overlapping registration does not preclude wildcarding. For example, it is possible to have two registered SAPs which both contain "SAP_FIELD_ANY" in some fields and different values in other fields.

Note The called party ATM number is mandatory, thus the satm_number field cannot contain "SAP_FIELD_ABSENT".

For connecting sockets, the sockaddr_atm structure is used to specify the destination SAP in connect/WSAConnect/WSPConnect for point-to-point connections, and WSAJoinLeaf/WSPJoinLeaf for point-to-multipoint connections. The fields in the destination SAP of a connecting socket must contain either a valid value or "SAP_FIELD_ABSENT", i.e., "SAP_FIELD_ANY" is not allowed. Furthermore, "SAP_FIELD_ABSENT" is not allowed for the satm_number field. The destination SAP is used to match against all the registered SAPs in the destination machine to determine who to forward this connection request to. If each and every field of the destination SAP of an incoming request either equals to the corresponding field of a registered SAP, or the corresponding field contains the "SAP_FIELD_ANY", the listening socket associated with this registered SAP will receive the incoming connection request.

If bind/WSPBind is used on a connecting socket to specify the calling party ATM address, the satm_blli and satm_bhli fields should be ignored and the ones specified in connect/WSAConnect/WSPConnect will be used.