| Internet-Draft | Distributed Synchronization RPKI RP Syst | February 2025 |
| Ma, et al. | Expires 19 August 2025 | [Page] |
This document describes a current practice of establishing an RPKI relying party with distributed systems of synchronization nodes.¶
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/.¶
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 19 August 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The relying party is a key role in the RPKI ecosystem,whose technical requirements are listed in RFC8897. However, how to follow RFC8897 to deploy such a relying party system to make the RPKI data take effect to the routing control system is yet another issue that is worth operational concerns.¶
AThe relying party is a key role in the RPKI ecosystem,whose technical requirements are listed in RFC8897. However, how to follow RFC8897 to deploy such a relying party system to make the RPKI data take effect to the routing control system is yet another issue that is worth operational concerns.¶
To meet this end, this document introduce a current practice of establish an RPKI relying party (this RP) with distributed systems of synchronization nodes.¶
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.¶
The overall system architecture is illustrated in Figure 1.¶
In general, this RP is combined with a set of RP Synchronization Nodes (RSN) and a single RP Console Node (RCN).¶
The set of RSNs are deployed across the Internet in geographically diverse locations with respect to worldwide RPKI publication points (RPP).¶
The single RP Console Node (RCN) is functioned to ascertain the updates from global RPPs, orchestrate RSNs to perform the task of downloading RPKI data respectively, and validate those data.¶
The relying party is a key role in the RPKI ecosystem,whose technical requirements are listed in RFC8897. However, how to follow RFC8897 to deploy such a relying party system to make the RPKI data take effect to the routing control system is yet another issue that worth operational concerns.¶
+--------------------------------------+
| |
| v
| +-----------------------------------------+
| | RCN |
+------------+ | +---------------------------------+ |
| RPPs | | |-Synchronous Task Dispatch | |
| | | |-Node Management | |
+-+-------+--+ | +---------------------------------+ |
| | +--------------------^--------------------+
| .---. | /|\
|( RPP )| / | \
| `---' | / | \
| | / | \
| .---. | /----------/ | \---------\
|( RPP )| / / | \ \
| `---' | / / | \ \
| | / / | \ \
| .---. | / / | \ \
|( RPP )| v | | | v
| `---' | +------------------+ | | | +-----------------+
| | | RSN | | | | | RSN |
| .---. | |+----------------+| / | \ | +------+ |
|( RPP )+--->||-Data Feedback || / v \ | |......| |
| `---' | ||-Task Execution || / +-----------------+ \ | +------+ |
| | |+----------------+| / | RSN | \ | ^ |
| .---. | +---------^--------+ / |+---------------+| \ +--------+--------+
|( RPP )| | / ||-Data Feedback || \ |
| `---' | | / ||-Task Execution|| \ |
| | | / |+---------------+| \ |
| .---. | | / +--------^--------+ v |
|( RPP )| | +---v---------------+ | +-----------------+ |
| `---' | | | RSN | | | RSN | |
| | | |+-----------------+| | |+---------------+| |
| .---. | | ||-Data Feedback || | ||-Data Feedback || |
|( RPP )| | ||-Task Execution || | ||-Task Execution|| |
| `---' | | |+-----------------+| | |+---------------+| |
| | | +---------^---------+ | +--------^--------+ |
| | | | | | |
+-------+ | | | | |
| | | | | |
| | | | | |
+------------------+-----------+-----------+--------------+----------+
The internal structure of RCN is shown in Figure 2.¶
+-------------------------------------------------------------------------+
| RCN |
| |
+-------------------------------------------------------------------------+
| |
| |
+---------------------------------------------------------------------+ |
| Data Storage Module | |
| +------------------------------------------------------------+ | |
| |-Manages sync nodes and CA repositories data for scheduling.| | |
| +------------------------------------------------------------+ | |
+------------------+--------------------------------------------------+ |
| | ^ |
| | | |
| | | |
| +--------------v-------------+ | |
| | Task Scheduling Module | | |
| | +------------------------+ | +----------------------------+ |
| | |-Assigns optimal RSN to | | | Data Aggregation Module | |
| | |each RPP. | | | | |
| | | | | | +------------------------+ | |
| | +------------+-----------+ | | | | | |
| +--------------+-------------+ | |-Collects data from RSN | | |
| | | |data upload module. | | |
| +-------------v-------------+ | | | | |
| | Task Dispatch Module | | +------------------------+ | |
| | +-----------------------+ | +----------------------------+ |
| | |-Generates and | | ^ |
| | |distributes tasks to | | | |
| | |RSN. | | | |
| | +-----------------------+ | | |
| +---------------------------+ | |
+------------------+----------------------------------+-------------------+
| |
| |
+-----------------------------------------------------+-------------------+
| RSN |
+-------------------------------------------------------------------------+
The main functions of the module include:¶
1). Management of RSN Metadata¶
The module maintains RSN Metadata and Load Information of this RP.¶
RSN Metadata including:¶
Load Information including:¶
The module dynamically updates the node information to provide real-time data input for the task assignment algorithm to make the selection of an RSN performing the very task.¶
2). Maintenance of global RPP Information¶
The module maintains the RPP information pertained to task assignment:¶
The module periodically updates this information to ensure that the task assignment algorithm generates synchronized tasks based on the latest RPP status.¶
Through dynamic management and real-time updating, the data storage module ensures the completeness and timeliness of the information of both RSNs and RPPs, facilitating synchronization task assignment.¶
The task scheduling module is responsible for selecting the optimal RSN to synchronize with an given RPP that has RPKI data update. The main functions of this module include:¶
1). Input¶
Retrieve the input information from the data storage module to do scheduling:¶
2). Calculation¶
Use a specific scheduling algorithm to analyze all the RSN Metadata and Load Information of this RP, combined with global RPP Update, to select optimal RSNs to synchronize with given RPPs that have RPKI data update.¶
3). Output¶
Push task assignments to Task Dispatch Module, in the form of a set with members, each indicating an specific RSN and its assigned synchronization tasks.¶
This module is responsible for communicating with RSNs to accomplish the assignments.¶
This module is responsible for collecting all the synchronization data from RSNs and make them aggregated into local cache to facilitate RPKI path validation.¶
Additionally, it periodically collects RSNs Load Information for scheduling cycle.¶
The internal structure of RSN is shown in Figure 3.¶
+-------------------------------------------------------------------------+
| RSN |
| |
+-------------------------------------------------------------------------+
| |
| |
| |
| +---------------------------------------------------------------------+ |
| | Task Execution Module | |
| | +---------------------------------------------------------------+ | |
| | |-Syncs data to the target repository per task parameters. | | |
| | +---------------------------------------------------------------+ | |
| +-----------------^-----------------------------------+---------------+ |
| | | |
| | | |
| | v |
|+------------------+----------------+ +-------------------------------+ |
|| Task Receiving Module | | Data Upload Module | |
||+--------------------------------+ | | +----------------------------+| |
|||-Receives sync tasks from RCN | | | |-Sends sync results to RCN || |
|||via network (e.g., HTTPS). | | | |after data download. || |
||+--------------------------------+ | | +----------------------------+| |
|+------------------^----------------+ +---------------+---------------+ |
| | | |
+-------------------+-----------------------------------+-----------------+
| |
| |
+-------------------------------------------------------v-----------------+
| RP Console Node(RCN) ... |
+-------------------------------------------------------------------------+
This module is responsible for communicating with RCN to receive the pushed task assignments.¶
The module is responsible for performing synchronization for specific resource URL according to the task parameters.¶
This module is responsible for communicating the encapsulated synchronization data obtained from Task Execution Module to RCN. Additionally, it periodically communicates its load information to RCN.¶
In practice, the characteristics of an RSN such as geographic location, network condition, bandwidth, CPU load, vary widely and are subject to change from time to time.¶
In this RP, scheduling algorithms are optional to the operator in his/her discretion according to local condition. There are six scheduling algorithms employed by this RP in various scenarios, to meet specific operational requirements.¶
This algorithm randomly selects an RSN from the list of available RSNs to perform a task. The algorithm is straightforward and does not rely on historical selection records. And is able to achieve roughly even distribution of tasks in homogeneous environments.¶
This algorithm traverses a sorted RSN list in a cyclical manner, ensuring fair and predictable task assignment. It maintains a selection history to uphold assignment consistency.¶
This algorithm dynamically assigns tasks based on real-time network performance metrics, focusing exclusively on network speed. RSNs continuously measure download speed from designated RPP sources and log performance data for analysis. During task assignment,RCN prioritizes RSN with the highest throughput,ensuring efficient synchronization and minimizing latency.¶
This algorithm dynamically adjusts RSN selection weights based on real-time synchronization task load and system performance metrics, prioritizing higher-weighted RSN for pending synchronization tasks. However, its complexity is high due to sensitivity to multiple parameters, making optimization and tuning challenging.¶
This algorithm assigns tasks based on RSN's geographic location and the RIR to which it belongs. For task assignment, the RSN with the closest geographic location to the repository address is prioritized.¶
This algorithm assigns tasks based on pre-specified RSN provided as input, offering high flexibility in task assignment. However, its effectiveness depends on extensive manual tuning and repeated experimentation, which may impact deployment efficiency.¶
The comparison among those scheduling algorithms are shown in Table 1.¶
| Algorithm | Advantages | Limitations | Scenarios |
|---|---|---|---|
| Random Task Assignment | Straightforward and fast to deploy. | Ignores node performance and task complexity, causing imbalance. | Best for low-load, balanced-performance scenarios. |
| Sequential Task Assignment | Fair and efficient assignment. | Lacks dynamic adaptability. | Ideal for stable synchronization tasks with balanced load. |
| Network-Aware Task Assignment | Network-aware, business-aligned. | Ignores node capacity and load. | Ideal for synchronization tasks with network bottlenecks. |
| Dynamic Task Assignment | Strong adaptability | High complexity, instability. | Ideal for dynamic synchronization and heterogeneous nodes. |
| RIR Region-Based Task Assignment | Location-aware efficient routing | Unreliable due to node config or CDN virtualization. | Ideal for geo-optimized network synchronization. |
| Designated Position Assignment | High control and flexibility. | Manual, inflexible, unscalable. | Suited for manual tuning or strict synchronization environments. |
This memo includes no request to IANA.¶
This document should not affect the security of the Internet.¶
This becomes an Appendix [REPLACE]¶
This template uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz. [REPLACE]¶
Thanks to all of the contributors. [REPLACE]¶