next up previous contents
Next: ESRO SERVICE NOTATION Up: Informational RFC-2188 Banan, et Previous: INTRODUCTION   Contents

Subsections


ESRO SERVICE DEFINITIONS

ESRO service primitives are illustrated in Figure 2, Table 1 and Table 2. The description of services and primitives comes in the following sections.

Figure 2: Time sequence diagram for ESRO services
\begin{figure}\begin{verbatim}Invoker Performer
ESRO SAP ESRO SAP
\vert \ve...
...<-----------\vert \vert-------->---------
\vert \vert\end{verbatim}\end{figure}

ESROS-User accesses ESRO services through Efficient Short Remote Operations Service Access Point (ESRO-SAP) as shown in Figure 2.


Table 1: ESRO Services
\begin{table}\begin{verbatim}_____________________________________________
\...
...t ________________\vert __________________________\vert\end{verbatim}\end{table}



Table 2: ESRO service primitives and associated parameters
\begin{table}\begin{verbatim}________________________________________________...
..._____________\vert _______________________________\vert\end{verbatim}\end{table}


The RESULT.request, ERROR.request and FAILURE.indication service primitives can be implemented in two different modes:

  1. Acknowledged Result, and

  2. Non-Acknowledged Result

as described below. The difference between different modes is in their reliability of service and efficiency. Reliability of service is defined based on the understanding of invoker and performer about the success or failure of the operation on the peer side. Table 3 and Table 4 summarize understanding of performer about success or failure on invoker side in different situations. In these tables the FAILURE.indication refers to the primitive generated by protocol and not the failure of local provider.

Acknowledged Result Service Mode

In this service mode, the result is acknowledged by invoker, but the mechanism by which the acknowledgment is accomplished may not be reliable. Table 3 summarizes the relationship between performer and invoker in success and failure cases.


Table 3: Success and Failure in Acknowledged Result Mode
\begin{table}\begin{verbatim}_________________________________________________...
...\vert ___________________\vert ___________________\vert\end{verbatim}\end{table}


Performer side

In this type of service, the RESULT.confirm and ERROR.confirm primitives on performer side are generated if the result/error is acknowledged by invoker.

The FAILURE.indication on performer side is generated if result/error is not acknowledged by invoker or if there is a local failure on performer side.

From the protocol point of view, the FAILURE.indication might be because either the result/error PDU or the ack PDU is lost. The outcome of this is that a FAILURE.indication is not robust as the operation may have been successful from the invoker's perspective. One method of compensating for this shortcoming is having the performer verify the FAILURE.indication in a separate operation.

Invoker side

When invoker receives failure indication, the performer has the failure indication too.

This type of service can be implemented by protocols based on 3-Way handshaking.

Non-acknowledged Result

In this service mode the result is not acknowledged. Table 4 summarizes the relationship between performer and invoker in success and failure cases.


Table 4: Success and Failure in Non-acknowledged Result Mode
\begin{table}\begin{verbatim}_________________________________________________...
...vert ____________________\vert ___________________\vert\end{verbatim}\end{table}


Performer side

In this type of service, the RESULT.confirm and ERROR.confirm primitives on performer side are generated without receiving additional information from the invoker peer. In other words, these Primitives have no protocol-related meaning and convey no information, other than end-of-operation.

The FAILURE.indication on performer side is not generated by protocol. The only case that can generate FAILURE.indication on performer side is local failure in service provider on performer side.

Invoker side

The FAILURE.indication on invoker side can be the resultof not receiving result/error/failure from peer performer or it can result from failure in local service provider.

This type of service can be implemented by protocols based on 2-Way handshaking.

Serialized Use of ESRO Services

Although the ESRO Services are defined to support asynchronous operation invocation in general, they can be used in the special case of synchronous (serialized) mode too. The serialized use of ESRO Services is implementation specific. However, one of the possible scenarios is as follows:

Invoker

Invokes an operation after it receives either RESULT.indication, ERROR.indication, or FAILURE.indication for the previous operation.

Performer

Considers an operation to be complete and accepts the next operation after it receives RESULT.confirm, ERROR.confirm, or FAILURE.indication.

ESROS-INVOKE Service

The ESROS-INVOKE service is used by an ESROS-User (the invoker) to cause the invocation of an OPERATION to be performed by the other ESROS-User (the performer).

ESROS Invoker User issues ESROS-INVOKE.request primitive to invoke an operation.

ESROS-INVOKE.indication primitive provides the ESROS Performer User with the parameters of the invoked operation.

ESRO Service Provider issues the ESROS-INVOKE-P.confirm primitive to provide the ESROS Invoker User with Invoke-ID of the invoked operation.

The related service structure consists of three service primitives as illustrated in Figure 3 and Table 5.

Figure 3: Time sequence diagram for ESROS-INVOKE service
\begin{figure}\begin{verbatim}Invoker Performer
ESROS AP ESROS AP
\vert \ve...
...ert \vert
--------<-----------\vert \vert
\vert \vert\end{verbatim}\end{figure}


Table 5: ESROS-INVOKE service primitives and associated parameters
\begin{table}\begin{verbatim}________________________________________________...
...___________\vert _________________________________\vert\end{verbatim}\end{table}


Operation-value

This value is the identifier of the operation to be invoked. The value is agreed upon between the ESROS Users. This parameter has to be supplied by the invoker of the service.

ESROS Invoker User provides the Operation-value parameter for the ESROS-INVOKE.request primitive. The Operation-value parameter of ESROS-INVOKE.indication is provided to the ESROS Performer User.

Performer-address

This parameter is the address of the ESROS Performer User which consists of ESRO Service Access Point (SAP) Selector, Transport Service Access Point (TSAP) Selector (e.g., port number), and Network Service Access Point (NSAP) address (e.g., IP address). This parameter has to be supplied by the invoker of the service.

ESROS Invoker User provides the Performer-address parameter for the ESROS-INVOKE.request primitive.

Invoker-address

This parameter is the address of the ESROS Invoker User which consists of ESRO Service Access Point (SAP) Selector, Transport Service Access Point (TSAP) Selector (e.g. port number), and Network Service Access Point (NSAP) address (e.g. IP address).

The Invoker-address parameter of ESROS-INVOKE.indication is provided to the ESROS Performer User.

Invoke-argument-encoding-type

This parameter identifies the encoding type of the Invoke-argument (see next subsection). The encoding type has to be agreed upon between ESROS Users. This parameter has to be supplied by the invoker of the service.

ESROS Invoker User provides the Invoke-argument-encoding-type parameter for the ESROS-INVOKE.request primitive. The Invoke-argument-encoding-type parameter of ESROS-INVOKE.indication is provided to the ESROS Performer User.

Invoke-argument

This parameter is the argument of the invoked operation. The type has to be agreed between the ESROS Users. This parameter has to be supplied by the invoker of the service. Encoding type of the Invoke-argument is specified through the Invoke-argument-encoding-type parameter (see previous subsection).

ESROS Invoker User provides the Invoke-argument parameter for the ESROS-INVOKE.request primitive. The Invoke-argument parameter of ESROS-INVOKE.indication is provided to the ESROS Performer User.

Invoke-ID

This parameter identifies the invocation of an ESROS-INVOKE service and is used to correlate this invocation with the corresponding replies (ESROS-RESULT, ESROS-ERROR, and ESROS-FAILURE services.) This parameter has to be supplied by the ESROS provider.

This parameter distinguishes several invocations of the service in progress (asynchronous operations). The ESROS provider may begin to reuse Invoke-ID values whenever it chooses, subject to the constraint that it may not reuse an Invoke-ID value that was previously assigned to an invocation of the service for which it expects, but has not yet received a reply. In other words, the provider does not reuse a previously used Invoke-ID unless the corresponding service is fully completed.

Failure-value

This parameter identifies the failure that occurred during the processing or transmission of any of the service primitives of ESROS. This parameter has to be supplied by the ESROS provider (see also Section 2.7).

ESROS-RESULT Service

The ESROS-RESULT service is used by an ESROS User to reply to a previous ESROS-INVOKE.indication in the case of a successfully performed operation. This service is either confirmed or non-confirmed based on the service mode (see Section 2).

The related service structure consists of three service primitives as illustrated in Figure 4 and Table 6.

Figure 4: Time sequence diagram for ESROS-RESULT service
\begin{figure}\begin{verbatim}Invoker Performer
ESROS AP ESROS AP
\vert \ve...
...ILURE.ind.
\vert \vert-------->---------
\vert \vert\end{verbatim}\end{figure}


Table 6: ESROS-RESULT service primitives and associated parameters
\begin{table}\begin{verbatim}_________________________________________________...
...___________\vert _________________________________\vert\end{verbatim}\end{table}


Result-argument-encoding-type

This parameter identifies the encoding type of the Result-argument (see next subsection). The encoding type has to be agreed upon between the ESROS Users. This parameter has to be supplied by the ESROS Performer User.

ESROS Performer User provides the Result-argument-encoding-type parameter for the ESROS-RESULT.request primitive. The Result-argument-encoding-type parameter of ESROS-RESULT.indication is provided to the ESROS Invoker User.

Result-argument

This parameter is the result of an invoked and successfully performed operation. The type has to be agreed between the ESROS Users. This parameter has to be supplied by the invoker of the service. Encoding type of the Result-argument is specified through the Result-argument-encoding-type parameter (see previous subsection).

ESROS Performer User provides the Result-argument parameter for the ESROS-RESULT.request primitive. The Result-argument parameter of ESROS-RESULT.indication is provided to the ESROS Invoker User.

Invoke-ID

This parameter identifies the corresponding invocation. This Invoke-ID, which is originally generated by the ESROS provider at the time of ESROS-INVOKE indication, is extracted from the Invoke ID that has to be supplied by the ESROS performer User. The value is that of the corresponding ESROS-INVOKE.indication primitive.

Failure-value

This parameter identifies the failure that occurred during the processing or transmission of any of the service primitives of ESROS. This parameter has to be supplied by the ESROS provider (see also Section 2.7).

ESROS-ERROR Service

The ESROS-ERROR service is used by an ESROS User to reply to a previous ESROS-INVOKE.indication in the case of an unsuccessfully performed operation. This service is either confirmed or non-confirmed based on the service mode (see Section 2).

The related service structure consists of three service primitives as illustrated in Figure 5 and Table 7.

Figure 5: Time sequence diagram for ESROS-ERROR service
\begin{figure}\begin{verbatim}Invoker Performer
ESROS AP ESROS AP
\vert \ve...
...vert ESROS-FAILURE.ind.
\vert \vert-------->---------\end{verbatim}\end{figure}


Table 7: ESROS-ERROR service primitives and associated parameters
\begin{table}\begin{verbatim}________________________________________________...
...________________\vert ____________________________\vert\end{verbatim}\end{table}


Error-value

This parameter identifies the error in reply to a previous ESROS-INVOKE.indication in the case of an unsuccessfully performed operation. The value has to be agreed between the ESROS-Users. This parameter has to be supplied by the ESROS Performer User.

ESROS Performer User provides the Error-argument parameter for the ESROS-ERROR.request primitive. The Error-argument parameter of ESROS-ERROR.indication is provided to the ESROS Invoker User.

Error-argument-encoding-type

This parameter identifies the encoding type of the Error-argument (see next subsection). The encoding type has to be agreed upon between the ESROS Users. This parameter has to be supplied by the ESROS Performer User.

ESROS Performer User provides the Error-argument-encoding-type parameter for the ESROS-ERROR.request primitive. The Error-argument-encoding-type parameter of ESROS-ERROR.indication is provided to the ESROS Invoker User.

Error-argument

This parameter provides additional information about the error in reply to a previous ESROS-INVOKE.indication in the case of an unsuccessfully performed operation. The type (if any) has to be agreed between the ESROS users. This parameter has to be supplied by the ESROS Performer User. Encoding type of the Error-argument is specified through the Error-argument-encoding-type parameter (see previous subsection).

ESROS Performer User provides the Error-argument parameter for the ESROS-ERROR.request primitive. The Error-argument parameter of ESROS-ERROR.indication is provided to the ESROS Invoker User.

Invoke-ID

This parameter identifies the corresponding invocation. This Invoke-ID, which is originally generated by the ESROS provider at the time of the ESROS-INVOKE.indication, is extracted from the Invoke ID which has to be supplied by the ESROS performer User. The value is that of the corresponding ESROS-INVOKE.indication primitive.

Failure-value

This parameter identifies the failure that occurred during the processing or transmission of any of the service primitives of ESROS. This parameter has to be supplied by the ESROS provider (see also Section 2.7).


ESROS-FAILURE Service

The ESROS-FAILURE service is used by ESROS provider to indicate the failure in providing an ESROS-INVOKE, ESROS-RESULT, or ESROS-ERROR service.

The related service structure consists of one service primitive as illustrated in Figure 6 and Table 8.

Figure 6: Time sequence diagram for ESROS-FAILURE service
\begin{figure}\begin{verbatim}Invoker Performer
ESROS AP ESROS AP
\vert \ve...
...LURE.ind.
\vert \vert--------->---------
\vert \vert\end{verbatim}\end{figure}


Table 8: ESROS-FAILURE service primitives and associated parameters
\begin{table}\begin{verbatim}_____________________________________________
\...
... __________________________\vert _________________\vert\end{verbatim}\end{table}


Failure-value

This parameter identifies the failure that occurred during the processing or transmission of any of the service primitives of ESROS. This parameter has to be supplied by the ESROS provider.

The values for encoding of Failure-value are presented in Table 9.

Invoke-ID

This parameter identifies the corresponding invocation. This Invoke-ID, which is originally generated by ESROS provider at the time of the ESROS-INVOKE.indication, is extracted from the Invoke ID which has to be supplied by ESROS performer User. The value is that of the corresponding ESROS-INVOKE.indication primitive.


Table 9: Encoding of Failure-value
\begin{table}\begin{verbatim}_________________________________________
\vert...
...vert _______________\vert ________________________\vert\end{verbatim}\end{table}



next up previous contents
Next: ESRO SERVICE NOTATION Up: Informational RFC-2188 Banan, et Previous: INTRODUCTION   Contents