Rank, a Resource Management Protocol for Allocation

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.1. Definitions of Commonly Used Terms

This section provides definitions for terms that have a specific meaning to the Rank protocol and that are used throughout the text.¶

Rank Session

Control messages and data transactions between two or more nodes, covering the connection between Rank end-points.¶

Rank Process

Execution instance of the Rank protocol in a node, possibly having zero or more sessions. Along the document this concept might be also mentioned as a Rank Instance.¶

Talker Node

A source end-point node for a Rank process to occur. This node type exists in both distributed and centralized environments, and it is responsible for starting a Rank session.¶

Listener Node

A destination end-point node for a Rank process to occur, to whom a talker intends to handle a data connection.¶

Intermediate Node

A node type that interconnects the talker to a the listeners (and other intermediate nodes if such a scenario applies), being also part of the resource admission request evaluation to some of the specified stated requirements.¶

Controller Node

An exclusive node type for a centralized network architecture, that can get information of all the featured nodes in a network (or in a network of networks), estimate paths, and delegate reservations within surrogate nodes (that can be intermediate or listener nodes).¶

Admission Request

Request made by a talker to listeners, initiating a Rank session with discovery and estimation features. It contains a list of requirements with variables for each requested resource, and a priority.¶

Suitability Value

A single precision floating point value that reflects the capability of a Rank node performing an admission request. This value is in range [0, 1]: if 0 then the node is not capable of accepting the admission request and rejects it; otherwise the node is capable of guaranteeing to perform the admission request.¶

2.2. Related Work

The fundamental basis for this work is the Resource ReSerVation Protocol (RSVP) [RFC2205], established in 1997, which enabled network nodes to flood PATH messages to discover and verify node capacity for quality-of-service (QoS) guarantees. Since that time, several new solutions were developed by the scientific community, but one cannot simply assess them through a unique time axis: as Rank is a resource management protocol supported by discovery, estimation, allocation, and sharing features, the related work must be assessed in these four axes.¶

Starting with resource discovery, RSVP used basic flooding techniques to discover network nodes, constantly sending messages that created heavy network overhead. More recent protocols, such as the Stream Reservation Protocol (SRP) [_802.1Q] improved upon this by using admission controls and allowing for path cancellations, reducing overhead. Nonetheless, other works can also be found using location-aware matching (client requests are matched with the geographically-closest available edge nodes with DNS [Horvath25]), semantic and context-aware discovery (architectures may use semantic layers to match resources based on user intent, time constraints, or historical patterns [Farhoudi25]), or other approaches differing on decentralized/centralized architectures (there are solutions with decentralized Named Data Networking (NDN) that enables dropping resource breadcrumbs to advertise availability without overloading nodes [Kondo24], and other more popular solutions rely on a centralized entity to monitor active resources [Kubernetes]).¶

On resource estimation, SRP [_802.1Q] is also considered as related work, since it uses admission control procedures to check the local capabilities, per node, of performing what is being requested in terms of network and time resources. Analytically, there are other solutions that dwell beyond linear admission requests such as by using probabilistic models [Li18], dynamic optimizations [Abou21], or reinforcement learning [Zhang20]. Outside academic environments, Kubernetes [Kubernetes] also apply tools like estimation via auto-scaling that automatically adjusts the number of workload replicas.¶

Looking now to resource allocation, over the years researchers have tried numerous mathematical and predictive methods to solve the allocation feature with limited resources. From early deterministic models to current solutions using deep reinforcement learning approaches there are still plenty of difficulties on this execution, be it from requirements of knowing everything about a network’s state in advance, or requiring massive computational overhead and long training times, respectively. Other solutions developed apply game theory [Yu25] and market models [Nguyen18], as these problems often involve multiple tenants and competing service providers. Moreover, other solutions can also be found using joint optimization in hybrid edge-cloud systems, in which research mainly focus on computation offloading with the help of dynamic partitioning to minimize latency and energy use by deciding which parts of a task should be processed locally versus sent to the cloud [Yi20].¶

Finally we must address resource sharing. Early studies introduced opportunistic and voluntary resource-sharing models, in which end-users or third-party devices temporarily contribute idle computing or storage resources to nearby tasks [Wang25]. Other approaches could also be found with game-theoretic models [Zafari21] to create structured sharing, auctions to negotiate different types of heterogeneous resources simultaneously [Liu24], or blockchain and smart contracts to also enforce trust on these transactions [Olaniyan18].¶

Despite significant advancements across edge computing, a unified set of open challenges continues to restrict the efficient discovery, estimation, allocation, and sharing of resources. Scalability and adaptability remain the most persistent hurdles, as current models struggle to perform in highly dynamic, mobile, and dense networks without introducing crippling computational or energy overheads. Furthermore, modern systems frequently fail at multi-objective optimization, finding it difficult to balance conflicting constraints like latency, computational power, bandwidth, and battery life simultaneously. Finally, in open, multi-tenant edge environments, establishing interoperability, trust, and security is a critical unresolved issue; the field lacks cohesive, vendor-neutral standardization and continues to grapple with how to enforce secure, fair, and verifiable resource transactions without triggering the heavy latency penalties associated with mechanisms such as blockchain.¶

2.3. Organization of this Document

The first two sections of this specification give a general view of the protocol and a clear description of the most critical concepts to retain during the reading of this document. From Section 3 to 6 explain the protocol’s mechanisms in detail. Packet formats are specified in the appendices.¶

The detailed specification of the protocol is presented in terms of data structures. This is done in order to make the explanation more precise.¶

2.4. Acknowledgements

The authors would like to thank Pedro Veloso Teixeira for the large discussion sessions and main alignment of contents in this document. This work was supported by Fundação para a Ciência e Tecnologia within grant FCT.2021.06223.BD, and by European Union Programa FEDER, Operação n.º 14795 - COMPETE2030-FEDER-00929900.¶

5.1. Sending Protocol Packets

When a Rank node sends a Rank protocol packet, it fills in the fields of the standard Rank protocol header as follows. For more details on the header format consult Appendix A.2.1.¶

Version (V)

Set to 0, the version number decremented by a unit of the protocol as documented in this specification.¶

Packet type

The type of the Rank packet, such as EAR, MAR, among others.¶

Reserved (R)

Set to 0. This field is reserved for future usages and other values will leave this packet to be parsed as invalid.¶

Session Identifier

Generated as a new ULID value. In the case the session being created is a replica of another that exists until the current Rank node, then a new ULID value must be created with a new timestamp, but with the same entropy value.¶

For more information on the format of the specific Rank protocol packet types, consult the sections listed in Table 1.¶

5.2. Receiving Protocol Packets

Whenever a protocol packet is received by the Rank node it is inserted in a specific depositing queue from the communication layer it was captured from. Depending on the communication level, several header considerations will be taken into consideration before reaching Rank validation. For instance, in order for the packet to be accepted at IP level, it must pass a number of tests, such as verifying if the IP checksum is correct; and verifying if the packet’s IP destination address is the IP address of the receiving interface. Nonetheless, Rank must have an extension so to prevent current operative systems to discard ingress packets for not having a IANA-valid IP protocol identifier (0x9B).¶

Next, the Rank packet header is verified. The fields specified in the header must match those configured for the receiving interface. If they do not, the packet should be discarded:¶

• The version number field must specify protocol version 1 (value 0, since this value is written as decremented by one unit).¶

• The type field must match with one of the types detailed in Table 1.¶

• The reserved field must specify 0.¶

• The session identifier must not have a timestamp for before or after 10 minutes than the current system clock.¶

5.3. Enabling a Handler for a Session

When a message is received by a Dispatcher in a Rank instance, if it passes the first validation steps as described in Section 5.2, then the packet will be enqueued in a depoisiting queue that is managed then by the Process entity. On such a reception, a proper algorithm will sort the type of packet but first will check if the session identifier is known and, in case it is, will verify if its last known state.¶

The first question that is applied is if the session identifier is known. If the identifier is not known, meaning that no entry exist in the Store with such session identifier as key, then a Handler must be created with this session identifier. As such, a new session identifier must be created and then the Handler must be saved in the Store, with Ready status. After this the Handler must be executed and its processing must parse and process the received message.¶

The Handler may only have one state at a time. The various states that a Handler might have are document in this section. Figure 1 shows the graph of the Handler state changes. The arcs of the graph are labelled with the event causing the state change. These events are documented in Section 5.4. The Handler state machine is described in more detail in Section 5.5.¶

                             ┌─────────┐
         ┌──────EAR Received─┤  Ready  ├─MAR Received───────┐
         │                   └────┬────┘                    │
         │                      RxAPI                       │
         │                        │                         │
         │                        │                         │
 ┌───────▼───────┐        ┌───────▼──────┐           ┌──────▼──────┐
 │   Assessing   │   ┌────┤  Presenting  ├─────┐     │   Auction   │
 └──┬────┬────┬──┘   │    └───────┬──────┘   MAR   ┌─┤   Bidding   │
   REF   │  MAR Sent │         MAR Sent      Sent  │ └──────┬──────┘
   Sent  │    └─┐   EAR           │            │  BID Sent  │
    │   EAR     │   Sent  ┌───────┼────────────┼───┘        │
    │   Sent    │    │    │       │            │            │
    │    │   ┌──▼────▼────▼─┐     │     ┌──────▼──────┐   0-BID
    │    └───▶ Pre-Reserved ◀─────┼─EAR │   Auction   │    Sent
    │        └──┬────┬────┬─┘     │ Sent┤   Waiting   │     │
    │    ┌──────┘    │    │       │     └──────┬──────┘     │
    │    │         ACC    EAR     │            │            │
    │    │    Received    Received│  ┌REP Sent─┘            │
    │    │           │    │       │  │                      │
    │    │   ┌───────▼────▼─┐     │  │  ┌─────────────┐     │
    │    │   │   Reserved   ├─*1──┼──┼──▶ Replenished │     │
    │    │   └───────┬──────┘     │  │  └──────┬──────┘     │
    │    │           └REF ─────┐  │  │        REF           │
    │   REF           Received │  │  │      Received        │
    │   Received               │  │  │         │            │
    │    └───────────────────▶─▼──▼──▼─◀───────┘            │
    └────────────────────────▶ Closed  ◀────────────────────┘
                             └─────────┘
     *1 Received REP

In the case the session identifier is already known, the last known state of its corresponding handler must be checked, since only some state values are expected to be resumed. If such a session identifier’s handler is currently running (this can only happen in the case in which a node is in Auction Waiting state and has already received a suitability value), then a new suitability value will be saved in the Handler’s bid set and the message is then discarded. Otherwise, if the Handler is not currently running, then further processing should only be considered if the last state of the Handler is of Pre-Reserved, Reserved, Auction Waiting, Replenishing, or Ready. If so, the Handler should be retrieved from the Store, resumed, and the new message should be delivered to it for further processing. In any other state, the message should be discarded and Process should wait for a new incoming message.¶

Right after executing for the first time or resuming a Handler, as the incoming message is delivered for processing to the handler, a selective section of the algorithm is chosen to be performed according to the message type. This selection is described in the following sections, per packet type, as pointed by Table 1.¶

5.4. Events Causing Handler State Changes

State changes can be effected by a number of events. These events are pictured as the labelled arcs in Figure 1. The label definitions are listed below. For a detailed explanation of the effect of these events on Rank protocol operation, consult Section 5.5.¶

RxAPI

Request Reservation via API.¶

X Received

X message was received through an ingress interface.¶

X Sent

X message was sent through an egress interface.¶

0-BID Sent

A BID message with a zero-value suitability value was sent through an egress interface. This happens to transmit the information that the current node does not have capability to perform the received admission request.¶

5.5. The Handler State Machine

A detailed description of the handler state change follows. Each state change is invoked by an event (Section 5.4). This event may produce different effects, depending on the current state of the handler. For this reason, the state machine below is organized by current handler state and received event. Each entry in the state machine described the resulting new handler state and the required set of additional actions.¶

 State(s):      Ready

    Event:      EAR Received

New state:      Assessing

   Action:      The receiving node was waiting on a Rank packet or request, and an EAR message was received as sent by another Rank node. This induces the transition between the Ready state to the Assessing state.

 State(s):      Ready

    Event:      RxAPI

New state:      Presenting

   Action:      The receiving node was waiting on a Rank packet or request, and a request incoming from the Rank API was received, as sent by a another local operating system’s process. This induces the transition between the Ready state to the Presenting state.

 State(s):      Ready

    Event:      MAR Received

New state:      Auction Bidding

   Action:      The receiving node was waiting on a Rank packet or request, and a MAR message was received as sent by another Rank node. As this message does not translates itself as a propagation of a Rank session, rather an evaluation of this node’s capabilities of performing the admission request, the current node assesses its capabilities and prepares itself to send the resulting suitability value back to sender.

 State(s):      Assessing

    Event:      REF Sent

New state:      Closed

   Action:      The current node where the Handler is being executed assessed its own capabilities of performing the admission request and it estimated that it is not capable to support the requested resources. For this reason, a REF message is sent to declare such result.

 State(s):      Assessing

    Event:      EAR Sent

New state:      Pre-reserved

   Action:      The current node where the Handler is being executed assessed its own capabilities of performing the admission request and it estimated that it is capable to support the requested resources. On assessing the connections it had to proceed with this request in line to the listener, it found that there is only a single path available, thus it sent an EAR message to it. With this, the Handler pre-reserved the requested resources.

 State(s):      Assessing

    Event:      MAR Sent

New state:      Pre-reserved

   Action:      The current node where the Handler is being executed assessed its own capabilities of performing the admission request and it estimated that it is capable to support the requested resources. On assessing the connections it had to proceed with this request in line to the listener, it found that there are more than one path available, thus it sent an MAR message to each of the alternatives. With this, the Handler pre-reserved the requested resources in the current node.

 State(s):      Presenting

    Event:      EAR Sent

New state:      Pre-reserved

   Action:      The current node where the Handler is being executed assessed its own capabilities of performing the admission request and it estimated that it is capable to support the requested resources. On assessing the connections it had to proceed with this request in line to the listener, it found that there is only a single path available, thus it sent an EAR message to it. With this, the Handler pre-reserved the requested resources.

 State(s):      Presenting

    Event:      REF Sent

New state:      Closed

   Action:      The current node where the Handler is being executed assessed its own capabilities of performing the admission request and it estimated that it is not capable to support the requested resources. For this reason, a REF message is sent to declare such result.

 State(s):      Presenting

    Event:      MAR Sent

New state:      Auction Waiting

   Action:      The current node where the Handler is being executed assessed its own capabilities of performing the admission request and it estimated that it is capable to support the requested resources. On assessing the connections it had to proceed with this request in line to the listener, it found that there are more than one path available, thus it sent an MAR message to each of the alternatives. With this, the inner reservation must change state to pre-reserved, while the Handler state switches to Auction Waiting.

 State(s):      Auction Bidding

    Event:      BID Sent

New state:      Pre-reserved

   Action:      The current node where the Handler is being executed was requested to estimate its capability of performing an admission request included in a MAR message. The outcome of this estimation—a suitability value—must now be sent over a BID message towards the origin of the MAR message.

 State(s):      Auction Bidding

    Event:      0-BID Sent

New state:      Closed

   Action:      The current node was requested to estimate its capability of performing an admission request included in a previous MAR message. The outcome of this estimation revealed that this Rank node cannot support the admission request and, as such, a null value (zero) must be sent over a BID message to the origin of the MAR message.

 State(s):      Pre-reserved

    Event:      REF Received

New state:      Closed

   Action:      A REF message was received in an ingress interface. This message must enable the deletion of the subject session and, as such, the current Handler must close its operation.

 State(s):      Pre-reserved

    Event:      ACC Received

New state:      Reserved

   Action:      An acceptation message was received meaning that a given pre-reservation state of an Handler may now transition into a reserved state.

 State(s):      Pre-reserved

    Event:      EAR Received

New state:      Reserved

   Action:      An EAR message set after the reception of a MAR message requesting a suitability value was received, meaning that a given pre-reservation state of an Handler may now transition into a reserved state. This EAR message does not contain any list of requirements, as this was already sent in the previous MAR message.

 State(s):      Auction Waiting

    Event:      EAR Sent

New state:      Pre-reserved

   Action:      The Handler has previously estimated its own suitability value regarding its session admission request and it reached a non-nullable value, admitting the support of the requested resources. The inner Reservation, at this Handler state, is already in pre-reserved state.

 State(s):      Auction Waiting

    Event:      REF Sent

New state:      Closed

   Action:      The current node reached a timeout on waiting for suitability values. This means that the session cannot proceed its processing and, thus, this Handler must close execution.

 State(s):      Reserved

    Event:      REP Received

New state:      Replenishing

   Action:      The current node has received a replenishing message to delete any resource reservation done within the context of this session.

 State(s):      Replenishing

    Event:      REF Received

New state:      Closed

   Action:      The current node received a refusal message to cancel the Handler session. This Handler must close its execution.

 State(s):      Reserved

    Event:      REF Received

New state:      Closed

   Action:      The current node received a refusal message to cancel the Handler session. This Handler must close its execution.

5.6. Handler Process on EAR Message Received

The reception of an EAR message is the most common execution segment of all the message parse and exchange algorithm in the Rank protocol operation. As soon as the Handler enters this execution line its state must change to one of the following.¶

• Update state to Presenting if the current node is the beginner of a Rank session (the message may be coming from the API).¶

• Update state to Assessing if the current node is just an intermediate node between a talker and a listener.¶

Having switched the state, then the handler must verify if the EAR message have reached its listener or not. In such a case, the node must self-assess its own capabilities of performing the admission request and, if such answer is also positive, then the affected resources must be reserved. With this line of operation, an ACC message must be sent back and the handler state must change to Reserved, and then suspend execution.¶

If the current handler is not running in the matching listener, then it is required, first, to check if there is any suitability value already saved for this given session. If so, that means that this EAR message is only serving to confirm a path that, previously was checked by having MAR and BID messages sent back and forth, and now we should skip to get new connections that lead the current node to the next ones in line with the targeted listener.¶

Considering that there is no current suitability values stored for this current session, then the node must self-assess on its own capabilities to perform the admission request contained in the EAR message. Both in this scenario and in the latter one, where the procedure is equivalent, if there is no capability to perform the admission request, then the processing of this session must terminate here and a REF message should be sent back to inform of that event, switching the state of the Handler to Closed, just before terminating the thread.¶

If the current node is able to support the admission request that was described in the received EAR message, then a pre-reservation of such resources must be done. Here, we now reach the same step as before if there was a suitability value already expecting us in the Handler’s data structure: we need to proceed to verify which are the candidate connections from this current node to the listener.¶

Three possibilities can happen in this situation: there is a single connection path to the listener; there are multiple connection paths to the listener; or there is none. In the latter case the procedure is simple, as a REF message must be sent back to notify that a dead-end was reached and, thus, the request could not be completed. In this situation the handler switches its state to Closed and then terminates its thread.¶

In the case of existing a single connection path towards the listener, then a new cloned EAR message must be sent over that connection. As the message is sent, the handler’s state must switch to Pre-Reserved and, internally to the Handler, the information about which was the message source node must be saved as a reservation past node.¶

In the case of existing more than a single connection path towards the listener, the procedure is similar to the single path case, but differing on the type of message sent, and the number of sent messages as well. In this case, a MAR message must be sent to each candidate next node in line towards the targeted listener. As soon as the MAR messages are sent, the Handler must switch is state to one of the following states. With this state update, and internally to the Handler, the information about which was the message source node must be saved as a reservation past node.¶

• Update state to Pre-Reserved if the last state was Assessing.¶

• Update state to Auction-Waiting if the last state was Presenting.¶

In both cases of single and multiple targeting, a parallel execution must be started in the end of this procedure, whilst the Handler thread is suspended waiting for new future actions: a timeout action is spawned so that, if no action happens on timeout, the actions done by the Handler are automatically subject to a rollback action. The management of the timeouts and such asynchronous calls must be the responsibility of the Timeout Handler component. In these cases, different timeout values must be considered for waiting for answer on EAR and MAR messages. When a timeout is reached and the Handler’s actions are subject to rollback, its state must also change to Closed before terminating the main thread.¶

5.7. Handler Process on MAR Message Received

When a MAR message is received in an ingress interface where Rank is capturing data, the Handler must start this set of steps for processing this type of messages. As soon as the Handler is created to handle this new MAR message, the Handler state must change to Auction Bidding.¶

After switching states, a self-assessment is required, so to estimate the suitability value that will represent the current capability of the Rank node to perform the admission request that is in place within the MAR message, by its list of requirements and priority. From this assessment two values are relevant: if the suitability value is zero, that means that the current node is unable to perform the admission request; otherwise, the node is able to perform and, as such further steps are required.¶

If the node assesses as unable to perform the admission request, then a BID message must be sent back with suitability value zero, and the Handler’s state must change to Closed before terminating itself.¶

If the node is able to perform the admission request, then a BID message with the estimated suitability value must be sent back. After this step, the state must be changed to Pre-Reserved, and the pre-reservation must be performed, of the affected resources in the current node. In this situation, again, a parallel execution must be done to coordinate a timeout action, controlled by the Timeout Handler: if no action is taken (no answer back after sending BID message), then the Handler’s actions must be subject to rollback.¶

5.8. Handler Process on BID Message Received

When a BID packet is received by a Handler, the Handler must verify if its state currently matches with Auction Waiting. If it does not match, then the Handler must update its state to Closed and then terminate its thread. Otherwise, a waiting time for all bids must start, in which each suitability value received from candidates are received and collected within the Handler data structure (Bid Set). This action occurs during a time slot bound by a Auction timeout, managed by the Timeout Handler: when the timeout is reached, the node must not waiting for any other suitability value. Consequently, if all candidates answer back before timeout being reached, the processing must continue.¶

With all suitability values duly collected in the Bid Set, the Handler must now check for its cardinal, leaving three alternative execution paths: an execution path if there is no suitability values in the set; an execution path if there is a single unique maximum suitability value in the set; or an execution path if there are several equal maximum suitability values in the set.¶

The first alternative (if there is no suitability value in the set) is straightforward to handle: in this case the Handler must cease its functions, sending a REF message back to the original node source, and switch its state to Closed beforehand.¶

The second alternative (if there is a single and unique maximum value in the Bid Set) requires the Handler to prepare an EAR message to send to the node that had estimated such suitability value. In such a case this EAR message is sent to the node that replied with a BID message carrying this suitability value, and this message is to be sent with an empty payload, as the next node already received and assessed its own capability of performing the admission request.¶

The third alternative (if there are multiple equal maximum suitability values within the Bid Set) requires the session identifier to be regenerated and translated in the Translation Table. In the case the Rank session gets in this stage, this means that replicas must be propagated from this point on, so that if any of these future sessions get refused, then only such branch is deleted. For this reason, a new ULID (hereby denoted by ULID) must be generated for each selected suitability value and the pair [ULID, ULID] must be saved in the Translation Table. With this, new EAR messages must be sent to each suitability value estimator with ULID* with an empty payload.¶

After sending the EAR messages, a timeout for receiving answers must be started by the Timeout Handler. On timeout, the Handler actions must be rollback and the Handler state must switch to Closed and have its thread terminated.¶

5.9. Handler Process on ACC Message Received

Receiving an ACC packet means that the current Handler processing this content is now in a node that already has a pre-reservation for a held session. As soon as the processing steps into this stage, then the Handler must automatically switch the pre-reservation to a reservation, by swtiching the Reservation state (the lifecycle of a reservation is described in detail in Section 5.12).¶

As this communication is already being done from the listener back to the talker, now we need to unravel if the session identifiers that we are receiving are originals or replicas that were once generated at this node, when the request first arrived here through an EAR/MAR packet. To do so we need to check if the session identifier exists in the Translation Table.¶

If the session identifier exists in the Translation Table, then a new ACC packet must be sent to the next node in line to the talker, with the original session identified (hereby called ULID, differing from the replica ULID*). On this event, the Handler state must switch to Reserved and, then, the current node (accepting node) must be added to the Handler’s data structure as next node in reservation. With this action, the Handler’s thread is suspended.¶

If the session identifier does not exist in the Translation Table we need to check if the current node is the origin node for this session.¶

If this node is the origin of this session, then the result (error code) of the reservation request must be sent back to the API, where the request was first triggered from: with this action, the Handler state must switch to Reserved and, then, the current node (accepting node) must be added to the Handler’s data structure as next node in reservation, and then the threading mechanism is suspended.¶

If this node is not the origin of this session, then an ACC packet must be sent over the next node in line to the talker. With this action, the Handler state must switch to Reserved and, then, the current node (accepting node) must be added to the Handler’s data structure as next node in reservation, and then the threading mechanism is suspended.¶

5.10. Handler Process on REF Message Received

Receiving a REF packet means that the current Handler processing this content is now in a node might have a pre-reservation. As soon as the processing steps into this stage, if such a scenario applies, then the pre-reservation must be revoked with the given session identifier from the REF packet. In this case, if there was a pre-reservation in place, then the Reservation itself must transition its state to Cleared (the lifecycle of a reservation is described in detail in Section 5.12).¶

As this communication is already being done from the listener back to the talker, now we need to unravel if the session identifiers that we are receiving are originals or replicas that were once generated at this node, when the request first arrived here through an EAR/MAR packet. To do so we need to check if the session identifier exists in the Translation Table.¶

If the session identifier exists in the Translation Table, then the replica session identifier (hereby denoted as ULID*) must be deleted from the Translation Table. If the Translation Table, with this action, is now clear, then the Handler’s state switches to Closed, without no further action, thus suspending the thread. If the Translation Table is not empty after this action, then a REF message must be sent to the next node in line with the talker. This action must be followed by the switching of the Handler’s state to Closed, and then its thread must be suspended.¶

If the session identifier does not exist in the Translation Table we need to check if the current node is the origin node for this session.¶

If this node is the origin of this session, then the result (error code) of the reservation request must be sent back to the API, where the request was first triggered from: with this action, the Handler state must switch to Closed and then the threading mechanism is suspended.¶

If this node is not the origin of this session, then a REF message must be sent to the next node in line with the talker. This action must be followed by the switching of the Handler’s state to Closed, and then its thread must be suspended.¶

5.11. Handler Process on REP Message Received

When receiving a REP message, the Handler must switch its state to Replenishing. After this action, the Handler must check if the current node is the session’s listener or not. If the current node is the session’s listener, then a REF packet must be sent to the next node in line to the talker, and then the Handler’s state must change to Closed and the thread is terminated.¶

In the scenario that the current node is not the session’s listener, then, if the current session is present in the Store of the current node, then a REP packet must be sent to the next node in line to the listener.¶

In this situation, the execution must be asynchronously set so that the current thread is suspended and another is spawn handling a timeout for the REP answer. The Timeout Handler must spawn this timeout thread that, if the time arrives with no REP answer (a REF message for the same session), then it must check if the current session identifier is in the Translation Table.¶

If the session identifier is in the Translation Table, then the Handler’s state must switch to Closed and such a identifier must be deleted from the Store, sending a REF message back (to the next node in line to the talker) with the original session identifier that was found matching in the Translation Table. On this change, the Handler with the original session identifier must also switch its state to Closed.¶

If the session identifier is not in the Translation Table, then a REF message must be sent to the next node in line with the talker, switching the state to Closing and terminating the thread.¶

5.12. Lifecycle of a Reservation

                              ┌─────────┐
┌────unconsider()─────────────┤ Created │
│                             └─┬──┬──┬─┘
│                               │  │  │
│         ┌wait_for_sacrifice()─┘  │  └────────────reserve()─┐
│         │                        │                         │
│         │                        │                         │
│ ┌───────▼───────┐          pre_reserve()                   │
│ │   Virtually   │                │                         │
│ │ Pre-Reserved  │                │                         │
│ └──┬────┬───────┘                │                         │
│    │    │                        │   ┌─mark_pre_reserved()─┼────┐
│    │    │                        │   │                     │    │
│    │    │                ┌───────▼───▼──┐                  │    │
│    │    │                │ Pre-Reserved ├─────────────┐    │    │
│    │    │                └───────┬──────┘             │    │    │
│    │    │                        │         mark_reserved() │    │
│    │    │                   replenish()               │    │    │
│    │    │                        │                 ┌──▼────▼────┴─┐
│    │    └─reserve()──────────────┼─────────────────▶   Reserved   │
│    │                             │                 └───────┬──────┘
│    │                             │                         │
│    │                             │                    replenish()
│    │                             │                         │
│    └─replenish()────────────▶────▼────┐                    │
└─────────────────────────────▶ Cleared ◀────────────────────┘
                              └─────────┘

State changes can be effected by a number of events. These events are pictured as the labelled arcs in Figure 2. The label definitions are listed below. For a detailed explanation of the effect of these events on Rank protocol operation, consult Section 5.13.¶

Wait for Sacrifice

As the current Rank node is saturated (cannot openly receive any other resource reservation for the set of resources in its admission request), the node will sacrifice another reservation that might create a vacant space for it, if it has a lower priority than the more recent one.¶

Unconsider

A reservation is deleted as soon as it is created.¶

Reserve

A reservation is made effective in the system.¶

Pre-Reserve

A reservation is prepared (temporarily saved) in the system.¶

Replenish

A reservation is cleared from the system.¶

Mark Reserved

Promote a pre-reservation to a reservation.¶

Mark Pre-Reserved

Demote a reservation to a pre-reservation. This can only happens in internal/debug transactions or in state switchings such as a consequence from the virtually pre-reservation state handling.¶

5.13. The Reservation State Machine

A detailed description of the Reservation state change follows. Each state change is invoked by an event (Section 5.12). This event may produce different effects, depending on the current state of the Reservation. For this reason, the state machine below is organized by current Reservation state and received event. Each entry in the state machine described the resulting new Reservation state and the required set of additional actions.¶

 State(s):      Created

    Event:      Unconsider

New state:      Cleared

   Action:      A reservation entity was created but is intended to be discarded.

 State(s):      Created

    Event:      Wait for Sacrifice

New state:      Virtually Pre-reserved

   Action:      A reservation was created but, currently, the node is saturated for a given admission request. But this request is still admissable since there is another, on system, that has a lower priority and will be replenished.

 State(s):      Created

    Event:      Pre-reserve

New state:      Pre-reserved

   Action:      A reservation was created and, while it waits for an answer from the listener, it marks itself as pre-reserved.

 State(s):      Created

    Event:      Reserve

New state:      Reserved

   Action:      A reservation was created and, as it is in the listener of a session and the current node is capable of performing the admission request, then the reservation swtiches to Reserved state.

 State(s):      Virtually Pre-reserved

    Event:      Replenish

New state:      Cleared

   Action:      A reservation that was marked as virtually pre-reserved was cancelled out.

 State(s):      Virtually Pre-reserved

    Event:      Reserve

New state:      Reserved

   Action:      A reservation that was marked as virtually pre-reserved was made effective after a confirmation of all nodes in the Rank session.

 State(s):      Pre-reserved

    Event:      Mark reserved

New state:      Reserved

   Action:      A reservation that was marked as pre-reserved was made effective after a confirmation of all nodes in the Rank session.

 State(s):      Pre-reserved

    Event:      Replenish

New state:      Cleared

   Action:      A reservation that was marked as pre-reserved was cancelled out.

 State(s):      Reserved

    Event:      Mark Pre-reserved

New state:      Pre-reserved

   Action:      For internal object initialization, a reservation transitioned from a reserved into pre-reserved state.

 State(s):      Reserved

    Event:      Replenish

New state:      Cleared

   Action:      A reservation was cleared out.

5.14. Heartbeat (HBT) Message Exchange

As it is stated until this point, the Rank protocol lack some reliability features. This is an issue in the way that it can void guarantees that Rank attempts to ensure to clients, in terms of resource allocation. For instance, if a link fails between two nodes that had an already reserved path, the current solution of Rank is not capable to proceed with a solution, and all the nodes affected by such session will be, from that moment on, in a dirty state.¶

This type of issue is a situation to which protocols such as the RSVP [RFC2205] are able to assist, since they are constantly dispatching a message with the reservation request, periodically, unil it is no longer needed. Rank, on the other hand, as a stateful protocol, does not require complete messages such as EAR messages to be periodically sent between nodes, as this would create a large and dispensable overhead, as well as it would introduce a new feature to a same message type.¶

For this reason, the heartbeat message (HBT) was created, with a similar structure to the ACC and REF messages, but with a different behavior. For each new HBT message, a new ULID is generated with the same entropy value, but differing on its timestamp. When created, the HBT is always sent to the next node in line towards the listener, with a pre-defined periodicity Ti (or given as a requiremement in the list of requirements that is part of the original admission request).¶

With the periodically created HBT being sent in each node towards their next in line, it is expected that each receiving node Ni may also predict the time instant in which a given message is to be received. This behavior will not only allow each node to report on the reliability of a given connection to the listener, as it also may be used to allow an easier method to get metrics for the proximity criterion of the self-assessment algorithm that each node performs when receiveing an admission request.¶

The handling of this message cannot be compared to others, since it is not part of a creation or a deletion of a Rank session, but rather maintains a session. Alternatively to other message processing, a new entity must be introduced to handle these messages and control the state of each reservation. For this reason, a Reservations Watchdog is able to keep up with time windows for the reception of next HBT messages, for each known session with reservation at each node.¶

When a HBT message is received, the first action to perform is to check if the given ULID entropy is known at the receiving node. Considering that the ULID entropy is known, then the message arrival time is captured (as Ta), and the predicted time (Tp) is estimated from the timestamp in the ULID, Ti, and the periodicity T, as Tp = Ti + T. From here, the the delta between the prediction and the arrival time Ta - Tp is estimated, whose value will then be confronted with two threshold values: OptimalTime that defines the limit time for the best time frame to receive a HBT message, and DangerousLimitTime, that defines the limit which, if passed, the link must be considered broken.¶

The time frame to which a message arrives, determines if the link is still synchronous or not:¶

• if the time frame in which the HBT arrived is after DangerousLimitTime, then the reservation will be considered Dead, and a REP message must be sent to replenish the session.¶

• if the HBT is received within the time frame limited by DangerousLimitTime, then a new HBT message should be sent to the next node.¶

The sending of a new message is also done according to a schedule. On sending these messages, as there is only one Reservations Watchdog for all reservations, a schedule, hereby called Slots, will register the instant on a cycle, It, in which a given session will have its HBT message sent. Figure 3 basically depicts a schedule being executed, in which, per instant, each record in Slots is checked and a message is sent if an element exists in Slots[It].¶

┌────────────────┐
│ Initialization ◀────────────────────────────────────────────┐
└────────┬───────┘                                            │
         │                                                    │
         │                                                    │
         ▼                                                    │
         Λ                                                    │
        ╱ ╲             ┌────────────┐          ┌────────┐    │
       is the           │send HBT to │          │ update │    │
     session in  ───────▶next node in├──────────▶ It, in ├───▶│
     Slots[It]?         │reservation │          │  time  │    │
        ╲ ╱             └────────────┘          └────────┘    │
         V                                                    │
         │                                                    │
         │                                                    │
   ┌─────▼────┐                                               │
   │update It,│                                               │
   │ in time  ├───────────────────────────────────────────────┘
   └──────────┘

6.1. The Composition of a Document

A YANG module, although it can represent a resource configuration, cannot hold the current information regarding a configuration: it is a schema. Being a shema, it means that it only standardizes how a given resource should be as input, and, aside, we need to hold a document file able to embody such a skeleton. From this conclusion, there are, at least, two possible alternatives for the actual document: as defined by the standard, a document could be specified as XML [RFC7950] or as JSON [RFC7951].¶

Considering the medium in which we want to use a document file to transmit data from one part to another, the JSON format defines a smaller footprint specification, enabling fast transmission, being better suited for data serialization, rather than XML, which is more convenient for data interchangeability.¶

Using JSON to describe our content as defined by the YANG modules schemas, unfortunately, does not provide the entire set of features XML can supply, but all the functionalities we require are cross-compatible with JSON.¶

Still, the JSON format does not deliver the capability for serialization and deserialization. To serialize a JSON document to, later, insert it within the payload of an EAR or MAR message, the marshalling method should be language-independent as the JSON file itself. To solve this issue, we have adopted CBOR as a data format whose design goals include the possibility of extermely small code size, fairly small message size, and extensibility without the need for version negotiation [RFC8949].¶

This representation allows us to pass a JSON object from its stringified form to a marshalled byte stream which is able to be inserted in the payload field of both EAR and MAR packets. In summary, from a requirement to a payload field of a Rank packet able to carry a list of requirements, we need to perform the following steps:¶

1. Identify the YANG module (schema) tuned to represent the given requirement.¶

2. Create the JSON object, compliant to the chosen YANG module, with the given requirement specifications.¶

3. Marshal the JSON object as a CBOR object in a serialized morph.¶

4. Place the serialized CBOR object in position within the payload of a Rank packet.¶

6.2. Marshalling of Requirements

Figure 4 depicts the lifecycle of a requirement from its packing into a Rank packet until its unpacking as a Rank node receives it. In this figure, Rank handles the context of a single requirement, not a list of requirements.¶

   start
     │
     ▼                "cpu-cores": {
                        "value": 2
2 CPU cores           }                      1010010..01

    (A) ─────────────────▶ (B) ────────────────▶ (C)
     ▲                                            │
         marshalling phase                        │
     │                           ┌───── (D) ──────┘
                                 │
     │                           │
       ┌───┬─┬──┬─┬──────────────▼──────────────┐
     │ │   │ │  │ │█████████████████████████████│
       └───┴─┴──┴─┴──────────────┬──────────────┘
     │  EAR/MAR                  │
                                 │
     │                           └───── (E) ──────┐
         unmarshalling phase                      │
     │                                            ▼
    (H) ◀───────────────── (G) ◀──────────────── (F)

2 CPU cores           "cpu-cores": {         1010010..01
                        "value": 2
                      }

To handle with the multiplicity of requirements as in the list of requirements that is part of an admission request, one can create a JSON object earlier, whose content is an array with the correctly set order of requirements. As such, a list of requirements can be characterized as a JSON object carrying a variety of requirements which, by themselves, are JSON objects representing single requirements whilst being fully compliant with their matching YANG module, as depicted in Figure 5.¶

(A)  I need 2 cores of CPU, a given CBS configuration, and a minimum
                     network bandwidth of 400 Mbps.

           │                        │                       │
           ▼                        ▼                       ▼
                  {
                    [
                      {"cpu-cores": {"value": 2}}},
(B)                   {"cbs": {...}},
                      {"bandwidth": {"value": 400}}}
                    ]
                  }
                                    │
                                    ▼
(C) 01101010101001010001001010100111100110101101010100101001010101010
                                    │
                                    └───────┐
                                            │
    ┌───┬─┬──┬─┬────────────────────────────▼────────────────────────┐
(D) │   │ │  │ │█████████████████████████████████████████████████████│
    └───┴─┴──┴─┴─────────────────────────────────────────────────────┘
     EAR/MAR

Regarding the ordered key points in the enumeration before, considering now a complete list of requirements, just before serializing each JSON object requirement, we can position each item into an array within a new JSON object which must be the one, then, subject to the serialization to CBOR.¶

From the perspective of a node receiving a message containing a marshalled list of requirements as a payload, the procedures to unpack are different. For the effect, let us consider that we are working under the context of a Rank node that happens to receive an EAR message. As we are parsing the EAR message, the contents of its payload are retrieved and, now, require to be parsed.¶

As such, we must reverse the steps on how to marshal a list of requirements, but we must take into account the possibility of the received byte stream to be invalid. A received message cannot be considered as being well-formed or coming from a reliable source. It is critical to analyze the entire composition of each requirement to proceed with the handling of such an admission request.¶

The byte stream must be deserialized from its CBOR representation and translated into its JSON counterpart. Here must be able to foresee an array with a collection of requirements, each one disposed in the same order as its sender requested it: this is the list of requirements. From this step, we now need to analyze the requirements, one by one.¶

The analysis of each requirement is a critical task. So it happens that as each requirement must be compliant with a specific way of characterizing an admission request, each one must comply with the schema defined in ta surrogate YANG module that meticulously defines such criteria. FOr this matter (an here is where the linearly reverse procedure of marshalling fails), for each requirement in the list, the requirement type must be identified. Then the JSON must be validated against the matching YANG module that defines its characteristics.¶

As one verify the JSON requirement against the YANG module two outcomes could occur: in case it is valid, then another requirement is also sbuject to validation or, if there are no other requirement in queue, the whole list of requirements is adopted as a valid list and the admission request is put into action; otherwise, if a requirement does not report being valid, the remainder requirements analysis is cancelled, and the admission request is reported back as refused.¶

7.1. Contextualization of Resource Estimation

The pattern in Figure 6 depicts the transaction of messages between both resource estimation processes that occur within the execution of Rank.¶

┌──────┐                                ┌──────┐
│Talker│                                │Talker│
└─┬────┘                                └─┬────┘
  └┐               .─.                    └┐               .─.
   │.─.     ┌─────▶ N0)                    │.─.     ┌─────▶ N0)
   ( M ──┬──┘      `┬'                  ╔═▶( M ──┬──┘      `┬'
    `┬'  │   .─.                        ║   ║┬'  │   .─.
     │   └─▶( N1)   │                   ╚═══╝│   └─▶( N1)   │
    .▼.      `┬'     ─                      .▼.      `┬'     ─
   ( NN)       ─ ─ ┐  │                    ( NN)       ─ ─ ┐  │
    `┬'                                     `┬'
      ─ ─ ─ ─   ┌──┴──┴──┐                    ─ ─ ─ ─   ┌──┴──┴──┐
             └ ─│Listener│                           └ ─│Listener│
                └────────┘                              └────────┘
            (A)                                     (B)

                     ┌──────┐
                     │Talker│
                     └─┬────┘
                       └┐        ┌─────▶.─.
                        │.─.     │   ╔▶( N0)
                        ( M ──┬──┘   ║  ║┬'
                         `┬'  └──▶.─.╚══╝
                          │    ╔▶( N1)   │
                         .▼.   ║  ║┬'     ─
                      ╔▶( NN)  ╚══╝ ─ ─ ┐  │
                      ║  ║┬'
                      ╚══╝ ─ ─ ─ ─   ┌──┴──┴──┐
                                  └ ─│Listener│
                                     └────────┘
                                 (C)

┌──────┐                              ┌──────┐
│Talker│                              │Talker│
└─┬────┘                              └─┬────┘
  └┐        ┌─────▶.─.                  └┐        ┌─────▶.─.
   │.─.◀════╬═════( N0)                  │.─.     │     ( N0)
╔═▶( M ──┬──┘  b0  `┬'                   ( M ══╦──┘      `─'
║   `┬◀═╗└──▶.─.                          `┬'  ╚══▶.─.
║bN  │  ╚═══( N1)   │                      │      ( N1)
║   .▼.  b1  `┬'     ─                    .▼.      `┬'
╚══( NN)       ─ ─ ┐  │                  ( NN)      └────┐
    `┬'                                   `─'            │
      ─ ─ ─ ─   ┌──┴──┴──┐                            ┌──▼─────┐
             └ ─│Listener│                            │Listener│
                └────────┘                            └────────┘
           (D)                                   (E)

In Figure 6, a node M receives an admission request forwarded from a talker T, and intends to proceed with the request through some nodes Ni that currently grants a connection to the targeted listener L. In Figure 6 each iteration is being by a different stage:¶

• In (A) the node M receives the message.¶

• In (B) the node M proceeds to self-assess its capabilities of performing the admission request, cancelling if not capable.¶

• As node M has three connecting nodes that can provide it with a path towards the listener, in (C) node M sent a message to each neighboring node Ni, leaving them to self-assess their own capabilities of performing what is being requested.¶

• In response to this action, in (D) each node answers back to node M with a suitability value.¶

• Node M, having received the suitability values from every node Ni, in (E), it is now responsible for sorting candidates for forwarding the request message.¶

When a node has requested others to perform a resource estimation, it waits for an answer per node (as in phase (D)). To allow this action to be performed, the suitability values that come from each assessing node must be comparable amongst them. Thus, the definition of the evaluation function not only has to be the same in each node, but the range of values must also be normalized, so that each final suitability value can be comparable on the same scale throughout every node in a Rank session.¶

In this protocol, the resource estimation must be able to accommodate a varied set of resources, for which assessing the current capability of performing a request cannot be evaluated equally or through the same means. This raises the question of how to assess a list of requirements in a node. As each resource is different from another, each resource must have a unique assessment function directly defined, and the results must be output in the same fashion as the final suitability value: in a normalized range.¶

By definition, the normalized range of values for the suitability value, B, and for each individually-assessed resource value is [0, 1], in which 0 means total inability of performing what is being requested, and any other value means that a resource is capable, in a crescent ratio from 0 to 1.¶

The task of self-assessment within a node against a list of requirements is not a computationally expensive execution. Still, Rank needs to do more than just a current evaluation of the node’s resources to ensure that a resource allocation is guaranteed to be working during the interval in which is in place. Therefore, several criteria need to be taken into consideration to declare that a given node is more capable than another to perform a given task under a strict list of requirements. The following criteria were designed:¶

1. Bare-metal node resources.¶

2. Current node resources.¶

3. Priority.¶

4. Proximity.¶

5. Historical performance.¶

At the end, a suitability value, B, is computed with these constributions from the following described criteria.¶

7.2. Bare-metal Node Resources for Suitability

Considering the list of requirements, the first approach to check if the current resources are capable of performing such specifications is to check if the surrogate node has bare-metal components that could support such an admission request. Let us consider some examples to better illustrate this criterion:¶

1. The list of requirements specifies the need for 2 GB of memory. In such a case, with this criterion, the node will assess if, independently of the current state of the machine, the node has at least 2 GB of memory (used or unused).¶

2. The list of requirements states a requirement for a time-critical traffic subject to time shaping. In such a case, the node will assess if there are capabilities to sustain the time-aware shaper (TAS) standard or not.¶

A first criterion of bare-metal node resources (hereby called C1) is called as a contribution to the self-assessment score of a Rank node. This criterion can result in two possible outcomes:¶

• 0 if the node total resources do not support at least of item of the list of requirements.¶

• 1 if the node total resources do support the list of requirements.¶

In the case of reaching an outcome of 0, then no more criteria is required for the self-assessment and the current node declares itself as uncapable to perform the admission request.¶

7.3. Current Node Resources for Suitability

It is possible that the outcome of the bare-metal criterion could not be enough to be fully able to guarantee a resource allocation without further disturbances along the duration of the reservation, at least whenever the answer to it is not zero: if the answer is zero, with absolute certainty, there is no way to handling such a resource allocation in the self-assessing node; otherwise the answer is still uncertain. This ambiguity needs a second criterion, so that a tiebreaker rule is applied.¶

To advance a tiebreaker, the current node resources (hereby called C2) is relevant as it steps one more level in the direction of what is really being performed within the context of the node under assessment. To better understand how someone can tackle this assessment, it is important first to describe how requirements are defined.¶

Let us consider a list of requirements R which is given as the requirements towards a reservation that should be assessed in a given Rank node. Such a list R is a collection where the insertion order of the elements is relevant, meaning that under the context of R = (r0, r1, …, ri), the first requirement has an higher relevance than the second, r1, which consequently is highly regarded in relation to the last requirement, ri.¶

The self-assessment of a Rank node considering the criterion of their currently available node resources must take into consideration the order of requirements as they are listed within R.¶

If the list of requirements has a cardinal of 1, then the self-assessment is trivial, being the direct evaluation value of the first and only requirement in r0, as z0. Following this case, the requirements must weigh differently, in a descending order from the first to the i-th element of R.¶

                                 taumin > 0.5               taumax < 1
                                  │                                  │
┌─────────────────────────────────┼────┳─────────────────────────────┤
│                   A                ◀─╋─▶            B              │
└─────────────────────────────────┴────╋─────────────────────────────┘
0                                      │                             1
                                      tau

In Figure 7 a generic distribution of weights between two requirements is depicted, in which a given weight (tau) is applied to the first requirement. Following this reasoning, the second requirement receives the remainder weight of 1–tau, since the total assessment value must be 1, that is, in the best-case when all the assessed requirements receive the highest grade zi, the total must result in 1. To allow the distintction between both stated requirements in R, and repecting that the i-th rqeuirement as always more value than its following (i+1)-th requirement, the value of tau cannot be lower or equal to 0.5 (half its individually-graded assessment value), in tau minimum (taumin). It cannot be higher or equal than 1 in taumax, as well.¶

The choice of the tau value should be parameterizable per assessing Rank node, and is a percentage applied over the individually-graded assessment value of a requirement, z. For instance, if the list of requirements has four items, R = (r0, r1, r2, r3), the distribution of weights can be depicted as in Figure 8.¶

┌───────────────────────┳──────────────────┳─────────────┳───────────┐
│           A           ┃         B        ┃       C     ┃     D     │
└───────────────────────╋──────────────────╋─────────────╋───────────┘
0                       │                  │             │           1
                      tau 0              tau 1         tau 2

Profiting from the recursive behavior of the starting expression and of the depiction in both Figure 7 and Figure 8, one can write C2 as the following C2(x) expression:¶

C2(R) = (z0) If (cardinal(R) = 1) Else ( Mul(tau, z0) + Mul(1–tau, C2(R[1..])) )¶

The possibility of parameterizing the value of tau in the range of (taumin, taumax) allows the Rank protocol instance to control a subjective amount of requirements it wants to consider.¶

By keeping the criterion of insertion order in the list of requirements, the assessing nodes are informed of which requirements must be checked before others. Nonetheless, there is a critical condition that must be enforced. If any requirement assessment zi is equal to 0, tehn the entire criterion of the current node resource must yield the same outcome (zero). This must be enforced since a node could have resources to support a given requirement request, but not at the time of the request, meaning this criterion must be able to cancel out such an admission request and further requirements assessment.¶

7.4. Priority for Suitability

Considering both C1 and C2 criteria, the self-assessment of a Rank node for the support of a given list of requirements must not be closed yet, as two or more machines, although being improbable, could achieve a same assessment score. Within the context of the admission request not only Rank nodes receive data on the list of requirements, but also a priority level. As such, this information must be considered in the node self-assessment.¶

The priority of an admission request is a critical concept within the domain of the Rank protocol, since it is a fairness criterion for self-assessment: the criterion C3.¶

A Rank node must be able to continue the assessment of a given list of requirements if the priority of its admission request is higher than the reservations that are already allocated within the system. In the case that a list of requirements is assessed that can be supported by the current Rank node’s system, then the Rank protocol instance must be able to allow the automatic selection of an allocated reservation and proceed to replenish its used resources (check this mechanics in Section 5.12).¶

The priority level is relative to the admission request, not with each requirement element of the list of requirements R. Similarly to the latter criteria, the criterion of priority C3 must be a value from 0 to 1, reflecting the level of priority that the given admission request has, where 0 means the lowest priority level, and 1 the highest possible. The highest priority level in a Rank admission request is defined as 7, according to both Appendix A.2.2 and Appendix A.2.3. The criteria C3’s outcome is evaluated as the message priority, p, over the maximum level: C3 = p / 7.¶

7.5. Proximity for Suitability

At this point, the node was already assessed regarding these resources (both bare-metal and current resources) and the priority of the admission request. These metrics are not be enough to solve the possibility of gathering two or more equal assessment values. Moreover, some considerations are still not considered, such as the position of the assessing node, connection-wise, towards the targeted listener of the admission request. This can be solved in a new criterion, of node proximity, C4.¶

Despite being subjective, since this assessment is not dependent on any input given by the admission request besides the information regarding its intended destination, the network assessment is critical to perform. It can be decisive when to choose the next target in line towards the listener, whenever there are multiple ones to choose from, and the assessment of the criteria is still giving an equal value. This assessment will be a reflection of the network uncertainty, considering that it will lead the algorithm for resource estimation not to ignore the network dynamics and asynchronous triggering effects on network management decisions that may occur: these considerations are taken in other works to allow several decisions in approaches of resource management [Shi2024].¶

Considering a criterion for the node proximity towards a targeted listener of a given Rank admission request is a rather subjective concept, since one can draw multiple conclusions about what proximity means. In terms of proximity, one should understand an association of connectivity evaluation functions towards the final destination node of the admission request under test.¶

To accomplish the goal of this criterion, a set of functions, F, must be used (such as latency, jitter, among others), whose final result is to be gathered as the average of all functions’ outcomes. This requires that all functions operate by retrieving a value in a normalized range from [0, 1].¶

In sum, the proximity criterion results in the following possible values:¶

• 0 if the network assessment functions (F) average 0.¶

• 1 if the network assessment functions (F) average 1.¶

• Any other value in between for any other proximity assessment value, as the average of the outcomes of each function in F.¶

7.6. Historical Performance for Suitability

There is a single criterion that should be set to feature some system hysteresis during the execution of a Rank instance. This being, we introduce historic performance, C5, as a criterion to help with the self-assessment of a node against a list of requirements R. Having such an assessment could lead a node to take into consideration admission requests made before, similar to the ones currently requested, and deliver a grade on how good such a performance was.¶

The historical performance of a given allowance for an admission request should be made by leveraging the following variables:¶

• a1, ratio of the number of requirements to the average number of requested resource requirements.¶

• a2, percentage of allocated but unused resource reservation.¶

• a3, ratio of how stable are the available resources.¶

• a4, percentage of strict resource reservations over all allowed admission requests.¶

Adding to this set of variables, an entropy value should be appended so that the odds of two nodes presenting the same assessment value are severely diminished without compromising the order of magnitude of the total self-assessment final grade and the consequent disposition of this node towards the admission request outcome. For this reason, a fifth contributor to C5 should be added to generate some salt over the estimated values of a1, a2, a3, and a4: the salt, s.¶

The salt must be seen as a tool to make it difficult for two or more assessment scores to be equal. This parameter is optional, as its weight can be set to zero. Still, its use may be helpful in scenarios where several candidate nodes for a reservation may share similar network patterns or characteristics. In such a case, the salt value may help the network uncertainty assessment to provide enough random proximity values even in similar conditions. This value must not, in any way, compromise the main function of the history performance criterion. Thus, it is suggested to assign W as a small percentage weight (below 1%).¶

The variables mentioned above are designed to be joint by a weighted sum of parameterizable weights di, as described as follows, where Sum(di) = 1.¶

C5 = Mul( (1–W), [ Mul(d1, a1) + Mul(d1, a1) + Mul(d1, a1) + Mul(d1, a1) ] + Mul(W, s) )¶

7.7. The Final Value, the Suitability Value

At this point, all the individual contributors to the final self-assessment grade are estimated, and the suitability value, B, can be estimated as follows, where B is a value in [0, 1].¶

B = Mul(C1, C2, C3, Avg(C4, C5))¶

The first three terms above, relative to the first three criteria, as they are directly estimated from the list of requirements or the priority given as input (from the admission request), are multiplied by each other. The cancellation of one of these three terms must undoubtedly break the resource estimation down to zero.¶

The last two criteria, as they are estimated from other parameters rather than what has been given as input, are considered both as an average, so that they do not cancel each other out. This reflects some subjectivity characteristic of proximity and historical performance criteria.¶

10.1. Normative References

[RFC0879]

Postel, J., "The TCP Maximum Segment Size and Related Topics", RFC 879, DOI 10.17487/RFC0879, November 1983, <https://www.rfc-editor.org/info/rfc879>.

[RFC2205]

Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.

[RFC6241]

Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC7950]

Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC7951]

Lhotka, L., "JSON Encoding of Data Modeled with YANG", RFC 7951, DOI 10.17487/RFC7951, August 2016, <https://www.rfc-editor.org/info/rfc7951>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

10.2. Informative References

[_802.1Q]

IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks", IEEE Std 802.1Q-2022, DOI 10.1109/IEEESTD.2022.10004498, 22 December 2022, <https://doi.org/10.1109/IEEESTD.2022.10004498>.

[Abou21]

Abouaomar, A., Cherkaoui, S., Mlika, Z., and A. Kobbane, "Resource Provisioning in Edge Computing for Latency-Sensitive Applications", IEEE Internet of Things Journal vol. 8, no. 14, pp. 11088-11099, DOI 10.1109/JIOT.2021.3052082, 15 July 2021, <https://doi.org/10.1109/JIOT.2021.3052082>.

[Farhoudi25]

Farhoudi, M., Shokrnezhad, M., Taleb, T., Li, R., and J. Song, "Discovery of 6G Services and Resources in Edge-Cloud-Continuum", IEEE Network vol. 39, no. 3, pp. 223-232, DOI 10.1109/MNET.2024.3438096, May 2025, <https://doi.org/10.1109/MNET.2024.3438096>.

[Horvath25]

Horvath, K. and D. Kimovski, "Efficient Location-Based Service Discovery for IoT and Edge Computing in the 6G Era", Conference 2025 10th International Conference on Information and Network Technologies (ICINT), Melbourne, Australia, pp. 94-101, DOI 10.1109/ICINT65528.2025.11030893, 2025, <https://doi.org/10.1109/ICINT65528.2025.11030893>.

[Kondo24]

Kondo, D., Ansquer, T., Tanigawa, Y., and H. Tode, "Resource Breadcrumbs: Discovering Edge Computing Resources Over Named Data Networking", IEEE Transactions on Network and Service Management vol. 21, no. 3, pp. 3305-3316, DOI 10.1109/TNSM.2024.3381591, June 2024, <https://doi.org/10.1109/TNSM.2024.3381591>.

[Kubernetes]

"Kubernetes Official Page", February 2026, <https://www.kubernetes.io>.

[Li18]

Li, G., Song, J., Wu, J., and J. Wang, "Method of Resource Estimation Based on QoS in Edge Computing", Wireless Communications and Mobile Computing 7308913, 9 pages, DOI 10.1155/2018/7308913, 2018, <https://doi.org/10.1155/2018/7308913>.

[Liu24]

Liu, X., Liu, J., and H. Wu, "A family of truthful mechanisms for resource allocation with multi-attribute demand in mobile edge computing", Cluster Comput 27, 11595–11610, DOI 10.1007/s10586-024-04552-x, 2024, <https://doi.org/10.1007/s10586-024-04552-x>.

[Nguyen18]

Nguyen, D. T., Le, L. B., and V. Bhargava, "Price-based Resource Allocation for Edge Computing: A Market Equilibrium Approach", arXiv Computer Science and Game Theory, DOI 10.48550/arXiv.1805.02982, May 2018, <https://doi.org/10.48550/arXiv.1805.02982>.

[Olaniyan18]

Olaniyan, R., Fadahunsi, O., Maheswaran, M., and M. F. Zhani, "Opportunistic Edge Computing: Concepts, opportunities and research challenges", Future Generation Computer Systems Volume 89, Pages 633-645, DOI 10.1016/j.future.2018.07.040, 2018, <https://doi.org/10.1016/j.future.2018.07.040>.

[Shi2024]

Shi, Y., Yi, C., Wang, R., Wu, Q., Chen, B., and J. Cai, "Service Migration or Task Rerouting: A Two-Timescale Online Resource Optimization for MEC", IEEE Transactions on Wireless Communications vol. 23, no. 2, pp. 1503-1519, DOI 10.1109/TWC.2023.3290005, February 2024, <https://doi.org/10.1109/TWC.2023.3290005>.

[ULIDCan]

ulid, "The canonical spec for ulid", Repository GitHub, February 2026, <https://github.com/ulid/spec>.

[Wang25]

Wang, H. and M. Mir, "Voluntary resource sharing at the network edge to provide cloud services: a systematic survey", Computing 107, 113, DOI 10.1007/s00607-025-01479-y, 2025, <https://doi.org/10.1007/s00607-025-01479-y>.

[Yi20]

Yi, C., Cai, J., and Z. Su, "A Multi-User Mobile Computation Offloading and Transmission Scheduling Mechanism for Delay-Sensitive Applications", IEEE Transactions on Mobile Computing vol. 19, no. 1, pp. 29-43, DOI 10.1109/TMC.2019.2891736, 1 January 2020, <https://doi.org/10.1109/TMC.2019.2891736>.

[Yu25]

Yu, J., Liu, S., Zou, Y., Wang, G., and C. Hu, "Auction Theory and Game Theory Based Pricing of Edge Computing Resources: A Survey", IEEE Internet of Things Journal vol. 12, no. 16, pp. 32394-32418, DOI 10.1109/JIOT.2025.3565539, 15 August 2025, <https://doi.org/10.1109/JIOT.2025.3565539>.

[Zafari21]

Zafari, F., Leung, K. K., Towsley, D., Basu, P., Swami, A., and J. Li, "Let’s Share: A Game-Theoretic Framework for Resource Sharing in Mobile Edge Clouds", IEEE Transactions on Network and Service Management vol. 18, no. 2, pp. 2107-2122, DOI 10.1109/TNSM.2020.3044870, June 2021, <https://doi.org/10.1109/TNSM.2020.3044870>.

[Zhang20]

Zhang, R. and W. Shi, "Research on Resource Allocation and Management of Mobile Edge Computing Network", Informatica 44(2), DOI 10.31449/inf.v44i2.3166, 2020, <https://doi.org/10.31449/inf.v44i2.3166>.

A.1. Encapsulation of Rank Packets

Rank runs alternatively, by requester definition, over several possible communication layers. Rank packets are therefore encapsulated, depending on the situation, by other headers that might exist in each applicable scenario.¶

Rank does not define a way to fragment its protocol packets, and, when transmitted from network layer and above, depends on IP fragmentation when doing that for packets larger than the network MTU. In practice, there is no proper reason to reach a point in which a Rank packet would require more than 65,535 bytes (including the communication layer headers that are required), since this would mean that the payload is reasonably large, thus having a large list of requirements that, tendencially, loses weight reaching no value.¶

There are some other important features of Rank encapsulation:¶

• Rank is proposed to be Ethernet Type (EtherType) number 0x7265 (29 285). This number is not registered.¶

• Rank is proposed to be IP protocol number 0x9B (155). This number is not registered.¶

• Rank is proposed to be transport protocol number 7265. This number is not registered.¶

A.2. Rank Packet Formats

There are seven Rank packet types. Not all of them as distinct in structure, but serve different purposes. All Rank packet types begin with a 17 byte header. This header is described first. Each packet type is then described in a succeeding section. In these sections each packet’s division into fields is displayed, and then the field definitions are enumerated.¶

Two Rank packet types (EAR and MAR) deal with a list of requirements, that are CBOR objects [RFC8949]. Because of this, these two Rank protocol packets cannot be parsed unless the format of CBOR is also understood.¶

The receive processing of Rank packets is detailed in Section 5.2.¶

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V | Type  | R |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
+                Session Identifier (128 bits)                  +
|                                                               |
+                                                               +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |
+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |   0   | R |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
+                Session Identifier (128 bits)                  +
|                                                               |
+                                                               +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               | Pri | LiL | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Listener (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Listener (2)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Listener (3)                         |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Listener (4 or 5)                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload length        |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                       Payload (variable)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |   1   | R |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
+                Session Identifier (128 bits)                  +
|                                                               |
+                                                               +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               | Pri | LiL | R |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Listener (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Listener (2)                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Listener (3)                         |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Listener (4 or 5)                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Payload length        |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                       Payload (variable)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |   2   | R |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
+                Session Identifier (128 bits)                  +
|                                                               |
+                                                               +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |            Suitability Value (B)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       B       |
+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |   3   | R |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
+                Session Identifier (128 bits)                  +
|                                                               |
+                                                               +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |
+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |   4   | R |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
+                Session Identifier (128 bits)                  +
|                                                               |
+                                                               +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |
+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |   5   | R |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
+                Session Identifier (128 bits)                  +
|                                                               |
+                                                               +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |
+-+-+-+-+-+-+-+-+

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V |   6   | R |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
+                Session Identifier (128 bits)                  +
|                                                               |
+                                                               +
|                                                               |
+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |
+-+-+-+-+-+-+-+-+