Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Rank, a Resource Management Protocol for Allocation
draft-lopes-rank-00

Versions:

This document is an Internet-Draft (I-D). Anyone may submit an I-D to the IETF. This I-D is not endorsed by the IETF and has no formal standing in the IETF standards process.

Document	Type	Active Internet-Draft (individual)
	Authors	Rui Eduardo Lopes , Duarte Raposo , Susana Sargento
	Last updated	2026-06-29
	RFC stream	(None)
	Intended RFC status	(None)
	Formats	txt html xml htmlized bibtex bibxml
	Additional resources	ID of Duarte Raposo ID of Rui Eduardo Lopes ID of Susana Sargento
Stream	Stream state	(No stream defined)
	Consensus boilerplate	Unknown
	RFC Editor Note	(None)
IESG	IESG state	I-D Exists
	Telechat date	(None)
	Responsible AD	(None)
	Send notices to	(None)

Email authors IPR References Referenced by Nits Nits v3 Search email archive

draft-lopes-rank-00

Network Working Group R. E. Lopes, Ed.
Internet-Draft Universidade de Aveiro and Instituto de Telecomunicações
Intended status: Informational D. Raposo
Expires: 31 December 2026 Instituto de Telecomunicações
S. Sargento
Universidade de Aveiro and Instituto de Telecomunicações
29 June 2026

Rank, a Resource Management Protocol for Allocation
draft-lopes-rank-00

Abstract

This document specifies Rank, a comprehensive resource management
protocol designed for modern edge-to-cloud computing infrastructures.
While traditional network protocols focus primarily on managing link
bandwidth and router buffer space, the shift toward decentralized
services demands a broader approach to resource allocation. Rank
addresses this gap by simultaneously managing computing capabilities
(such as CPU, memory, and storage), network capacity, and time-
sensitive constraints (such as clock synchronization and task
scheduling) within a unified framework.

Operating primarily as a fully distributed protocol, Rank enables
dynamic resource discovery, estimation, allocation, and sharing. It
works by establishing a path between a source ("talker") and a
destination ("listener") node, actively negotiating resource
requirements across all intermediate nodes. Because it is fully
distributed, all participating nodes carry equal responsibility in
handling a session, such as processing requests, evaluating their own
capacity to meet the resource demands, and strategically forwarding
messages to ensure an optimized, end-to-end connection without
relying on a centralized controller.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Lopes, et al. Expires 31 December 2026 [Page 1]
Internet-Draft Rank Protocol June 2026

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 31 December 2026.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions of Commonly Used Terms . . . . . . . . . . . 4
2.2. Related Work . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Organization of this Document . . . . . . . . . . . . . . 7
2.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 7
3. Functional Summary . . . . . . . . . . . . . . . . . . . . . 7
4. Protocol Data Structures . . . . . . . . . . . . . . . . . . 9
5. Protocol Packet Processing . . . . . . . . . . . . . . . . . 12
5.1. Sending Protocol Packets . . . . . . . . . . . . . . . . 12
5.2. Receiving Protocol Packets . . . . . . . . . . . . . . . 13
5.3. Enabling a Handler for a Session . . . . . . . . . . . . 14
5.4. Events Causing Handler State Changes . . . . . . . . . . 16
5.5. The Handler State Machine . . . . . . . . . . . . . . . . 16
5.6. Handler Process on EAR Message Received . . . . . . . . . 19
5.7. Handler Process on MAR Message Received . . . . . . . . . 21
5.8. Handler Process on BID Message Received . . . . . . . . . 22
5.9. Handler Process on ACC Message Received . . . . . . . . . 23
5.10. Handler Process on REF Message Received . . . . . . . . . 24
5.11. Handler Process on REP Message Received . . . . . . . . . 25
5.12. Lifecycle of a Reservation . . . . . . . . . . . . . . . 26
5.13. The Reservation State Machine . . . . . . . . . . . . . . 27
5.14. Heartbeat (HBT) Message Exchange . . . . . . . . . . . . 29
6. List of Requirements Specification . . . . . . . . . . . . . 31
6.1. The Composition of a Document . . . . . . . . . . . . . . 31
6.2. Marshalling of Requirements . . . . . . . . . . . . . . . 32
7. Suitability Value Estimation . . . . . . . . . . . . . . . . 35

Lopes, et al. Expires 31 December 2026 [Page 2]
Internet-Draft Rank Protocol June 2026

7.1. Contextualization of Resource Estimation . . . . . . . . 35
7.2. Bare-metal Node Resources for Suitability . . . . . . . . 38
7.3. Current Node Resources for Suitability . . . . . . . . . 39
7.4. Priority for Suitability . . . . . . . . . . . . . . . . 41
7.5. Proximity for Suitability . . . . . . . . . . . . . . . . 42
7.6. Historical Performance for Suitability . . . . . . . . . 43
7.7. The Final Value, the Suitability Value . . . . . . . . . 44
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.1. Normative References . . . . . . . . . . . . . . . . . . 44
10.2. Informative References . . . . . . . . . . . . . . . . . 45
Appendix A. Rank Data Formats . . . . . . . . . . . . . . . . . 47
A.1. Encapsulation of Rank Packets . . . . . . . . . . . . . . 47
A.2. Rank Packet Formats . . . . . . . . . . . . . . . . . . . 48
A.2.1. The Rank Packet Header . . . . . . . . . . . . . . . 48
A.2.2. The EAR Packet . . . . . . . . . . . . . . . . . . . 49
A.2.3. The MAR Packet . . . . . . . . . . . . . . . . . . . 51
A.2.4. The BID Packet . . . . . . . . . . . . . . . . . . . 53
A.2.5. The ACC Packet . . . . . . . . . . . . . . . . . . . 54
A.2.6. The REF Packet . . . . . . . . . . . . . . . . . . . 55
A.2.7. The REP Packet . . . . . . . . . . . . . . . . . . . 55
A.2.8. The HBT Packet . . . . . . . . . . . . . . . . . . . 56
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57

1. Introduction

The Internet’s evolution has consistently faced challenges related to
network congestion, initially recognized in 1984 [RFC0879]. Early
solutions, such as TCP retransmissions, paradoxically exacerbated
these issues by increasing data rates at intermediate routers. This
led to the development of resource management protocols, primarily
focused on network resources such as link bandwidth and buffer space
within routers and switches, often employing quality-of-services
(QoS) mechanisms.

However, modern network infrastructures, driven by the migration of
services to edge, fog, and cloud computing layers, demand a broader
scope of resource allocation. Beyond traditional network resources,
computational capabilities of intermediate nodes (such as CPU,
memory, storage, among others) and timely aspects (clock
synchronization, task scheduling) have become critical. This
expansion requires a protocol capable of, as a single package,
managing diverse resource types in heterogeneous environments, in
both number and quality of network nodes.

Lopes, et al. Expires 31 December 2026 [Page 3]
Internet-Draft Rank Protocol June 2026

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. Protocol Overview

Rank is a network protocol that is able to discover a path in which
it negotiates a list of requirements for computing, network, and time
resources, connecting a service between a talker and a listener.
This resource management is made in a fully distributed way and this
document strictly defines its behavior as a distributed protocol.
Nonetheless, Rank may be modified and implemented as a centralized
protocol.

As a fully distributed protocol, all nodes carry the same level of
responsibility in handling a session. No node gathers more
information than other during a Rank session being established, nor a
node save information regarding other nodes. Each node has the sole
responsibility of receiving a Rank packet, process it and send it to
a new node, registering such a connection in its internal data
structures.

All nodes run the exact same algorithm, in parallel. From the
reception of a requesting message, each node maintains a database of
all the session IDs that have passed, with all the last known status
of them. Each participating node has an identical database content
related to a same session.

In terms of communication, each node transmits a message towards its
targeted listener through a non-greedy routing, in which intermediate
nodes are first selected according to their capability of reaching
the target, and then, if there are multiple nodes to choose from, a
proper message is sent to get more data on which of the nodes is more
capable of supporting the requested resources. Worst-case scenario,
in case there are no difference between the capabilities of the
requested nodes, all of these already selected nodes are appropriate
candidates to proceed with the message selected flooding towards the
listener.

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.

Lopes, et al. Expires 31 December 2026 [Page 4]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 5]
Internet-Draft Rank Protocol June 2026

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

Lopes, et al. Expires 31 December 2026 [Page 6]
Internet-Draft Rank Protocol June 2026

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.

3. Functional Summary

A unique instance of a Rank runs in each node. No node is able to
run more than a single process. A brief summary of the resource
management algorithm follows.

Lopes, et al. Expires 31 December 2026 [Page 7]
Internet-Draft Rank Protocol June 2026

When a Rank process starts, it first initializes the protocol data
structures. The node then waits for any Rank message incoming
through one of the ingress network interfaces or an internal API for
application-level interface.

There is no indication that the Rank instance is running besides
checking the state of the assigned port for the process execution.
If a running application, in parallel to the Rank process, intends to
request a given list of computing, network, or time resources to be
allocated throughout a path towards another remote Rank node, the
service use the local and designated Rank API to trigger the process.

As soon as the request is dropped through the API at the local Rank
process, a unit responsible for external interactions with the
process itself will enqueue the request at a depositing queue that
will be directly parsed by the main entity of the Rank instance,
called the Process. The Process, as it has direct access to the
depositing queue, will dequeue the request and assess its validity,
by verifying if all fields match with the expected formats.

Passing the first validation, the request is now analyzed regarding
the session identification. As this is a new session, locally
created when the API was used, a new session identifier can be found,
that the Process will not parse as one that it already knows: at this
stage the Process will check if that the received message contains an
already known session identifier; if it already knows, then the last
known state of that session will be checked and, if it is not
invalid, then the session is resumed; otherwise, a new session will
be locally registered in a specific data structure called Store, and
a Handler structure will be created to handle this new session.

A Handler is an entity that represents the current state of a session
at a given Rank node. There is no Handler instantiation without a
session assignment and all Handler entities are saved in the Store
data structure, which matches a Handler with an associated session
identifier. Moreover, a Handler entity, as it resides within the
Store, has its proper threading mechanism that may suspend execution
when no further processing is required for a session, at a given
time.

As a message is received by the Process and then passed to a specific
Handler, depending on the type of message received, a message parser
and exchange algorithm will be in place (thoroughly described in
Section 5) and the designated listener will be searched along the
node operating system’s tables: if there is a single path towards the
listener, a new EAR message is sent through the network interface
leading to it; if there is no connection towards the listener, then a
refusal message is sent back to the requester (REF packet or an error

Lopes, et al. Expires 31 December 2026 [Page 8]
Internet-Draft Rank Protocol June 2026

code, if this is the first request made by an API), describing that
the request could not be performed; otherwise, if there are more than
a single path towards, a MAR message must be sent to each one of
these neighbor nodes, requesting them to self-assess their own
capability of performing the request and then tell it back, so that,
preferably a best single path is chosen. During this procedure each
requested node will tell back a suitability value, encapsulated
within a BID message that is estimated according an algorithm that is
described in Section 7.

As soon as an EAR message is received in the listener node and this
self-assess as able to perform the list of requirements that are set
in the admission request, a new message of acceptation (ACC) is sent
back to the talker, via the same path. When the ACC reaches the
talker, then the Rank session is said to be effective.

A session may also be terminated and that action must be propagated
throughout all the participating nodes. There are two possible ways
to terminate a Rank session: by request (REP message) or by link
failure. If a request for replenishing is placed in a given node of
a session, REP messages are flooded in the session’s nodes towards
the listener and, as they reach the listener, a REF message is sent
back in direction of the talker, closing the session.

During the execution of a session, heartbeat (HBT) messages are
periodically sent from a node to its next in line to the listener.
If a HBT takes a long time being received by a node, this one must
start suspecting that the connection might be unstable or even
broken. In case a connection is broken, then the nodes should start
a timeout and then sending REF messages so to take the session down.

4. Protocol Data Structures

The Rank protocol is described herein in terms of its operation on
various protocol data structures. The following list comprises the
top-level Rank data structures. Any initialization that needs to be
done is noted.

Session Identifier A 128-bit number that uniquely identifies a

Lopes, et al. Expires 31 December 2026 [Page 9]
Internet-Draft Rank Protocol June 2026

session. This identifier is represented by a ULID [ULIDCan] that
is a data structure comprised by an entropy value and a timestamp,
that allows this records to be lexicographically sortable. As
soon as a session is created, a ULID is created, independently of
the location. It is recommended that clocks are synchronized
along Rank nodes (at least those candidates for same sessions),
but in case there is no synchronization and ULIDs are sent with
equal timestamps, the entropy value that is conisdered in their
content is sufficiently large so that 1.21e+24 unique values are
possible per millisecond.

Process Top-level entity that is responsible for handling all data
from a Rank process. In a Rank node it can only exist a single
instance of a Process running. From this entity, every other data
structure and mechanism are instantiated, initialized, and
managed.

Store Data structure responsible for keeping record of known
sessions by means of their Handler structures. This structure is
a set of key-value pairs, in which each key corresponds to a
session identifier (as a ULID), and each value is a reference for
the responsible Handler for that session.

Translation Table Data structure responsible for saving matches
between original and replicas of sessions. When discovering paths
towards the listener, the Rank algorithm may find alternative/
disjoint paths to which it the current session identifier will be
unrolled into a set of newer and related ones. These matches are
saved within the local (to the transitioning node) data structure
of the Translation Table.

Handler Entity that is created to manage a given session. There is
only one Handler per session. This entity is created at a Rank
node, by a Process, when a new session is created. Each Handler
has a state (ready, assessing, presenting, auction waiting,
auction bidding, pre-reserved, reserved, replenishing, closed) and
it starts by being ready. A Handler has a threading mechanism
integrated, so that it can have its own data structure and be
suspended and resumed by request. When a given session is being
processed in a Rank node the respective Handler must be awaken
from the Store and its state and status must be saved before
suspending again. When a session is closed, the handler is saved
in a minimal storage footprint condition, for auditing purposes,
with a closed state. Multiple Handler entities may run
simultaneously.

Dispatcher Attached and controlled by a Process, the Dispatcher is

Lopes, et al. Expires 31 December 2026 [Page 10]
Internet-Draft Rank Protocol June 2026

the only component of a Rank system that manages the communication
to and from a Rank node (and the hosting system, if using an API).
The Dispatcher has three main components: a set of receivers, a
sender, and an API. The set of receivers are a collection of
receivers per communication layer, that are able to get and parse
Rank messages on ingress network interfaces. The sender component
works similarly in the opposite direction: creates a structure to
encapsulate the message and send it through a given egress network
interface. The API is the third component whose mission is to
create a communication channel with other parallel services
running in the local machine.

Resources This entity is an internal representation within the Rank
instance of the local machine resources, so that they can be
estimated by the process and requested, for allocation and
sharing, to the host’s operative system. This entity has the
concept of current capabilities and it also knows how to hold a
reservation. This entity is also the component responsible to
provide means to a node self-assess its own capabilities of
performing the requested in the admission request.

Reservation A Reservation is a component in a Rank instance that
carries an internal representation of the received admission
requests. A reservation has the same fields as the admission
requests (list of requirements and priority), but using internal
representations different from those used in the Rank packets.

Timeout Handler As Rank is a distributed resource management
protocol, all actions performed before and after requesting
resources to the operative system must be bound to time instants
in which the instance knows, effectively, that those resources are
being used well and that there is a constant connection between
all the participant nodes. To failsafe, timeouts are considered
on actions that enable reservations of resources (such as the
reservation and the replenishing of resources). To manage these
timeouts, a Timeout Handler is an entity that is managed by the
Process and is able to asynchronously start timers that are able
to rollback and sets of changes in case a timeout has been
achieved.

API The communications to and from Rank instances are not

Lopes, et al. Expires 31 December 2026 [Page 11]
Internet-Draft Rank Protocol June 2026

exclusively horizontal (between nodes). The starting point for a
resource reservation (the launch of an admission request) is any
service that might require a list of requirements to a listener,
so that a connection between such service and its local Rank
instance. This way, an API exists that is able to establish a
two-way inter-process communication allowing requests to be sent
to the Rank instance, and error codes to be sent to the requesting
service. This component is managed by the Dispatcher component.

5. Protocol Packet Processing

This section discusses the general processing of Rank protocol
packets. It is very important to recall that each node has its own
database of sessions (Store) that are not synchronized between them
besides the first communication of the session request.

All Rank protocol packets begin with a standard header. The sections
below provide details on how to fill in and verify this standard
header. Then, for each packet type, the section giving more details
on that particular packet type’s processing is listed.

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.

Lopes, et al. Expires 31 December 2026 [Page 12]
Internet-Draft Rank Protocol June 2026

+======+=====================+=============================+
| Type | Packet name | detailed section (transmit) |
+======+=====================+=============================+
| 0 | Exclusive Admission | Section 5.6 |
| | Request (EAR) | |
+------+---------------------+-----------------------------+
| 1 | Multiple Admission | Section 5.7 |
| | Request (MAR) | |
+------+---------------------+-----------------------------+
| 2 | Bid (BID) | Section 5.8 |
+------+---------------------+-----------------------------+
| 3 | Acceptation (ACC) | Section 5.9 |
+------+---------------------+-----------------------------+
| 4 | Refusal (REF) | Section 5.10 |
+------+---------------------+-----------------------------+
| 5 | Replenishing (REP) | Section 5.11 |
+------+---------------------+-----------------------------+
| 6 | Heartbeat (HBT) | Section 5.14 |
+------+---------------------+-----------------------------+

Table 1: Sections describing Rank protocol packet
transmission.

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.

Lopes, et al. Expires 31 December 2026 [Page 13]
Internet-Draft Rank Protocol June 2026

* 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.

Lopes, et al. Expires 31 December 2026 [Page 14]
Internet-Draft Rank Protocol June 2026

┌─────────┐
┌──────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

Figure 1: The Handler State finite state machine (FSM) diagram.

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.

Lopes, et al. Expires 31 December 2026 [Page 15]
Internet-Draft Rank Protocol June 2026

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

Lopes, et al. Expires 31 December 2026 [Page 16]
Internet-Draft Rank Protocol June 2026

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

State(s): Presenting

Event: REF Sent

New state: Closed

Lopes, et al. Expires 31 December 2026 [Page 17]
Internet-Draft Rank Protocol June 2026

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

Lopes, et al. Expires 31 December 2026 [Page 18]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 19]
Internet-Draft Rank Protocol June 2026

* 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.

Lopes, et al. Expires 31 December 2026 [Page 20]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 21]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 22]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 23]
Internet-Draft Rank Protocol June 2026

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).

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.

Lopes, et al. Expires 31 December 2026 [Page 24]
Internet-Draft Rank Protocol June 2026

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 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.

Lopes, et al. Expires 31 December 2026 [Page 25]
Internet-Draft Rank Protocol June 2026

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 ◀────────────────────┘
└─────────┘

Figure 2: The Reservation State finite state machine (FSM) diagram.

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

Lopes, et al. Expires 31 December 2026 [Page 26]
Internet-Draft Rank Protocol June 2026

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

Lopes, et al. Expires 31 December 2026 [Page 27]
Internet-Draft Rank Protocol June 2026

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

Lopes, et al. Expires 31 December 2026 [Page 28]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 29]
Internet-Draft Rank Protocol June 2026

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].

Lopes, et al. Expires 31 December 2026 [Page 30]
Internet-Draft Rank Protocol June 2026

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

Figure 3: Sending of a HBT message.

6. List of Requirements Specification

An admission request is a structure that is comprised of a priority
and a list of requirements that is being requested. In this section
the specification for such requirements is described.

The description of a requirement may be similar to what one would use
to characterize a resource, independently of its type. With the
joint effort from standardization entities such as IETF, IEEE, and
IANA, and also with the help of some vendors, a normalized interface
for resource configuration was created, in which resource description
files were also normalized. This interface is NETCONF [RFC6241], and
the description files are YANG modules [RFC7950].

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].

Lopes, et al. Expires 31 December 2026 [Page 31]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 32]
Internet-Draft Rank Protocol June 2026

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
}

Figure 4: Lifecycle of a requirement from packing to unpacking in
a Rank EAR/ MAR message. Legend: (A) a requirement is stated for
admission request; (B) with a YANG module identified, a
requirement is written as JSON; (C) from JSON, the object is
serialized into CBOR; (D) the serialized CBOR is placed as a
message’s payload; (E) the serialized CBOR is retrieved from the
message; (F) from CBOR, the object is deserialized into JSON; (G)
if the content is YANG valid, the requirement is parsed; (H) the
requirement is assessed in the receiving node.

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.

Lopes, et al. Expires 31 December 2026 [Page 33]
Internet-Draft Rank Protocol June 2026

(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

Figure 5: Marshalled list of requirements.

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

Lopes, et al. Expires 31 December 2026 [Page 34]
Internet-Draft Rank Protocol June 2026

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. Suitability Value Estimation

As soon as a message is received at a Rank node, besides unpacking
the requirements and verifying their conformity against their
respective YANG modules, each node self-assesses its own capability
of performing the admission request. The outcome of this assessment,
generally speaking, cannot be a binary value and, in this section, we
describe how is this suitability value estimated.

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.

Lopes, et al. Expires 31 December 2026 [Page 35]
Internet-Draft Rank Protocol June 2026

┌──────┐ ┌──────┐
│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)

Lopes, et al. Expires 31 December 2026 [Page 36]
Internet-Draft Rank Protocol June 2026

Figure 6: Process of resource estimation in assessing suitability
value. In phases (B) and (C) the arrows represent the execution
of the self- assessment to generate each B outcome.

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.

Lopes, et al. Expires 31 December 2026 [Page 37]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 38]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 39]
Internet-Draft Rank Protocol June 2026

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

Figure 7: Generic representation of weights distribution between two
requirements A and B, in a list of requirements R.

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

Figure 8: Generic representation of weights distribution between four
requirements (A, B, C, D), in a list of requirements R.

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..])) )

Lopes, et al. Expires 31 December 2026 [Page 40]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 41]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 42]
Internet-Draft Rank Protocol June 2026

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.

Lopes, et al. Expires 31 December 2026 [Page 43]
Internet-Draft Rank Protocol June 2026

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.

8. Security Considerations

TODO Security

9. IANA Considerations

This document has no IANA actions.

10. References

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>.

Lopes, et al. Expires 31 December 2026 [Page 44]
Internet-Draft Rank Protocol June 2026

[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,

Lopes, et al. Expires 31 December 2026 [Page 45]
Internet-Draft Rank Protocol June 2026

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>.

Lopes, et al. Expires 31 December 2026 [Page 46]
Internet-Draft Rank Protocol June 2026

[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>.

Appendix A. Rank Data Formats

This appendix describes the format of Rank protocol packets. The
Rank protocol may run over different OSI layers depending on the
intended situation. Before any data format are described, the
details of the Rank encapsulation are explained.

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.

Lopes, et al. Expires 31 December 2026 [Page 47]
Internet-Draft Rank Protocol June 2026

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.

A.2.1. The Rank Packet Header

Every Rank packet starts with a standard 17 byte header. This header
contains all the information necessary to determine whether the
packet should be accepted for further processing. This determination
is described in Section 5.2 of the specification.

Lopes, et al. Expires 31 December 2026 [Page 48]
Internet-Draft Rank Protocol June 2026

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) +
| |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+

Version (V) This 2-bits field holds the information about the
version of Rank of this message. As of this document, this field
MUST be set to all zeroes (0).

Type This 4-bits field unsigned integer indicates the type code of
the message. This document defines the following type codes: 0 -
Exclusive Admission Request (EAR) 1 - Multiple Admission Request
(MAR) 2 - Bid (BID) 3 - Acceptation (ACC) 4 - Refusal (REF) 5 -
Replenishing (REP) 6 - Heartbeat (HBT)

Reserved (R) This 2-bits field is reserved for future use and MUST
be zero (0).

Session Identifier This 16-octet field holds the Rank session
identifier. This field is typed for a universally unique
lexicographically sortable identifier (ULID) [ULIDCan]. A ULID is
a 16-octet identifier that splits into a 6-octet field for UNIX
timestamp in milliseconds and a 10-octet field for randomness from
a cryptographically secure source of randomness, if possible.

A.2.2. The EAR Packet

EAR packets are Rank packet type 0. These packets are sent to
initiate a request on a node or start the processing of a new session
at an intermediate or listener node.

As soon as a node intends to send an admission request towards a
listener, but targeting a single following node, the message sent in
the Rank session is an EAR message.

Lopes, et al. Expires 31 December 2026 [Page 49]
Internet-Draft Rank Protocol June 2026

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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Priority (Pri) This 3-bits field holds the admission request
priority value from 0 to 7, where 0 means the lowest priority
level, and 7 identifies the maximum priority level. The priority
will be used in the self-assessment of each node in regards to
their capability of performing the list of requirements that is
also carried in this message. Although coincidental, this field
might not be exactly the same as a priority code point (PCP) from
an IEEE 802.1Q virtual local area network (VLAN) header, but can
be used as such.

Listener Length (LiL) This 3-bits field encodes the length of the
intended listener whose identification is described in a next
field. Depending on the abstraction layer level where a Rank
instance is being run on, the address length will change

Lopes, et al. Expires 31 December 2026 [Page 50]
Internet-Draft Rank Protocol June 2026

accordingly. To that matter, this field identifies this through
encoding the current situation of this Rank session. This data
will define the length of the following Listener field. This
document defines the following codes: 0 - 1-octet defined listener
addresses for testing purposes 2 - 4-octet defined listener
addresses for IPv4 representation. 3 - 6-octet defined listener
addresses for MAC representation. 4 - 16-octet defined listener
addresses for IPv6 representation. 5 - 16-octet defined listener
addresses for DDS-GUID representation.

Reserved field (R) This 2-bits field is reserved for future use and
MUST be all zeroes (0).

Listener This variable length field holds the address or identifier
of the intended listener of the admission request being carried
within this message. The length of this field is determined by
the coded value of the Listener Length field: this document
defines four possible lengths to the identifier or address of a
listener.

Payload Length This 2-octet unsigned integer represents the length
of the Payload field following it. This field may port a value of
zero if there is no payload to be carried (this is an exceptional
behavior of an EAR message, as reported below).

Payload This variable length field holds the list of requirements of
the admission request being transmitted in this message. The
definition of the list of requirements is originally made in JSON
following a format specified in Section 6.1, that is converted to
CBOR.

A.2.3. The MAR Packet

MAR packets are Rank packet type 1. These packets are sent to
initiate a request on a node or start the processing of a new session
at an intermediate node, when a requester has more than a single node
to interact with, targeting a listener.

Similarly to an EAR message, as soon as a node intends to send an
admission request towards a listener, but instead targeting more than
a single following node, the messages sent in the Rank session are
MAR messages.

Lopes, et al. Expires 31 December 2026 [Page 51]
Internet-Draft Rank Protocol June 2026

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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Lopes, et al. Expires 31 December 2026 [Page 52]
Internet-Draft Rank Protocol June 2026

Reserved field (R) This 2-bits field is reserved for future use and
MUST be all zeroes (0).

A.2.4. The BID Packet

When a node receives a MAR message it must self-assess its own
capabilities of performing the list of requirements sent in the
admission request and then answer back with a final suitability
value, in a BID message.

A suitability value is a single precision floating point value that
ranges from zero to one, where 0 means no capability to perform the
admission request, and any other value to 1 the capability of
performing the intended in the admission request. This suitability
value estimation is detailed in Section 7 of this specification.

Lopes, et al. Expires 31 December 2026 [Page 53]
Internet-Draft Rank Protocol June 2026

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 |
+-+-+-+-+-+-+-+-+

Suitability Value This 4-octet single precision floating point value
carries an outcome of a self-assessment ranging in [0, 1], where 0
means no capability of accepting an admission request, and other
value how easily it accepts performing it.

A BID message carrying a value of zero is also mentioned as being a
null-bid.

A.2.5. The ACC Packet

In a Rank session, after the admission request reaches the intended
listener, an answer must be retropropagated towards the talker, so to
admit or reject the pre-reservations done along the discovered path
until reaching the target of the request. In case of approval, the
listener node (as well as others if they are intermediate nodes) will
dispatch an ACC message.

This message does not have a body besides the common header in which
the ACC code data is placed, since the only required information to
pass is the Rank session identifier, which is part of the header of
all messages.

Lopes, et al. Expires 31 December 2026 [Page 54]
Internet-Draft Rank Protocol June 2026

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) +
| |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+

A.2.6. The REF Packet

Contrary to the ACC message, in case an admission request reaches the
intended listener and it is rejected (or before, if an incapable
intermediate node is reached), a REF message is sent towards the next
node towards the talker.

This message does not have a body besides the common header where the
single requirement for this message is carried, being the Rank
session that is refused to proceed through this path.

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) +
| |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+

A.2.7. The REP Packet

At the time of having a set of resources already allocated, meaning
that a reservation has taken place, a trigger should be possible to
set for the recovery of those resources, by deleting such
reservation. To trigger this action a REP message can be sent in any
of the nodes of a Rank session, which will first initiate a cascading
effect of REP messages towards the listener and, by reaching the
listener, answer back with REF messages towards the talker of the

Lopes, et al. Expires 31 December 2026 [Page 55]
Internet-Draft Rank Protocol June 2026

session.

The REP message, again, only requires a Rank session identifier to
proceed, thus this message does not contain any other fields rather
than the current common header of a Rank message.

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) +
| |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+

A.2.8. The HBT Packet

To allow reliability features to Rank protocol, the HBT messages are
periodically sent from a Rank node to a next node in line of a Rank
session towards the listener. With a pre-determined periodicity
between participants, the heartbeat message will be the trigger for
REP/REF messages if a connection is dropped between a pair of nodes.

If multiple sessions coexist between a same pair of Rank nodes, a
single HBT message could aggregate the intentions so as to diminish
the network overhead of the message transmission, in which case the
Rank session in the header may be arbitrary within the set of
sessions present in such a connection.

Besides the common header, the HBT message does not carry a body.

Lopes, et al. Expires 31 December 2026 [Page 56]
Internet-Draft Rank Protocol June 2026

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) +
| |
+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+

Contributors

Pedro Veloso Teixeira
Universidade de Aveiro
Email: pedro.teix@ua.pt

Authors' Addresses

Rui Eduardo Lopes (editor)
Universidade de Aveiro and Instituto de Telecomunicações
Aveiro
Portugal
Email: ruieduardo.fa.lopes@ua.pt

Duarte Raposo
Instituto de Telecomunicações
Aveiro
Portugal
Email: dmgraposo@av.it.pt

Susana Sargento
Universidade de Aveiro and Instituto de Telecomunicações
Aveiro
Portugal
Email: susana@ua.pt

Lopes, et al. Expires 31 December 2026 [Page 57]

Rank, a Resource Management Protocol for Allocation draft-lopes-rank-00

Rank, a Resource Management Protocol for Allocation
draft-lopes-rank-00