3.1.4.4.2 Resolving a PNRP ID

  • Article

All nodes taking part in PNRP will carry out the resolve process from time to time. Resolve-only nodes use the resolve process to handle requests from higher-layer applications to resolve a Peer Name. The process is also used in cache maintenance operations. Publishers use the resolve operation to advertise published IDs to the rest of the cloud. Publishers also use the resolve operation to attempt to detect splits in the cloud.

The following parameters MUST be supplied to the resolving logic:

  1. Target PNRP ID, which is mapped to the PNRP_ID obtained in section 3.1.4.4.1.

  2. ResolveCriteria, which maps to ResolveCriteria provided by the application or higher-layer protocol as defined in section 3.1.4.4.

  3. PickBestMatchFromLocalIds, which maps to PickBestMatchFromLocalIds provided by the application or higher-layer protocol as defined in 3.1.4.4.

  4. ResolveReasonCode, which maps to ResolveReasonCode provided by the application or higher-level protocol.

    And optionally:

  5. InitialBestMatchRouteEntry, which is a ROUTE_ENTRY structure used by the protocol during PeerName registration. See section 3.2.4.1 for details.

  6. InitialNextHopRouteEntry, which is a ROUTE_ENTRY structure used by the protocol during maintenance. See section 3.2.6.2.1 for details.

A Resolver MUST then perform the following steps:

  1. Attempt to create a new entry in the Outstanding Resolves Table, and fail the request if one cannot be created. If one was created, initialize the fields as follows.

  2. Initialize SuspiciousCount and TotalUsefulHops to 0.

  3. The resolve entry's ResolvePath MUST be initialized to contain any one of the endpoints in the Local Endpoint List.

  4. Save the supplied Target PNRP ID and ResolveReasonCode in the corresponding fields of the resolve entry.

  5. If InitialNextHopRouteEntry was supplied, push it onto NextHopStack. Otherwise, select the route entry from the cache for the PNRP ID numerically closest to the Target PNRP ID and push this route entry onto the resolve entry's NextHopStack. In both cases the UseCount for the entry on the stack MUST be set to zero.

  6. If an InitialBestMatchRouteEntry was supplied, push it onto the resolve entry's BestMatchStack.

  7. If the resolve entry's CurrentBestMatch is not empty and the PNRP ID of the most recently pushed entry in BestMatchStack is sufficiently close (per the ResolveCriteria) to the Target PNRP ID, then:

    Create an INQUIRE message with the Validate PNRP ID field set to the PNRP ID of CurrentBestMatch, and the Request CPA, Certificate Chain, Classifier, and Extended Payload flags set. Set LastSentMessageID to the message ID of the INQUIRE message. Then choose an address from the CurrentBestMatch route entry's address list by using the algorithm as specified in [RFC3484] section 6, and send the INQUIRE message to that address. Finally, put the INQUIRE message in the Pending List, set the message Retry Count to 2, and start its Message Retransmission Timer. If the timer expires and the message Retry Count is reduced to 0, reattempt the process starting from step 7 (i.e., If the resolve entry's CurrentBestMatch is not empty…).

    Otherwise (for example, if the resolve entry's CurrentBestMatch is empty or the most recently pushed entry in BestMatchStack is not sufficiently close to the Target PNRP ID), continue processing as follows.

  8. Attempt to pop a route entry off NextHopStack and store this route entry in the resolve entry's CurrentNextHop. If CurrentNextHop is empty, SuspiciousCount is greater than 6, or TotalUsefulHops is greater than 22, the Resolver MUST do the following:

    If the resolve entry's CurrentBestMatch is not empty, check to see whether the CurrentBestMatch is sufficiently close (per the ResolveCriteria) to the Target PNRP ID. If it is not, or the CurrentBestMatch is empty, return no results to caller because no adequate match was found; the Resolve operation is now complete. Otherwise, send an INQUIRE message as in the previous step.

    If NextHopStack is not empty, SuspiciousCount is less than or equal to 6, and TotalUsefulHops is less than or equal to 22, then continue processing as follows.

  9. Prepare a LOOKUP message with the Validate PNRP ID field set to the PNRP ID from the route entry in the CurrentNextHop, and the Flagged Path field filled with the entries from the ResolvePath. If the number of entries in the cache is less than 8, the Resolver SHOULD set the A flag in the LOOKUP message.

  10. Choose an address from the list of addresses in the route entry in CurrentNextHop state, using the algorithm as specified in [RFC3484] section 6, send the LOOKUP message to it, and then increment the UseCount in the CurrentNextHop state. Set LastSentMessageID to the message ID of the LOOKUP message. Put the LOOKUP message in the Pending List, set the message Retry Count to 2, and start its Message Retransmission Timer.