Previous section.

Technical Standard: Networking Services (XNS), Issue 5.2 Draft 2.0
Copyright © 1999 The Open Group

ATM Transport Protocol Information for XTI

General

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

The following notes apply:

ATM Addresses

This section describes the two kinds of ATM addresses mentioned in this appendix: network and protocol.

ATM Network Address

An ATM network address specifies an ATM device that resides on the user side of the User Network Interface (UNI). There are three typical uses of an ATM network address:

The ATM network address is expressed by either the t_atm_addr structure or the t_atm_sap structure, depending on the context. The t_atm_addr structure is used to query and negotiate options with the transport provider, whereas the t_atm_sap structure is used for any function that requires an ATM address as a parameter.

The t_atm_addr structure is defined in the options section. The t_atm_sap structure is defined in t_atm_sap Structure. Note that when the t_atm_sap structure is used to convey a network address, the following fields of the structure must have a value of TATM_ABSENT:


t_atm_sap_layer2.SVE_tag
t_atm_sap_layer3.SVE_tag
t_atm_sap_appl.SVE_tag

ATM Protocol Address

An ATM protocol address specifies an ATM device that resides on the user side of the UNI, plus a service access point (SAP) within the said ATM device. There are two typical uses of an ATM protocol address:

t_atm_sap Structure

The ATM address (network or protocol) is expressed via the t_atm_sap structure, defined below. Note that an implementation may overlay this structure onto a character array, prepended by other information (for example, address family identifier).

struct t_atm_sap { struct t_atm_sap_addr { int8_t SVE_tag_addr; int8_t SVE_tag_selector; uint8_t address_format; uint8_t address_length; uint8_t address [20]; } t_atm_sap_addr; struct t_atm_sap_layer2 { int8_t SVE_tag; uint8_t ID_type; union { uint8_t simple_ID; uint8_t user_defined_ID; } ID; } t_atm_sap_layer2; struct t_atm_sap_layer3 { int8_t SVE_tag; uint8_t ID_type; union { uint8_t simple_ID; int32_t IPI_ID; struct { uint8_t OUI [3]; uint8_t PID [2]; } SNAP_ID; uint8_t user_defined_ID; } ID; } t_atm_sap_layer3; struct t_atm_sap_appl { int8_t SVE_tag; uint8_t ID_type; union { uint8_t T_ISO_ID [8]; struct { uint8_t OUI [3]; uint8_t app_ID [4]; } vendor_ID; uint8_t user_defined_ID[8]; } ID; } t_atm_sap_appl; }

Legal values for the field t_atm_sap_addr.SVE_tag_addr are T_ATM_PRESENT and T_ATM_ANY. The semantic meaning of this field is found in section 4.4 of referenced document ATMNAS.

Legal values for the field t_atm_sap_addr.SVE_tag_selector are T_ATM_PRESENT, T_ATM_ABSENT, and T_ATM_ANY. Note that T_ATM_PRESENT is valid only for ATM Endsystem addresses, and T_ATM_ABSENT is valid only for E.164 addresses. The semantic meaning of this field is found in section 4.4 of referenced document ATMNAS.

Legal values for the field t_atm_sap_addr.address_format are T_ATM_ENDSYS_ADDR and T_ATM_E164_ADDR. This field is mapped to octet 5 of the Q.2931 "Called Party Number" information element.

Legal values for the field t_atm_sap_addr.address_length are 0 thru 20. This field is not mapped to any octets of a Q.2931 information element. Instead, it specifies the valid number of array elements in field t_atm_sap_addr.address.

Legal values for the field t_atm_sap_addr.address can be found in section 5.1.3 of the referenced UNI specification (versions 3.0 and 3.1). This field is mapped to octets 6 and beyond of the Q.2931 "Called Party Number" information element.

Legal values for the field t_atm_sap_layer2.SVE_tag are T_ATM_PRESENT, T_ATM_ABSENT, and T_ATM_ANY. The semantic meaning of this field is found in section 4.4 of referenced document ATMNAS.

Legal values for the field t_atm_sap_layer2.ID_type are:

T_ATM_SIMPLE_ID
identification via ITU encoding

T_ATM_USER_ID
identification via a user-defined codepoint.

This field is not mapped to any octets of a Q.2931 information element. Instead, it specifies the proper union member in the t_atm_layer2 structure.

Legal values for the field t_atm_sap_layer2.ID.simple_ID are:

T_ATM_BLLI2_I1745
I.1745

T_ATM_BLLI2_Q921
Q.921

T_ATM_BLLI2_X25_LINK
X.25, link layer

T_ATM_BLLI2_X25_MLINK
X.25, multilink

T_ATM_BLLI2_LAPB
Extended LAPB

T_ATM_BLLI2_HDLC_ARM
I.4335, ARM

T_ATM_BLLI2_HDLC_NRM
I.4335, NRM

T_ATM_BLLI2_HDLC_ABM
I.4335, ABM

T_ATM_BLLI2_I8802
I.8802

T_ATM_BLLI2_X75
X.75

T_ATM_BLLI2_Q922
Q.922

T_ATM_BLLI2_I7776
I.7776

This field is mapped to octet 6 (bits 1 thru 5) of the Q.2931 BLLI ("Broadband Low Layer Information") information element.

Legal values for the field t_atm_sap_layer2.ID.user_defined_ID are 0 thru 127. This field is mapped to octet 6a (bits 1 thru 7) of the Q.2931 BLLI information element.

Legal values for the field t_atm_sap_layer3.SVE_tag are T_ATM_PRESENT, T_ATM_ABSENT, and T_ATM_ANY. The semantic meaning of this field is found in section 4.4 of referenced document ATMNAS.

Legal values for the field t_atm_sap_layer3.ID_type are:

T_ATM_SIMPLE_ID
identification via ITU encoding

T_ATM_IPI_ID
identification via ISO/IEC TR 9577 (during connection setup)

T_ATM_SNAP_ID
identification via SNAP

T_ATM_USER_ID
identification via a user-defined codepoint

This field is not mapped to any octets of a Q.2931 information element. Instead, it specifies the proper union member in the t_atm_layer3 structure.

Legal values for the field t_atm_sap_layer3.ID.simple_ID are:

T_ATM_BLLI3_X25
X.25

T_ATM_BLLI3_I8208
I.8208

T_ATM_BLLI3_X223
X.223

T_ATM_BLLI3_I8473
I.8473

T_ATM_BLLI3_T70
T.70

T_ATM_BLLI3_I9577
I.9577

Note that a value of T_ATM_BLLI3_I9577 in this field indicates that the identification of the layer 3 protocol is done in the user (data) plane, as specified in ISO/IEC TR 9577. This field is mapped to octet 7 (bits 1 thru 5) of the Q.2931 BLLI information element.

Legal values for the field t_atm_sap_layer3.ID.IPI_ID are those values defined by ISO/IEC TR 9577. This field is mapped to octet 7a (bits 1 thru 7) and octet 7b (bit 7) of the Q.2931 BLLI information element.

Legal values for the field t_atm_sap_layer3.ID.SNAP_ID.OUI are the 24-bit Organization Unique Identifiers assigned by the IEEE. This field is mapped to octets 8.1 thru 8.3 of the Q.2931 BLLI information element.

Legal values for the field t_atm_sap_layer3.ID.SNAP_ID.PID are defined by the organization identified in the preceding field. This field is mapped to octets 8.4 thru 8.5 of the Q.2931 BLLI information element.

Legal values for the field t_atm_sap_layer3.ID.user_defined_ID are 0 thru 127. This field is mapped to octet 7a (bits 1 thru 7) of the Q.2931 BLLI information element.

Legal values for the field t_atm_sap_appl.SVE_tag are T_ATM_PRESENT, T_ATM_ABSENT, and T_ATM_ANY. The semantic meaning of this field is found in section 4.4 of referenced document ATMNAS.

Legal values for the field t_atm_sap_appl.ID_type are:

T_ATM_ISO_APP_ID
ISO codepoint

T_ATM_VENDOR_APP_ID
vendor-specific codepoint

T_ATM_USER_APP_ID
identification via a user-defined codepoint

This field is mapped to octet 5 (bits 1 thru 7) of the Q.2931 BHLI information element. It also specifies the proper union member in the t_atm_sap_appl structure.

Legal values for the field t_atm_sap_appl.ID.T_ISO_ID are reserved for specification by ISO. At the time of publication, this was an area of further study for ISO. This field is mapped to octets 6 thru 13 of the Q.2931 BHLI information element.

Legal values for the field t_atm_sap_appl.ID.vendor_ID.OUI are the 24-bit Organizationally Unique Identifiers assigned by the IEEE. This field is mapped to octets 6 thru 8 of the Q.2931 BHLI information element.

Legal values for the field t_atm_sap_appl.ID.vendor_ID.app_ID are specified by the vendor identified in the vendor_ID.OUI field. The vendor_ID.app_ID field is mapped to octets 9 thru 12 of the Q.2931 BHLI information element.

Legal values for the field t_atm_sap_appl.ID.user_defined_ID are 0 through 127. This field is mapped to octets 6 thru 13 of the Q.2931 BHLI information element.

Options

Options are formatted according to the structure t_opthdr as described in The Use of Options in XTI. A compliant ATM transport provider supports all of the options defined in this appendix. An implementation may restrict the use of any of these options by offering them only in the privileged or read-only mode.

Signalling-level Options

The protocol level is T_ATM_SIGNALING. For this level, Signaling-level Options shows the options that are defined.

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

Table: Signaling-level Options

These options are all association-related. See The Use of Options in XTI for the difference between options that are association-related and those that are not.

With the exception of option T_ATM_CAUSE, each of these options may be negotiated for a connection initiated by the transport user. The results of any such negotiation are signalled to the remote device during connection establishment. The negotiation could be done in either of the following ways:

The first of the above two methods is recommended, since some of the option values can change during connection establishment. Use of the first method returns the updated options to the transport user as parameters of the t_connect() or t_rcvconnect() function call.

For the case of a transport user passively awaiting incoming calls, only the T_ATM_AAL5 and T_ATM_BLLI options may be negotiated. The results of any such negotiation are signalled to the remote device during connection establishment. The negotiation could be done in either of the following ways:

The first of the above two methods is recommended, since the options proposed by the initiating party are not associated with the responding transport endpoint prior to t_accept(). Thus, the t_optmgmt() function call could succeed with invalid options, but the connection would be aborted when t_accept() is called.

Absolute Requirements

A request for option T_ATM_AAL5, T_ATM_TRAFFIC, T_ATM_BLLI, or T_ATM_QOS is not an absolute requirement1. Any other option request is an absolute requirement.

The above listed options can be negotiated down by the ATM transport provider or peer endsystem if necessary and when appropriate.

Further Remarks

T_ATM_AAL5

This option is used to signal end-to-end ATM adaptation layer (AAL5) parameters. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.5 of the referenced UNI specification (versions 3.0 and 3.1).

When an incoming connection indication is present, the transport user optionally negotiates this option, which is signalled to the ATM device originating the ATM call. The specific fields within this option that may be modified by the transport user are forward_max_SDU_size and backward_max_SDU_size. The negotiation could be done in either of the following ways:

The option value consists of a structure t_atm_aal5 declared as:


struct t_atm_aal5 { int32_t forward_max_SDU_size; int32_t backward_max_SDU_size; int32_t SSCS_type; }

Legal values for the field forward_max_SDU_size are T_ATM_ABSENT, and 0 through (2**16 - 1). This field is mapped to octets 6.1 and 6.2 of the Q.2931 information element.

Legal values for the field backward_max_SDU_size are T_ATM_ABSENT, and 0 thru (2**16 - 1). This field is mapped to octets 7.1 and 7.2 of the Q.2931 information element.

Legal values for the field SSCS_type are:

T_ATM_ABSENT
no indication

T_ATM_NULL
no SSCS layer on top of AAL5

T_ATM_SSCS_SSCOP_REL
SSCOP (assured) SSCS

T_ATM_SSCS_SSCOP_UNREL
SSCOP (unassured) SSCS

T_ATM_SSCS_FR
frame relay SSCS

This field is mapped to octet 8.1 of the Q.2931 information element. If, as a default, the transport provider causes this Q.2931 information element field to be present in the connection setup, then this field shall default to a value consistent with the parameter name that was specified for t_open():

t_open() name parameter default SSCS_type
AAL5 T_ATM_NULL
SSCOP/AAL5 T_ATM_SSCS_SSCOP_REL

Note that if all fields of the option have a value of T_ATM_ABSENT, then this denotes that the entire information element is not present in the Q.2931 network message.

T_ATM_TRAFFIC

This option is used to signal the data bandwidth parameters. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.6 of the referenced UNI specification (versions 3.0 and 3.1).

The option value consists of a structure t_atm_traffic declared as:


struct t_atm_traffic_substruct { int32_t PCR_high_priority; int32_t PCR_all_traffic; int32_t SCR_high_priority; int32_t SCR_all_traffic; int32_t MBS_high_priority; int32_t MBS_all_traffic; int32_t tagging; } struct t_atm_traffic { struct t_atm_traffic_substruct forward; struct t_atm_traffic_substruct backward; uint8_t best_effort; }

Legal values for the field forward.PCR_high_priority are T_ATM_ABSENT, and 0 thru (2**24 - 1). This field is mapped to octets 5.1 thru 5.3 of the Q.2931 information element.

Legal values for the field forward.PCR_all_traffic are 0 thru (2**24 - 1). This field is mapped to octets 7.1 thru 7.3 of the Q.2931 information element.

Legal values for the field forward.SCR_high_priority are T_ATM_ABSENT, and 0 thru (2**24 - 1). This field is mapped to octets 9.1 thru 9.3 of the Q.2931 information element.

Legal values for the field forward.SCR_all_traffic are T_ATM_ABSENT, and 0 thru (2**24 - 1). This field is mapped to octets 11.1 thru 11.3 of the Q.2931 information element.

Legal values for the field forward.MBS_high_priority are T_ATM_ABSENT, and 0 thru (2**24 - 1). This field is mapped to octets 13.1 thru 13.3 of the Q.2931 information element.

Legal values for the field forward.MBS_all_traffic are T_ATM_ABSENT, and 0 thru (2**24 - 1). This field is mapped to octets 15.1 thru 15.3 of the Q.2931 information element.

Legal values for the field forward.tagging are T_YES and T_NO. This field is mapped to octet 18.1 (bit 1) of the Q.2931 information element.

Legal values for the field backward.PCR_high_priority are T_ATM_ABSENT, and 0 thru (2**24 - 1). This field is mapped to octets 6.1 thru 6.3 of the Q.2931 information element.

Legal values for the field backward.PCR_all_traffic are 0 thru (2**24 - 1). This field is mapped to octets 8.1 thru 8.3 of the Q.2931 information element.

Legal values for the field backward.SCR_high_priority are T_ATM_ABSENT, and 0 thru (2**24 - 1). This field is mapped to octets 10.1 thru 10.3 of the Q.2931 information element.

Legal values for the field backward.SCR_all_traffic are T_ATM_ABSENT, and 0 thru (2**24 - 1). This field is mapped to octets 12.1 thru 12.3 of the Q.2931 information element.

Legal values for the field backward.MBS_high_priority are T_ATM_ABSENT, and 0 thru (2**24 - 1). This field is mapped to octets 14.1 thru 14.3 of the Q.2931 information element.

Legal values for the field backward.MBS_all_traffic are T_ATM_ABSENT, and 0 thru (2**24 - 1). This field is mapped to octets 16.1 thru 16.3 of the Q.2931 information element.

Legal values for the field backward.tagging are T_YES and T_NO. This field is mapped to octet 18.1 (bit 2) of the Q.2931 information element.

Legal values for the field best_effort are T_YES and T_NO. This field is mapped to octet 17 of the Q.2931 information element.

T_ATM_BEARER_CAP

This option is used to signal the capabilities of the ATM service. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.7 of the referenced UNI specification (versions 3.0 and 3.1).

The option value consists of a structure t_atm_bearer declared as:


struct t_atm_bearer { uint8_t bearer_class; uint8_t traffic_type; uint8_t timing_requirements; uint8_t clipping_susceptibility; uint8_t connection_configuration; }

Legal values for the field bearer_class (see ITU Recommendation F.811) are:

T_ATM_CLASS_A
bearer class A

T_ATM_CLASS_C
bearer class C

T_ATM_CLASS_X
bearer class X

This field is mapped to octet 5 (bits 1 thru 5) of the Q.2931 information element.

Legal values for the field traffic_type are:

T_ATM_NULL
no indication of traffic type

T_ATM_CBR
constant bit rate

T_ATM_VBR
variable bit rate

This field is mapped to octet 5a (bits 3 thru 5) of the Q.2931 information element.

Legal values for the field timing_requirements are:

T_ATM_NULL
no indication of requirements

T_ATM_END_TO_END
end-to-end timing required

T_ATM_NO_END_TO_END
end-to-end timing not required

This field is mapped to octet 5a (bits 1 and 2) of the Q.2931 information element.

Legal values for the field clipping_susceptibility are:

T_NO
not susceptible to clipping

T_YES
susceptible to clipping

This field is mapped to octet 6 (bits 6 and 7) of the Q.2931 information element.

Legal values for the field connection_configuration are:

T_ATM_1_TO_1
point-to-point connection

T_ATM_1_TO_MANY
point-to-multipoint connection

This field is mapped to octet 6 (bits 1 and 2) of the Q.2931 information element.

T_ATM_BHLI

This option is used to signal information about the application that will communicate across the connection. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.8 of the referenced UNI specification (versions 3.0 and 3.1).

For the transport user initiating the connection, the option values pertaining to the specification of the remote ATM protocol address are overwritten with the corresponding parameters of the t_connect() function call. The following fields of this option are set to values found in analogous fields of t_atm_sap_appl structure in the destination protocol address when function t_connect() is invoked:


ID_type,
and all members of union
ID.

The option value consists of a structure t_atm_bhli declared as:


struct t_atm_bhli { int32_t ID_type; union { uint8_t T_ISO_ID [8]; struct { uint8_t OUI [3]; uint8_t app_ID [4]; } vendor_ID; uint8_t user_defined_ID[8]; } ID; }

Legal values for the field ID_type are:

T_ATM_ABSENT
application ID is not indicated

T_ATM_ISO_APP_ID
ISO codepoint

T_ATM_VENDOR_APP_ID
vendor-specific codepoint

T_ATM_USER_APP_ID
identification via a user-defined codepoint

This field is mapped to octet 5 (bits 1 thru 7) of the Q.2931 information element. The value T_ATM_ABSENT denotes that the entire information element is not present in the Q.2931 network message.

Legal values for the field ID.T_ISO_ID are reserved for specification by ISO. At the time of publication, this was an area of further study for ISO. This field is mapped to octets 6 thru 13 of the Q.2931 information element.

Legal values for the field ID.vendor_ID.OUI are the 24-bit Organization Unique Identifiers assigned by the IEEE. This field is mapped to octets 6 thru 8 of the Q.2931 information element.

Legal values for the field ID.vendor_ID.app_ID are specified by the vendor identified in the ID.vendor_ID.OUI field. The ID.vendor_ID.app_ID field is mapped to octets 9 thru 12 of the Q.2931 information element.

Legal values for the field ID.user_defined_ID are 0 through 127. This field is mapped to octets 6 thru 13 of the Q.2931 BHLI information element.

T_ATM_BLLI

This option is used to signal information about the layer 2 and layer 3 protocols (if any) that will communicate across the connection. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.9 of the referenced UNI specification (versions 3.0 and 3.1). Note that this option represents the first choice of a transport user initiating a connection across the ATM network. Up to three such choices can be signalled across the ATM network (however, XTI supports only one choice at this time).

For the transport user initiating the connection, the option values pertaining to the specification of the remote ATM protocol address are overwritten with the corresponding parameters of the t_connect() function call. The following fields of this option are set to values found in analogous fields of t_atm_sap_layer2 and t_atm_sap_layer3 structures in the destination protocol address when function t_connect() is invoked:

When an incoming connection indication is present, the transport user optionally negotiates this option, which is signalled to the ATM device originating the ATM call. The specific fields within this option that may be modified by the transport user are:

The option negotiation could be done in either of the following ways:

The transport user accepting the incoming connection indication must perform any negotiation according to the guidelines described in section C.3, Annex C of the referenced UNI specification, versions 3.0 and 3.1. Support of negotiation described in section C.4 of Annex C is for further study.

The option value consists of a structure t_atm_blli declared as:


struct t_atm_blli { struct { int8_t ID_type; union { uint8_t simple_ID; uint8_t user_defined_ID; } ID; int8_t mode; int8_t window_size; } layer_2_protocol; struct { int8_t ID_type; union { uint8_t simple_ID; int32_t IPI_ID; struct { uint8_t OUI [3]; uint8_t PID [2]; } SNAP_ID; uint8_t user_defined_ID; } ID; int8_t mode; int8_t packet_size; int8_t window_size; } layer_3_protocol; }

Legal values for the field layer_2_protocol.ID_type are:

T_ATM_ABSENT
layer 2 identification is not present

T_ATM_SIMPLE_ID
identification via ITU encoding

T_ATM_USER_ID
identification via a user-defined codepoint

This field is not mapped to any octets of a Q.2931 information element. Instead, it specifies the proper union member in the t_atm_layer2 structure.

Legal values for the field layer_2_protocol.ID.simple_ID are:

T_ATM_BLLI2_I174
I.1745

T_ATM_BLLI2_Q921
Q.921

T_ATM_BLLI2_X25_LINK
X.25, link layer

T_ATM_BLLI2_X25_MLINK
X.25, multilink

T_ATM_BLLI2_LAPB
Extended LAPB

T_ATM_BLLI2_HDLC_ARM
I.4335, ARM

T_ATM_BLLI2_HDLC_NRM
I.4335, NRM

T_ATM_BLLI2_HDLC_ABM
I.4335, ABM

T_ATM_BLLI2_I8802
I.8802

T_ATM_BLLI2_X75
X.75

T_ATM_BLLI2_Q922
Q.922

T_ATM_BLLI2_I7776
I.7776

This field is mapped to octet 6 (bits 1 thru 5) of the Q.2931 information element.

Legal values for the field layer_2_protocol.ID.user_defined_ID are 0 thru 127. This field is mapped to octet 6a (bits 1 thru 7) of the Q.2931 BLLI information element.

Legal values for the field layer_2_protocol.mode are T_ATM_ABSENT, T_ATM_BLLI_NORMAL_MODE, and T_ATM_BLLI_EXTENDED_MODE. This field is mapped to octet 6a (bits 6 and 7) of the Q.2931 information element.

Legal values for the field layer_2_protocol.window_size are T_ATM_ABSENT, and 1 thru 127. This field is mapped to octet 6b (bits 1 thru 7) of the Q.2931 information element.

Legal values for the field layer_3_protocol.ID_type are:

T_ATM_ABSENT
no layer 3 protocol identification

T_ATM_SIMPLE
ID identification via ITU encoding

T_ATM_IPI_ID
identification via ISO/IEC TR 9577

T_ATM_SNAP_ID
identification via SNAP

T_ATM_USER_ID
identification via a user-defined codepoint

This field is not mapped to any octets of the Q.2931 information element. Instead, it specifies the proper union member in structure t_atm_blli.

Legal values for the field layer_3_protocol.ID.simple_ID are:

T_ATM_BLLI3_X25
X.25

T_ATM_BLLI3_I8208
I.8208

T_ATM_BLLI3_X223
X.223

T_ATM_BLLI3_I8473
I.8473

T_ATM_BLLI3_T70
70

T_ATM_BLLI3_I9577
I.9577 (during connection setup)

Note that a value of T_ATM_BLLI3_I9577 in this field indicates that the identification of the layer 3 protocol is done in the user (data) plane, as specified in ISO/IEC TR 9577. This field is mapped to octet 7 (bits 1 thru 5) of the Q.2931 information element.

Legal values for the field layer_3_protocol.ID.IPI_ID are T_ATM_ABSENT, and those values defined by ISO/IEC TR 9577. This field is mapped to octet 7a (bits 1 thru 7) and octet 7b (bit 7) of the Q.2931 information element. Note that the value T_ATM_ABSENT is used to signal that the identification of the network-layer protocol is carried with each TSDU in the data plane, according to codepoints defined by ISO/IEC TR 9577.

Legal values for the field layer_3_protocol.ID.SNAP_ID.OUI are the 24-bit Organization Unique Identifiers assigned by IEEE. This field is mapped to octets 8.1 thru 8.3 of the Q.2931 information element.

Legal values for the field layer_3_protocol.ID.SNAP_ID.PID are defined by the organization identified in the preceding field. This field is mapped to octets 8.4 thru 8.5 of the Q.2931 information element.

Legal values for the field layer_3_protocol.ID.user_defined_ID are 0 thru 127. This field is mapped to octet 7a (bits 1 thru 7) of the Q.2931 BLLI information element.

Legal values for the field layer_3_protocol.mode are T_ATM_ABSENT, T_ATM_BLLI_NORMAL_MODE, and T_ATM_BLLI_EXTENDED_MODE. This field is mapped to octet 7a (bits 6 and 7) of the Q.2931 information element.

Legal values for the field layer_3_protocol.packet_size are:

T_ATM_ABSENT

T_ATM_PACKET_SIZE_16

T_ATM_PACKET_SIZE_32

T_ATM_PACKET_SIZE_64

T_ATM_PACKET_SIZE_128

T_ATM_PACKET_SIZE_256

T_ATM_PACKET_SIZE_512

T_ATM_PACKET_SIZE_1024

T_ATM_PACKET_SIZE_2048

T_ATM_PACKET_SIZE_4096

This field is mapped to octet 7b (bits 1 thru 4) of the Q.2931 information element.

Legal values for the field layer_3_protocol.window_size are T_ATM_ABSENT, and 1 thru 127. This field is mapped to octet 7c (bits 1 thru 7) of the Q.2931 information element.

T_ATM_DEST_ADDR

This option is used to signal the ATM network address of the connection’s destination. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.11 of the referenced UNI specification (versions 3.0 and 3.1).

For the transport user initiating the connection, the option values pertaining to the specification of the remote ATM protocol address are overwritten with the corresponding parameters of the t_connect() function call. The following fields of this option are set to values found in analogous fields of the destination protocol address when function t_connect() is invoked:

The option value consists of a structure t_atm_addr declared as:


struct t_atm_addr { int8_t address_format; uint8_t address_length; uint8_t address [20]; }

Legal values for the field address_format are T_ATM_ENDSYS_ADDR and T_ATM_E164_ADDR. This field is mapped to octet 5 of the Q.2931 information element.

Legal values for the field address_length are 0 thru 20. This field is not mapped to any octets of a Q.2931 information element. Instead, it specifies the valid number of array elements in field address.

Legal values for the field address can be found in section 5.1.3 of the referenced UNI specification (versions 3.0 and 3.1). This field is mapped to octets 6 and beyond of the Q.2931 information element.

T_ATM_DEST_SUB

This option is used to signal the ATM subaddress of the connection’s destination. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.12 of the referenced UNI specification (versions 3.0 and 3.1).

The option value consists of a structure t_atm_addr (see option T_ATM_DEST_ADDR for the structure's declaration). Note that for this option, field address_format must have a value of either T_ATM_NSAP_ADDR or T_ATM_ABSENT.

A value of T_ATM_ABSENT in field address_format of structure t_atm_addr indicates that the information element is not present in the Q.2931 signalling message.

T_ATM_ORIG_ADDR

This option is used to signal the ATM network address of the connection’s originator. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.13 of the referenced UNI specification (versions 3.0 and 3.1).

The option value consists of a structure t_atm_addr (see option T_ATM_DEST_ADDR for the structure's declaration).

A value of T_ATM_ABSENT in field address_format of structure t_atm_addr indicates that the information element is not present in the Q.2931 signalling message.

T_ATM_ORIG_SUB

This option is used to signal the ATM subaddress of the connection’s originator. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.14 of the referenced UNI specification (versions 3.0 and 3.1).

The option value consists of a structure t_atm_addr (see option T_ATM_DEST_ADDR for the structure's declaration). Note that for this option, field address_format must have a value of either T_ATM_NSAP_ADDR or T_ATM_ABSENT.

A value of T_ATM_ABSENT in field address_format of structure t_atm_addr indicates that the information element is not present in the Q.2931 signalling message.

T_ATM_CALLER_ID

This option is used to signal additional attributes concerning the network address of the connection's originator. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.13 of the referenced UNI specification (versions 3.0 and 3.1).

The option value consists of a structure t_atm_caller_id declared as:


struct t_atm_caller_id { int8_t presentation; uint8_t screening; }

Legal values for the field presentation are:

T_ATM_ABSENT

T_ATM_PRES_ALLOWED

T_ATM_PRES_RESTRICTED

T_ATM_PRES_UNAVAILABLE

This field is mapped to octet 5a (bits 6 and 7) of the Q.2931 information element.

Legal values for the field screening are:

T_ATM_ABSENT

T_ATM_USER_ID_NOT_SCREENED

T_ATM_USER_ID_PASSED_SCREEN

T_ATM_USER_ID_FAILED_SCREEN

T_ATM_NETWORK_PROVIDED_ID

This field is mapped to octet 5a (bits 1 and 2) of the Q.2931 information element.

T_ATM_CAUSE

This option is used to signal the cause of a disconnection. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.15 of the referenced UNI specification (versions 3.0 and 3.1).

Upon disconnection, the transport user optionally negotiates this option, the results of which are signalled to the remote ATM device. Any such negotiation must be performed via the t_optmgmt() function.

The option value consists of a structure t_atm_cause declared as:


struct t_atm_cause { int8_t coding_standard; uint8_r location; uint8_r cause_value; uint8_r diagnostics [4]; }

Legal values for the field coding_standard are T_ATM_ABSENT, T_ATM_ITU_CODING, and T_ATM_NETWORK_CODING. This field is mapped to octet 2 (bits 6 and 7) of the Q.2931 information element. The value of T_ATM_ABSENT denotes that the entire information element is not present in the Q.2931 network message.

Legal values for the field location are:

T_ATM_LOC_USER

T_ATM_LOC_LOCAL_PRIVATE_NET

T_ATM_LOC_LOCAL_PUBLIC_NET

T_ATM_LOC_TRANSIT_NET

T_ATM_LOC_REMOTE_PUBLIC_NET

T_ATM_LOC_REMOTE_PRIVATE_NET

T_ATM_LOC_INTERNATIONAL_NET

T_ATM_LOC_BEYOND_INTERWORKING

This field is mapped to octet 5 (bits 1 thru 4) of the Q.2931 information element.

Legal values for the field cause_value are listed in a full-page table in the referenced UNI specification. This field is mapped to octet 6 (bits 1 thru 7) of the Q.2931 information element.

Legal values for the field diagnostics are beyond the scope of this specification. This field is mapped to octets 7 and beyond of the Q.2931 information element.

T_ATM_QOS

This option is used to signal the desired quality of service. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.18 of the referenced UNI specification (versions 3.0 and 3.1).

The option value consists of a structure t_atm_qos declared as:


struct t_atm_qos_substruct { int32_t coding_standard; } struct t_atm_qos { int8_t coding_standard; struct t_atm_qos_substruct forward; struct t_atm_qos_substruct backward; }

Legal values for the field coding_standard are T_ATM_ABSENT, T_ATM_ITU_CODING, and T_ATM_NETWORK_CODING. This field is mapped to octet 2 (bits 6 and 7) of the Q.2931 information element. The value of T_ATM_ABSENT denotes that the entire information element is not present in the Q.2931 network message.

Legal values for the field forward.qos_class are:

T_ATM_QOS_CLASS_0

T_ATM_QOS_CLASS_1

T_ATM_QOS_CLASS_2

T_ATM_QOS_CLASS_3

T_ATM_QOS_CLASS_4

This field is mapped to octet 5 of the Q.2931 information element.

Legal values for the field backward.qos_class are the same as those specified for field forward.qos_class above. This field ( backward.qos_class) is mapped to octet 6 of the Q.2931 information element.

T_ATM_TRANSIT

This option is used to signal the selection of the inter-exchange public carrier. The description of the information element that is signalled across the ATM network can be found in section 5.4.5.22 of the referenced UNI specification (versions 3.0 and 3.1).

The option value consists of a structure t_atm_transit declared as:


struct t_atm_transit { uint8_t length; uint8_t network_id[]; }
The field length specifies how many characters in array network_id are valid.

Legal values for the field length are 0 thru 255. The value of 0 denotes that the entire information element is not present in the Q.2931 network message.

Legal values for the field network_id are beyond the scope of this document. This field is mapped to octets 6 and beyond of the Q.2931 information element.

Existing Functions

t_accept()

The parameter call->addr is ignored by the ATM transport provider.

The parameter call->opt is used only to set negotiable ATM connection attributes. These attributes (and XTI options) are T_ATM_AAL5 and T_ATM_BLLI.

Note that the transport provider must queue data sent via t_snd() until the end-to-end data path is operational.

t_bind()

When a transport user wishes to passively wait for incoming connect indications through a transport endpoint, then t_bind() is called with parameter req->qlen having a non-zero value. For ATM, the following additional restrictions apply:

When a transport user wishes to initiate outgoing connect requests through a transport endpoint, it is recommended that t_bind() be called with parameters req and ret being null pointers.

If t_bind() is called with parameter req->addr.buf pointing to an ATM network or protocol address, and parameter req->qlen having a value of zero; then the ATM provider must perform the following:

t_close()

If the transport user wishes to convey the cause of the disconnection to the remote user, then option T_ATM_CAUSE must be negotiated via t_optmgmt() prior to calling t_close().

t_connect()

Parameter sndcall->addr specifies the ATM protocol address of the destination transport user. This ATM protocol address 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.

t_getinfo()

The following information parameters are returned:

    After Call
Parameters Before _
  Call AAL-5 SSCOP / AAL-5
fd x / /
info->addr / x x
info->options / x x
info->tsdu / 1 & 60;= x &
info->etsdu / -2 -2
info->connect / -2 -2
info->discon / -2 -2
info->servtype / T_COTS T_COTS
info->flags / 0 0

t_listen()

The parameter call->addr is not the ATM protocol address of the calling transport user; it is merely the network address of the calling user's ATM device. This address may not be sufficient to be the destination protocol address in the t_connect() function.

Upon successful return of t_listen(), the options contained in parameter call are those received in the Q.2931 signalling SETUP message from the ATM network.

t_look()

A new event, T_LEAFCHANGE, is defined which is used by event management to notify a transport user when the status of a leaf has changed on a point-to-multipoint connection.

t_open()

The choice of whether or not the transport provider is requested to implement the SSCOP protocol above AAL-5 in the data plane is conveyed via parameter name. The SSCOP protocol provides a reliable data delivery service. See the notes on function t_getinfo() in this section for a discussion of parameter info.

t_rcvdis()

The parameter reason is an 8-bit cause value that is sent across the ATM network in octet 6 of the Q.2931 Cause information element. Additional cause information may be obtained from the T_ATM_CAUSE option via t_optmgmt().

t_snd()

ATM does not support the transport of expedited data. If the transport user sets the T_EXPEDITED flag in parameter flags, then error [TBADFLAG] is returned.

ATM does not support a zero-length TSDU. If parameter nbytes is zero, then [TBADDATA] is returned if either:

When the connection present at the transport endpoint is a leaf on a point-to-multipoint connection, the transport provider returns [TNOTSUPPORT] for t_snd().

t_snddis()

If the transport user wishes to convey the cause of the disconnection to the remote user, then option T_ATM_CAUSE must be negotiated via t_optmgmt() prior to calling t_snddis().

Implementation Notes

This section maps the functions of XTI onto the primitives specified in referenced document ATMNAS). This mapping information is provided as guidance for the design and development of ATM Transport Providers.

t_accept()

This function implements the ATM Forum’s ATM_accept_incoming_call primitive. If any options are present in parameter call->opt, then each of these options is an implementation of the ATM Forum's ATM_set_connection_attributes primitive.

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

t_bind()

For transport users passively waiting for incoming connect indications, this function implements the ATM Forum primitives ATM_prepare_incoming_call and ATM_wait_on_incoming_call. For transport users initiating connect requests, this function implements the ATM Forum’s ATM_prepare_outgoing_call primitive.

Note that parameter queue_size of the ATM Forum's ATM_prepare_incoming_call primitive is different to XTI's qlen: The parameter queue_size is the maximum number of incoming calls that have arrived but have not yet been presented to the transport user, while the parameter qlen is the maximum number of incoming calls that have been presented to the transport user but not yet accepted. Therefore, queue_size cannot be set via the t_bind() function; the value is determined by the transport provider..

t_close()

Normally, this function is called from the T_UNBND state; in this case, there is no needed mapping to the ATM Forum primitives. XTI also allows this function to be legally called from other states as well. When that occurs, this function implements the ATM Forum's ATM_abort_connection primitive. However, the transport user cannot specify the cause of the aborted connection.

t_connect()

The invocation of this function implements the ATM Forum's ATM_connect_outgoing_call primitive. If any options are present in parameter sndcall->opt, then each of these options is an implementation of the ATM Forum's ATM_set_connection_attributes primitive. If any options are present in parameter rcvcall->optc, then each of these options is an implementation of the ATM Forum's ATM_query_connection_attributes primitive.

Additionally, when the transport endpoint is in synchronous mode, the return of this function can be mapped to the following ATM Forum primitives:

t_listen()

The successful return of this function is an implementation of the ATM Forum's ATM_arrival_of_incoming_call primitive.

The ATM network address (of the calling user) returned in parameter call->addr is an implementation of the ATM Forum's ATM_query_connection_attributes primitive, where the connection attribute (and XTI option) being queried is T_ATM_ORIG_ADDR. If any options are present in parameter call->opt, then each of these options is an implementation of the ATM Forum's ATM_query_connection_attributes primitive.

t_open()

This function implements the ATM Forum’s ATM_associate_endpoint primitive.

t_optmgmt()

For any option values that the transport user attempts to negotiate (present in parameter req->opt when parameter req->flags equals T_NEGOTIATE), each of these options is an implementation of the ATM Forum's ATM_set_connection_attributes primitive. For any options present in parameter ret->opt, each of these options is an implementation of the ATM Forum's ATM_query_connection_attributes primitive.

t_rcv()

The invocation of this function implements the ATM Forum's ATM_receive_data primitive. Note that the ATM Forum's primitive can be further classified as either a "polling implementation" or a "blocking implementation". XTI's synchronous mode corresponds to "blocking implementation"; asynchronous mode corresponds to "polling implementation".

t_rcvconnect()

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

If any options are present in parameter call->opt, then each of these options is an implementation of the ATM Forum's ATM_query_connection_attributes primitive.

t_rcvdis()

The successful return of this function implements the ATM Forum’s ATM_call_release (indication) primitive.

t_snd()

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

t_snddis()

Depending on the XTI state, invocation of this function implements the following ATM Forum primitives:

state T_DATAXFER:
ATM_call_release (request) or ATM_abort_connection

state T_INCON:
ATM_reject_incoming_call

all other valid states:
ATM_abort_connection.

t_unbind()

There is no ATM Forum primitive to which this function can be mapped. From the perspective of the ATM Forum state machine, this function does the following:

t_addleaf()

This function implements the ATM Forum's ATM_add_party primitive. If successful in the addition of the leaf, the function's return implements the ATM Forum's ATM_add_party_success primitive.

t_removeleaf()

This function implements the ATM Forum's ATM_drop_party (Request) primitive.

t_rcvleafchange()

This function implements the following ATM Forum primitives:

ATM_add_party_success
ATM_add_party_reject
ATM_drop_party(Indication)

New Functions

The following new functions are defined in the following man-pages:

t_addleaf()
t_removeleaf()
t_rcvleafchange()


Footnotes

1.
The definition of absolute requirement is given in Initiating an Option Negotiation.

Contents Next section Index