Previous section.

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

Minimum OSI Functionality

General

The purpose of this specification is to provide a simple API exposing a minimum set of OSI Upper Layers functionality (mOSI).

Rationale for using XTI-mOSI

This appendix uses the concept of a minimal set of OSI upper layer facilities that support basic communication applications. A Basic Communication Application simply requires the ability to open and close communications with a peer and to send and receive messages with a peer.

XTI-mOSI is designed specifically for Basic Communication Applications that are in one of these categories:

Migrant Applications

For the first kind of applications (those migrating to OSI or intended to work over a variety of transport mechanisms), the migration effort will be greatly simplified if they were already using XTI - mOSI offers several new options, but, as described later in this section, default values are generally provided.

In addition to applications already using XTI, the X Window System (X) and Internet Protocol Suite applications (in general) are examples of potential Migrant applications.

OSI Functionality

mOSI is suited to applications that require only the Minimal Upper Layer facilities which are described in the profile ISO/IEC DISP 11188 - Common Upper Layer Requirements, Part 3: Minimal OSI upper layer facilities, expected to reach International Standardized Profile (ISP) status in the first half of 1995. These are:

The XTI-mOSI interface provides access to OSI ACSE and Presentation services. With mOSI, the optional parameters available to the application have been selected with the intent of facilitating interoperability and diagnostic of problems. They are described later in this section.

Most applications only need the Kernel functionality. This is even true for most of the OSI standard applications: Remote Database Access (RDA), Directory (X.500), FTAM without recovery, OSI Distributed Transaction Processing (TP) without 2-phase commitment, OSI Management.

mOSI API versus XAP

X/Open has developed the XAP interface (ACSE/Presentation API) to provide access to ACSE and Presentation functionality. It provides an interface which spans from implementations of minimal OSI through to full ACSE/Presentation/Session with all functional units.

XTI-mOSI has been developed to support migrant transport applications, and also applications which require a simple octet stream connection between peers.

Application designers should consider which API is most appropriate to their needs.

Applications which are being ported from other transport providers, or require a simple octet string connection, should use XTI-mOSI.

Applications which require session function units outside kernel, or which require multiple presentation contexts, or which may require additional session/presentation by mOSI in the future, should use XAP.

When only minimal OSI support is required, the user should consider the availability of XTI-mOSI and XAP on target hardware platforms when selecting an interface.

Upper Layers Functionality Exposed via mOSI

These are presented as they are exposed via mOSI options and specific parameters.
Naming and Addressing Information used by mOSI
The addr structure (used in t_bind(), t_connect(), t_accept()) is a combined naming and addressing data type, identifying one end or the other of the association.

The address part is a Presentation Address. The calling and called addresses are required parameters, while the use of a responding address is optional.

The name part (Application Process (AP) Title, Application Entity (AE) Qualifier and the AP and AE invocation-identifiers) is always optional.

ISO Directory facilities, when available, can relate the name parts (identifying specific applications) to the addresses of the real locations where they can be accessed.

The general format of the addr structure can be found in Option Data Types and Structures, while its precise structure is implementation dependent.

XTI Options Specific to mOSI

Options

Options are formatted according to the structure t_opthdr as described in The Use of Options in XTI. An OSI provider compliant to this specification supports all, none or a subset of the options defined in ACSE/Presentation Connection-mode Service. An implementation may restrict the use of any of the options by offering them in privileged or read_only mode.

An explanation of when an application may benefit from using the XTI options specific to mOSI can be found in General.

ACSE/Presentation Connection-mode Service

The protocol level for all subsequent options is T_ISO_APCO.

All options have end-to-end significance (see The Use of Options in XTI. They may be negotiated in the XTI states T_IDLE and T_INCON, and are read-only in all other states except T_UNINIT. The structures referenced are specified in Option Data Types and Structures.

Option Name Type of Option Legal Meaning
  Value Option Value  
T_AP_CNTX_NAME Object identifier item (see Option Data Types and Structures) see text
default: see text
Application Context Name
T_AP_PCL Presentation Context Definition and Result list (see Option Data Types and Structures)
see text
default: see text
Presentation Context Definition and Result List

Table: APCO-level Options
Further Remarks
Negotiation of Abstract and Transfer Syntax
When initiating a connection, the application proposes one or more presentation contexts, each comprising an abstract syntax and one or more transfer syntaxes in the Presentation Context Definition and Result List option (or omits this option to select the CULR-3 defaults), and issues a t_connect().

If the connection is accepted, the Presentation Context Definition and Result List is updated to reflect the results of negotiation for each element of the context list, and a single presentation context is selected.

Note:
If the responder accepts multiple presentation contexts, the XTI-mOSI provider aborts the connection on receipt of the A-ASSOCIATE confirm.

When responding to a remote connect, the application can specifically mark presentation contexts as rejected using the res field, and can re-order the syntax array to select a single transfer syntax.

On calling t_accept(), the first presentation context marked as accepted is selected, and all other contexts omitted or not marked rejected-user are marked as by the provider as rejected (T_PCL_PREJ_LMT_DCS_EXCEED). In an accepted context, the provider will accept the first (or only remaining) transfer syntax.

Note:
On return to the application from t_listen(), all supportable presentation contexts are marked as accepted in the T_AP_PCL option, and all unsupportable contexts are marked as rejected-provider. This permits the application to return the same option value on t_accept() (or leave it unchanged) to select the first available abstract syntax and transfer syntax.
Management Options

No management options are defined.

ACSE/Presentation Connectionless-mode Service

The protocol level for all subsequent options is T_ISO_APCL.

All options have end-to-end significance (see The Use of Options in XTI). They may be negotiated in all XTI states except T_UNINIT. The structures referenced are specified in Option Data Types and Structures.

Option Name Type of Option Legal Meaning
  Value Option Value  
T_AP_CNTX_NAME Object identifier item (see Option Data Types and Structures) see text
default: see text
Application Context Name
T_AP_PCL Presentation Context Definition and Result list (see Option Data Types and Structures) see text
default: see text
Presentation Context Definition and Result List

Table: APCL-level Options

Further Remarks

Management Options

No management options are defined.

Transport Service Options

Some of the options defined for XTI ISO Transport Connection-mode Service or Transport Connectionless-mode Service may be made available to mOSI users: the Options for Quality of Service.

These Options are defined in Options for Quality of Service and Expedited Data and Options for Quality of Service. The Quality of Service parameters are passed directly by the OSI Upper Layers to the Transport Layer. These options can thus be used to specify OSI Upper Layers quality of service parameters via XTI.

This facility is implementation dependent. An attempt to specify an unsupported option will return with the status field set to T_NOTSUPPORT.

None of these options are available with an ISO-over-TCP transport provider.

Functions

Functions rcvreldata() (see t_rcvreldata) and sndreldata() (see t_sndreldata) were introduced as part of this XTI-mOSI functionality. The rationale for this is that for ISO ACSE providing an orderly release mechanism, user data is a parameter of the release service, so when mapping XTI primitives to ACSE/Presentation (XTI-mOSI), disconnection user data may be received from peer applications. Although abortive release primitives (t_snddis, t_rcvdis) permit sending and receiving of user data, orderly release primitives (t_sndrel, t_rcvrel) do not. Therefore, new functions having a user data parameter t_rcvreldata() and t_sndreldata() were were added to provide the necessary support to handle this user data.

t_accept()
If fd is not equal to resfd, resfd should either be in state T_UNBND or be in state T_IDLE with the qlen parameter set to 0.

The addr parameter passed to/returned from t_bind() when resfd is bound may be different from the addr parameter corresponding to fd.

The opt parameter may be used to change the Application Context Name received.

t_alloc()
No special considerations for mOSI providers.

t_bind()
The addr field of the t_bind structure represents the local presentation address and optionally the local AP Title, AE Qualifier, AP and AE invocation-identifiers (see General and Option Data Types and Structures for more details).

This local addr field is used, depending on the XTI primitive, as the calling, called or responding address, the called address being different from the responding address only when two different file descriptors (fd, resfd), bound to different addresses, are used.

t_close()
Any connections that are still active at the endpoint are abnormally terminated. The peer applications will be informed of the disconnection by a [T_DISCONNECT] event. The value of the disconnection reason will be T_AC_ABRT_NSPEC.

t_connect()
The sndcall->addr structure specifies the Called Presentation Address. The rcvcall->addr structure specifies the Responding Presentation Address. The structure may also be used to assign values for the Called AP Title, Called AE Qualifier, Called AP invocation-identifier and Called AE invocation-identifier.

Before the call, the sndcall->opt structure may be used to request an Application Context name or Presentation Context different from the default value.

t_error()
No special considerations for mOSI providers.

t_free()
No special considerations for mOSI providers.

t_getinfo()
The information supported by t_getinfo() reflects the characteristics of the transport connection, or if no connection is established, the default characteristics of the underlying OSI layers. In all possible states except T_DATAXFER, the function t_getinfo() returns in the parameter info the same information as was returned by t_open(). In state T_DATAXFER, however, the information returned in info->connect and info->discon may differ.
The parameters of the t_getinfo() function are summarised in the table below.

Parameters Before call After call
    _
    Connection-mode Connectionless-mode
fd x / /
info->addr / x x
info->options / x x
info->tsdu / T_INFINITE (-1) T_INFINITE (-1)
info->etsdu / (T_INVALID (-2) T_INVALID (-2)
info->connect / x T_INVALID (-2)
info->discon / x T_INVALID (-2)
info->servtype / T_COTS_ORD T_CLTS
info->flags / 0 0

x equals an integral number greater than 0.

The values of the parameters in the t_info structure for the t_getinfo() function reflect the mOSI provider particularities.

t_getprotaddr()
The protocol addresses are naming and addressing parameters as defined in General and Option Data Types and Structures.

t_getstate()
No special considerations for mOSI providers.

t_listen()
The call->addr structure contains the remote Calling Presentation Address and the remote Calling AP Title, AE Qualifier, and AP and AE invocation identifiers if received.

Incoming user data encoded as multiple presentation data values will cause the TBADDATA error to be returned.

t_look()
Since expedited data is not supported for a mOSI provider, T_EXDATA and T_GOEXDATA events cannot occur.

t_open()
t_open() is called as the first step in the initialisation of a transport endpoint. This function returns various default characteristics of the underlying OSI layers.
The parameters of the t_open() function are summarised in the table below.

Parameters Before call After call
    _
    Connection-mode Connectionless-mode
name x / /
oflag   / /
info->addr / x x
info->options / x x
info->tsdu / T_INFINITE (-1) T_INFINITE (-1)
info->etsdu / T_INVALID (-2) T_INVALID (-2)
info->connect / x T_INVALID (-2)
info->discon / x T_INVALID (-2)
info->servtype / T_COTS_ORD T_CLTS
info->flags / 0 0

x equals an integral number greater than 0.

The values of the parameters in the t_info structure reflect mOSI limitations as follows:

Note:
The name (device file) parameter passed to t_open() will differ when the application accesses an mOSI provider or an ISO Transport provider.

t_optmgt()
The options available with mOSI providers are described in section Options.

t_rcv()
The flags parameter will never be set to [T_EXPEDITED], as expedited data transfer is not supported.

t_rcvconnect()
The call->addr structure specifies the remote Responding Presentation Address, and the remote responding AP Title, AE Qualifier, and AP and AE invocation identifiers if received.

The call->opt structure may also contain an Application Context Name and/or Presentation Context Definition Result List.

t_rcvdis()
Possible values for disconnection reason codes are specified in Option Data Types and Structures.

t_rcvrel()
With this primitive, user data cannot be received on normal release: any user data in the received flow is discarded (see t_rcvreldata).

t_rcvudata()
The unitdata->addr structure specifies the remote Presentation address, and optionally the remote AP Title, AE Qualifier, AP and AE invocation-identifiers. If the T_MORE flag is set, an additional t_rcvudata() call is needed to retrieve the entire A-UNIT-DATA service unit. Only normal data is returned via the t_rcvudata() call.

t_rcvuderr()
This function is not supported by a mOSI provider since badly formed A-UNIT-DATA APDUs are discarded.

t_snd()
Zero-length TSDUs are not supported.

Since expedited data transfer is not supported for a mOSI provider, the parameter flags shall not have [T_EXPEDITED] set.

t_snddis()
No special considerations for mOSI providers.

t_sndrel()
With this primitive, user data cannot be sent on normal release (see t_sndreldata).

t_sndudata()
The unitdata->addr structure specifies the remote Presentation address, and optionally the remote AP Title, AE Qualifier, AP and AE invocation-identifiers. Only normal data is sent via the t_sndudata() call.

t_strerror()
No special considerations for mOSI providers.

t_sync()
No special considerations for mOSI providers.

t_unbind()
No special considerations for mOSI providers.

Implementors' Notes

Upper Layers FUs, Versions and Protocol Mechanisms

The implementation negotiates:

Session:
Kernel, Full Duplex, version 2, or version 1 if version 2 not supported, no segmentation.

Other session protocol mechanisms are out of scope, except Basic Concatenation which is mandatory and transparent to the application.

Presentation:
Kernel, Normal Mode

ACSE:
Kernel

If invalid (non-negotiable) options are requested by the peer and detected by the provider once the association is already established (such as the ACSE presentation context missing in the Defined Context Set), the association is rejected via an A-(P)-ABORT generated by the implementation.

Mandatory and Optional Parameters

Mapping XTI Functions to ACSE/Presentation Services

In the following tables, the definition of which parameters are mandatory and which are optional can be found in ISO/IEC DISP 11183 - Common Upper Layers Requirements, part 3 (see reference CULR).
Connection-mode Services
Association Establishment (successful, unsuccessful)
Note:
XTI does not support the concept of a negative association establishment; that is, the equivalent of a negative A-ASSOCIATE response. That is, an XTI-mOSI implementation does not generate an AARE- APDU.

To reject an association request, the responding application issues t_snddis(), which is mapped to a A-ABORT.

However, a negative A-ASSOCIATE confirm (AARE- APDU) may be received from a non-XTI OSI peer. The negative A-ASSOCIATE confirm event is mapped to t_rcvdis().


Table: Association Establishment

XTI call Parameter Service Parameter
t_connect   A-ASSOCIATE req  
  sndcall->addr   Called Presentation Address
  sndcall->addr (1)   Called AP Title
  sndcall->addr (1)   Called AE Qualifier
  sndcall->addr   Called AP invocation-identifier
  sndcall->addr   Called AE invocation-identifier
  sndcall->opt (2)   Application Context Name
  sndcall->opt (3)   P-context Definition and Result List
  sndcall->udata   User Information
{t_bind} req|ret->addr   Calling Presentation Address
{t_bind} req|ret->addr   Calling AP Title
{t_bind} req|ret->addr   Calling AE Qualifier
       
t_listen   A-ASSOCIATE ind  
  call->addr   Calling Presentation Address
  call->addr (1)   Calling AP Title
  call->addr (1)   Calling AE Qualifier
  call->opt   Application Context Name
  call->opt (4)   P-context Definition and Result List
  call->udata   User Information
{t_bind} req|ret->addr   Called Presentation Address
{t_bind} req|ret->addr (1)   Called AP Title
{t_bind} req|ret->addr (1)   Called AE Qualifier
{t_bind} req|ret->addr   Calling AP invocation-identifier
{t_bind} req|ret->addr   Calling AE invocation-identifier
       
t_accept   A-ASSOCIATE rsp+  
  call->addr   not used: Calling Presentation Address
  call->opt   Application Context Name
  call->opt   P-context Definition and Result List
  call->udata   User Information
{internal} ::="accepted"   Result
{t_bind} req|ret->addr   Responding Presentation Address
{t_bind} req|ret->addr (1)   Responding AP Title
{t_bind} req|ret->addr (1)   Responding AE Qualifier
{t_bind} req|ret->addr   Responding AP invocation-identifier
{t_bind} req|ret->addr   Responding AE invocation-identifier
       
not sent   A-ASSOCIATE rsp-  
       
t_connect (synchronous mode) A-ASSOCIATE cnf+  
  rcvcall->addr   Responding Presentation Address
  rcvcall->addr   Responding AP Title
  rcvcall->addr   Responding AE Qualifier
  rcvcall->addr   Responding AP invocation-identifier
  rcvcall->addr   Responding AE invocation-identifier
  rcvcall->opt   Application Context Name
  rcvcall->opt   P-context Definition and Result List
  rcvcall->udata   User Information
{internal} ::="accepted"   Result
{internal} ::="ACSE service-user"   Result Source
       
t_rcvconnect (asynchronous mode) A-ASSOCIATE cnf+  
  call->addr   Responding Presentation Address
  call->addr   Responding AP Title
  call->addr   Responding AE Qualifier
  call->addr   Responding AP invocation-identifier
  call->addr   Responding AE invocation-identifier
  call->opt   Application Context Name
  call->opt   P-context Definition and Result List
  call->udata   User Information
{discarded} ::="accepted"   Result
{discarded} ::="ACSE service-user"   Result Source-diagnostic
       
t_rcvdis   A-ASSOCIATE cnf-  
  discon->udata   User Information
  discon->reason (5)   Result
{internal} ACSE serv-user|pres serv-prov   Result Source-diagnostic
  {discarded}   Application Context Name
  {discarded}   P-context Definition and Result List

Notes:

  1. if either the AP title or AE qualifier is selected for sending, the other must be selected.

  2. sndcall->opt or, if no option specified, default value

  3. sndcall->opt or, if no option specified, default value, with ACSE added by provider

  4. call->opt with ACSE context removed from the list passed to user

  5. combines Result and Result Source-diagnostic

Data Transfer

XTI call Parameter Service Parameter
t_snd   P-DATA req  
  buf   User Data
       
t_rcv   P-DATA ind  
  buf   User Data

Table: Data Transfer

Association Release (orderly, abortive)

This table makes the assumption that the XTI-mOSI provider supports the orderly release facility with user data ( t_sndreldata() - see t_rcvreldata, and t_rcvreldata() - see t_rcvreldata). When this is not the case, User Information is not sent, Reason is supplied via an internal mechanism with A-RELEASE request and response, User Information and Reason received in A-RELEASE indication and confirmation are discarded.

XTI call Parameter Service Parameter
t_sndrel2   A-RELEASE req  
  reldata->reason   Reason
  reldata->udata   User Information
       
t_rcvreldata   A-RELEASE ind  
  reldata->reason   Reason
  reldata->udata   User Information
       
t_sndrel2   A-RELEASE rsp  
  reldata->reason   Reason
  reldata->udata   User Information
       
t_rcvreldata   A-RELEASE cnf  
  reldata->reason   Reason
  reldata->udata   User Information
       
t_snddis   A-ABORT req  
  n/s   Diagnostic
  call->udata   User Information
       
t_rcvdis   A-ABORT ind  
  discon->reason   Diagnostic
  discon->udata   User Information
       
t_rcvdis   A-P-ABORT ind  
  discon->reason   Diagnostic

Table: Association Release

Connectionless-mode Services

XTI call Parameter Service Parameter
t_sndudata   A-UNIT-DATA source  
  unitdata->addr   Called Presentation Address
  unitdata->addr   Called AP Title
  unitdata->addr   Called AE Qualifier
  unitdata->addr   Called AP invocation-identifier
  unitdata->addr   Called AE invocation-identifier
  unitdata->opt (1)   Application Context Name
  unitdata->opt (2)   P-context Definition and Result List
  unitdata->udata   User Information
{t_bind} req|ret->addr   Calling Presentation Address
{t_bind} req|ret->addr   Calling AP Title
{t_bind} req|ret->addr   Calling AE Qualifier
{t_bind} req|ret->addr   Calling AP invocation-identifier
{t_bind} req|ret->addr   Calling AE invocation-identifier
       
t_rcvudata   A-UNIT-DATA sink  
  unitdata->addr   Calling Presentation Address
  unitdata->addr   Calling AP Title
  unitdata->addr   Calling AE Qualifier
  unitdata->addr   Calling AP invocation-identifier
  unitdata->addr   Calling AE invocation-identifier
  unitdata->opt   Application Context Name
  unitdata->opt (3)   P-context Definition and Result List
  unitdata->udata   User Information
{t_bind} req|ret->addr   Called Presentation Address
{t_bind} req|ret->addr   Called AP Title
{t_bind} req|ret->addr   Called AE Qualifier
{t_bind} req|ret->addr   Called AP invocation-identifier
{t_bind} req|ret->addr   Called AE invocation-identifier

Table: Connectionless-mode ACSE Service
Notes:

  1. unitdata->opt or, if no option specified, default value

  2. unitdata->opt or, if no option specified, default value, with ACSE added by provider

  3. unitdata->opt with ACSE context removed from the list passed to user

Option Data Types and Structures

SPECIFIC ISO ACSE/PRESENTATION OPTIONS
Naming and Addressing Datatype
The buf[] part of the addr structure is an mosiaddr structure defined in the following way:

struct t_mosiaddr { t_uscalar_t flags; t_scalar_t osi_ap_inv_id; t_scalar_t osi_ae_inv_id; unsigned int osi_apt_len; unsigned int osi_aeq_len; unsigned int osi_paddr_len; unsigned char osi_addr[T_AP_MAX_ADDR]; };

where:

The application is responsible for encoding/decoding the AP title and AE qualifier; alternatively, a lookup routine may be provided (outside the scope of this specification).

ACSE/Presentation Option Levels and Names

#define T_ISO_APCO      0x0200
#define T_ISO_APCL      0x0300
#define T_AP_CNTX_NAME  0x1
#define T_AP_PCL        0x2


Object Identifier Representation within Options
The application context, abstract syntax and transfer syntax all utilise object identifiers. An object identifier is held in the BER encoded form as a variable length item, whose length can be inferred from the length of the option, as in the following macro:

#define T_OPT_VALEN(opt) (opt->len - sizeof(struct t_opthdr)).

The application is responsible for encoding/decoding the object identifier value. Alternatively, a lookup routine may be provided (outside the scope of this specification).

Application Context Name Option
The application context name option consists of an object identifier item as defined above.
Presentation Context Definition and Result List Option
The Presentation Context Definition and Result List option is used to propose a presentation context, giving its abstract and transfer syntax, and to hold the result of negotiation of a presentation context.

The presentation context definition and result list option is a variable sized option consisting of a t_scalar_t giving the number of presentation contexts followed by an array of that number of presentation context item offset elements. Each element is defined as:


struct t_ap_pco_el { t_scalar_t count; t_scalar_t offset; }

Each presentation context items offset element gives: the count of syntax entries in the presentation context item (including the abstract syntax entry) and the offset of the presentation context item from the beginning of the Presentation Context Definition and Result List option value.

Each presentation context item consists of a header followed by an array.

The header is defined as:


struct t_ap_pc_item { t_scalar_t pci; t_scalar_t res; }

where pci is a unique odd integer (if this is zero in the sndcall argument of t_connect(), the provider will substitute an appropriate value), and res is the result of negotiation. The array of syntax offset elements immediately follows the header. Each element is defined as:


struct t_ap_syn_off { t_scalar_t size; t_scalar_t offset; }

where size is the length of the syntax object identifier contents, and offset is the offset of the object identifier for the syntax from the beginning of the Presentation Context Definition and Result List option value.

The first element in the array of syntax offset elements refers to the abstract syntax the second to the first transfer syntax, and so on.

The following values are used in the res field of a presentation context item:


#define T_PCL_ACCEPT 0x0000 /*pres. context accepted */ #define T_PCL_USER_REJ 0x0100 /*pres. context rejected by peer application */ #define T_PCL_PREJ_RSN_NSPEC 0x0200 /*prov. reject: no reason specified */ #define T_PCL_PREJ_A_SYTX_NSUP 0x0201 /*prov. reject: abstract syntax not supported*/ #define T_PCL_PREJ_T_SYTX_NSUP 0x0202 /*prov. reject:transfer syntax not supported */ #define T_PCL_PREJ_LMT_DCS_EXCEED 0x0203 /*prov. reject: local limit on DCS exceeded */

For the default abstract syntax, transfer syntax and application context, this Appendix uses object identifiers which are specified in the profile (ISO/IEC pDISP 11188 - Common Upper Layer Requirements (CULR), Part 3: Minimal OSI upper layer facilities - OIW/EWOS working document). Thus the descriptions provided in this Appendix are informative only.

Default Abstract Syntax for mOSI

The following OBJECT IDENTIFIER have been defined in CULR part 3:


{iso(1) standard(0) curl(11188) mosi(3) default-abstract-syntax(1) version(1)}

This object identifier can be used as the abstract syntax when the application protocol (above ACSE) can be treated as single presentation data values (PDVs). Each PDV is a sequence of consecutive octets without regard for semantic or other boundaries. The object identifier may also be used when, for pragmatic reasons, the actual abstract syntax of the application is not identified in Presentation Layer negotiation.

Notes:

  1. Applications specified using ASN.1 should not use the default abstract syntax.

  2. As this object identifier is used by all applications using the default abstract syntax for mOSI, it cannot be used to differentiate between applications. One of the ACSE parameters; for example, AE Title or Presentation address, may be used to differentiate between applications.

Default Transfer Syntax for mOSI

If the default transfer syntax and the abstract syntax are identical, the OBJECT IDENTIFIER for the default abstract syntax is used. If they are not identical, the OBJECT identifier for the default transfer syntax is:


{iso(1) standard(0) curl(11188) mosi(3) default-transfer-syntax(2) version(1)}
Note:
In the presentation data value of the PDV list of Presentation Protocol or in the encoding of User Information of ACSE Protocol, only octet-aligned or arbitrary can be used for default transfer syntax for mOSI. Single-ASN1-type cannot be used for default transfer syntax for mOSI.
Default Application Context for mOSI

The following OBJECT IDENTIFIER has been defined in Common Upper Layer Requirements (CULR) part 3:


{iso(1) standard(0) curl(11188) mosi(3) default-application-context(3) version(1)}

This application context supports the execution of any application using the default abstract syntax for mOSI.

Reason Codes for Disconnections

#define T_AC_U_AARE__NONE  0x0001     /* connection rejected by      */
                                      /* peer user: no reason given  */
#define T_AC_U_AARE_ACN    0x0002     /* connection rejected:        */
                                      /* application context name    */
                                      /* not supported               */
#define T_AC_U_AARE_APT    0x0003     /* connection rejected:        */
                                      /* AP title not recognised     */
#define T_AC_U_AARE_AEQ    0x0005     /* connection rejected:        */
                                      /* AE qualifier not recognised */
#define T_AC_U_AARE_PEER_AUTH 0x000e  /* connection rejected:        */
                                      /* authentication required     */
#define T_AC_P_ABRT_NSPEC  0x0011     /* aborted by peer provider:   */
                                      /* no reason given             */
#define T_AC_P_AARE_VERSION 0x0012    /* connection rejected:        */
                                      /* no common version           */


Other reason codes may be specified as implementation defined constants. In order to be portable, an application should not interpret such information, which should only be used for troubleshooting purposes.

<xti_mosi.h> Header File

This section presents the additional header file information for XTI-mOSI.

Implementations supporting XTI-mOSI will provide equivalent definitions in <xti_mosi.h>. XTI-mOSI programs should include <xti_mosi.h> as well as <xti.h>.


/* mosi address structure */

struct t_mosiaddr {
    t_uscalar_t     flags;
    t_scalar_t      osi_ap_inv_id;
    t_scalar_t      osi_ae_inv_id;
    unsigned int    osi_apt_len;
    unsigned int    osi_aeq_len;
    unsigned int    osi_paddr_len;
    unsigned char   osi_addr[MAX_ADDR];
};

#define T_ISO_APCO      0x0200
#define T_ISO_APCL      0x0300
#define T_AP_CNTX_NAME  0x1
#define T_AP_PCL        0x2

#define T_OPT_VALEN(opt) (opt->len - sizeof(struct t_opthdr)).

/* presentation context definition and result list option */

struct t_ap_pco_el {
    t_scalar_t count;
    t_scalar_t offset;
}

/* presentation context item header */

struct t_ap_pc_item {
    t_scalar_t pci;      /* unique odd integer    */
    t_scalar_t res;      /* result of negotiation */
}
 
/* presentation context item element */

struct t_ap_syn_off {
    t_scalar_t size;   /* length of syntax object identifier contents */
    t_scalar_t offset; /* offset of object identifier for the syntax  */
}

/* values for res of a presentation context item */

#define T_PCL_ACCEPT              0x0000 /* pres. context accepted */
#define T_PCL_USER_REJ            0x0100 /* pres. context rejected */
                                         /* by peer application    */
#define T_PCL_PREJ_RSN_NSPEC      0x0200 /* prov. reject:          */
                                         /* no reason specified    */
#define T_PCL_PREJ_A_SYTX_NSUP    0x0201 /* prov. reject: abstract */
                                         /* syntax not supported   */
#define T_PCL_PREJ_T_SYTX_NSUP    0x0202 /* prov. reject: transfer */
                                         /* syntax not supported   */

#define T_PCL_PREJ_LMT_DCS_EXCEED 0x0203 /* prov. reject: local */ /* limit on DCS exceeded */ /* Reason Codes for Disconnections */ #define T_AC_U_AARE__NONE 0x0001 /*connection rejected by */ /*peer user: no reason given */ #define T_AT_C_U_AARE_ACN 0x0002 /*connection rejected: */ /*application context name */ /*not supported */ #define T_AC_U_AARE_APT 0x0003 /*connection rejected: */ /*AP title not recognised */ #define T_AC_U_AARE_AEQ 0x0005 /*connection rejected: */ /*AE qualifier not recognised */ #define T_AC_U_AARE_PEER_AUTH 0x000e /*connection rejected: */ /*authentication required */ #define T_AC_P_ABRT_NSPEC 0x0011 /*aborted by peer provider: */ /*no reason given */ #define T_AC_P_AARE_VERSION 0x0012 /*connection rejected: */ /*no common version */

Contents Next section Index