Request for Comments: 2188 Neda
Category: Informational M. Taylor
AWS
J. Cheng
AWS
September 1997
AT&T/Neda's Efficient Short Remote Operations (ESRO)
Protocol Specification Version 1.2
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
IESG Note
This protocol has not had the benefit of IETF Working Group review,
but a cursory examination reveals several issues which may be
significant issues for scalability. A site considering deployment
should conduct a careful analysis to ensure they understand the
potential impacts.
Abstract
This document specifies the service model, the notation and protocol
for Efficient Short Remote Operations (ESRO). The ESRO service is
similar to and is consistent with other Remote Procedure Call
services. The emphasis of ESRO service definition and the ESRO
protocol is on efficiency. ESRO is designed specifically with
wireless network (e.g., CDPD) usage in mind.
ESRO protocol provides reliable connectionless remote operation
services on top of UDP (or any other non-reliable connectionless
transport service) with minimum overhead. ESRO protocol supports
segmentation and reassembly, concatenation and separation as well as
multiplexing for service users (applications).
ESRO allows for trade-offs between efficiency and reliability by
specifying both 2-way hand-shake and 3-way hand-shake based protocols.
Encoding mechanisms for presentation of the parameters of remote
operations are outside the scope of this document. But,
identification (tagging) of the encoding mechanism in use (e.g., XDR,
BER, PER) is supported by ESRO protocol.
A variety of applications can use the ESRO protocol. Some early
applications using ESRO include efficient short message submission and
delivery, credit card authorization and white pages lookup.
Contents
1 INTRODUCTION 4
1.1 Relationship To Existing Remote Operation Services . 5
1.1.1 ESRO and RPC . . . . . . . . . 5
1.1.2 ESRO and ROSE . . . . . . . . . 5
1.2 Overview of ESROS . . . . . . . . . 5
1.3 The Remote Operation Model . . . . . . . 6
2 ESRO SERVICE DEFINITIONS 8
2.1 Acknowledged Result Service Mode . . . . . . 9
2.1.1 Performer side . . . . . . . . . 9
2.1.2 Invoker side . . . . . . . . . 11
2.2 Non-acknowledged Result . . . . . . . . 11
2.2.1 Performer side . . . . . . . . . 12
2.2.2 Invoker side . . . . . . . . . 12
2.3 Serialized Use of ESRO Services . . . . . . 12
2.3.1 Invoker . . . . . . . . . . 12
2.3.2 Performer . . . . . . . . . . 12
2.4 ESROS-INVOKE Service . . . . . . . . . 13
2.4.1 Operation-value . . . . . . . . 13
2.4.2 Performer-address . . . . . . . . 14
2.4.3 Invoker-address . . . . . . . . 14
2.4.4 Invoke-argument-encoding-type . . . . . 15
2.4.5 Invoke-argument . . . . . . . . 15
2.4.6 Invoke-ID . . . . . . . . . . 15
2.4.7 Failure-value . . . . . . . . . 16
2.5 ESROS-RESULT Service . . . . . . . . . 16
2.5.1 Result-argument-encoding-type . . . . . 16
2.5.2 Result-argument . . . . . . . . 17
2.5.3 Invoke-ID . . . . . . . . . . 17
2.5.4 Failure-value . . . . . . . . . 18
2.6 ESROS-ERROR Service . . . . . . . . . 18
2.6.1 Error-value . . . . . . . . . 18
2.6.2 Error-argument-encoding-type . . . . . 19
2.6.3 Error-argument . . . . . . . . . 19
2.6.4 Invoke-ID . . . . . . . . . . 20
2.6.5 Failure-value . . . . . . . . . 20
2.7 ESROS-FAILURE Service . . . . . . . . 20
2.7.1 Failure-value . . . . . . . . . 21
2.7.2 Invoke-ID . . . . . . . . . . 21
3 ESRO SERVICE NOTATION 21
3.1 ES-OPERATION Notation . . . . . . . . 22
3.2 Mapping of ESROS Notation . . . . . . . 22
3.2.1 Invocation of an Operation . . . . . . 22
3.2.2 Reply of an Operation . . . . . . . 22
4 REMOTE OPERATIONS PROTOCOL 23
4.1 Overview of the Protocol . . . . . . . . 23
4.1.1 Service Provision (Invoker User) . . . . 24
4.1.2 Service Provision (Performer User) . . . . 24
4.2 Protocol Procedures . . . . . . . . . 25
4.2.1 Service Access Point (SAP) Bind Procedure . . 25
4.2.2 Invoke Service Procedure . . . . . . 25
4.2.3 Invoke ID Assignment Procedure . . . . . 25
4.2.4 Functional Unit Selection Procedure . . . 26
4.3 Connectionless PDU Transfer For Small PDUs . . . 26
4.3.1 Overview . . . . . . . . . . 26
4.3.2 3-Way Handshake Functional Unit . . . . 28
4.3.3 2-Way Handshake Functional Unit . . . . 35
4.3.4 Segmentation and Reassembly . . . . . 40
4.4 Structure and Encoding of ESROS PDUs . . . . . 43
4.4.1 ESRO-INVOKE-PDU Format . . . . . . . 43
4.4.2 ESRO-RESULT-PDU Format . . . . . . . 45
4.4.3 ESRO-ERROR-PDU Format . . . . . . . 46
4.4.4 ESRO-ACK-PDU Format . . . . . . . 47
4.4.5 ESRO-FAILURE-PDU Format . . . . . . 47
4.4.6 ESRO-INVOKE-SEGMENTED-PDU Format . . . . 48
4.4.7 ESRO-RESULT-SEGMENTED-PDU Format . . . . 50
4.4.8 ESRO-ERROR-SEGMENTED-PDU Format . . . . 51
4.5 Concatenation and Separation . . . . . . . 52
4.5.1 Procedures . . . . . . . . . . 53
4.5.2 ESRO-CONCATENATED-PDU format . . . . . 53
4.6 ES Remote Operations Protocol Parameters . . . . 54
4.6.1 PDU size . . . . . . . . . . 54
4.6.2 Timers . . . . . . . . . . . 55
4.6.3 Use of lower layers . . . . . . . 56
5 ACKNOWLEDGMENTS . . . . . . . . . . . . 56
6 SECURITY CONSIDERATIONS . . . . . . . . . . 56
7 AUTHORS' ADDRESSES . . . . . . . . . . . 56
1 INTRODUCTION
Efficient Short Remote Operations (ESRO) provide an efficent
mechanism for realization of Remote Procedure Call. This document
specifies many aspects of ESRO including:
o Service Model
o Service Primitves
o A Notation for user of the Service
o Confirmed Connectionless Protocol (based on a 3-way hand-shake)
o Unconfirmed Connectionless Protocol (based on a 2-way hand-shake)
1.1 Relationship To Existing Remote Operation Services
The overall model of ESRO is similar to and consistent with many
existing protocols. ESRO's distinguishing characteristic is
efficiency.
A brief comparison of ESRO and Remote Procedure Calls [7] and Remote
Operation Service Elements [1] follows.
1.1.1 ESRO and RPC
Remote Procedure Call (RPC) is specified in [7] (RFC-1831) and [6]
(RFC-1833).
RPC specifications define a remote procedure model that is
essentially same as ESRO. RPC's notation uses a syntax quite
different from that of ESRO. RPC can rely on a connection oriented or
connectionless transport mechanism. When using the connectionless
mechanism, the retransmission and reliability issues are considered
beyond the scope of the RPC specification. RPC is usually used in
combination with External Data Representation, XDR [8] (RFC-1832).
1.1.2 ESRO and ROSE
ROSE is specified in [1] and [2]. The service definition for ESRO
Service (ESROS) specified in this document is similar ROSE's
Notation. The Notation specified in this document for ESROS is
similar ROSE's Notation. The ESRO protocol specified in this
document is very different from the ROSE protocol [2].
The operation model for ESRO Service (ESROS) is based on Remote
Operations Services Element (ROSE) in [1]. In ESROS model both
entities can invoke operations.
ESRO protocols can accomplish short operations with much less
overhead than ROSE.
1.2 Overview of ESROS
ESROS provides a service which supports interaction of applications
based on a remote operation model. A Remote Operation is invoked by
one entity; the other entity attempts to perform the Remote Operation
and then reports the outcome of the attempt. The ESROS protocol is
designed such that it could support many applications.
1.3 The Remote Operation Model
ESROS provides for performance of operations between two peer
sublayers. Users of the ESROS assume the roles of invoker and
performer which invoke and perform the operations respectively. An
ESROS-User can assume both roles and be an invoker for some
operations and be a performer for other operations. The performer is
expected to report either the result of the operation or an error. A
result reply is sent to the invoker if the operation is successful,
and an error reply is sent if the operation is unsuccessful. If the
performer is unreachable, the ESROS sends a failure indication
primitive to the invoker.
Operations are asynchronous and the invoker may continue to invoke
further operations without waiting for a reply. Synchronous or
serialized operations are also supported as a subset and a special
case of asynchronous service. By default the ESRO service provider
on both invoker and performer sides supports the asynchronous
operation invocation. However, if one side is to support only
serialized (synchronous) mode, it should be in agreement with the
peer side.
ESROS has no authentication mechanism. Authentication is the
responsibility of the performer (which is outside of the scope of
ESROS) and the performer is not expected to honor the invoker when it
is not authenticated.
The ESROS operation model is represented in Figure 1. In this
example, the ESROS User on the left is the Invoker and the ESROS User
on the right is the Performer. The Provider is the entity providing
a service to the layer above it.
ESROS ------------------- ------------------- ESROS
User | Layer above ESROS | | Layer above ESROS | User
(Invoker) | | | | (Performer)
------------------- -------------------
^ | | ^
| | | |
v | | v
ESROS ------------------- ------------------- ESROS
Provider | ESROS | | ESROS | Provider
------------------- -------------------
| |
| |
| |
------------------- -------------------
| UDP | | UDP |
------------------- -------------------
_ _/
_ _/
_ . _/
_ . .* . _/
. * .* .
* . *
Figure 1: ES Remote Operation Model
Invoker Performer
ESRO SAP ESRO SAP
| |
| |
ESROS-INVOKE.req. | | ESROS-INVOKE.ind.
-------->-----------| |-------->---------
| |
ESROS-INVOKE-P.conf.| |
--------<-----------| |
| |
| |
| |
ESROS-RESULT.ind. | | ESROS-RESULT.req.
--------<-----------| |--------<---------
| |
| | ESROS-RESULT.conf.
| |-------->---------
| |
| |
ESROS-ERROR.ind. | | ESROS-ERROR.req.
--------<-----------| |--------<---------
| |
| | ESROS-ERROR.conf.
| |-------->---------
| |
| |
| |
| |
ESROS-FAILURE.ind. | | ESROS-FAILURE.ind.
--------<-----------| |-------->---------
| |
Figure 2: Time sequence diagram for ESRO services
2 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.
ESROS-User accesses ESRO services through Efficient Short Remote
Operations Service Access Point (ESRO-SAP) as shown in Figure 2.
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
_____________________________________________
| ESRO Service |Type |
|________________|__________________________|
| ESROS-INVOKE |Non-confirmed |
| ESROS-INVOKE-P |Provider-initiated |
| ESROS-RESULT |Confirmed / Non-confirmed |
| ESROS-ERROR |Confirmed / Non-confirmed |
| ESROS-FAILURE |Provider initiated |
|________________|__________________________|
Table 1: ESRO Services
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.
2.1 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.
2.1.1 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.
____________________________________________________________
| Primitive |Parameters |
|--------------------------+-------------------------------|
| |Operation-value |
| |Performer-address |
| ESROS-INVOKE.request |Invoke-argument-encoding-type |
| |Invoke-argument |
|--------------------------+-------------------------------|
| |Operation-value |
| |Invoker-address |
| ESROS-INVOKE.indication |Invoke-argument-encoding-type |
| |Invoke-argument |
| |Invoke-ID |
|--------------------------+-------------------------------|
| ESROS-INVOKE-P.confirm |Invoke-ID |
|==========================================================|
| | |
| |Result-argument-encoding-type |
| ESROS-RESULT.request |Result-argument |
| |Invoke-ID |
|--------------------------+-------------------------------|
| |Result-argument-encoding-type |
| ESROS-RESULT.indication |Result-argument |
| |Invoke-ID |
|--------------------------+-------------------------------|
| ESROS-RESULT.confirm |Invoke-ID |
|==========================================================|
| | |
| |Error-value |
| |Error-argument-encoding-type |
| ESROS-ERROR.request |Error-argument |
|--------------------------+-------------------------------|
| |Error-value |
| |Error-argument-encoding-type |
| ESROS-ERROR.indication |Error-argument |
| |Invoke-ID |
|--------------------------+-------------------------------|
| ESROS-ERROR.confirm |Invoke-ID |
|==========================================================|
| | |
| |Failure-value |
| ESROS-FAILURE.indication |Invoke-ID |
|__________________________|_______________________________|
Table 2: ESRO service primitives and associated parameters
______________________________________________________________
|Service Mode |Performer |Invoker |
|--------------------+-------------------+-------------------|
|Acknowledged Result |RESULT.confirm |RESULT.indication |
| |-------------------+-------------------|
| |FAILURE.indication |RESULT.indication |
| | (protocol) | |
| |-------------------+-------------------|
| |FAILURE.indication |FAILURE.indication |
| | (protocol) | (protocol) |
|____________________|___________________|___________________|
Table 3: Success and Failure in Acknowledged Result Mode
__________________________________________________________________
|Service Mode |Performer |Invoker |
|------------------------+--------------------+-------------------|
|Non-acknowledged Result |RESULT.confirm |RESULT.indication |
| +--------------------+-------------------|
| |RESULT.confirm |FAILURE.indication |
| | | (protocol) |
| +--------------------+-------------------|
| |FAILURE.indication | |
| |(protocol) | |
| |does not |--- |
| |exist | |
|________________________|____________________|___________________|
Table 4: Success and Failure in Non-acknowledged Result Mode
2.1.2 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.
2.2 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.
2.2.1 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.
2.2.2 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.
2.3 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:
2.3.1 Invoker
Invokes an operation after it receives either RESULT.indication,
ERROR.indication, or FAILURE.indication for the previous operation.
2.3.2 Performer
Considers an operation to be complete and accepts the next operation
after it receives RESULT.confirm, ERROR.confirm, or
FAILURE.indication.
Invoker Performer
ESROS AP ESROS AP
| |
| |
ESROS-INVOKE.req. | | ESROS-INVOKE.ind.
-------->-----------| |-------->---------
| |
ESROS-INVOKE-P.conf.| |
--------<-----------| |
| |
ESROS-FAILURE.ind. | |
--------<-----------| |
| |
Figure 3: Time sequence diagram for ESROS-INVOKE service
2.4 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.
2.4.1 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.
_____________________________________________________________
| Primitive |Parameters |
|__________________________|_________________________________|
| |Operation-value |
| |Performer-address |
| ESROS-INVOKE.request |Invoke-argument-encoding-type |
| |Invoke-argument |
|__________________________|_________________________________|
| |Operation-value |
| |Invoker-address |
| |Invoke-argument-encoding-type |
| ESROS-INVOKE.indication |Invoke-argument |
| |Invoke-ID |
|__________________________|_________________________________|
| ESROS-INVOKE-P.confirm |Invoke-ID |
| |Failure-value |
|__________________________|_________________________________|
| ESROS-FAILURE.indication |Invoke-ID |
|__________________________|_________________________________|
Table 5: ESROS-INVOKE service primitives and associated parameters
2.4.2 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.
2.4.3 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.
2.4.4 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.
2.4.5 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.
2.4.6 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.
2.4.7 Failure-value
This parameter identifies the failure that occurred during the
processing or transmission of any of the service primitives of ESROS.
Invoker Performer
ESROS AP ESROS AP
| |
| |
ESROS-RESULT.ind. | | ESROS-RESULT.req.
--------<-----------| |--------<---------
| |
| | ESROS-RESULT.conf.
| |-------->---------
| |
| | ESROS-FAILURE.ind.
| |-------->---------
| |
Figure 4: Time sequence diagram for ESROS-RESULT service
This parameter has to be supplied by the ESROS provider (see also
Section 2.7).
2.5 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.
2.5.1 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.
______________________________________________________________
| Primitive |Parameters |
|__________________________|_________________________________|
| |Result-argument-encoding-type |
| |Result-argument |
| ESROS-RESULT.request |Invoke-ID |
|__________________________|_________________________________|
| | |
| |Result-argument-encoding-type |
| |Result-argument |
| ESROS-RESULT.indication |Invoke-ID |
|__________________________|_________________________________|
| | |
| ESROS-RESULT.confirm |Invoke-ID |
| |Failure-value |
| | |
|__________________________|_________________________________|
| ESROS-FAILURE.indication |Invoke-ID |
|__________________________|_________________________________|
Table 6: ESROS-RESULT service primitives and associated parameters
2.5.2 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.
2.5.3 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.
Invoker Performer
ESROS AP ESROS AP
| |
| |
ESROS-ERROR.ind. | | ESROS-ERROR.req.
--------<-----------| |--------<---------
| |
| | ESROS-ERROR.conf.
| |-------->---------
| |
| | ESROS-FAILURE.ind.
| |-------->---------
Figure 5: Time sequence diagram for ESROS-ERROR service
2.5.4 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).
2.6 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.
2.6.1 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.
________________________________________________________
| Primitive |Parameters |
|__________________________|____________________________|
| |Error-value |
| |Error-argument-encoding-type|
| ESROS-ERROR.request |Error-argument |
|__________________________|____________________________|
| | |
| |Error-value |
| |Error-argument-encoding-type|
| ESROS-ERROR.indication |Error-argument |
| |Invoke-ID |
| | |
|__________________________|____________________________|
| ESROS-ERROR.confirm |Invoke-ID |
| |Failure-value |
| | |
|__________________________|____________________________|
| ESROS-FAILURE.indication |Invoke-ID |
|__________________________|____________________________|
Table 7: ESROS-ERROR service primitives and associated parameters
2.6.2 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.
2.6.3 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).
Invoker Performer
ESROS AP ESROS AP
| |
| |
ESROS-FAILURE.ind. | |
--------<-----------| |
| |
| | ESROS-FAILURE.ind.
| |--------->---------
| |
Figure 6: Time sequence diagram for ESROS-FAILURE service
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.
2.6.4 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.
2.6.5 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).
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.
_____________________________________________
| Primitive |Parameters |
|__________________________|_________________|
| |Failure-value |
| ESROS-FAILURE.indication |Invoke-ID |
|__________________________|_________________|
Table 8: ESROS-FAILURE service primitives and associated parameters
_________________________________________
| Failure Value |Meaning |
|_______________|________________________|
| 0 |Transmission failure |
| 1 |Out of local resources |
| 2 |User not responding |
| 3 |Out of remote resources |
| 4 |Reassembly failure |
|_______________|________________________|
Table 9: Encoding of Failure-value
2.7.1 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.
2.7.2 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.
3 ESRO SERVICE NOTATION
Users of ESRO services (invoker and performer) need to agree on a
well defined set of parameters which are enumerated below.
1. The operation's Argument data type.
2. The operation's Result data type.
3. The operation's Error data type.
4. The operation's value. A specific tag which uniquely identifies
the operation.
The invoker and the performer can specify these parameters using a
variety of mechanisms. The notation specified in this section is one
such mechanism. It is not the only machanism and ESRO protocol can
be used independent of this notation.
3.1 ES-OPERATION Notation
The Remote Operations and Operation Errors are specified in this
section. The notation is defined by means of the macro facility
defined in [3].
The macros enabling the specification of operations and errors are
listed in Figure 7.
Note that this notation is very similar to the abstract operation
defined in [1]. The value form of ES-OPERATION is always an integer.
3.2 Mapping of ESROS Notation
3.2.1 Invocation of an Operation
An operation is mapped onto the ESRO Services.
The invocation of an operation is mapped on the ESRO-INVOKE service.
The value assigned to the operation is mapped on the Operation-value
parameter of that service. The value of the Named-Type in the
ARGUMENT clause of the OPERATION Macro is mapped on the Argument
parameter of that service.
3.2.2 Reply of an Operation
If an operation was successfully performed, the reply is mapped on
the ESRO-RESULT service.
The value of the Named-Type in the RESULT clause of the OPERATION
DEFINITIONS ::=
BEGIN
ES-OPERATION, ERROR;
-- macro definition for operations
ES-OPERATION MACRO ::=
BEGIN
TYPE NOTATION ::= Argument Result Errors
VALUE NOTATION ::= value (localValue INTEGER)
Argument ::= "ARGUMENT" NamedType | empty
Result ::= "RESULT" ResultType | empty
ResultType ::= NamedType | empty
Errors ::= "ERRORS" "{"ErrorNames"}" | empty
ErrorNames ::= ErrorList | empty
ErrorList ::= Error | ErrorList "," Error
Error ::= value (ERROR) | type
NamedType ::= identifier type | type
END
-- macro definition for operations errors
ERROR MACRO ::=
BEGIN
TYPE NOTATION ::= Parameter
VALUE NOTATION ::= value (localValue INTEGER)
Parameter ::= "PARAMETER" NamedType | empty
NamedType ::= identifier type | type
END
END
Figure 7: ES Remote Operation Notation
macro is mapped on the Result parameter of that service.
If an operation was not successfully performed, the reply is mapped
on the ESRO-ERROR service.
In this case one of the errors in the Identifier List of Error Names
in the ERROR clause of the OPERATION macro may be applied. The value
assigned to the applied error is mapped onto the Error parameter of
that service. The value of the Named-Type in the PARAMETER clause of
the ERROR macro of the applied error is mapped on the Error-
parameter of that service.
4 REMOTE OPERATIONS PROTOCOL
4.1 Overview of the Protocol
The ESROS protocol realizes the services defined in the section
entitled ESROS Service Definitions. Short operations are performed
in a highly efficient manner. The protocol operation is summarized
below and is described in detail in the following sections.
Two Functional Units are defined which realize the services with 2-
Way handshake and 3-Way handshake, called 2-Way Handshake Functional
Unit and 3-Way Handshake Functional Unit respectively.
The procedures specified in this section refer to Protocol Data Units
(PDUs) which are defined in Section 4.4.
4.1.1 Service Provision (Invoker User)
o An ESROS user binds to an ESRO Service Access Point (SAP) and
specifies whether 3-Way or 2-Way handshake Functional Unit is to
be associated with the SAP.
o An ESROS user initiates the transfer of a PDU using the INVOKE
service.
o On receipt of an ESROS-INVOKE.request service primitive from the
ESROS user:
-- The ESROS provider generates an Invoke ID,
-- Communicates the Invoke-ID to the invoker of the service
through the ESROS-INVOKE-P.confirm primitive,
4.1.2 Service Provision (Performer User)
o An ESROS user binds to an ESRO Service Access Point (SAP) and
specifies whether 3-Way or 2-Way handshake Functional Unit is to
be associated with the SAP.
o On receipt of an ESRO-INVOKE-PDU, the ESROS provider issues an
ESROS-INVOKE.indication to the ESROS performer user.
o On receipt of ESROS-RESULT.request or ESROS-ERROR.request from
the performer, the provider creates the ESRO-RESULT-PDU or
ESRO-ERROR-PDU.
o In the case that the provider receives an ESRO-ACK-PDU for the
transmitted ESRO-RESULT-PDU or ESRO-ERROR-PDU, if the
corresponding SAP is associated with the 3-Way Handshake
Functional Unit, it passes an ESROS-RESULT.confirm or ESROS-
ERROR.confirm to the performer user. If the corresponding SAP
is associated with the 2-Way handshake Functional Unit, the
ESRO-ACK-PDU is dropped as an invalid PDU.
o In the case that the provider is not able to deliver the
ESRO-RESULT-PDU or ESRO-ERROR-PDU, it issues an ESROS-
FAILURE.indication to the performer user. In the case that the
performer's SAP is associated with the 3-Way handshake
Functional Unit and provider doesn't receive the ESRO-ACK-PDU
for a transmitted ESRO-RESULT-PDU or an ESRO-ERROR-PDU, it
passes an ESROS- FAILURE.indication to the performer user.
o In the case that the performer's SAP is associated with the
3-Way handshake Functional Unit and provider receives an ESRO-
ACK-PDU for the operation, it passes an ESROS-RESULT.confirm or
ESROS-ERROR.confirm. In the case that the performer's SAP is
associated with a 2-Way handshake Functional Unit and provider
doesn't receive duplicate ESROS-INVOKE-PDUs from the invoker, it
passes an ESROS-RESULT.confirm or ESROS-ERROR.confirm.
o On receipt of an ESRO-FAILURE-PDU, the ESROS provider issues an
ESROS-FAILURE.indication to the ESROS performer user.
4.2 Protocol Procedures
4.2.1 Service Access Point (SAP) Bind Procedure
To access the ESRO Services, an ESROS user binds to an ESRO Service
Access Point and specifies the SAP to be associated with 3-Way
handshake Functional Unit or 2-Way handshake Functional Unit. ESROS
provider generates a SAP descriptor which is passed to the user. The
handshaking for all Invoke.requests addressed to that SAP and all
PDUs addressed to that SAP will be either 3-Way or 2-Way based on the
Functional Unit associated with SAP and specified by user at SAP bind
time.
It is the responsibility of the ESROS peer users (invoker and
performer) to address their operations to the appropriate SAP (3-Way
or 2-Way) based on the agreement between users.
4.2.2 Invoke Service Procedure
An ESROS user initiates the transfer of a PDU using the INVOKE
service.
On receipt of an ESRO-INVOKE-PDU, the ESROS provider sends an ESROS-
INVOKE.indication primitive to the ESROS performer user.
4.2.3 Invoke ID Assignment Procedure
On receipt of an ESROS-INVOKE.request primitive from the ESROS user,
the ESROS provider generates two invoke identifiers:
o Invoke-Reference-Number: Uniquely identifies the invocation
between the two peers. This is a PDU field with a length of 8
bits (see section 4.4).
o Invoke-ID-Parameter: Uniquely identifies the invocation to the
service user. This Invoke-ID-Parameter is a combination of the
Invoke-Reference-Number described above and the invoker address,
performer address, and the SAP Selector.
The provider communicates the Invoke-ID-Parameter to the invoker of
the INVOKE service through the ESROS-INVOKE-P.confirm primitive.
The Invoke-Reference-Number distinguishes several invocations of the
service in progress (asynchronous operations). It is also used as
segment identifier when a Service Data Unit (SDU) is transferred
using segmentation and reassembly. The ESROS provider may begin to
reuse the Invoke-Reference-Number values whenever it chooses, subject
to the constraint that it may not reuse an Invoke-Reference-Number
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-
Reference-Number unless the corresponding service is fully completed.
The same value of the Invoke-Reference-Number can be reused to
identify the invocation between different peer entities. In that
case, the combination of the peer entity's address and the Invoke-
Reference-Number guarantees unique identification of each invocation.
4.2.4 Functional Unit Selection Procedure
When an ESRO Services user binds to an ESRO SAP, it associates its
SAP descriptor to 3-Way Handshake Functional Unit or 2-Way Handshake
Functional Unit.
Based on the Functional Unit associated with SAP, provider selects
the corresponding Functional Unit for all Invoke Requests or PDUs
addressed to that SAP.
4.3 Connectionless PDU Transfer For Small PDUs
4.3.1 Overview
PDUs sent by UDP use port ESRO_CL_PORT. PDUs carried by UDP are
restricted to CLRO_SMALL_PDU_MAX_SIZE bytes (see 4.6.1)
Each PDU is encapsulated in a single UDP datagram.
For PDUs larger than CLRO_SMALL_PDU_MAX_SIZE but smaller than
CLRO_SEGMENTED_PDU_MAX_SIZE bytes (see 4.6.1), segmentation and
reassembly is used and each segment is transmitted in a UDP datagram.
PDUs sent using UDP may be lost, and hence a retransmission strategy
is defined. When a PDU is segmented, the retransmission strategy is
not applied to individual segments (i.e., loss of one segment results
in retransmission of the whole SDU).
The optimal UDP retransmission policy will vary with the performance
of the network and the needs of the transmitter, but the following
are considered:
The retransmission interval should be based on prior statistics if
possible. Too aggressive retransmission can easily slow response
time of the network at large. Depending on how well connected the
invoker is to its performer, the minimum retransmission interval
should be RETRANSMISSION_INTERVAL (see 4.6.2) seconds.
Delivery of PDUs is asynchronous which means the ESROS does not wait
for the result of a transmitted PDU and continues delivering the next
PDUs.
______________________________________________________
|From Idle to: |Event |
|___________________________________|_________________|
|CL-Invoker Transition Diagram |ESRO-INVOKE.req |
| 2-way Handshake (Connectionless) | |
|___________________________________|_________________|
|CL-Invoker Transition Diagram |ESRO-INVOKE.req |
| 3-way Handshake (Connectionless) | |
|___________________________________|_________________|
|CL-Performer Transition Diagram |INVOKE-PDU |
| 3-way Handshake (Connectionless) | |
|___________________________________|_________________|
|CL-Performer Transition Diagram |INVOKE-PDU |
| 2-way Handshake (Connectionless) | |
|___________________________________|_________________|
Table 10: ESROS Finite State Machine
This section describes the ESROS protocols in terms of state
diagrams. The ESROS Finite State Machine is expressed as four
separate transition diagrams. This is illustrated in Table 10.
Details of each of the two transition diagrams for connectionless
transmission and different handshakings are described in the
following sections. The state diagrams show the state, the events,
the actions taken and the resultant state.The ESROS state transition
diagrams for connectionless data transmission are presented in Table
11, Table 12, Table 13, and Table 14.
Transitions are identified by numbers on the state diagrams. The
corresponding actions are listed next to each table.
4.3.2 3-Way Handshake Functional Unit
This unit implements the Acknowledged Result model of ESRO Services.
3-Way handshaking is used in this unit.
The RESULT.confirm and ERROR.confirm primitives on performer are
generated when ESRO-ACK-PDU is received.
The FAILURE.indication on performer side is resulted from remote or
local failures. Not receiving ESRO-ACK-PDU or local failure can
generate FAILURE.indication primitive.
The FAILURE.indication on invoker side is generated if a local
failure happens or a ESRO-FAILURE-PDU is received.
_______________________________________________________________
| State |STA01 |STA02 |STA03 |STA04 |
| |CL Invoker|Invoke PDU |ACK-PDU |Invoker |
|Event |Start |Send |Send |RefNu Wait|
|-----------------+----------+-----------+---------+----------+
|U: INVOKE.request|(1) STA02 | | | |
|-----------------+----------+-----------+---------+----------+
|T: INVOKE PDU | |(2) STA02 | | |
| Retransmit | | | | |
|-----------------+----------+-----------+---------+----------+
|T: Last Timer | |(3) STA04 | | |
|-----------------+----------+-----------+---------+----------+
|P: Result-PDU | | | |(9) STA04 |
|-----------------+----------+-----------+---------+----------+
|P: Failure-PDU | |(5) STA04 | | |
|-----------------+----------+-----------+---------+----------+
|P: ACK-PDU | |(6) STA02 | | |
| (Hold On) | | | | |
|-----------------+----------+-----------+---------+----------+
|P: Duplicate | | |(7) STA03| |
| Result-PDU | | | | |
|-----------------+----------+-----------+---------+----------+
|T: RefNu Timer | | | |(8) STA01 |
|-----------------+----------+-----------+---------+----------+
|P: Result-PDU | |(4) STA03 | | |
|-----------------+----------+-----------+---------+----------+
|T: Inactivity | | |(10) | |
| Timer | | |STA04 | |
|_________________|__________|___________|_________|__________|
Table 11: ESROS State Transition Diagram-Connectionless Transmission,
3-Way HS. P = Protocol, T = Timer, U = User, I = Internal.
The transmission of INVOKE, RESULT, and ERROR SDUs can be in a single
PDU (when it fits in one UDP) or a sequence of segment PDUs.
3-Way Handshake Connectionless Transmission: Invoker
For each transition number in the state diagram Table 11, the
corresponding actions are listed below:
1. INVOKE.request:
o Assign Invoke-ID.
o Issue ESROS-INVOKE-P.confirm primitive.
o Assign invoke reference number.
o Send operation in one ESRO-INVOKE-PDU or in segmented INVOKE-
PDUs depending on the size of the operation.
o Initialize retransmission counter.
o Initialize retransmission timer.
2. Invoke PDU Retransmit:
o Retransmit operation in one ESRO-INVOKE-PDU or segmented PDUs
while number of retransmissions is less than
MAX_RETRANSMISSIONS.
o Increment the retransmission counter. When MAX_RETRANSMISSIONS
reached, start LAST_TIMER, otherwise initialize retransmission
timer.
3. Last Timer:
o Issue ESROS-FAILURE.indication primitive.
o Initialize reference number timer.
4. ESRO-RESULT-PDU or ESRO-ERROR-PDU (or reassembled ESRO-
RESULT-SEGMENTED-PDU or ESRO-ERROR-SEGMENTED-PDU when the PDU is
received in segmented format):
o Send ESRO-ACK-PDU.
o Issue ESROS-RESULT.indication or ESROS-ERROR.indication
primitive.
o Initialize inactivity timer.
5. ESRO-FAILURE-PDU:
o Issue ESROS-FAILURE.indication primitive with User not
Responding failure cause.
o Initialize reference number timer.
6. ESRO-ACK-PDU (Hold on):
o For future use (no action).
7. Duplicate ESRO-RESULT-PDU or ESRO-ERROR-PDU:
o Initialize inactivity timer (Ignore PDU).
o Send ESRO-ACK-PDU.
8. Invoke reference number timer:
o Release the invoke reference number.
9. ESRO-RESULT-PDU or ESRO-ERROR-PDU:
o Reset Invoke reference number timer.
10. Inactivity timer:
o Initialize reference number timer.
On receipt of an ESROS-INVOKE.request, ESROS provider generates an
Invoke- Reference-Number and an Invoke-ID (see Section 4.2.3). The
provider issues an ESROS-INVOKE-P.confirm primitive and passes the
Invoke-ID to the invoker.
The ESROS provider initiates the timer for the Invoke-ID and
transmits the PDU. Based on the size of SDU, if segmentation is