Message Receipt and Forwarding

When a node receives a message, it first examines the overlay,

version, and other header fields to determine whether the message is one it can process. If any of these are incorrect, as defined in Section 6.3.2, it is an error and the message MUST be discarded. The peer SHOULD generate an appropriate error, but local policy can

override this and cause the message to be silently dropped.

Once the peer has determined that the message is correctly formatted (note that this does not include signature-checking on intermediate nodes as the message may be fragmented), it examines the first entry on the Destination List. There are three possible cases here:

o The first entry on the Destination List is an ID for which the peer is responsible. A peer is always responsible for the wildcard Node-ID. Handling of this case is described in Section 6.1.1.

o The first entry on the Destination List is an ID for which another peer is responsible. Handling of this case is described in

Section 6.1.2.

o The first entry on the Destination List is an opaque ID that is being used for Destination List compression. Handling of this case is described in Section 6.1.3. Note that opaque IDs can be distinguished from Node-IDs and Resource-IDs on the wire as described in Section 6.3.2.2.

These cases are handled as discussed below.

6.1.1. Responsible ID

If the first entry on the Destination List is an ID for which the peer is responsible, there are several (mutually exclusive) subcases to consider.

o If the entry is a Resource-ID, then it MUST be the only entry on the Destination List. If there are other entries, the message MUST be silently dropped. Otherwise, the message is destined for this node, so the node MUST verify the signature as described in Section 7.1 and MUST pass it to the upper layers. "Upper layers"

is used here to mean the components above the "Overlay Link Service Boundary" line in the figure in Section 1.2.

o If the entry is a Node-ID which equals this node’s Node-ID, then the message is destined for this node. If it is the only entry on the Destination List, the message is destined for this node and so the node passes it to the upper layers. Otherwise, the node

removes the entry from the Destination List and repeats the routing process with the next entry on the Destination List. If the message is a response and list compression was used, then the node first modifies the Destination List to reinsert the saved state, e.g., by unpacking any opaque IDs.

o If the entry is the wildcard Node-ID (all "1"s), the message is destined for this node, and the node passes the message to the upper layers. A message with a wildcard Node-ID as its first entry is never forwarded; it is consumed locally.

o If the entry is a Node-ID which is not equal to this node, then the node MUST drop the message silently unless the Node-ID corresponds to a node which is directly connected to this node (i.e., a client). In the latter case, the node MUST attempt to forward the message to the destination node as described in the next section (though this may fail for connectivity reasons, because the TTL has expired, or because of some other error.) Note that this process implies that in order to address a message to "the peer that controls region X", a sender sends to Resource-ID X, not Node-ID X.

6.1.2. Other ID

If the first entry on the Destination List is neither an opaque ID nor an ID the peer is responsible for, then the peer MUST forward the message towards that entry. This means that it MUST select one of the peers to which it is connected and which is most likely to be responsible (according to the Topology Plug-in) for the first entry

on the Destination List. For the CHORD-RELOAD topology, the routing to the most likely responsible node is explained in Section 10.3. If the first entry on the Destination List is in the peer’s Connection Table, the peer MUST forward the message to that peer directly.

Otherwise, the peer consults the Routing Table to forward the message.

Any intermediate peer which forwards a RELOAD request MUST ensure that if it receives a response to that message, the response can be routed back through the set of nodes through which the request passed. The peer selects one of these approaches:

o The peer can add an entry to the Via List in the forwarding header that will enable it to determine the correct node. This is done by appending to the Via List the Node-ID of the node from which the request was received.

o The peer can keep per-transaction state which will allow it to determine the correct node.

As an example of the first strategy, consider an example with nodes A, B, C, D, and E. If node D receives a message from node C with Via List [A, B], then D would forward to the next node E with Via List [A, B, C]. Now, if E wants to respond to the message, it reverses the Via List to produce the Destination List, resulting in

[D, C, B, A]. When D forwards the response to C, the Destination List will contain [C, B, A].

As an example of the second strategy, if node D receives a message from node C with transaction ID X (as assigned by A) and Via List [A, B], it could store [X, C] in its state database and forward the message with the Via List unchanged. When D receives the response, it consults its state database for transaction ID X, determines that the request came from C, and forwards the response to C.

Intermediate peers which modify the Via List are not required to simply add entries. The only requirement is that the peer MUST be able to reconstruct the correct Destination List on the return route.

RELOAD provides explicit support for this functionality in the form of opaque IDs, which can replace any number of Via List entries.

For instance, in the above example, Node D might send E a Via List containing only the opaque ID I. E would then use the Destination List [D, I] to send its return message. When D processes this

Destination List, it would detect that I is an opaque ID, recover the Via List [A, B, C], and reverse that to produce the correct

Destination List [C, B, A] before sending it to C. This feature is

compressed and/or encrypted version of the original Via List and an index into a state database containing the original Via List, but the details are a local matter.

No matter what mechanism for storing Via List state is used, if an intermediate peer exits the overlay, then on the return trip the message cannot be forwarded and will be dropped. The ordinary timeout and retransmission mechanisms provide stability over this type of failure.

Note that if an intermediate peer retains per-transaction state

instead of modifying the Via List, it needs some mechanism for timing out that state; otherwise, its state database will grow without

bound. Whatever algorithm is used, unless a FORWARD_CRITICAL forwarding option (Section 6.3.2.3) or an overlay configuration option explicitly indicates this state is not needed, the state MUST be maintained for at least the value of the overlay-reliability-timer configuration parameter and MAY be kept longer. Future extensions, such as [P2PSIP-RELAY], may define mechanisms for determining when this state does not need to be retained.

There is no requirement to ensure that a request issued after the receipt of a response follows the same path as the response. As a consequence, there is no requirement to use either of the mechanisms described above (Via List or state retention) when processing a response message.

A node receiving a request from another node MUST ensure that any response to that request exits that node with a Destination List equal to the concatenation of the Node-ID of the node from which the request was received with the Via List in the original request. The intermediate node normally learns the Node-ID that the other node is using via an Attach, but a node using a certificate with a single Node-ID MAY elect not to send an Attach (see Section 4.2.1, bullet 2). If a node with a certificate with multiple Node-IDs attempts to route a message other than a Ping or Attach through a node without performing an Attach, the receiving node MUST reject the request with an Error_Forbidden error. The node MUST implement support for

returning responses to a Ping or Attach request made by a Joining Node Attaching to its responsible peer.

6.1.3. Opaque ID

If the first entry on the Destination List is an opaque ID (e.g., a compressed Via List), the peer MUST replace the entry with the original Via List that it replaced and then re-examine the

Destination List to determine which of the three cases in Section 6.1 now applies.