RFC 2188
AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2
RFC 2188: AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2 🎀
okay bestie, the title block is the vibe check, so here's the tea ☕
- Stream: Network Working Group 🌸
- RFC number: 2188
- Authors: M. Banan, Neda, M. Taylor (AWS), and J. Cheng (AWS) 👯
- Category: Informational (it's giving "for your information," not a standard 💅)
- Date: September 1997 📅
- Obsoletes / Updates: nothing listed in the title block, so this doc isn't replacing or updating any other RFC 🦋
Status of this Memo ✨
so this memo is here to inform the Internet community. It is NOT an Internet standard of any kind 🙈 Distribution is unlimited, so share it with everyone you know 💖
IESG Note 🚨
this protocol didn't go through IETF Working Group review 😬 A quick look turned up some issues that could be a big deal for scalability. So if your site is thinking about deploying it, do a careful analysis first so you actually understand the potential impacts. Protect your network like it's your phone 🫶
Abstract 🦋
okay, the main idea: this doc spells out the service model, the notation, and the protocol for Efficient Short Remote Operations (ESRO) 🧚 ESRO is similar to and consistent with other Remote Procedure Call services, but its whole personality is efficiency ⚡ It was designed with wireless networks in mind, like CDPD 📡
ESRO gives you reliable, connectionless remote operations on top of UDP (or any other non-reliable connectionless transport) with minimal overhead 💅 It also handles segmentation and reassembly, concatenation and separation, and multiplexing for the service users (the applications) 🎀
Want to trade efficiency for reliability? ESRO lets you do that, because it specifies both a 2-way hand-shake protocol and a 3-way hand-shake protocol 🔥
The encoding mechanisms used to present the parameters of remote operations are out of scope here 🙅♀️ BUT ESRO does support identifying (tagging) the encoding in use, like XDR, BER, or PER 🧠
Applications that can use 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 . . . . . . . . . . . 561. INTRODUCTION ✨
so ESRO is an efficient mechanism for making Remote Procedure Call happen 🔥 This doc covers a bunch of ESRO stuff, including:
- Service Model 💅
- Service Primitives 🎀
- A Notation for users of the Service 📝
- Confirmed Connectionless Protocol (based on a 3-way hand-shake) 🤝
- 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 a lot of existing protocols 🌈 What makes ESRO special is that it's efficient ⚡
here's a quick comparison of ESRO with Remote Procedure Calls [7] and Remote Operation Service Elements [1] 👀
1.1.1. ESRO and RPC 🧚
Remote Procedure Call (RPC) is specified in [7] (RFC-1831) and [6] (RFC-1833) 📚
RPC's remote procedure model is basically the same as ESRO's 💖 The difference is that RPC's notation has a syntax that's pretty different from ESRO's. RPC can run over a connection-oriented or a connectionless transport. When it's connectionless, retransmission and reliability are treated as out of scope for the RPC spec 🙈 RPC is usually paired 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 the ESRO Service (ESROS) in this document is similar to ROSE's Notation. And the notation this doc uses for ESROS is also similar to ROSE's Notation ✨ But the ESRO protocol here is very different from the ROSE protocol [2] 💀
The operation model for the ESRO Service (ESROS) is based on the Remote Operations Services Element (ROSE) in [1]. In the ESROS model, both entities can invoke operations 🔥
Bottom line: ESRO protocols can do short operations with way less overhead than ROSE 🏃♀️💨
1.2. Overview of ESROS 🌸
ESROS provides a service that supports applications interacting through a remote operation model 🎀 One entity invokes a Remote Operation. The other entity tries to perform it, then reports how the attempt turned out 💅 The ESROS protocol is designed so it could support lots of different applications 🌟
1.3 The Remote Operation Model 💅
Okay bestie, so ESROS is what lets two peer sublayers actually do operations for each other 🫶. The users of ESROS take on two roles: the invoker, who asks for an operation, and the performer, who does it ✨. An ESROS-User can be both! It can be an invoker for some operations and a performer for others, which is such main character energy 👑. The performer is expected to report back either a result or an error. If the operation works, a result reply goes to the invoker. If it doesn't, an error reply goes. And if the performer is unreachable, the ESROS sends a failure indication primitive to the invoker 💀.
Operations are asynchronous, so the invoker can keep invoking more operations without waiting for replies 🦋. Synchronous or serialized operations are still supported, but only as a subset and a special case of the asynchronous service 🌸. By default, the ESRO service provider on both the invoker and performer sides supports asynchronous operation invocation. But if one side only supports serialized (synchronous) mode, it should be in agreement with the peer side 🤝.
ESROS has no authentication mechanism 🙈. Authentication is the performer's responsibility (and that's outside the scope of ESROS), and the performer is not expected to honor the invoker when it is not authenticated. Lowkey the most important bit of this whole section 🔥.
The ESROS operation model is shown 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 ModelHere's the time sequence diagram for the ESRO services 🎀:
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 services2. ESRO SERVICE DEFINITIONS ✨
ESRO service primitives are illustrated in Figure 2, Table 1 and Table 2. The services and primitives are described in the following sections 🧚.
The ESROS-User accesses ESRO services through the 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 💜:
- Acknowledged Result, and
- Non-Acknowledged Result
Here's the full list of ESRO services and their types:
_____________________________________________
| 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 ServicesNow, the difference between the modes is in their reliability of service and their efficiency 🍓. Reliability of service is defined based on how the invoker and performer understand the success or failure of the operation on the peer side. Table 3 and Table 4 summarize what the performer understands about success or failure on the invoker side in different situations. In these tables, the FAILURE.indication refers to the primitive generated by the protocol, not the failure of the local provider. ✨
2.1. Acknowledged Result Service Mode 🦋
In this service mode, the result is acknowledged by the invoker, but the mechanism by which the acknowledgment is accomplished may not be reliable 🙃. Table 3 summarizes the relationship between the 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 the performer side are generated if the result or error is acknowledged by the invoker ✅.
The FAILURE.indication on the performer side is generated if the result or error is not acknowledged by the invoker, or if there is a local failure on the performer side.
From the protocol point of view, the FAILURE.indication might happen because either the result/error PDU or the ack PDU is lost. The outcome is that a FAILURE.indication is not robust, because the operation may have been successful from the invoker's perspective 😭. One way of compensating for this shortcoming is having the performer verify the FAILURE.indication in a separate operation 💖.
Here are the ESRO service primitives and their parameters:
____________________________________________________________
| 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 parametersAnd here's how the performer and invoker line up in Acknowledged Result mode 🎀:
______________________________________________________________
|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 ModeAnd finally, the Non-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 Mode2.1.2. Invoker side
okay so on the invoker side 🫶 when the invoker gets a failure indication, the performer also ends up with that failure indication 💅
this flavour of service can be built on protocols that use a 3-way handshake 🤝
2.2. Non-acknowledged Result
in this service mode the result is not acknowledged 🙈 Table 4 sums up how the performer and invoker line up in success and failure cases ✨
2.2.1. Performer side
in this type of service, the RESULT.confirm and ERROR.confirm primitives on the performer side are generated without getting any extra info from the invoker peer 🎀 these primitives have no protocol-related meaning and carry no information beyond end-of-operation, so they're basically just a little "we're done" 🦋
the FAILURE.indication on the performer side is not generated by the protocol 🙅♀️ the only thing that can generate it there is a local failure in the service provider on the performer side 💀
2.2.2. Invoker side
the FAILURE.indication on the invoker side can happen because the invoker didn't receive a result, error, or failure from the peer performer, or because of a failure in the local service provider 😭
this type of service can be implemented by protocols based on 2-Way handshaking 🌸
2.3. Serialized Use of ESRO Services
even though the ESRO Services are defined to support asynchronous operation invocation in general, they can totally be used in the special case of synchronous (serialized) mode too 🧚 the serialized use is implementation specific, but one possible scenario goes like this 👑
2.3.1. Invoker
the invoker invokes an operation after it receives either RESULT.indication, ERROR.indication, or FAILURE.indication for the previous operation 🍓
2.3.2. Performer
the 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 service2.4. ESROS-INVOKE Service
the ESROS-INVOKE service is how an ESROS-User (the invoker) makes an OPERATION get performed by the other ESROS-User (the performer) 🔥
the ESROS Invoker User issues the ESROS-INVOKE.request primitive to invoke an operation 💖
the ESROS-INVOKE.indication primitive gives the ESROS Performer User the parameters of the invoked operation 🫶
the ESRO Service Provider issues the ESROS-INVOKE-P.confirm primitive to give the ESROS Invoker User the Invoke-ID of the invoked operation 🎀
the related service structure has three service primitives, as shown 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, and the invoker of the service has to supply it 💅
the ESROS Invoker User provides the Operation-value parameter for the ESROS-INVOKE.request primitive, and the Operation-value parameter of ESROS-INVOKE.indication is handed over 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 parameters2.4.2. Performer-address
this parameter is the address of the ESROS Performer User 🗺️ it's made up of an ESRO Service Access Point (SAP) Selector, a Transport Service Access Point (TSAP) Selector (e.g., port number), and a Network Service Access Point (NSAP) address (e.g., IP address) 🧩 the invoker of the service has to supply it 💖
the 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, and it's made up of the same three pieces: an ESRO Service Access Point (SAP) Selector, a Transport Service Access Point (TSAP) Selector (e.g. port number), and a 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 the ESROS Users, and the invoker of the service has to supply it ✨
the ESROS Invoker User provides the Invoke-argument-encoding-type parameter for the ESROS-INVOKE.request primitive, and 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, and the invoker of the service has to supply it 💅 the encoding type of the Invoke-argument is specified through the Invoke-argument-encoding-type parameter (see previous subsection) 🦋
the ESROS Invoker User provides the Invoke-argument parameter for the ESROS-INVOKE.request primitive, and 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 match that invocation with the corresponding replies (ESROS-RESULT, ESROS-ERROR, and ESROS-FAILURE services.) 🔥 the ESROS provider has to supply it 👑
this parameter is how several invocations of the service in progress (asynchronous operations) get told apart 🧚 the ESROS provider may begin to reuse Invoke-ID values whenever it chooses, with one catch: 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 doesn't 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 servicethis parameter has to be supplied by the ESROS provider (see also Section 2.7) 🌷
2.5. ESROS-RESULT Service
the ESROS-RESULT service is how an ESROS User replies to a previous ESROS-INVOKE.indication when an operation was successfully performed 🎉 this service is either confirmed or non-confirmed, depending on the service mode (see Section 2) 🦋
the related service structure has three service primitives, as shown 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, and the ESROS Performer User has to supply it 🫶
the ESROS Performer User provides the Result-argument-encoding-type parameter for the ESROS-RESULT.request primitive, and 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 parameters2.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, and the invoker of the service has to supply it 💅 the encoding type of the Result-argument is specified through the Result-argument-encoding-type parameter (see previous subsection) 🦋
the ESROS Performer User provides the Result-argument parameter for the ESROS-RESULT.request primitive, and the Result-argument parameter of ESROS-RESULT.indication is provided to the ESROS Invoker User 🫶
2.5.3. Invoke-ID ✨
okay so this parameter is how we say which invocation we're talking about 🎀 The Invoke-ID is originally generated by the ESROS provider at the time of the ESROS-INVOKE indication, and then it gets pulled out of the Invoke ID that the ESROS performer User has to supply. The value is the same as the one on the corresponding ESROS-INVOKE.indication primitive. it's the receipts, bestie 🧾💅
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 tells us which failure happened while any of the ESROS service primitives was being processed or sent. the ESROS provider is the one that has to fill it in (see also Section 2.7) 🫶
2.6. ESROS-ERROR Service 🌸
the ESROS-ERROR service is what an ESROS User uses to reply to an earlier ESROS-INVOKE.indication when the operation didn't go through. depending on the service mode (see Section 2), it's either confirmed or non-confirmed. it's giving flexible 💜
the whole service is made of three service primitives, as you can see in Figure 5 and Table 7 ✨
2.6.1. Error-value 🔥
this parameter identifies the error that's being sent back in reply to an earlier ESROS-INVOKE.indication, for an operation that didn't work out. the value has to be agreed between the ESROS-Users, and the ESROS Performer User is the one who has to supply it 👑
the ESROS Performer User gives the Error-argument parameter for the ESROS-ERROR.request primitive. the Error-argument parameter of ESROS-ERROR.indication then goes 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 says what encoding type the Error-argument uses (more on that in the next subsection). the ESROS Users have to agree on the encoding type, and the ESROS Performer User is the one who supplies it 💖
the 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 handed over to the ESROS Invoker User ✨
2.6.3. Error-argument 🌈
this parameter gives extra info about the error, again for an earlier ESROS-INVOKE.indication where the operation wasn't successfully performed. whatever type it is (if there is one) has to be agreed between the ESROS users. the ESROS Performer User has to supply it, and its encoding type is set by the Error-argument-encoding-type parameter (see the previous subsection) 🫶
Invoker Performer
ESROS AP ESROS AP
| |
| |
ESROS-FAILURE.ind. | |
--------<-----------| |
| |
| | ESROS-FAILURE.ind.
| |--------->---------
| |Figure 6: Time sequence diagram for ESROS-FAILURE service 🦋
the ESROS Performer User provides the Error-argument parameter for the ESROS-ERROR.request primitive. the Error-argument parameter of ESROS-ERROR.indication is handed over to the ESROS Invoker User 🎀
2.6.4. Invoke-ID 💜
this parameter identifies the corresponding invocation 🔥 The Invoke-ID is originally generated by the ESROS provider at the time of the ESROS-INVOKE.indication, and it gets extracted from the Invoke ID which has to be supplied by the ESROS performer User. the value is the same as the one on the corresponding ESROS-INVOKE.indication primitive 🧾
2.6.5. Failure-value 💀
this parameter identifies the failure that happened during the processing or transmission of any of the ESROS service primitives. the ESROS provider has to supply it (see also Section 2.7) 🫶
2.7. ESROS-FAILURE Service 🚨
the ESROS-FAILURE service is what the ESROS provider uses to report a failure in providing an ESROS-INVOKE, ESROS-RESULT, or ESROS-ERROR service 🙈
the related service structure is just one service primitive, as shown 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 happened during the processing or transmission of any of the ESROS service primitives. the ESROS provider has to supply it 💖
the values used to encode Failure-value are listed in Table 9 🎀
2.7.2. Invoke-ID 🦋
this parameter identifies the corresponding invocation 💜 The Invoke-ID is originally generated by the ESROS provider at the time of the ESROS-INVOKE.indication, and it gets extracted from the Invoke ID which has to be supplied by the ESROS performer User. the value is the same as the one on the corresponding ESROS-INVOKE.indication primitive ✨
3. ESRO SERVICE NOTATION 📚
ESRO service users (invoker and performer) need to agree on a well-defined set of parameters, listed below 🫶
- The operation's Argument data type.
- The operation's Result data type.
- The operation's Error data type.
- The operation's value. A specific tag which uniquely identifies the operation.
the invoker and the performer can specify these parameters in a bunch of different ways. the notation in this section is just one of them. it's not the only mechanism, and the ESRO protocol can be used independently of this notation 🌈
3.1. ES-OPERATION Notation 🧚
the Remote Operations and Operation Errors are specified in this section. the notation is defined using the macro facility from [3] 💖
the macros that let you specify 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 gets 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
ENDFigure 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 a 2-Way handshake and a 3-Way handshake. they're called the 2-Way Handshake Functional Unit and the 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)
okay bestie, let's start with the invoker side 🎀
- 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.
- An ESROS user initiates the transfer of a PDU using the INVOKE service.
- 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)
now the performer side, and this one has a lot going on 👑
- 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.
- On receipt of an ESRO-INVOKE-PDU, the ESROS provider issues an ESROS-INVOKE.indication to the ESROS performer user.
- On receipt of ESROS-RESULT.request or ESROS-ERROR.request from the performer, the provider creates the ESRO-RESULT-PDU or ESRO-ERROR-PDU.
- 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.
- 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.
- 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.
- 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
so the bind is the first step 🦋 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. The ESROS provider generates a SAP descriptor, and that descriptor gets passed back to the user. Every Invoke.request addressed to that SAP, and every PDU addressed to that SAP, gets handshaken either 3-Way or 2-Way, depending on the Functional Unit tied to the SAP and the one the user picked at 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. 🫶 so the two users have to agree on it between themselves!!
4.2.2 Invoke Service Procedure
an ESROS user starts sending a PDU with 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
this is where the IDs get made, and there are two of them 🧚
On receipt of an ESROS-INVOKE.request primitive from the ESROS user, the ESROS provider generates two invoke identifiers:
- 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).
- 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. 🔥 the combo of peer address + ref number is what keeps everything unique, periodt
4.2.4 Functional Unit Selection Procedure
when an ESRO Services user binds to an ESRO SAP, it attaches its SAP descriptor to either the 3-Way Handshake Functional Unit or the 2-Way Handshake Functional Unit 🌸
Based on the Functional Unit associated with SAP, the 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
okay so here's the connectionless rundown, and it's giving UDP vibes 💜
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). 😭 one lost segment means the whole SDU gets resent, so rude
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. ✨ no waiting around, it just keeps on going
______________________________________________________
|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 Machinethis section describes the ESROS protocols with state diagrams, and the ESROS Finite State Machine is split into four separate transition diagrams 📊 that's Table 10 up there. Each state diagram shows the state, the events, the actions taken, and the resultant state.
Details of each of the two transition diagrams for connectionless transmission and different handshakings are described in the following sections. 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
the 3-Way unit is the Acknowledged Result model of ESRO Services, so it's all about the handshake 🤝 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 results 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, here's what happens 💖
- INVOKE.request:
- Assign Invoke-ID.
- Issue ESROS-INVOKE-P.confirm primitive.
- Assign invoke reference number.
- Send operation in one
ESRO-INVOKE-PDUor in segmentedINVOKE-PDUs, depending on how big the operation is. 📦 - Initialize the retransmission counter. 🔢
- Initialize the retransmission timer. ⏰
- Invoke PDU Retransmit: 🔁
- Retransmit the operation in one
ESRO-INVOKE-PDUor in segmented PDUs while the number of retransmissions is less thanMAX_RETRANSMISSIONS. - Increment the retransmission counter. When
MAX_RETRANSMISSIONSis reached, startLAST_TIMER. Otherwise, initialize the retransmission timer.
- Retransmit the operation in one
- Last Timer: 🕰️
- Issue the
ESROS-FAILURE.indicationprimitive. - Initialize the reference number timer.
- Issue the
ESRO-RESULT-PDUorESRO-ERROR-PDU(or a reassembledESRO-RESULT-SEGMENTED-PDUorESRO-ERROR-SEGMENTED-PDUwhen the PDU arrives in segmented format): 🎉- Send
ESRO-ACK-PDU. - Issue the
ESROS-RESULT.indicationorESROS-ERROR.indicationprimitive. - Initialize the inactivity timer.
- Send
ESRO-FAILURE-PDU: 💀- Issue the
ESROS-FAILURE.indicationprimitive with the User not Responding failure cause. - Initialize the reference number timer.
- Issue the
ESRO-ACK-PDU(Hold on): 🙈- For future use (no action).
- Duplicate
ESRO-RESULT-PDUorESRO-ERROR-PDU: 👯- Initialize the inactivity timer (ignore the PDU).
- Send
ESRO-ACK-PDU.
- Invoke reference number timer: 👋
- Release the invoke reference number.
ESRO-RESULT-PDUorESRO-ERROR-PDU: 🔄- Reset the invoke reference number timer.
- Inactivity timer: 😴
- Initialize the reference number timer.
Okay, so when the ESROS provider gets an ESROS-INVOKE.request, it makes an Invoke-Reference-Number and an Invoke-ID (see Section 4.2.3). The provider then issues an ESROS-INVOKE-P.confirm primitive and hands the Invoke-ID back to the invoker. ✨
The ESROS provider starts the timer for the Invoke-ID and sends the PDU. Depending on the size of the SDU, if segmentation is needed, the SDU gets chopped up and sent as a sequence of segmented PDUs. If no ESRO-RESULT-PDU or ESRO-ERROR-PDU tied to that invoke ID shows up within the INVOKE_PDU_RETRANSMISSION_INTERVAL (see 4.6.2) period, the SDU gets sent again (as one PDU, or segmented into a sequence of segment PDUs). This keeps going for a maximum of MAX_RETRANSMISSIONS unless an ESRO-RESULT-PDU or ESRO-ERROR-PDU arrives. 🔁
If the ESRO-RESULT-PDU or ESRO-ERROR-PDU comes in segmented format, the reassembly process puts the sequence of segment PDUs back together. 🧩
If the performer sends back a Hold-on ESRO-ACK-PDU, the provider stops retransmitting the ESRO-INVOKE-PDU and waits for the ESRO-RESULT-PDU or ESRO-ERROR-PDU for a period equal to INVOKE_PDU_RETRANSMISSION_INTERVAL (see 4.6.2) multiplied by MAX_RETRANSMISSIONS (see 4.6.2, for future use). 🫶
If the ESRO-INVOKE-PDU has gone out MAX_RETRANSMISSIONS (see 4.6.2) times and still no ESRO-RESULT-PDU or ESRO-ERROR-PDU has come back, the ESROS provider sends an ESROS-FAILURE.indication primitive to the invoker, carrying the Invoke-ID of the failed PDU and the Failure-value as parameters. 😭
When an ESRO-RESULT-PDU or ESRO-ERROR-PDU arrives (whether it came as one PDU or was reassembled from segmented PDUs), the provider issues an ESROS-RESULT.indication or ESROS-ERROR.indication to the invoker user, sends an ESRO-ACK-PDU, and initializes the inactivity timer. If a duplicate ESRO-RESULT-PDU or ESRO-ERROR-PDU gets received, it is ignored, the inactivity timer is reset, and an ESRO-ACK-PDU is sent again. 🌸
____________________________________________________________________
| 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: Performer. P = Protocol, T = Timer, U = User, I = Internal.
are received, they are ignored, the inactivity timer is reset, and an ESRO-ACK-PDU is retransmitted. 🔁
When no duplicate ESRO-RESULT-PDU or ESRO-ERROR-PDU is received for a period equal to INACTIVITY_TIME (see 4.6.2), or after an ESRO-INVOKE-PDU retransmission time-out, or in the case of internal failure, the provider initializes the reference number timer. After REFERENCE_NUMBER_TIME (see 4.6.2), the reference number is released. ⏳
3-Way Handshake Connectionless Transmission: Performer ✨
For each transition number in the state diagram above, the corresponding actions are listed below:
ESRO-INVOKE-PDU(as a single PDU or a sequence of segment PDUs): 📥- Issue the
ESROS-INVOKE.indicationprimitive.
- Issue the
ESROS-RESULT.requestorESROS-ERROR.request: 📤- Add the invoke reference number to the active list.
- Transmit
ESRO-RESULT-PDUorESRO-ERROR-PDU(in a single PDU or a sequence of segment PDUs). - Set the
ESRO-RESULT-PDUorESRO-ERROR-PDUretransmission timer.
ESRO-ACK-PDU: 🥂- Initialize the invoke reference number timer.
- Issue
ESROS-RESULT.confirmorESROS-ERROR.confirm.
- Duplicate
ESRO-INVOKE-PDU: 🙃- No action (ignore the duplicate
ESRO-INVOKE-PDU).
- No action (ignore the duplicate
ESRO-RESULT-PDUorESRO-ERROR-PDUretransmission timer: ⏰- Retransmit
ESRO-RESULT-PDUorESRO-ERROR-PDU(in a single PDU or in a segmented format) while the number of retransmissions is less thanMAX_RETRANSMISSIONS. - Increment the transmission counter.
- Retransmit
- Duplicate
ESRO-INVOKE-PDU: 🔁- Retransmit
ESRO-RESULT-PDUorESRO-ERROR-PDU. - Reset the
ESRO-RESULT-PDUorESRO-ERROR-PDUretransmission timer. - Re-initialize the number of retransmissions counter to 1.
- Retransmit
- Duplicate
ESRO-INVOKE-PDU: 🔄- Reset the invoke reference number timer.
- Internal failure: 🚨
- Send
ESRO-FAILURE-PDU. - Release the invoke reference number.
- Send
- Last time: 🕰️
- Issue
ESROS-FAILURE.indication. - Initialize the invoke reference number timer.
- Issue
- Invoke reference number timer: 👋
- Release the invoke reference number.
- Duplicate
ESRO-ACK-PDU: 👯- Reset the invoke reference number timer.
- Hold-on ACK request: 🙈
- Send Hold-on
ESRO-ACK-PDU(for future use).
- Send Hold-on
Okay so on receipt of an ESRO-INVOKE-PDU, the ESROS provider issues an ESROS-INVOKE.indication to the ESROS performer user. The provider ignores the duplicate ESRO-INVOKE-PDUs. 👀
If there's an internal failure or no response from the performer user, the provider sends an ESRO-FAILURE-PDU and releases the invoke reference number. 💔
When the provider gets a Hold-on request from the performer user, or based on other information, it sends a Hold-on ESRO-ACK-PDU (future use). 🫶
When the ESROS performer user sends either ESROS-RESULT.request or ESROS-ERROR.request, the ESROS provider starts the retransmission timer for the ESRO-RESULT-PDU or ESRO-ERROR-PDU and transmits it in a single PDU or as a sequence of segment PDUs. If the ESRO-ACK-PDU tied to the Invoke-ID doesn't arrive within RESULT_ERROR_PDU_RETRANSMISSION_INTERVAL (see 4.6.2), the PDU gets retransmitted. 🔁
While the provider is waiting for an ESRO-ACK-PDU and a duplicate ESRO-INVOKE-PDU shows up, the ESRO-RESULT-PDU or ESRO-ERROR-PDU is retransmitted (in a single PDU or as a sequence of segment PDUs), the retransmission timer is reset, and the retransmission counter is re-initialized to 1. 🌈
If no ESRO-ACK-PDU is received after MAX_TRANSMISSIONS (see 4.6.2), the provider issues an ESROS-FAILURE.indication primitive to the performer user, carrying the Invoke-ID of the failed PDU and the Failure-value as parameters. Then the provider sets the reference number timer and releases the reference number after REFERENCE_NUMBER_TIME (see 4.6.2). 😵
When an ESRO-ACK-PDU tied to the Invoke-ID arrives before MAX_TRANSMISSIONS (see 4.6.2), the provider issues an ESROS-RESULT.confirm or ESROS-ERROR.confirm primitive, sets the reference number timer, and releases the reference number after REFERENCE_NUMBER_TIME (see 4.6.2). 🥳
Duplicate ESRO-ACK-PDUs and duplicate ESRO-INVOKE-PDUs are ignored while the provider waits for the reference number timer to expire. 💜
4.3.3. 2-Way Handshake Functional Unit ✨
okay bestie, this one is the Not-Acknowledged Result model of ESRO Services 💅 and it runs on 2-Way handshaking, so there's no extra "yep got it" step at the end 🫶
the performer's RESULT.confirm and ERROR.confirm are generated by a timeout 🕰️ if no duplicate ESRO-INVOKE-PDU shows up within a set period, the provider goes "okay, we're done" and issues RESULT.confirm or ERROR.confirm 💖
on the performer side, FAILURE.indication comes from a local failure, or after the retransmissions of ESRO-RESULT-PDU or ESRO-ERROR-PDU time out 😭
on the invoker side, FAILURE.indication shows up if there's a local failure or if an ESRO-FAILURE-PDU arrives 🙈
INVOKE, RESULT, and ERROR PDUs can each go as one single PDU (if it fits) or as a sequence of segmented PDUs 🧩
2-Way Handshake Connectionless Transmission: Invoker 🦋
for every transition number in the state diagram above, here's what happens 👑
- INVOKE.request:
- Assign Invoke-ID.
- Issue ESROS-INVOKE-P.confirm primitive.
- Assign invoke reference number.
- Send ESRO-INVOKE-PDU in a single PDU or as a sequence of segment PDUs.
- Initialize retransmission counter.
______________________________________________________________
| State |STA01 |STA02 |STA03 |
| |2-Way HS |Invoke PDU |Invoker |
| |CL Invoker |Send |RefNu Wait|
|Event |Start | | |
|-------------------------+-----------+-----------+----------|
|U: INVOKE.req. |(1) STA02 | | |
|-------------------------+-----------+-----------+----------|
|T: Invoke PDU Retransmit | |(2) STA02 | |
|-------------------------+-----------+-----------+----------|
|T: Last Timer | |(3) STA03 | |
|-------------------------+-----------+-----------+----------|
|P: Result/Error PDU | |(4) STA03 | |
|-------------------------+-----------+-----------+----------|
|P: Failure-PDU | |(5) STA03 | |
|-------------------------+-----------+-----------+----------|
|P: Duplicate Result PDU | | |(6) STA03 |
|-------------------------+-----------+-----------+----------|
|T: RefNu Timer | | |(7) STA01 |
|_________________________|___________|___________|__________|Table 13: ESROS State Transition Diagram-Connectionless Transmission, 2-Way HS: Invoker p = Protocol, T = Timer, U = User, I = Internal.
- Invoke PDU Retransmit:
- Retransmit ESRO-INVOKE-PDU (in a single PDU or in a sequence of segment PDUs) while the number of retransmissions is less than MAX_RETRANSMISSIONS.
- Increment the transmission counter. When MAX_RETRANSMISSIONS is reached, start LAST_TIMER.
- Last Timer:
- Issue ESROS-FAILURE.indication primitive.
- Initialize reference number timer.
- ESRO-RESULT-PDU or ESRO-ERROR-PDU:
- Issue ESROS-RESULT.indication or ESROS-ERROR.indication primitive.
- Initialize reference number timer.
- ESRO-FAILURE-PDU:
- Issue ESROS-FAILURE.indication primitive with User not Responding failure cause.
- Initialize reference number timer.
- Duplicate ESRO-RESULT-PDU or ESRO-ERROR-PDU:
- Reset Invoke reference number timer.
- Invoke reference number timer:
- Release the invoke reference number.
when an ESROS-INVOKE.request comes in, the ESROS provider makes an Invoke-Reference-Number and an Invoke-ID (see 4.2.3) ✨ it issues an ESROS-INVOKE-P.confirm primitive and hands the Invoke-ID to the invoker 🎀
then the ESROS provider starts the timer for the Invoke-ID and sends the PDU 📮 the PDU goes out as a single PDU or a sequence of segment PDUs 🧩 if the ESRO-RESULT-PDU or ESRO-ERROR-PDU tied to that invoke ID doesn't show up within the INVOKE_PDU_RETRANSMISSION_INTERVAL (see 4.6.2) period, the PDU gets resent 🔁 this keeps going for a maximum of MAX_RETRANSMISSIONS, unless an ESRO-RESULT-PDU or ESRO-ERROR-PDU arrives first 💅
if the ESRO-INVOKE-PDU has gone out MAX_RETRANSMISSIONS (see 4.6.2) times and still no ESRO-RESULT-PDU or ESRO-ERROR-PDU has landed, the ESROS provider sends an ESROS-FAILURE.indication primitive to the invoker 💀 that primitive carries the Invoke-ID of the failed PDU and the Failure-value as parameters 📝 and if an ESRO-FAILURE-PDU is received, the ESROS provider does the same thing: sends an ESROS-FAILURE.indication primitive, with 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, the provider issues an ESROS-RESULT.indication or ESROS-ERROR.indication to the invoker user and starts the Reference-Number timer ⏰ duplicate ESRO-RESULT-PDU or ESRO-ERROR-PDU get ignored, no drama 🙅♀️ if there's an internal failure, the provider starts the reference number timer too 🌸 and once REFERENCE_NUMBER_TIME (see 4.6.2) is up, the reference number gets released 🦋
2-Way Handshake Connectionless Transmission: Performer 🌈
this is the performer's side, and it's giving state machine realness 🤌
___________________________________________________________________
| State |STA01 |STA02 |STA03 |STA04 |
| |2-Way HS CL|Invoke PDU|Result PDU|Performer |
|Event |Performer |Received |Retransmit|RefNu Wait |
| |Start | | | |
|-------------------+-----------+----------+----------+-----------|
|P: Invoke-PDU |(1) STA02 | | | |
|-------------------+-----------+----------+----------+-----------|
|P: Invoke-PDU | |(2) STA02 |(5) STA03 |(7) STA04 |
| Duplicate | | | | |
|-------------------+-----------+----------+----------+-----------|
|U: RESULT.req. | |(3) STA03 | | |
|-------------------+-----------+----------+----------+-----------|
|I: Failure | |(4) STA01 | | |
|-------------------+-----------+----------+----------+-----------|
|T: Inactivity Timer| | |(6) STA04 | |
|-------------------+-----------+----------+----------+-----------|
|T: RefNu Timer | | | |(8) STA01 |
___________________________________________________________________Table 14: ESROS State Transition Diagram-Connectionless Transmission, 2-Way HS: Performer. P = Protocol, T = Timer, U = User, I = Internal.
for each transition number in the state diagram above, the actions go like this 👑
- ESRO-INVOKE-PDU (received in a single PDU or reassembled from a sequence of segment PDUs):
- Issue ESROS-INVOKE.indication primitive.
- Duplicate ESRO-INVOKE-PDU:
- No action (ignore the duplicate ESRO-INVOKE-PDU).
- EROS-RESULT.request or ESROS-ERROR.request:
- Add invoke reference number to the active list.
- Transmit ESRO-RESULT-PDU or ESRO-ERROR-PDU (as a single PDU or as a sequence of segment PDUs.)
- Set Inactivity timer.
- Internal failure:
- Send ESRO-FAILURE-PDU.
- Release the invoke reference number.
- Duplicate ESRO-INVOKE-PDU:
- Retransmit ESRO-RESULT-PDU or ESRO-ERROR-PDU (as a single PDU or as a sequence of segment PDUs.)
- Set Inactivity timer.
- Inactivity Timer:
- Issue ESROS-RESULT.confirm.
- Initialize invoke reference number timer.
- Duplicate ESRO-INVOKE-PDU:
- Reset invoke reference number timer.
- Invoke reference number timer:
- Release the invoke reference number.
when an ESRO-INVOKE-PDU arrives (as a single PDU or reassembled from a sequence of segment PDUs), the ESROS provider issues an ESROS-INVOKE.indication to the ESROS performer user 📬 the provider ignores duplicate ESRO-INVOKE-PDUs, because it's not about the repeats 🙄
if there's an internal failure or the performer user doesn't respond, the provider sends an ESRO-FAILURE-PDU and releases the invoke reference number 💔
when the ESROS performer user sends either ESROS-RESULT.request or ESROS-ERROR.request, the ESROS provider starts the inactivity timer for the ESRO-RESULT-PDU or ESRO-ERROR-PDU and transmits it (in a single PDU or as a sequence of segment PDUs) 🚀 if a duplicate ESRO-INVOKE-PDU tied to the Invoke-ID shows up within the INACTIVITY_TIME interval (see 4.6.2), the PDU gets retransmitted 🔁
if no duplicate ESRO-INVOKE-PDU arrives within the INACTIVITY_TIME interval (see 4.6.2), the provider issues an ESROS-RESULT.confirm or ESROS-ERROR.confirm primitive, sets the reference number timer, and releases the reference number after REFERENCE_NUMBER_TIME (see 4.6.2) 🌷
the duplicate ESRO-INVOKE-PDUs get ignored while the provider waits for the reference number timer to expire ⏳✨
4.3.4. Segmentation and Reassembly ✨
okay bestie, tiny ESRO-SDUs get to vibe with the efficiency of the connectionless feature of ESROS 🦋 (see Section 4.3.1).
When an ESRO-SDU is too chunky to fit in one connectionless PDU, it gets segmented and reassembled 🧩. The upper layers might have their own version of this with different levels of efficiency 💅. If the upper layers can also do segmentation/reassembly on top of the ESROS one, the ESROS user gets to decide whether to use the ESROS mechanism, depending on stuff like how reliable the underlying network is 🫶.
If it's the ESROS layer doing the segmentation/reassembly, operation segments aren't acknowledged. ngl that's super efficient over a reliable underlying network 🔥. The catch is that if one segment fails, every single segment gets retransmitted 💀.
If you want acknowledged segments, the ESROS user should implement it using the acknowledged result service of ESROS 🌸.
The ESROS segmentation/reassembly is accommodated by:
- Use of two additional PDU codes for segmented INVOKE PDU.
- Use of one byte segmentation information, which contains First/Other flag and segment number.
- Use of unused bits of RESULT and ERROR PDUs to identify a segmented RESULT or ERROR PDU.
Segmentation and Assembly applies to INVOKE, RESULT, and ERROR SDUs 🎀.
The sender of the message is responsible for segmenting the ESRO-SDU into segments that fit in CL PDUs. The segmented ESRO-SDU goes out as a sequence of segments, each carrying a piece of the SDU. The Invoke-Reference-Number is a unique identifier used as the segment identifier, so it's what ties all the segments of one ESRO-SDU together 🔗. On top of that, the first segment tells you the total number of segments (number-of-segments). The other segments carry a segment sequence number (segment-number) 🔢. The receiver is responsible for sequencing them (based on segment-number) and reassembling the entire ESRO-SDU 🧚.
Segmenting/Reassembling over the Connectionless ESRO Service
The sender maps the original ESRO-SDU into an ordered sequence of segments. Several ESRO-SDU segment sequences can exist over the same ESROS association, and they're told apart by their Invoke-Reference-Number (used as the segment identifier) 👯.
All segments in the sequence have the same Invoke-Reference-Number, assigned by the sender 💜.
The first segment specifies the total number of segments. All segments in the sequence except the first one shall be sequentially numbered, starting at 1. The first segment has an implicit segment number of 0 🍓.
Each segment is transmitted in one UDP PDU and is sent by the sender. All segments of a segmented ESRO-SDU are identified by the same Invoke-Reference-Number. For a given operation, the receiver should not impose any restrictions on the order of arrival of segments 🌈.
There's no requirement that any segment's content be of CLRO_SMALL_PDU_MAX_SIZE for connectionless transmission. However, no more than CLRO_MAX_PDU_SEGMENTS segments can be derived from a single ESRO-SDU 🙈.
The receiver reassembles a sequence of segments into a single ESRO-SDU. An ESRO-SDU shall not be further processed unless all of its segments are received. Failure to receive the SDU shall be determined by the following event:
- Expiration of Reassembly Timer (see Section 4.3.4).
When that failure happens, the receiver shall discard the partially assembled sequence 🗑️.
The reassembly is done as described below:
- In the case of a segmented Invoke ESRO-SDU, the encoding type and operation-value fields are carried in the first segment used for the whole operation. These three fields are ignored in the segments other than the first one.
- In the case of a segmented Result ESRO-SDU, the encoding type of the first segment is used for all segments. The encoding type field of segments other than the first one are ignored.
- In the case of a segmented Error ESRO-SDU, the encoding type and Error-value field of the first segment are used for all segments. These two fields are ignored in segments other than the first one.
The sender sends all segments of a segmented ESRO-SDU one after the other. There's no mechanism for retransmitting a single segment 🙅♀️. If the sender gets a failure indication for a segment, that means the receiver failed in the reassembly process, so the sender retransmits the whole ESRO-SDU (all segments) 😭.
Reassembly Timer
The Reassembly Timer is a local timer maintained by the receiver of the segments, and it helps with the reassembly function ⏰. It determines how long a receiver waits to receive all segments of a segment sequence.
The Reassembly Timer shall be started on receipt of a segment with a different sequence identifier (Invoke-Reference-Number). Once all the segments of a sequence are received, the corresponding reassembly timer shall be stopped 🛑.
The value of the Reassembly Timer is defined based on the network characteristics and the number of segments. This means the transmission of all segments of a single ESRO-SDU must be completed within this time limit ⌛.
4.4. Structure and Encoding of ESROS PDUs 🎀
Five PDU types are used in the ESRO protocol, and they're described in the following sections. PDU type coding is presented in Table 15 💖.
The octets are numbered in increasing order, starting from 1. The bits of an octet are numbered from 1 to 8, where 1 is the low-order bit 🔢.
4.4.1. ESRO-INVOKE-PDU Format
Bit string format of the ESRO-INVOKE-PDU is represented in Table 16 and Table 17 🦋.
_______________________________________
| PDU Name |PDU Type Code |
_______________________________________
| ESRO-INVOKE |0 |
| ESRO-RESULT |1 |
| ESRO-ERROR |2 |
| ESRO-ACK |3 |
| ESRO-FAILURE |4 |
| ESRO-SEGMENTED-INVOKE |5 |
_______________________________________
Table 15: PDU Coding __________________________________________________________
|Bit |8 | 7 |6 |5 |4 |3 |2 |1 |
|----------+--+------------------------+--+--+--+--+--+--|
|Octet 1 | Performer SAP |0 |0 |0 |0 |
|----------+--+------------------------+--+--+--+--+--+--|
|Octet 2 | Invoke Reference Number |
|----------+--+------------------------+--+--+--+--+--+--|
|Octet 3 |Parameter Encoding Type |Operation Value |
|----------+--+------------------------+--+--+--+--+--+--|
|Octet 4 | |
| ... | Operation Information |
|Octet N | |
|__________|_____________________________________________|
Table 16: ESRO-INVOKE-PDU format. ESRO-INVOKE-PDU Type Code =
0. Note: Invoker SAP = Performer SAP - 1. _______________________
| Value | Meaning |
|_______|______________|
| 0 | BER [5] |
|_______|______________|
| 1 | PER [4] |
|_______|______________|
| 2 | XDR [8] |
|_______|______________|
| 3 | Reserved |
|_______|______________|
Table 17: Parameter Encoding Type for ESRO-INVOKE-PDU ---------------------------------------------------------
|Bit | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
|--------|-----------|-----|-----|-----|-----|-----|-----|
| | Parameter | | | | | | |
| | Encoding | | | | | | |
|Octet 1 | Type | 0 | 0 | 0 | 0 | 0 | 1 |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
|--------|-----------------------------------------------|
|Octet 2 | Invoke Reference Number |
|--------|-----------------------------------------------|
|Octet 3 | |
|... | Result-parameter |
|Octet N | |
---------------------------------------------------------
ESRO-RESULT-PDU Type Code = 1.
Table 18: ESRO-RESULT-PDU format _______________________
| Value | Meaning |
|_______|______________|
| 0 | Basic |
|_______|______________|
| 1 | Packed |
|_______|______________|
| 2 | XDR |
|_______|______________|
| 3 | Reserved |
|_______|______________|
Table 19: Parameter Encoding Type for ESRO-RESULT-PDU4.4.2. ESRO-RESULT-PDU Format
Bit string format of the ESRO-RESULT-PDU is represented in Table 18 and Table 19 🌸.
4.4.3. ESRO-ERROR-PDU Format 💖
okay bestie, the bit string format of the ESRO-ERROR-PDU is laid out in Table 20 and Table 21 🎀 look at this structure, it's giving organized 💅
---------------------------------------------------------
|Bit | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
|--------|-----------|-----|-----|-----|-----|-----|-----|
| | Parameter | | | | | | |
| | Encoding | | | | | | |
|Octet 1 | Type | 0 | 0 | 0 | 0 | 1 | 0 |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
|--------|-----------------------------------------------|
|Octet 2 | Invoke Reference Number |
|--------|-----------------------------------------------|
|Octet 3 | Error Value |
|--------|-----------------------------------------------|
|Octet 4 | |
|... | Error parameter |
|Octet N | |
---------------------------------------------------------
ESRO-ERROR-PDU Type Code = 2.
Table 20: ESRO-ERROR-PDU format
_______________________
| Value | Meaning |
|_______|______________|
| 0 | Basic |
|_______|______________|
| 1 | Packed |
|_______|______________|
| 2 | XDR |
|_______|______________|
| 3 | Reserved |
|_______|______________|
Table 21: Parameter Encoding Type for ESRO-ERROR-PDUthe Parameter Encoding Type bits go in Octet 1 and the Error Value goes in Octet 3, so the error message gets its own little lane 🧚
---------------------------------------------------------
|Bit | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
|--------|-----------------------|-----|-----|-----|-----|
| | ESRO-ACK-PDU Type | | | | |
|Octet 1 | | 0 | 0 | 1 | 1 |
|--------|-----------------------------------------------|
|Octet 2 | Invoke Reference Number |
---------------------------------------------------------
ESRO-ACK-PDU Type Code = 3.
Table 22: Fields of ESRO-ACK-PDU
_____________________________________________
| ESRO-ACK-PDU Type | Meaning |
|___________________|________________________|
| 0 |Complete 3-way handshake|
|___________________|________________________|
| 1 | Hold on |
|___________________|________________________|
Table 23: Encoding of ESRO-ACK-PDU Type4.4.4. ESRO-ACK-PDU Format 🦋
so the bit string format of the ESRO-ACK-PDU is shown in Table 22 and Table 23 🫶 the ACK type is what tells you whether the 3-way handshake is done or if it's a "hold on" moment ✨
4.4.5. ESRO-FAILURE-PDU Format 🥀
bit string format of the ESROS-FAILURE-PDU is represented in Table 24 and Table 25 📋
and this part matters, bestie: the first nibble of the first octet of ESRO-FAILURE-PDU shall be set to zero. no skipping that one 🙅♀️
----------------------------------------------------------
|Bit | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
|--------|-----------------------|-----|-----|-----|-----|
|Octet 1 | Not used | 0 | 1 | 0 | 0 |
|--------|-----------------------------------------------|
|Octet 2 | Invoke Reference Number |
|--------|-----------------------------------------------|
|Octet 3 | Failure Value |
----------------------------------------------------------
ESRO-FAILURE-PDU Type Code = 4.
Table 24: ESRO-FAILURE-PDU format
________________________________________
| Failure Value | Meaning |
|_______________|_______________________|
| 0 |Transmission failure |
|_______________|_______________________|
| 1 |Out of local resources |
|_______________|_______________________|
| 2 | User not responding |
|_______________|_______________________|
| 3 |Out of remote resources|
|_______________|_______________________|
Table 25: Encoding of failure value4.4.6. ESRO-INVOKE-SEGMENTED-PDU Format 🧩
the bit string format of the ESRO-INVOKE-SEGMENTED-PDU is represented in Table 25 and Table 26 🌸
Note: Invoker SAP = Performer SAP - 1. 👑
---------------------------------------------------------
|Bit | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
|--------|-----------------------|-----|-----|-----|-----|
|Octet 1 | Not used | 0 | 1 | 0 | 0 |
|--------|-----------------------------------------------|
|Octet 2 | Invoke Reference Number |
|--------|-----------------------------------------------|
|Octet 3 | Failure Value |
----------------------------------------------------------
ESRO-FAILURE-PDU Type Code = 4.wait, scratch that, I double-posted the failure layout by accident 🙈 the real segmented layout is the one below, and it's the big one with Performer Service Access Point Selector up top 💅
-----------------------------------------------------------------
|Bit | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
|--------|---------------------------|------|------|------|------|
|Octet 1 | Performer Service | 0 | 1 | 0 | 1 |
| | Access Point Selector | | | | |
|--------|-------------------------------------------------------|
|Octet 2 | Invoke Reference Number |
|--------|-------------------------------------------------------|
| | Parameter | |
| | Encoding | |
|Octet 3 | Type | Operation Value |
| | | |
| | | |
| | | |
|--------|-------------------------------------------------------|
|Octet 4 |First/| |
| |Other | Segment Number |
|--------|-------------------------------------------------------|
|Octet 5 | |
|... | Operation Information |
|Octet N | |
----------------------------------------------------------------|
ESRO-INVOKE-PDU Type Code = 5.
Table 26: ESRO-INVOKE-SEGMENTED-PDU format
_______________________
| Value | Meaning |
|_______|______________|
| 0 | Basic |
|_______|______________|
| 1 | Packed |
|_______|______________|
| 2 | XDR |
|_______|______________|
| 3 | Reserved |
|_______|______________|
Table 27: Parameter Encoding Type for ESRO-INVOKE-SEGMENTED-PDUso the first/other bit and the segment number do the heavy lifting here, and the rules are:
- for the first segment, the
first/otherbit is set to one, and the segment number field has the total number of segments 🔢 - for segments other than the first one, the
first/otherbit is set to zero, and the segment number field has the sequence number of that segment 🧵
the vibe check on the first segment is that it's the main character 👑 its Performer-SAP, Parameter-Encoding-Type, and Operation-Value fields are the ones the performer actually uses, and they get ignored in every other segment, so don't stress about them there 💖
4.4.7 ESRO-RESULT-SEGMENTED-PDU Format 🎀
okay bestie, the bit layout for the ESRO-RESULT-SEGMENTED-PDU lives in Table 28 and Table 29 💅
- for the first segment, the first/other bit is set to one, and the segment number field holds the total number of segments ✨
- for every segment after the first, the first/other bit is set to zero, and the segment number field holds that segment's sequence number 🦋
ngl the Parameter-Encoding-Type field only matters on the first segment. the invoker is the one who uses it, and the segments after the first just ignore it 🙈
-----------------------------------------------------------------
|Bit | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
|--------|-------------|------|------|------|------|------|------|
| | Parameter | | | | | | |
| | Encoding | | | | | | |
|Octet 1 | Type | 0 | 1 | 0 | 0 | 0 | 1 |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
|--------|-------------------------------------------------------|
|Octet 2 | Invoke Reference Number |
|--------|-------------------------------------------------------|
|Octet 4 |First/| |
| |Other | Segment Number |
|--------|-------------------------------------------------------|
|Octet 5 | |
|... | Result Parameter |
|Octet N | |
----------------------------------------------------------------|
ESRO-RESULT-SEGMENTED-PDU Type Code = 1.
Table 28: ESRO-RESULT-SEGMENTED-PDU format
_______________________
| Value | Meaning |
|_______|______________|
| 0 | Basic |
|_______|______________|
| 1 | Packed |
|_______|______________|
| 2 | XDR |
|_______|______________|
| 3 | Reserved |
|_______|______________|
Table 29: Parameter Encoding Type for ESRO-RESULT-SEGMENTED-PDU4.4.8 ESRO-ERROR-SEGMENTED-PDU Format 🧚
the bit string for the ESRO-ERROR-PDU is shown in Table 30 and Table 31 💖
- for the first segment, the first/other bit is set to one, and the segment number field holds the total number of segments ✨
- for segments other than the first one, the first/other bit is set to zero, and the segment number field holds the sequence number of that segment 🦋
again, the Parameter-Encoding-Type field on the first segment is what the invoker uses, and it gets ignored in the rest of the segments 🫶
-----------------------------------------------------------------
|Bit | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
|--------|-------------|------|------|------|------|------|------|
| | Parameter | | | | | | |
| | Encoding | | | | | | |
|Octet 1 | Type | 0 | 1 | 0 | 0 | 1 | 0 |
| | | | | | | | |
| | | | | | | | |
| | | | | | | | |
|--------|-------------------------------------------------------|
|Octet 2 | Invoke Reference Number |
|--------|-------------------------------------------------------|
|Octet 3 |First/| |
| |Other | Segment Number |
|--------|-------------------------------------------------------|
|Octet 4 | Error Value |
|--------|-------------------------------------------------------|
|Octet 5 | |
|... | Error Parameter |
|Octet N | |
----------------------------------------------------------------|
ESRO-ERROR-SEGMENTED-PDU Type Code = 2.
Table 30: ESRO-ERROR-SEGMENTED-PDU4.5 Concatenation and Separation 🌈
the concatenation and separation procedure lets you pack several ESRO-PDUs into one TSDU, and the ESRO-CONCATENATED-PDU is what makes that happen 🎀
_______________________
| Value | Meaning |
|_______|______________|
| 0 | Basic |
|_______|______________|
| 1 | Packed |
|_______|______________|
| 2 | XDR |
|_______|______________|
| 3 | Reserved |
|_______|______________|Table 31: Parameter Encoding Type for ESRO-SEGMENTED-ERROR-PDU
an ESRO-CONCATENATED-PDU can hold one or more of these PDUs: INVOKE, RESULT, ERROR, FAILURE, and ACK 💅
the ESRO-PDUs inside a concatenated set can be told apart by their length indicator. every ESRO-PDU gets a one byte length indicator sitting in front of it 🔥
the number of ESRO-PDUs that fit in one ESRO-CONCATENATED-PDU is capped by the maximum length of TSDU 👑
4.5.1 Procedures 🦋
Concatenation
the ESROS provider does the concatenating like this:
- PDU type code 8 is used.
- the length indicator, which is the total length of the first ESRO-PDU (header and data) in octets, goes right after the PDU type code, in the length indicator field of the ESRO-CONCATENATED-PDU (see Section 4.5.2).
- the first PDU (header and data) goes after the length indicator field, in the ESRO-PDU field of the ESRO-CONCATENATED-PDU (see Section 4.5.2).
- for any additional ESRO-PDU, its length indicator and PDU are concatenated on.
Separation
when the ESRO service provider gets a PDU with PDU type code 8, it splits the concatenated PDUs apart like this:
- the length indicator field right after the type code field (see Section 4.5.2) gives the total length of the first PDU in octets.
- the first PDU sits in the ESRO-PDU field after the length indicator field (see Section 4.5.2).
- any additional PDU has a length indicator field giving the total length of that PDU, followed by the PDU itself (see Section 4.5.2).
- PDUs keep getting separated until the end of the ESRO-CONCATENATED-PDU is reached 🧚
4.5.2 ESRO-CONCATENATED-PDU format 💖
the bit string for an ESRO-CONCATENATED-PDU holding several ESRO-PDUs is shown in Table 32 ✨
Length Indicator field
this field is one octet, and it shows up in front of each ESROS-PDU inside the concatenated PDU. the value tells you the total length, in octets, of the ESRO-PDU (including header and data) that comes right after it 🫶
ESRO-PDU field
this field holds an ESRO-INVOKE-PDU, ESRO-RESULT-PDU, ESRO-ERROR-PDU, ESRO-FAILURE-PDU, or ESRO-ACK-PDU 🌸
the length of this field is set by the length indicator field that comes right before it 💅
4.6 ES Remote Operations Protocol Parameters 👑
4.6.1 PDU size 🍓
- CLRO_SMALL_PDU_MAX_SIZE:
________________________________________________________________
|Bit | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 |
|--------|---------------------------|------|------|------|------|
|Octet 1 | Not used | 1 | 0 | 0 | 0 |
|--------|-------------------------------------------------------|
|Octet 2 | Length Indicator |
|--------|-------------------------------------------------------|
|Octet 3 | |
|... | ESRO-PDU |
|Octet N | |
|--------|-------------------------------------------------------|
|Octet | |
| N+1 | Length Indicator |
|--------|-------------------------------------------------------|
|Octet | |
| N+2 | ESRO-PDU |
| ... | |
|--------|-------------------------------------------------------|
| ... | ... |
|________|_______________________________________________________|
ESRO-CONCATENATED-PDU Type Code = 8.
Table 32: ESRO-CONCATENATED-PDU formatthe value of this parameter should be chosen based on the specifics of the subnetwork in use. for example, in CDPD the maximum size of SN-Userdata size can be up to 2048 bytes (see part 404-2.b of CDPD Specification V1.1). based on this value and IP and UDP protocol information fields, the value of CLRO_SMALL_PDU_MAX_SIZE may be determined for CDPD. again based on the specifics of the subnetwork, the optimum value of CLRO_SMALL_PDU_MAX_SIZE may best be determined based on field experience and may be smaller than the maximum size that the subnetwork supports 🔥
- CLRO_SEGMENTED_PDU_MAX_SIZE
the value of this parameter should be chosen based on the specifics of the subnetwork in use. the optimum value of CLRO_SEGMENTED_PDU_MAX_SIZE may best be determined based on field experience 🌈
- CLRO_MAX_PDU_SEGMENTS
the value of this parameter should be chosen based on the specifics of the subnetwork in use. the optimum value of CLRO_MAX_PDU_SEGMENTS may best be determined based on field experience. in any case, this value should be smaller than 127 🙈
4.6.2 Timers ⭐
- INVOKE_PDU_RETRANSMISSION_INTERVAL:
the INVOKE_PDU retransmission interval should be specified and optimized based on the characteristics of the network in use.
- RESULT_ERROR_PDU_RETRANSMISSION_INTERVAL:
the RESULT and ERROR-PDU retransmission interval should be specified and optimized based on the characteristics of the network in use.
- MAX_RETRANSMISSIONS:
the maximum number of retransmissions should be specified and optimized based on the characteristics of the network in use.
- INACTIVITY_TIME:
the minimum waiting time during which no duplicate PDU is received should be specified and optimized based on the characteristics of the network in use.
- REFERENCE_NUMBER_TIME: the reference number lifetime timer should be specified and optimized based on the characteristics of the network in use. 🧚
4.6.3. Use of lower layers ✨
okay so the ESRO protocol runs over UDP, and it uses port number 259 🦋. that's the whole thing for this one, bestie 💅
5. ACKNOWLEDGMENTS 🫶
okay, big shoutout time 📣 development of this spec was funded by AT&T Wireless Services (AWS) 💖 it's derived from AT&T Wireless Services' document titled: "Limited Size Remote Operation Services (LSROS)", Revision 0.8, dated April 20, 1995 🎀
also, this spec is technically consistent with the CDPD Forum's Implementor's Guidelines Part 1028, Release 1.03, dated June 21, 1996 ✨ so it lines up with that too, which is iconic 👑
6. SECURITY CONSIDERATIONS 💀
okay, this part is SERIOUS bestie 😭 ESROS has no authentication mechanism at all. zero. none. nada 🙈
authentication is the responsibility of the performer, and that's outside the scope of ESROS 🧚 so the performer is not expected to honor the invoker when the invoker isn't authenticated. not me being dramatic, that's just the rule 💅
7. AUTHORS' ADDRESSES 🌸
here are the authors, all nicely listed so you can reach out 💌
Mohsen Banan
Neda Communications, Inc.
17005 SE 31st Place
Bellevue, WA 98008
EMail: mohsen@neda.com
Mark S. Taylor
Director of Strategic Engineering
AT&T Wireless Services
Wireless Data Division
10230 NE Points Drive
Kirkland, WA 98033-7869 USA
EMail: mark.taylor@airdata.com
Jia-bing Cheng
AT&T Wireless Services
Wireless Data Division
10230 NE Points Drive
Kirkland, WA 98033-7869 USA
EMail: jcheng@airdata.comReferences 📚
these are the sources the spec leans on, so you know where the ideas came from 🧠
- [1] Remote Operations: Model, Notation and Service Definition, March 1988. Recommendation X.219.
- [2] Remote Operations: Protocol Specification, March 1988. Recommendation X.229.
- [3] Specification of Abstract Syntax Notation One, 1988. Recommendation X.208.
- [4] Information Processing --- Open Systems Interconnection --- Specification of Packed Encoding Rules for Abstract Syntax Notation One (ASN.1). International Standard 8825-2.
- [5] Information Processing --- Open Systems Interconnection --- Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1), 1987. International Standard 8825.
- [6] Srinivasan, R., "Binding protocols for onc rpc version 2". RFC 1833, Sun Microsystems Inc, August 1995.
- [7] Srinivasan, R., "Rpc: Remote procedure call protocol specification version 2". RFC 1831, Sun Microsystems Inc, August 1995.
- [8] Srinivasan, R., "Xdr: External data representation standard". RFC 1832, Sun Microsystems Inc, August 1995.
ngl that's the whole spec, periodt 🌈✨
📦 where this page comes from
- ietf: rfc2188 1997-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms