Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
Extracted elements (24)
A local temporary cache MAY be maintained during a lookup to store all RedirServiceProvider entries fetched during the walk. If the lookup fails because a successor's record has just expired, the cache can be searched for a fallback successor, recovering gracefully from the race condition.
A naive approach of storing all service provider Node-IDs under a single well-known key scales linearly with providers, overloading the responsible node. ReDiR instead builds a distributed tree structure so that lookup load is spread across many nodes and lookup completes in a constant average number of Fetch operations.
ReDiR requires no new RELOAD protocol functionality; it operates entirely by storing and fetching data via existing RELOAD Store and Fetch requests. This design choice keeps the mechanism simple and reusable across any RELOAD overlay without protocol changes.
The 'turn-server' namespace in the RELOAD Services Registry allows the ReDiR-based service discovery mechanism to be used as an alternative to the TURN server discovery mechanism already specified in the RELOAD base protocol (RFC 6940), providing backward-compatible co-existence.
A node MUST use the specified five-step procedure to register as a service provider: start at Lstart, fetch and store at I(level, n.id) with a wildcard fetch, then walk upward if n.id is the lowest or highest Node-ID in the interval, and also walk downward until it is the sole provider in its interval.
A service provider SHOULD initiate each refresh process slightly before expiry (e.g., when 90% of the refresh interval has passed) to avoid gaps in registration.
Before leaving the RELOAD Overlay Instance, a service provider SHOULD remove its RedirServiceProvider records by storing exists=False values in their place, as defined in RFC 6940.
Before registering or performing a lookup, a peer MUST determine a starting level Lstart. It is RECOMMENDED that Lstart be set to 2 for the first operation; in subsequent lookups, nodes MAY use the mode of the last 16 lookup completion depths as an optimization.
During a service lookup, at each step a node MUST fetch the tree node responsible for I(level, n.id) and MUST apply Conditions 1–3 to determine whether to go up, go down, or terminate the lookup.
During service provider registration, node n MUST send a RELOAD Fetch request (wildcard fetch) to retrieve the tree node responsible for I(level, n.id) before storing its own record there.
Every service provider MUST periodically repeat the entire registration process to refresh its RedirServiceProvider Resource Record. Records that expire MUST be dropped from the dictionary. A default lifetime of 10 minutes is RECOMMENDED.
The NODE-ID-MATCH access control policy requires that a value MUST be written or overwritten only if the request is signed with a key whose certificate Node-ID equals the dictionary key, the Node-ID belongs to one of the tree node's intervals (when exists=True), and H(namespace, level, node) equals the Resource-ID.
The overlay configuration document is extended with a 'redir:branching-factor' element (xsd:unsignedInt) inside the REDIR kind element, specifying the branching factor of the ReDiR tree. The default value is 10. The redir namespace is 'urn:ietf:params:xml:ns:p2p:redir'.
The REDIR Kind stores RedirServiceProvider structures in a dictionary data model keyed by the service provider's Node-ID. The Kind-ID resource name is derived from H(namespace, level, node number). The assigned Kind-ID value is 0x104.
The ReDiR tree is a b-ary tree stored node-by-node in the RELOAD overlay. Each tree node (lvl, j) is stored at key H(namespace, level, j), covers b intervals of the DHT identifier space, and is uniquely identified by its (level, position) pair. The default branching factor is 10.
The RedirServiceProvider Resource Record stores a service provider's routing information and its position in the ReDiR tree. Fields include: type (RedirServiceProviderExtType, 1 byte), destination_list (variable, up to 2^16-1 bytes), namespace (opaque UTF-8, up to 2^16-1 bytes), level (uint16), node (uint16), length (uint16), and an optional extension.
IANA added Kind-ID 0x104 with the name 'REDIR' to the 'RELOAD Data Kind-ID' registry, as defined in Section 6 of this document.
IANA added 'NODE-ID-MATCH' to the 'RELOAD Access Control Policies' registry, as defined in Section 5 of this document.
IANA created the 'RELOAD Services Registry' for ReDiR namespace strings, with registration procedure 'Specification Required'. Initial entries are 'turn-server' and 'voice-mail', both referencing RFC 7374.
IANA registered the URI 'urn:ietf:params:xml:ns:p2p:redir' in the IETF XML Registry (RFC 3688) for the 'redir' namespace used in RELOAD overlay configuration documents.
Attacks such as a malicious node refusing to store a value or denying knowledge of a previously accepted value are inherited from the RELOAD base protocol threat model and are addressed in RFC 6940, not repeated here.
The NODE-ID-MATCH access control policy ensures only a service provider itself can insert a pointer to itself in the ReDiR tree, preventing a malicious node from inserting pointers to arbitrary other nodes. It also limits a node to one RedirServiceProvider record per tree level, blocking pointer-flooding attacks.
Service lookup traverses the ReDiR tree using three conditions: (1) no successor found → move up one level; (2) n.id is neither lowest nor highest in its interval → move down one level; (3) a successor exists and n.id is at a boundary → lookup complete. The walk terminates when Condition 3 holds or the root is reached.
RedirServiceProvider encodes: a 1-byte extension type enum, a destination_list of up to 2^16-1 bytes, a namespace opaque field of up to 2^16-1 bytes, a uint16 level, a uint16 node position, a uint16 length, and a variable-length extension selected on type.