HANDLE.NET Services: Global Handle Registry®
The Handle System has a two-level hierarchical service model. The top level consists of a HANDLE.NET Service known as the Global Handle Registry (GHR). The lower level consists of all other handle services, which are known as local handle services (LHS).
The Global Handle Registry is a handle service like any other and can be used to manage any handle namespace. It is unique among handle services only in that it provides the service used to manage the namespace of all handle prefixes, also known as naming authorities. The global service contains information about the local handle service responsible for resolving identifiers created with a given prefix.
The connection between a given identifier and the responsible local handle service is determined from the prefix. Prefix information is maintained by the GHR as handle records. For resolution from a local handle service, a client with no built-in or cached knowledge would have to consult the GHR and then one local handle service to resolve a specific identifier.
A prefix handle is used to access the service information that describes the "home" service of the prefix. The service information lists the service sites of the given handle service, as well as the interface to each handle server within each site. To find the "home" service for any handle, a client can query the GHR for the service information associated with the corresponding prefix handle. The service information provides the necessary information for clients to communicate with the "home" service.
To improve resolution performance, the client software has the ability to cache the service information returned from the global service, and/or the resolution result from any local service. A separate handle caching server, either stand-alone or as a piece of a general caching mechanism, may also be used to provide shared caching within a local community. Given a cached resolution result, subsequent queries of the same identifier may be provided from the cache without contacting any handle service. Given cached service information, clients can send their requests directly to the responsible local service without contacting the GHR.
Currently, CNRI has responsibility for the primary global site, and two secondary sites (or mirror) sites. The integrity of the data on the sites and the overall performance of the GHR is monitored on a continuous basis. In an effort to make the global infrastructure more robust, other trusted organizations are being authorized to run additional global mirrors.
The GHR is operated with oversight provided by the Handle System Advisory Committee, which was established to enable the fair and open evolution of the Handle System in the public interest and to promote its widespread adoption. Committee members are drawn from the public and private sectors, representing technology development and digital content interests, as well as educational and policy interests.
Root service information
The GHR knows about each local handle service (LHS) and stores each service's prefix . A naming authority handle may be resolved to obtain the "service information" that clients and servers need in order to locate that LHS. For example, to learn which LHS to query for the handle 123/456, a client will ask the GHR to resolve the prefix handle for prefix 123. The GHR will respond with the service information for the LHS responsible for all identifiers under prefix 123. The client will then query that LHS for handle 123/456.
The prefix 0.NA may be used to obtain source information for a given prefix by creating a handle of the form 0.NA/<prefix>. Like every other handle service, the GHR itself has service information, called "root info", found in the designated "root" prefix handle, 0.NA/0.NA. Each site within the GHR has an HS_SITE value that includes the IP address(es) of each handle server(s) in that site; the port number that each server in each site is listening on, each server's public key, and a serial number that identifies that HS_SITE value. The GHR root info could be visualized as shown in Table 1 below. (Additional administrative values such as TTL are not included in this example.)
Table 1: Visualization of the Global Service Information
When a mirror site is added to the GHR, it's HS_SITE value is added to the root info (or removed in the case of a deleted site) resulting in a change to the 0.NA/0.NA handle data. The new root info is acquired by handle servers and clients via the handle 0.NA/0.NA. Root info is known to all handle clients and servers on start up, but storing it in a handle record provides clients and servers with an easy way to keep their root info up to date.
Checking for updated root info
Handle servers and clients are configured with the root info prior to being placed in service, and know what to do to find the LHS responsible for handle resolution. The root info is in the java client library, and is included with the handle server software.
In order to keep up to date, handle servers update their root info every twenty-four hours by sending a signed request for the handle 0.NA/0.NA to the GHR. The client software checks the root info every time it communicates with one of the global sites.
When handle clients (both the C and Java versions) send a request to a global site, they include the serial number of the site information that was derived from the root info to locate that server. The root server that responds always includes the serial number of its own site information in its response. When a client receives a response from one of the root servers, it compares the serial number in the response to that of the site info that it already has. If the number in the response is greater than the serial number in the site information, the client refreshes its entire copy of the root service information.
The Handle System can continue without interruption as long as at least one of the root sites is available. The root info will be refreshed if a client sends a signed request for the handle 0.NA/0.NA to the root service. If any of the servers fail to respond, or returns an unverifiable response, the client will try to download the root information from the another site in the root service.