]> Universidade de Aveiro and Instituto de Telecomunicações

Aveiro PT ruieduardo.fa.lopes@ua.pt

Instituto de Telecomunicações

Aveiro PT dmgraposo@av.it.pt

Universidade de Aveiro and Instituto de Telecomunicações

Aveiro PT susana@ua.pt

next generation unicorn sparkling distributed ledger 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.

Introduction The Internet’s evolution has consistently faced challenges related to network congestion, initially recognized in 1984 . 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.

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 when, and only when, they appear in all capitals, as shown here.

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.

Definitions of Commonly Used Terms This section provides definitions for terms that have a specific meaning to the Rank protocol and that are used throughout the text.

Rank Session

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

Rank Process

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

Talker Node

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

Listener Node

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

Intermediate Node

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

Controller Node

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

Admission Request

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

Suitability Value

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

Related Work The fundamental basis for this work is the Resource ReSerVation Protocol (RSVP) , established in 1997, which enabled network nodes to flood PATH messages to discover and verify node capacity for quality-of-service (QoS) guarantees. Since that time, several new solutions were developed by the scientific community, but one cannot simply assess them through a unique time axis: as Rank is a resource management protocol supported by discovery, estimation, allocation, and sharing features, the related work must be assessed in these four axes. Starting with resource discovery, RSVP used basic flooding techniques to discover network nodes, constantly sending messages that created heavy network overhead. More recent protocols, such as the Stream Reservation Protocol (SRP) 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 ), semantic and context-aware discovery (architectures may use semantic layers to match resources based on user intent, time constraints, or historical patterns ), 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 , and other more popular solutions rely on a centralized entity to monitor active resources ). On resource estimation, SRP 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 , dynamic optimizations , or reinforcement learning . Outside academic environments, 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 and market models , 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 . 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 . Other approaches could also be found with game-theoretic models to create structured sharing, auctions to negotiate different types of heterogeneous resources simultaneously , or blockchain and smart contracts to also enforce trust on these transactions . 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.

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

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.

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

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 session. This identifier is represented by a ULID 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 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 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.

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.

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 .

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 . Sections describing Rank protocol packet transmission.

Type	Packet name	detailed section (transmit)
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)

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 .
• The reserved field must specify 0.
• The session identifier must not have a timestamp for before or after 10 minutes than the current system clock.

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 , 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. 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 . The Handler state machine is described in more detail in .

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

Events Causing Handler State Changes State changes can be effected by a number of events. These events are pictured as the labelled arcs in . The label definitions are listed below. For a detailed explanation of the effect of these events on Rank protocol operation, consult .

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.

The Handler State Machine A detailed description of the handler state change follows. Each state change is invoked by an event (). 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.

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

• Update state to Presenting if the current node is the beginner of a Rank session (the message may be coming from the API).
• Update state to Assessing if the current node is just an intermediate node between a talker and a listener.

Having switched the state, then the handler must verify if the EAR message have reached its listener or not. In such a case, the node must self-assess its own capabilities of performing the admission request and, if such answer is also positive, then the affected resources must be reserved. With this line of operation, an ACC message must be sent back and the handler state must change to Reserved, and then suspend execution. If the current handler is not running in the matching listener, then it is required, first, to check if there is any suitability value already saved for this given session. If so, that means that this EAR message is only serving to confirm a path that, previously was checked by having MAR and BID messages sent back and forth, and now we should skip to get new connections that lead the current node to the next ones in line with the targeted listener. Considering that there is no current suitability values stored for this current session, then the node must self-assess on its own capabilities to perform the admission request contained in the EAR message. Both in this scenario and in the latter one, where the procedure is equivalent, if there is no capability to perform the admission request, then the processing of this session must terminate here and a REF message should be sent back to inform of that event, switching the state of the Handler to Closed, just before terminating the thread. If the current node is able to support the admission request that was described in the received EAR message, then a pre-reservation of such resources must be done. Here, we now reach the same step as before if there was a suitability value already expecting us in the Handler’s data structure: we need to proceed to verify which are the candidate connections from this current node to the listener. Three possibilities can happen in this situation: there is a single connection path to the listener; there are multiple connection paths to the listener; or there is none. In the latter case the procedure is simple, as a REF message must be sent back to notify that a dead-end was reached and, thus, the request could not be completed. In this situation the handler switches its state to Closed and then terminates its thread. In the case of existing a single connection path towards the listener, then a new cloned EAR message must be sent over that connection. As the message is sent, the handler’s state must switch to Pre-Reserved and, internally to the Handler, the information about which was the message source node must be saved as a reservation past node. In the case of existing more than a single connection path towards the listener, the procedure is similar to the single path case, but differing on the type of message sent, and the number of sent messages as well. In this case, a MAR message must be sent to each candidate next node in line towards the targeted listener. As soon as the MAR messages are sent, the Handler must switch is state to one of the following states. With this state update, and internally to the Handler, the information about which was the message source node must be saved as a reservation past node.

• Update state to Pre-Reserved if the last state was Assessing.
• Update state to Auction-Waiting if the last state was Presenting.

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

Handler Process on MAR Message Received When a MAR message is received in an ingress interface where Rank is capturing data, the Handler must start this set of steps for processing this type of messages. As soon as the Handler is created to handle this new MAR message, the Handler state must change to Auction Bidding. After switching states, a self-assessment is required, so to estimate the suitability value that will represent the current capability of the Rank node to perform the admission request that is in place within the MAR message, by its list of requirements and priority. From this assessment two values are relevant: if the suitability value is zero, that means that the current node is unable to perform the admission request; otherwise, the node is able to perform and, as such further steps are required. If the node assesses as unable to perform the admission request, then a BID message must be sent back with suitability value zero, and the Handler’s state must change to Closed before terminating itself. If the node is able to perform the admission request, then a BID message with the estimated suitability value must be sent back. After this step, the state must be changed to Pre-Reserved, and the pre-reservation must be performed, of the affected resources in the current node. In this situation, again, a parallel execution must be done to coordinate a timeout action, controlled by the Timeout Handler: if no action is taken (no answer back after sending BID message), then the Handler’s actions must be subject to rollback.

Handler Process on BID Message Received When a BID packet is received by a Handler, the Handler must verify if its state currently matches with Auction Waiting. If it does not match, then the Handler must update its state to Closed and then terminate its thread. Otherwise, a waiting time for all bids must start, in which each suitability value received from candidates are received and collected within the Handler data structure (Bid Set). This action occurs during a time slot bound by a Auction timeout, managed by the Timeout Handler: when the timeout is reached, the node must not waiting for any other suitability value. Consequently, if all candidates answer back before timeout being reached, the processing must continue. With all suitability values duly collected in the Bid Set, the Handler must now check for its cardinal, leaving three alternative execution paths: an execution path if there is no suitability values in the set; an execution path if there is a single unique maximum suitability value in the set; or an execution path if there are several equal maximum suitability values in the set. The first alternative (if there is no suitability value in the set) is straightforward to handle: in this case the Handler must cease its functions, sending a REF message back to the original node source, and switch its state to Closed beforehand. The second alternative (if there is a single and unique maximum value in the Bid Set) requires the Handler to prepare an EAR message to send to the node that had estimated such suitability value. In such a case this EAR message is sent to the node that replied with a BID message carrying this suitability value, and this message is to be sent with an empty payload, as the next node already received and assessed its own capability of performing the admission request. The third alternative (if there are multiple equal maximum suitability values within the Bid Set) requires the session identifier to be regenerated and translated in the Translation Table. In the case the Rank session gets in this stage, this means that replicas must be propagated from this point on, so that if any of these future sessions get refused, then only such branch is deleted. For this reason, a new ULID (hereby denoted by ULID) must be generated for each selected suitability value and the pair [ULID, ULID] must be saved in the Translation Table. With this, new EAR messages must be sent to each suitability value estimator with ULID* with an empty payload. After sending the EAR messages, a timeout for receiving answers must be started by the Timeout Handler. On timeout, the Handler actions must be rollback and the Handler state must switch to Closed and have its thread terminated.

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 ). As this communication is already being done from the listener back to the talker, now we need to unravel if the session identifiers that we are receiving are originals or replicas that were once generated at this node, when the request first arrived here through an EAR/MAR packet. To do so we need to check if the session identifier exists in the Translation Table. If the session identifier exists in the Translation Table, then a new ACC packet must be sent to the next node in line to the talker, with the original session identified (hereby called ULID, differing from the replica ULID*). On this event, the Handler state must switch to Reserved and, then, the current node (accepting node) must be added to the Handler’s data structure as next node in reservation. With this action, the Handler’s thread is suspended. If the session identifier does not exist in the Translation Table we need to check if the current node is the origin node for this session. If this node is the origin of this session, then the result (error code) of the reservation request must be sent back to the API, where the request was first triggered from: with this action, the Handler state must switch to Reserved and, then, the current node (accepting node) must be added to the Handler’s data structure as next node in reservation, and then the threading mechanism is suspended. If this node is not the origin of this session, then an ACC packet must be sent over the next node in line to the talker. With this action, the Handler state must switch to Reserved and, then, the current node (accepting node) must be added to the Handler’s data structure as next node in reservation, and then the threading mechanism is suspended.

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 ). As this communication is already being done from the listener back to the talker, now we need to unravel if the session identifiers that we are receiving are originals or replicas that were once generated at this node, when the request first arrived here through an EAR/MAR packet. To do so we need to check if the session identifier exists in the Translation Table. If the session identifier exists in the Translation Table, then the replica session identifier (hereby denoted as ULID*) must be deleted from the Translation Table. If the Translation Table, with this action, is now clear, then the Handler’s state switches to Closed, without no further action, thus suspending the thread. If the Translation Table is not empty after this action, then a REF message must be sent to the next node in line with the talker. This action must be followed by the switching of the Handler’s state to Closed, and then its thread must be suspended. If the session identifier does not exist in the Translation Table we need to check if the current node is the origin node for this session. If this node is the origin of this session, then the result (error code) of the reservation request must be sent back to the API, where the request was first triggered from: with this action, the Handler state must switch to Closed and then the threading mechanism is suspended. If this node is not the origin of this session, then a REF message must be sent to the next node in line with the talker. This action must be followed by the switching of the Handler’s state to Closed, and then its thread must be suspended.

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.

Lifecycle of a Reservation

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 . The label definitions are listed below. For a detailed explanation of the effect of these events on Rank protocol operation, consult .

Wait for Sacrifice

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

Unconsider

A reservation is deleted as soon as it is created.

Reserve

A reservation is made effective in the system.

Pre-Reserve

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

Replenish

A reservation is cleared from the system.

Mark Reserved

Promote a pre-reservation to a reservation.

Mark Pre-Reserved

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

The Reservation State Machine A detailed description of the Reservation state change follows. Each state change is invoked by an event (). 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.

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 are able to assist, since they are constantly dispatching a message with the reservation request, periodically, unil it is no longer needed. Rank, on the other hand, as a stateful protocol, does not require complete messages such as EAR messages to be periodically sent between nodes, as this would create a large and dispensable overhead, as well as it would introduce a new feature to a same message type. For this reason, the heartbeat message (HBT) was created, with a similar structure to the ACC and REF messages, but with a different behavior. For each new HBT message, a new ULID is generated with the same entropy value, but differing on its timestamp. When created, the HBT is always sent to the next node in line towards the listener, with a pre-defined periodicity Ti (or given as a requiremement in the list of requirements that is part of the original admission request). With the periodically created HBT being sent in each node towards their next in line, it is expected that each receiving node Ni may also predict the time instant in which a given message is to be received. This behavior will not only allow each node to report on the reliability of a given connection to the listener, as it also may be used to allow an easier method to get metrics for the proximity criterion of the self-assessment algorithm that each node performs when receiveing an admission request. The handling of this message cannot be compared to others, since it is not part of a creation or a deletion of a Rank session, but rather maintains a session. Alternatively to other message processing, a new entity must be introduced to handle these messages and control the state of each reservation. For this reason, a Reservations Watchdog is able to keep up with time windows for the reception of next HBT messages, for each known session with reservation at each node. When a HBT message is received, the first action to perform is to check if the given ULID entropy is known at the receiving node. Considering that the ULID entropy is known, then the message arrival time is captured (as Ta), and the predicted time (Tp) is estimated from the timestamp in the ULID, Ti, and the periodicity T, as Tp = Ti + T. From here, the the delta between the prediction and the arrival time Ta - Tp is estimated, whose value will then be confronted with two threshold values: OptimalTime that defines the limit time for the best time frame to receive a HBT message, and DangerousLimitTime, that defines the limit which, if passed, the link must be considered broken. The time frame to which a message arrives, determines if the link is still synchronous or not:

• if the time frame in which the HBT arrived is after DangerousLimitTime, then the reservation will be considered Dead, and a REP message must be sent to replenish the session.
• if the HBT is received within the time frame limited by DangerousLimitTime, then a new HBT message should be sent to the next node.

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

Sending of a HBT message.

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 , and the description files are YANG modules .

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 or as JSON . 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 . 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.

Marshalling of Requirements 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.

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 .

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

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.

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.

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 , 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 each iteration is being by a different stage:

• In (A) the node M receives the message.
• In (B) the node M proceeds to self-assess its capabilities of performing the admission request, cancelling if not capable.
• As node M has three connecting nodes that can provide it with a path towards the listener, in (C) node M sent a message to each neighboring node Ni, leaving them to self-assess their own capabilities of performing what is being requested.
• In response to this action, in (D) each node answers back to node M with a suitability value.
• Node M, having received the suitability values from every node Ni, in (E), it is now responsible for sorting candidates for forwarding the request message.

When a node has requested others to perform a resource estimation, it waits for an answer per node (as in phase (D)). To allow this action to be performed, the suitability values that come from each assessing node must be comparable amongst them. Thus, the definition of the evaluation function not only has to be the same in each node, but the range of values must also be normalized, so that each final suitability value can be comparable on the same scale throughout every node in a Rank session. In this protocol, the resource estimation must be able to accommodate a varied set of resources, for which assessing the current capability of performing a request cannot be evaluated equally or through the same means. This raises the question of how to assess a list of requirements in a node. As each resource is different from another, each resource must have a unique assessment function directly defined, and the results must be output in the same fashion as the final suitability value: in a normalized range. By definition, the normalized range of values for the suitability value, B, and for each individually-assessed resource value is [0, 1], in which 0 means total inability of performing what is being requested, and any other value means that a resource is capable, in a crescent ratio from 0 to 1. The task of self-assessment within a node against a list of requirements is not a computationally expensive execution. Still, Rank needs to do more than just a current evaluation of the node’s resources to ensure that a resource allocation is guaranteed to be working during the interval in which is in place. Therefore, several criteria need to be taken into consideration to declare that a given node is more capable than another to perform a given task under a strict list of requirements. The following criteria were designed:

1. Bare-metal node resources.
2. Current node resources.
3. Priority.
4. Proximity.
5. Historical performance.

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

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

1. The list of requirements specifies the need for 2 GB of memory. In such a case, with this criterion, the node will assess if, independently of the current state of the machine, the node has at least 2 GB of memory (used or unused).
2. The list of requirements states a requirement for a time-critical traffic subject to time shaping. In such a case, the node will assess if there are capabilities to sustain the time-aware shaper (TAS) standard or not.

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

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

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

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.

Generic representation of weights distribution between two requirements A and B, in a list of requirements R. 0.5 taumax < 1 │ │ ┌─────────────────────────────────┼────┳─────────────────────────────┤ │ A ◀─╋─▶ B │ └─────────────────────────────────┴────╋─────────────────────────────┘ 0 │ 1 tau ]]>

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

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 and , one can write C2 as the following C2(x) expression: C2(R) = (z0) If (cardinal(R) = 1) Else ( Mul(tau, z0) + Mul(1–tau, C2(R[1..])) ) The possibility of parameterizing the value of tau in the range of (taumin, taumax) allows the Rank protocol instance to control a subjective amount of requirements it wants to consider. By keeping the criterion of insertion order in the list of requirements, the assessing nodes are informed of which requirements must be checked before others. Nonetheless, there is a critical condition that must be enforced. If any requirement assessment zi is equal to 0, tehn the entire criterion of the current node resource must yield the same outcome (zero). This must be enforced since a node could have resources to support a given requirement request, but not at the time of the request, meaning this criterion must be able to cancel out such an admission request and further requirements assessment.

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 ). 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 and . The criteria C3’s outcome is evaluated as the message priority, p, over the maximum level: C3 = p / 7.

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

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

• a1, ratio of the number of requirements to the average number of requested resource requirements.
• a2, percentage of allocated but unused resource reservation.
• a3, ratio of how stable are the available resources.
• a4, percentage of strict resource reservations over all allowed admission requests.

Adding to this set of variables, an entropy value should be appended so that the odds of two nodes presenting the same assessment value are severely diminished without compromising the order of magnitude of the total self-assessment final grade and the consequent disposition of this node towards the admission request outcome. For this reason, a fifth contributor to C5 should be added to generate some salt over the estimated values of a1, a2, a3, and a4: the salt, s. The salt must be seen as a tool to make it difficult for two or more assessment scores to be equal. This parameter is optional, as its weight can be set to zero. Still, its use may be helpful in scenarios where several candidate nodes for a reservation may share similar network patterns or characteristics. In such a case, the salt value may help the network uncertainty assessment to provide enough random proximity values even in similar conditions. This value must not, in any way, compromise the main function of the history performance criterion. Thus, it is suggested to assign W as a small percentage weight (below 1%). The variables mentioned above are designed to be joint by a weighted sum of parameterizable weights di, as described as follows, where Sum(di) = 1. C5 = Mul( (1–W), [ Mul(d1, a1) + Mul(d1, a1) + Mul(d1, a1) + Mul(d1, a1) ] + Mul(W, s) )

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.

Security Considerations TODO Security

IANA Considerations This document has no IANA actions.

References Normative References This RFC discusses the TCP Maximum Segment Size Option and related topics. The purposes is to clarify some aspects of TCP and its interaction with IP. This memo is a clarification to the TCP specification, and contains information that may be considered as "advice to implementers". This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK] The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document defines encoding rules for representing configuration data, state data, parameters of Remote Procedure Call (RPC) operations or actions, and notifications defined using YANG as JavaScript Object Notation (JSON) text. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References IEEE ulid

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.

Encapsulation of Rank Packets Rank runs alternatively, by requester definition, over several possible communication layers. Rank packets are therefore encapsulated, depending on the situation, by other headers that might exist in each applicable scenario. Rank does not define a way to fragment its protocol packets, and, when transmitted from network layer and above, depends on IP fragmentation when doing that for packets larger than the network MTU. In practice, there is no proper reason to reach a point in which a Rank packet would require more than 65,535 bytes (including the communication layer headers that are required), since this would mean that the payload is reasonably large, thus having a large list of requirements that, tendencially, loses weight reaching no value. There are some other important features of Rank encapsulation:

• Rank is proposed to be Ethernet Type (EtherType) number 0x7265 (29 285). This number is not registered.
• Rank is proposed to be IP protocol number 0x9B (155). This number is not registered.
• Rank is proposed to be transport protocol number 7265. This number is not registered.

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

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 of the specification.

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

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.

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 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 , that is converted to CBOR.

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.

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 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 , that is converted to CBOR.

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 of this specification.

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.

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.

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.

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

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.

Contributors Universidade de Aveiro

pedro.teix@ua.pt