As per Relevance of the word provider, we have this rfc below:
Network Working Group M.
Request for Comments: 2188
Category: Informational M.
J.
September 1997
AT&T/Neda's Efficient Short Remote Operations (ESRO
Protocol Specification Version 1.2
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
IESG
This protocol has not had the benefit of IETF Working Group review
but a cursory examination reveals several issues which may
significant issues for scalability. A site considering
should conduct a careful analysis to ensure they understand
potential impacts
This document specifies the service model, the notation and
for Efficient Short Remote Operations (ESRO). The ESRO service
similar to and is consistent with other Remote Procedure
services. The emphasis of ESRO service definition and the
protocol is on efficiency. ESRO is designed specifically
wireless network (e.g., CDPD) usage in mind
ESRO protocol provides reliable connectionless remote
services on top of UDP (or any other non-reliable
transport service) with minimum overhead. ESRO protocol
segmentation and reassembly, concatenation and separation as well
multiplexing for service users (applications).
ESRO allows for trade-offs between efficiency and reliability
specifying both 2-way hand-shake and 3-way hand-shake based protocols
Encoding mechanisms for presentation of the parameters of
operations are outside the scope of this document. But
identification (tagging) of the encoding mechanism in use (e.g., XDR
Banan, et. al Informational [Page 1]
RFC 2188 ESRO September 1997
BER, PER) is supported by ESRO protocol
A variety of applications can use the ESRO protocol. Some
applications using ESRO include efficient short message submission
delivery, credit card authorization and white pages lookup
Banan, et. al Informational [Page 2]
RFC 2188 ESRO September 1997
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
Banan, et. al Informational [Page 3]
RFC 2188 ESRO September 1997
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
Efficient Short Remote Operations (ESRO) provide an
mechanism for realization of Remote Procedure Call. This
specifies many aspects of ESRO including
o Service
o Service
o A Notation for user of the
o Confirmed Connectionless Protocol (based on a 3-way hand-shake
o Unconfirmed Connectionless Protocol (based on a 2-way hand-shake
Banan, et. al Informational [Page 4]
RFC 2188 ESRO September 1997
1.1 Relationship To Existing Remote Operation
The overall model of ESRO is similar to and consistent with
existing protocols. ESRO's distinguishing characteristic
efficiency
A brief comparison of ESRO and Remote Procedure Calls [7] and
Operation Service Elements [1] follows
1.1.1 ESRO and
Remote Procedure Call (RPC) is specified in [7] (RFC-1831) and [6]
(RFC-1833).
RPC specifications define a remote procedure model that
essentially same as ESRO. RPC's notation uses a syntax
different from that of ESRO. RPC can rely on a connection oriented
connectionless transport mechanism. When using the
mechanism, the retransmission and reliability issues are
beyond the scope of the RPC specification. RPC is usually used
combination with External Data Representation, XDR [8] (RFC-1832).
1.1.2 ESRO and
ROSE is specified in [1] and [2]. The service definition for
Service (ESROS) specified in this document is similar ROSE'
Notation. The Notation specified in this document for ESROS
similar ROSE's Notation. The ESRO protocol specified in
document is very different from the ROSE protocol [2].
The operation model for ESRO Service (ESROS) is based on
Operations Services Element (ROSE) in [1]. In ESROS model
entities can invoke operations
ESRO protocols can accomplish short operations with much
overhead than ROSE
1.2 Overview of
ESROS provides a service which supports interaction of
based on a remote operation model. A Remote Operation is invoked
one entity; the other entity attempts to perform the Remote
and then reports the outcome of the attempt. The ESROS protocol
designed such that it could support many applications
Banan, et. al Informational [Page 5]
RFC 2188 ESRO September 1997
1.3 The Remote Operation
ESROS provides for performance of operations between two
sublayers. Users of the ESROS assume the roles of invoker
performer which invoke and perform the operations respectively.
ESROS-User can assume both roles and be an invoker for
operations and be a performer for other operations. The performer
expected to report either the result of the operation or an error.
result reply is sent to the invoker if the operation is successful
and an error reply is sent if the operation is unsuccessful. If
performer is unreachable, the ESROS sends a failure
primitive to the invoker
Operations are asynchronous and the invoker may continue to
further operations without waiting for a reply. Synchronous
serialized operations are also supported as a subset and a
case of asynchronous service. By default the ESRO service
on both invoker and performer sides supports the
operation invocation. However, if one side is to support
serialized (synchronous) mode, it should be in agreement with
peer side
ESROS has no authentication mechanism. Authentication is
responsibility of the performer (which is outside of the scope
ESROS) and the performer is not expected to honor the invoker when
is not authenticated
The ESROS operation model is represented in Figure 1. In
example, the ESROS User on the left is the Invoker and the ESROS
on the right is the Performer. The Provider is the entity
a service to the layer above it
Banan, et. al Informational [Page 6]
RFC 2188 ESRO September 1997
ESROS ------------------- -------------------
User | Layer above ESROS | | Layer above ESROS |
(Invoker) | | | | (Performer
------------------- -------------------
^ | | ^
| | | |
v | |
ESROS ------------------- -------------------
Provider | ESROS | | ESROS |
------------------- -------------------
| |
| |
| |
------------------- -------------------
| UDP | | UDP |
------------------- -------------------
_ _/
_ _/
_ . _/
_ . .* . _/
. * .* .
* . *
Figure 1: ES Remote Operation
Banan, et. al Informational [Page 7]
RFC 2188 ESRO September 1997
Invoker
ESRO SAP ESRO
| |
| |
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
2 ESRO SERVICE
ESRO service primitives are illustrated in Figure 2, Table 1
Table 2. The description of services and primitives comes in
following sections
ESROS-User accesses ESRO services through Efficient Short
Operations Service Access Point (ESRO-SAP) as shown in Figure 2.
The RESULT.request, ERROR.request and FAILURE.indication
primitives can be implemented in two different modes
Banan, et. al Informational [Page 8]
RFC 2188 ESRO September 1997
1. Acknowledged Result,
2. Non-Acknowledged
_____________________________________________
| 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
as described below. The difference between different modes is
their reliability of service and efficiency. Reliability of
is defined based on the understanding of invoker and performer
the success or failure of the operation on the peer side. Table 3
and Table 4 summarize understanding of performer about success
failure on invoker side in different situations. In these tables
FAILURE.indication refers to the primitive generated by protocol
not the failure of local provider
2.1 Acknowledged Result Service
In this service mode, the result is acknowledged by invoker, but
mechanism by which the acknowledgment is accomplished may not
reliable. Table 3 summarizes the relationship between performer
invoker in success and failure cases
2.1.1 Performer
In this type of service, the RESULT.confirm and ERROR.
primitives on performer side are generated if the result/error
acknowledged by invoker
The FAILURE.indication on performer side is generated if result/
is not acknowledged by invoker or if there is a local failure
performer side
>From the protocol point of view, the FAILURE.indication might
because either the result/error PDU or the ack PDU is lost.
outcome of this is that a FAILURE.indication is not robust as
operation may have been successful from the invoker's perspective
One method of compensating for this shortcoming is having
performer verify the FAILURE.indication in a separate operation
Banan, et. al Informational [Page 9]
RFC 2188 ESRO September 1997
____________________________________________________________
| 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
Banan, et. al Informational [Page 10]
RFC 2188 ESRO September 1997
______________________________________________________________
|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
__________________________________________________________________
|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
2.1.2 Invoker
When invoker receives failure indication, the performer has
failure indication too
This type of service can be implemented by protocols based on 3-
handshaking
2.2 Non-acknowledged
In this service mode the result is not acknowledged. Table 4
summarizes the relationship between performer and invoker in
and failure cases
Banan, et. al Informational [Page 11]
RFC 2188 ESRO September 1997
2.2.1 Performer
In this type of service, the RESULT.confirm and ERROR.
primitives on performer side are generated without
additional information from the invoker peer. In other words,
Primitives have no protocol-related meaning and convey
information, other than end-of-operation
The FAILURE.indication on performer side is not generated
protocol. The only case that can generate FAILURE.indication
performer side is local failure in service provider on
side
2.2.2 Invoker
The FAILURE.indication on invoker side can be the resultof
receiving result/error/failure from peer performer or it can
from failure in local service provider
This type of service can be implemented by protocols based on 2-
handshaking
2.3 Serialized Use of ESRO
Although the ESRO Services are defined to support
operation invocation in general, they can be used in the special
of synchronous (serialized) mode too. The serialized use of
Services is implementation specific. However, one of the
scenarios is as follows
2.3.1
Invokes an operation after it receives either RESULT.indication
ERROR.indication, or FAILURE.indication for the previous operation
2.3.2
Considers an operation to be complete and accepts the next
after it receives RESULT.confirm, ERROR.confirm,
FAILURE.indication
Banan, et. al Informational [Page 12]
RFC 2188 ESRO September 1997
Invoker
ESROS AP ESROS
| |
| |
ESROS-INVOKE.req. | | ESROS-INVOKE.ind
-------->-----------| |-------->---------
| |
ESROS-INVOKE-P.conf.| |
--------<-----------| |
| |
ESROS-FAILURE.ind. | |
--------<-----------| |
| |
Figure 3: Time sequence diagram for ESROS-INVOKE
2.4 ESROS-INVOKE
The ESROS-INVOKE service is used by an ESROS-User (the invoker)
cause the invocation of an OPERATION to be performed by the
ESROS-User (the performer).
ESROS Invoker User issues ESROS-INVOKE.request primitive to invoke
operation
ESROS-INVOKE.indication primitive provides the ESROS Performer
with the parameters of the invoked operation
ESRO Service Provider issues the ESROS-INVOKE-P.confirm primitive
provide the ESROS Invoker User with Invoke-ID of the
operation
The related service structure consists of three service primitives
illustrated in Figure 3 and Table 5.
2.4.1 Operation-
This value is the identifier of the operation to be invoked.
value is agreed upon between the ESROS Users. This parameter has
be supplied by the invoker of the service
ESROS Invoker User provides the Operation-value parameter for
ESROS-INVOKE.request primitive. The Operation-value parameter
ESROS-INVOKE.indication is provided to the ESROS Performer User
Banan, et. al Informational [Page 13]
RFC 2188 ESRO September 1997
_____________________________________________________________
| 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
2.4.2 Performer-
This parameter is the address of the ESROS Performer User
consists of ESRO Service Access Point (SAP) Selector,
Service Access Point (TSAP) Selector (e.g., port number), and
Service Access Point (NSAP) address (e.g., IP address).
parameter has to be supplied by the invoker of the service
ESROS Invoker User provides the Performer-address parameter for
ESROS-INVOKE.request primitive
2.4.3 Invoker-
This parameter is the address of the ESROS Invoker User
consists of ESRO Service Access Point (SAP) Selector,
Service Access Point (TSAP) Selector (e.g. port number), and
Service Access Point (NSAP) address (e.g. IP address).
The Invoker-address parameter of ESROS-INVOKE.indication is
to the ESROS Performer User
Banan, et. al Informational [Page 14]
RFC 2188 ESRO September 1997
2.4.4 Invoke-argument-encoding-
This parameter identifies the encoding type of the Invoke-
(see next subsection). The encoding type has to be agreed
between ESROS Users. This parameter has to be supplied by
invoker of the service
ESROS Invoker User provides the Invoke-argument-encoding-
parameter for the ESROS-INVOKE.request primitive. The Invoke
argument-encoding-type parameter of ESROS-INVOKE.indication
provided to the ESROS Performer User
2.4.5 Invoke-
This parameter is the argument of the invoked operation. The
has to be agreed between the ESROS Users. This parameter has to
supplied by the invoker of the service. Encoding type of
Invoke-argument is specified through the Invoke-argument-encoding
type parameter (see previous subsection).
ESROS Invoker User provides the Invoke-argument parameter for
ESROS-INVOKE.request primitive. The Invoke-argument parameter
ESROS-INVOKE.indication is provided to the ESROS Performer User
2.4.6 Invoke-
This parameter identifies the invocation of an ESROS-INVOKE
and is used to correlate this invocation with the
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
progress (asynchronous operations). The ESROS provider may begin
reuse Invoke-ID values whenever it chooses, subject to the
that it may not reuse an Invoke-ID value that was previously
to an invocation of the service for which it expects, but has not
received a reply. In other words, the provider does not reuse
previously used Invoke-ID unless the corresponding service is
completed
Banan, et. al Informational [Page 15]
RFC 2188 ESRO September 1997
2.4.7 Failure-
This parameter identifies the failure that occurred during
processing or transmission of any of the service primitives of ESROS
Invoker
ESROS AP ESROS
| |
| |
ESROS-RESULT.ind. | | ESROS-RESULT.req
--------<-----------| |--------<---------
| |
| | ESROS-RESULT.conf
| |-------->---------
| |
| | ESROS-FAILURE.ind
| |-------->---------
| |
Figure 4: Time sequence diagram for ESROS-RESULT
This parameter has to be supplied by the ESROS provider (see
Section 2.7).
2.5 ESROS-RESULT
The ESROS-RESULT service is used by an ESROS User to reply to
previous ESROS-INVOKE.indication in the case of a
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
illustrated in Figure 4 and Table 6.
2.5.1 Result-argument-encoding-
This parameter identifies the encoding type of the Result-
(see next subsection). The encoding type has to be agreed
between the ESROS Users. This parameter has to be supplied by
ESROS Performer User
ESROS Performer User provides the Result-argument-encoding-
parameter for the ESROS-RESULT.request primitive. The Result
argument-encoding-type parameter of ESROS-RESULT.indication
provided to the ESROS Invoker User
Banan, et. al Informational [Page 16]
RFC 2188 ESRO September 1997
______________________________________________________________
| 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
2.5.2 Result-
This parameter is the result of an invoked and successfully
operation. The type has to be agreed between the ESROS Users.
parameter has to be supplied by the invoker of the service.
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
ESROS-RESULT.request primitive. The Result-argument parameter
ESROS-RESULT.indication is provided to the ESROS Invoker User
2.5.3 Invoke-
This parameter identifies the corresponding invocation.
Invoke-ID, which is originally generated by the ESROS provider at
time of ESROS-INVOKE indication, is extracted from the Invoke ID
has to be supplied by the ESROS performer User. The value is that
the corresponding ESROS-INVOKE.indication primitive
Banan, et. al Informational [Page 17]
RFC 2188 ESRO September 1997
Invoker
ESROS AP ESROS
| |
| |
ESROS-ERROR.ind. | | ESROS-ERROR.req
--------<-----------| |--------<---------
| |
| | ESROS-ERROR.conf
| |-------->---------
| |
| | ESROS-FAILURE.ind
| |-------->---------
Figure 5: Time sequence diagram for ESROS-ERROR
2.5.4 Failure-
This parameter identifies the failure that occurred during
processing or transmission of any of the service primitives of ESROS
This parameter has to be supplied by the ESROS provider (see
Section 2.7).
2.6 ESROS-ERROR
The ESROS-ERROR service is used by an ESROS User to reply to
previous ESROS-INVOKE.indication in the case of an
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
illustrated in Figure 5 and Table 7.
2.6.1 Error-
This parameter identifies the error in reply to a previous ESROS
INVOKE.indication in the case of an unsuccessfully
operation. The value has to be agreed between the ESROS-Users.
parameter has to be supplied by the ESROS Performer User
ESROS Performer User provides the Error-argument parameter for
ESROS-ERROR.request primitive. The Error-argument parameter
ESROS-ERROR.indication is provided to the ESROS Invoker User
Banan, et. al Informational [Page 18]
RFC 2188 ESRO September 1997
________________________________________________________
| 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
2.6.2 Error-argument-encoding-
This parameter identifies the encoding type of the Error-
(see next subsection). The encoding type has to be agreed
between the ESROS Users. This parameter has to be supplied by
ESROS Performer User
ESROS Performer User provides the Error-argument-encoding-
parameter for the ESROS-ERROR.request primitive. The Error
argument-encoding-type parameter of ESROS-ERROR.indication
provided to the ESROS Invoker User
2.6.3 Error-
This parameter provides additional information about the error
reply to a previous ESROS-INVOKE.indication in the case of
unsuccessfully performed operation. The type (if any) has to
agreed between the ESROS users. This parameter has to be supplied
the ESROS Performer User. Encoding type of the Error-argument
specified through the Error-argument-encoding-type parameter (
previous subsection).
Banan, et. al Informational [Page 19]
RFC 2188 ESRO September 1997
Invoker
ESROS AP ESROS
| |
| |
ESROS-FAILURE.ind. | |
--------<-----------| |
| |
| | ESROS-FAILURE.ind
| |--------->---------
| |
Figure 6: Time sequence diagram for ESROS-FAILURE
ESROS Performer User provides the Error-argument parameter for
ESROS-ERROR.request primitive. The Error-argument parameter
ESROS-ERROR.indication is provided to the ESROS Invoker User
2.6.4 Invoke-
This parameter identifies the corresponding invocation.
Invoke-ID, which is originally generated by the ESROS provider at
time of the ESROS-INVOKE.indication, is extracted from the Invoke
which has to be supplied by the ESROS performer User. The value
that of the corresponding ESROS-INVOKE.indication primitive
2.6.5 Failure-
This parameter identifies the failure that occurred during
processing or transmission of any of the service primitives of ESROS
This parameter has to be supplied by the ESROS provider (see
Section 2.7).
2.7 ESROS-FAILURE
The ESROS-FAILURE service is used by ESROS provider to indicate
failure in providing an ESROS-INVOKE, ESROS-RESULT, or ESROS-
service
The related service structure consists of one service primitive
illustrated in Figure 6 and Table 8.
Banan, et. al Informational [Page 20]
RFC 2188 ESRO September 1997
_____________________________________________
| Primitive |Parameters |
|__________________________|_________________|
| |Failure-value |
| ESROS-FAILURE.indication |Invoke-ID |
|__________________________|_________________|
Table 8: ESROS-FAILURE service primitives and associated
_________________________________________
| 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-
2.7.1 Failure-
This parameter identifies the failure that occurred during
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-
This parameter identifies the corresponding invocation.
Invoke-ID, which is originally generated by ESROS provider at
time of the ESROS-INVOKE.indication, is extracted from the Invoke
which has to be supplied by ESROS performer User. The value is
of the corresponding ESROS-INVOKE.indication primitive
3 ESRO SERVICE
Users of ESRO services (invoker and performer) need to agree on
well defined set of parameters which are enumerated below
1. The operation's Argument data type
Banan, et. al Informational [Page 21]
RFC 2188 ESRO September 1997
2. The operation's Result data type
3. The operation's Error data type
4. The operation's value. A specific tag which uniquely
the operation
The invoker and the performer can specify these parameters using
variety of mechanisms. The notation specified in this section is
such mechanism. It is not the only machanism and ESRO protocol
be used independent of this notation
3.1 ES-OPERATION
The Remote Operations and Operation Errors are specified in
section. The notation is defined by means of the macro
defined in [3].
The macros enabling the specification of operations and errors
listed in Figure 7.
Note that this notation is very similar to the abstract
defined in [1]. The value form of ES-OPERATION is always an integer
3.2 Mapping of ESROS
3.2.1 Invocation of an
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-
parameter of that service. The value of the Named-Type in
ARGUMENT clause of the OPERATION Macro is mapped on the
parameter of that service
3.2.2 Reply of an
If an operation was successfully performed, the reply is mapped
the ESRO-RESULT service
The value of the Named-Type in the RESULT clause of the
DEFINITIONS ::=
ES-OPERATION, ERROR
-- macro definition for
Banan, et. al Informational [Page 22]
RFC 2188 ESRO September 1997
ES-OPERATION MACRO ::=
TYPE NOTATION ::= Argument Result
VALUE NOTATION ::= value (localValue INTEGER
Argument ::= "ARGUMENT" NamedType |
Result ::= "RESULT" ResultType |
ResultType ::= NamedType |
Errors ::= "ERRORS" "{"ErrorNames"}" |
ErrorNames ::= ErrorList |
ErrorList ::= Error | ErrorList ","
Error ::= value (ERROR) |
NamedType ::= identifier type |
-- macro definition for operations
ERROR MACRO ::=
TYPE NOTATION ::=
VALUE NOTATION ::= value (localValue INTEGER
Parameter ::= "PARAMETER" NamedType |
NamedType ::= identifier type |
Figure 7: ES Remote Operation
macro is mapped on the Result parameter of that service
If an operation was not successfully performed, the reply is
on the ESRO-ERROR service
In this case one of the errors in the Identifier List of Error
in the ERROR clause of the OPERATION macro may be applied. The
assigned to the applied error is mapped onto the Error parameter
that service. The value of the Named-Type in the PARAMETER clause
the ERROR macro of the applied error is mapped on the Error
parameter of that service
4 REMOTE OPERATIONS
4.1 Overview of the
The ESROS protocol realizes the services defined in the
entitled ESROS Service Definitions. Short operations are
in a highly efficient manner. The protocol operation is
below and is described in detail in the following sections
Banan, et. al Informational [Page 23]
RFC 2188 ESRO September 1997
Two Functional Units are defined which realize the services with 2-
Way handshake and 3-Way handshake, called 2-Way Handshake
Unit and 3-Way Handshake Functional Unit respectively
The procedures specified in this section refer to Protocol Data
(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)
specifies whether 3-Way or 2-Way handshake Functional Unit is
be associated with the SAP
o An ESROS user initiates the transfer of a PDU using the
service
o On receipt of an ESROS-INVOKE.request service primitive from
ESROS user
-- The ESROS provider generates an Invoke ID
-- Communicates the Invoke-ID to the invoker of the
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)
specifies whether 3-Way or 2-Way handshake Functional Unit is
be associated with the SAP
o On receipt of an ESRO-INVOKE-PDU, the ESROS provider issues
ESROS-INVOKE.indication to the ESROS performer user
o On receipt of ESROS-RESULT.request or ESROS-ERROR.request
the performer, the provider creates the ESRO-RESULT-PDU
ESRO-ERROR-PDU
o In the case that the provider receives an ESRO-ACK-PDU for
transmitted ESRO-RESULT-PDU or ESRO-ERROR-PDU, if
corresponding SAP is associated with the 3-Way
Functional Unit, it passes an ESROS-RESULT.confirm or ESROS
ERROR.confirm to the performer user. If the corresponding
is associated with the 2-Way handshake Functional Unit,
ESRO-ACK-PDU is dropped as an invalid PDU
o In the case that the provider is not able to deliver
ESRO-RESULT-PDU or ESRO-ERROR-PDU, it issues an ESROS
FAILURE.indication to the performer user. In the case that
Banan, et. al Informational [Page 24]
RFC 2188 ESRO September 1997
performer's SAP is associated with the 3-Way
Functional Unit and provider doesn't receive the ESRO-ACK-
for a transmitted ESRO-RESULT-PDU or an ESRO-ERROR-PDU,
passes an ESROS- FAILURE.indication to the performer user
o In the case that the performer's SAP is associated with
3-Way handshake Functional Unit and provider receives an ESRO
ACK-PDU for the operation, it passes an ESROS-RESULT.confirm
ESROS-ERROR.confirm. In the case that the performer's SAP
associated with a 2-Way handshake Functional Unit and
doesn't receive duplicate ESROS-INVOKE-PDUs from the invoker,
passes an ESROS-RESULT.confirm or ESROS-ERROR.confirm
o On receipt of an ESRO-FAILURE-PDU, the ESROS provider issues
ESROS-FAILURE.indication to the ESROS performer user
4.2 Protocol
4.2.1 Service Access Point (SAP) Bind
To access the ESRO Services, an ESROS user binds to an ESRO
Access Point and specifies the SAP to be associated with 3-
handshake Functional Unit or 2-Way handshake Functional Unit.
provider generates a SAP descriptor which is passed to the user.
handshaking for all Invoke.requests addressed to that SAP and
PDUs addressed to that SAP will be either 3-Way or 2-Way based on
Functional Unit associated with SAP and specified by user at SAP
time
It is the responsibility of the ESROS peer users (invoker
performer) to address their operations to the appropriate SAP (3-
or 2-Way) based on the agreement between users
4.2.2 Invoke Service
An ESROS user initiates the transfer of a PDU using the
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
On receipt of an ESROS-INVOKE.request primitive from the ESROS user
the ESROS provider generates two invoke identifiers
Banan, et. al Informational [Page 25]
RFC 2188 ESRO September 1997
o Invoke-Reference-Number: Uniquely identifies the
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
service user. This Invoke-ID-Parameter is a combination of
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
the INVOKE service through the ESROS-INVOKE-P.confirm primitive
The Invoke-Reference-Number distinguishes several invocations of
service in progress (asynchronous operations). It is also used
segment identifier when a Service Data Unit (SDU) is
using segmentation and reassembly. The ESROS provider may begin
reuse the Invoke-Reference-Number values whenever it chooses,
to the constraint that it may not reuse an Invoke-Reference-
value that was previously assigned to an invocation of the
for which it expects, but has not yet received, a reply. In
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
identify the invocation between different peer entities. In
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
When an ESRO Services user binds to an ESRO SAP, it associates
SAP descriptor to 3-Way Handshake Functional Unit or 2-Way
Functional Unit
Based on the Functional Unit associated with SAP, provider
the corresponding Functional Unit for all Invoke Requests or
addressed to that SAP
4.3 Connectionless PDU Transfer For Small
4.3.1
PDUs sent by UDP use port ESRO_CL_PORT. PDUs carried by UDP
restricted to CLRO_SMALL_PDU_MAX_SIZE bytes (see 4.6.1)
Each PDU is encapsulated in a single UDP datagram
Banan, et. al Informational [Page 26]
RFC 2188 ESRO September 1997
For PDUs larger than CLRO_SMALL_PDU_MAX_SIZE but smaller
CLRO_SEGMENTED_PDU_MAX_SIZE bytes (see 4.6.1), segmentation
reassembly is used and each segment is transmitted in a UDP datagram
PDUs sent using UDP may be lost, and hence a retransmission
is defined. When a PDU is segmented, the retransmission strategy
not applied to individual segments (i.e., loss of one segment
in retransmission of the whole SDU).
The optimal UDP retransmission policy will vary with the
of the network and the needs of the transmitter, but the
are considered
The retransmission interval should be based on prior statistics
possible. Too aggressive retransmission can easily slow
time of the network at large. Depending on how well connected
invoker is to its performer, the minimum retransmission
should be RETRANSMISSION_INTERVAL (see 4.6.2) seconds
Delivery of PDUs is asynchronous which means the ESROS does not
for the result of a transmitted PDU and continues delivering the
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
This section describes the ESROS protocols in terms of
diagrams. The ESROS Finite State Machine is expressed as
separate transition diagrams. This is illustrated in Table 10.
Banan, et. al Informational [Page 27]
RFC 2188 ESRO September 1997
Details of each of the two transition diagrams for
transmission and different handshakings are described in
following sections. The state diagrams show the state, the events
the actions taken and the resultant state.The ESROS state
diagrams for connectionless data transmission are presented in
11, Table 12, Table 13, and Table 14.
Transitions are identified by numbers on the state diagrams.
corresponding actions are listed next to each table
4.3.2 3-Way Handshake Functional
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
generated when ESRO-ACK-PDU is received
The FAILURE.indication on performer side is resulted from remote
local failures. Not receiving ESRO-ACK-PDU or local failure
generate FAILURE.indication primitive
The FAILURE.indication on invoker side is generated if a
failure happens or a ESRO-FAILURE-PDU is received
Banan, et. al Informational [Page 28]
RFC 2188 ESRO September 1997
_______________________________________________________________
| 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
PDU (when it fits in one UDP) or a sequence of segment PDUs
3-Way Handshake Connectionless Transmission:
For each transition number in the state diagram Table 11,
corresponding actions are listed below
1. INVOKE.request
o Assign Invoke-ID
Banan, et. al Informational [Page 29]
RFC 2188 ESRO September 1997
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
while number of retransmissions is less
MAX_RETRANSMISSIONS
o Increment the retransmission counter. When MAX_
reached, start LAST_TIMER, otherwise initialize
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
received in segmented format):
o Send ESRO-ACK-PDU
o Issue ESROS-RESULT.indication or ESROS-ERROR.
primitive
o Initialize inactivity timer
5. ESRO-FAILURE-PDU
o Issue ESROS-FAILURE.indication primitive with User
Responding failure cause
o Initialize reference number timer
Banan, et. al Informational [Page 30]
RFC 2188 ESRO September 1997
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
Invoke- Reference-Number and an Invoke-ID (see Section 4.2.3).
provider issues an ESROS-INVOKE-P.confirm primitive and passes
Invoke-ID to the invoker
The ESROS provider initiates the timer for the Invoke-ID
transmits the PDU. Based on the size of SDU, if segmentation
required, the SDU is segmented and transmitted in a sequence
segmented PDUs. If the ESRO-RESULT-PDU or ESRO-ERROR-PDU
with the invoke ID is not received within
INVOKE_PDU_RETRANSMISSION_INTERVAL (see 4.6.2) period, the SDU
retransmitted (in one PDU or segmented and transmitted in a
of segment PDUs). The retransmission is repeated for a maximum
MAX_RETRANSMISSIONS unless an ESRO-RESULT-PDU or ESRO-ERROR-PDU
received
If the ESRO-RESULT-PDU or ESRO-ERROR-PDU is received in a
format, the reassembly process reassembles the sequence of
PDUs
In the case that the Hold-on ESRO-ACK-PDU is received from
performer, the provider stops retransmitting the ESRO-INVOKE-PDU
waits for the ESRO- RESULT-PDU or ESRO-ERROR-PDU for a period
to the multiplication of INVOKE_PDU_RETRANSMISSION_INTERVAL (
4.6.2) and MAX_RETRANSMISSIONS (see 4.6.2, for future use).
Banan, et. al Informational [Page 31]
RFC 2188 ESRO September 1997
In the case that the ESRO-INVOKE-PDU is sent MAX_RETRANSMISSIONS (
4.6.2) times and no ESRO-RESULT-PDU or ESRO-ERROR-PDU is received
the ESROS provider sends an ESROS-FAILURE.indication primitive,
the Invoke-ID of the failed PDU and the Failure-value as parameters
to the invoker
When an ESRO-RESULT-PDU or ESRO-ERROR-PDU is received (whether in
PDU or reassembled from a sequence of segmented PDUs), the
issues an ESROS-RESULT.indication or ESROS-ERROR.indication to
invoker user, sends an ESRO-ACK-PDU and initializes the
timer. In the case that duplicate ESRO- RESULT-PDU or ESRO-ERROR-
____________________________________________________________________
| State |STA01 |STA02 |STA03 |STA04 |
| |CL Performer |Invoke PDU |ACK-PDU |Performer |
|Event |Start |Received |Wait |RefNu Wait |
|-----------------+-------------+-----------+----------+-----------|
|P: Invoke-PDU |(1) STA02 | | | |
|-----------------+-------------+-----------+----------+-----------|
|U: RESULT.req. | |(2) STA03 | | |
|-----------------+-------------+-----------+----------+-----------|
|P: ACK-PDU | | |(3) STA04 | |
|-----------------+-------------+-----------+----------+-----------|
|P: Invoke-PDU | |(4) STA02 |(6) STA03 |(7) STA04 |
| Duplicate | | | | |
|-----------------+-------------+-----------+----------+-----------|
|T: Result-PDU | | |(5) STA03 | |
| Retransmission | | | | |
| Timer | | | | |
|-----------------+-------------+-----------+----------+-----------|
|I: Failure | |(8) STA01 | | |
|-----------------+-------------+-----------+----------+-----------|
|T: Last Time | | |(9) STA04 | |
|-----------------+-------------+-----------+----------+-----------|
|T: RefNu Timer | | | |(10) STA01 |
|-----------------+-------------+-----------+----------+-----------|
|P: ACK-PDU | | | |(11) STA04 |
| Duplicate | | | | |
|-----------------+-------------+-----------+----------+-----------|
|U/P: Hold On ACK | |(12) STA02 | | |
____________________________________________________________________
Table 12: ESROS State Transition Diagram-Connectionless Transmission
3-Way HS: 