* [ <ServiceType>
<TransmissionProtocol>
<PortNumber> ]
A 4-byte integer followed by an array of triplets consisting of
<ServiceType, TransmissionProtocol, PortNumber>. The 4-byte
integer specifies the number of triplets. Each triplet lists a
service interface provided by the handle server. For each
triplet, the <ServiceType> is an octet (as a bit mask) that
specifies whether the interface is for handle resolution
(0x01), handle administration (0x02), or both. The
<TransmissionProtocol> is also an octet (as a bit mask) that
specifies the transmission protocol. Possible transmission
protocols include TCP (0x01), UDP (0x02), and HTTP (0x04). The
<PortNumber> is a 4-byte unsigned integer that specifies the
port number used by the interface. The default port number is
2641.
Figure 3.2.2 shows an example of handle service site in terms of a
HS_SITE value. The HS_SITE value is assigned to the naming authority
handle "0.NA/10". The <PrimaryMask> indicates that it is the only
primary site of the handle service. The site consists of three
handle servers, as indicated in the <NumOfServer>. These servers
provide handle resolution and administration service for every handle
under the naming authority "10". The first server record (ServerID
0) shows two service interfaces, one for handle resolution and the
other for handle administration. Each interface has its own port.
Each server within a service site is responsible for a subset of
handles managed by the handle service. Clients can find the
responsible server by performing a common hash-operation. The hash-
operation will first convert all ASCII characters in the handle into
upper-case. It then applies the MD5 hashing upon the portion of the
converted handle string (according to the <HashOption> entry). The
result is a 16-byte integer. The absolute value of the integer will
be divided by the number of servers (specified in the <NumOfServer>
entry). The remainder is the sequence number (starting with zero) of
the <ServerRecord> listed in the HS_SITE value. From the
<ServerRecord>, clients can find the IP address of the handle server
for their handle requests.
------------------------------------------------------------
------------------------------------------------------------ |
----------------------------------------------------------- | |
| | | |
| <index>: 2 | | |
| <type>: HS_SITE | | |
| <data>: | | |
| Version: 0 | | |
| ProtocolVersion: 2.1 | | |
| SerialNumber: 1 | | |
| PrimaryMask: | | |
| MultiPrimary: FALSE | | |
| PrimarySite: TRUE | | |
| HashOption: HASH_BY_HANDLE | | |
| HashFilter: {empty UTF8-String} | | |
| AttributeList: 0 {followed by no attributes} | | |
| NumOfServer: 3 | | |
| {followed by a list of <ServerRecord>} | | |
| | | |
| ----------------------------------------- | | |
| ------------------------------------------ | | | |
| ------------------------------------------ || | | |
| | ServerID: 1 ||| | | |
| | Address: :FFFF:132.151.1.155 ||| | | |
| | PublicKeyRecord: HS_DSAKEY, iQCuR2R... ||| | | |
| | ServiceInterface ||| | | |
| | ServiceType: Resolution_Only ||| | | |
| | TransmissionProtocol: TCP & UDP ||| | | |
| | PortNumber: 2641 ||| | | |
| | ||| | | |
| | ServiceType: Admin only ||| | | |
| | TransmissionProtocol: TCP || | | |
| | PortNumber: 2642 | | | |
| ------------------------------------------ | | |
| | | |
| <TTL>: 24 hours | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <reference>: {empty} | |-
| |-
-----------------------------------------------------------
Fig. 3.2.2: The primary service site for the naming authority "10"
3.2.3. Naming Authority Delegation Service: HS_NA_DELEGATE
The HS_NA_DELEGATE is a pre-defined Handle System data type. It has
the exact same format as the HS_SITE value. Like HS_SITE values,
HS_NA_DELEGATE values are used to describe service sites of a LHS.
HS_NA_DELEGATE values may be assigned to naming authority handles to
designate naming authority administration to a LHS. A naming
authority handle with a set of HS_NA_DELEGATE values indicates that
all child naming authorities of the naming authority are managed by
the LHS described by the HS_NA_DELEGATE values.
For example, suppose the naming authority "foo.bar" decides to have
its child naming authorities delegated to a LHS. To achieve this,
one may assign the naming authority handle "0.NA/foo.bar" with a set
of HS_NA_DELEGATE values that describes the LHS. The set of
HS_NA_DELEGATE values indicate that the service information of any
child naming authority of the "foo.bar", such as "foo.bar.baz", can
be found by querying the naming authority handle "0.NA/foo.bar.baz"
from the LHS.
3.2.4. Service Handle: HS_SERV
Any handle service, global or local, can be defined in terms of a set
of HS_SITE values. These HS_SITE values may be assigned directly to
the relevant naming authority handle, or an additional level of
indirection may be introduced through the use of service handles. A
service handle may be thought of as a name for a handle service. It
may be used to maintain the HS_SITE values for the handle service and
referenced from a naming authority handle via a HS_SERV value. A
HS_SERV value is a handle value whose <type> field is HS_SERV and
whose <data> field contains the reference to the service handle.
HS_SERV values are typically assigned to naming authority handles to
refer clients to the responsible handle service.
Use of service handle allows sharing of service information among
multiple naming authorities. It also allows changes to service
configuration (e.g., adding a new site) to be made in one place
rather than in every naming authority handle involved. The mechanism
may also be used to support service referral from one handle service
to another for whatever reason.
A naming authority handle may have no more than one HS_SERV value
assigned to it, otherwise it is an error. If a naming authority
handle has both a list of HS_SITE values and an HS_SERV value, the
HS_SITE values should be used as the service information for the
naming authority.
Service handles can be registered under the reserved naming authority
"0.SERV". Handles under "0.SERV" are managed by the GHR. For
example, the service handle "0.SERV/123" may be created to maintain
the service information for the handle service that manages handles
under the naming authority "123" and any of its sub-naming
authorities.
Similarly, a service handle "0.SERV/a.b.c" may be created to host the
service information for the handle service that manages handles under
the naming authority "a.b.c".
The use of service handles raises several special considerations.
Multiple levels of service handle redirection should be avoided due
to their lack of efficiency, but are not signaled as an error.
Looped reference of service handles or HS_SERV values that point to
non-existent service handles should be caught and error conditions
passed back to the user.
3.2.5. Alias Handle: HS_ALIAS
In practice, it is very possible that a digital object may have
multiple names that will identify the object. The Handle System
supports such feature via the pre-defined data type HS_ALIAS. An
HS_ALIAS value is a handle value whose <type> field is HS_ALIAS and
whose <data> field contains a reference to another handle. A handle
with a HS_ALIAS value is an alias handle to the handle referenced in
the HS_ALIAS value. An alias handle should not have any additional
handle values other than HS_ALIAS or HS_ADMIN (for administration)
values. This is necessary to prevent any inconsistency between a
handle and its aliases.
During a handle resolution, a client may get back an HS_ALIAS value.
This indicates that the handle in question is an alias handle. The
client may then retry the query against the handle specified in the
HS_ALIAS value until final results are obtained.
The use of alias handle introduces a number of special
considerations. For example, multiple levels of aliases should be
avoided for the sake of efficiency, but are not signaled as an error.
Alias loops and aliases that point to non-existent handles should be
caught and error conditions passed back to the user.
One potential use of alias handle would be to support the transfer of
ownership of any named resource. When a resource identified by a
handle transfers from one organization to another, a new handle for
the resource may be created. To avoid inconsistency and any broken
reference, the handle used before the ownership transfer may be
changed into an alias handle and point its HS_ALIAS value to the
newly created handle.
3.2.6. Primary Site: HS_PRIMARY
HS_PRIMARY is a pre-defined data type used to designate the primary
service sites for any given handle. A handle service with multiple
primary service sites is called a multi-primary service. Otherwise
it is called a single-primary service. Each handle managed by a
multi-primary handle service may specify its primary service sites in
terms of an HS_PRIMARY value. A HS_PRIMARY value is a handle value
whose <type> field is HS_PRIMARY and whose <data> field contains a
list of references to HS_SITE values. Each of these HS_SITE defines
a primary service site for the handle.
There can be at most one HS_PRIMARY value assigned to each handle.
Otherwise it is an error. A handle with no HS_PRIMARY value but
managed by a multi-primary handle service is not an error. In this
case, every primary service site of the handle service will also be
the primary site for the handle. Handles managed by a single-primary
handle service do not need any HS_PRIMARY values and any such values
should be ignored.
3.2.7. Handle Value List: HS_VLIST
HS_VLIST is a pre-defined data type that allows a handle value to be
used as a reference to a list of other handle values. An HS_VLIST
value is a handle value whose <type> is HS_VLIST and whose <data>
consists of a 4-byte unsigned integer followed by a list of
references to other handle values. The integer specifies the number
of references in the list. The references may refer to handle values
under the same handle or handle values from any other handles. Each
reference is encoded as an UTF8-string followed by a 4-byte unsigned
integer that identifies the referenced handle and its value index.
HS_VLIST values may be used to define administrator groups for
handles. In this case, each reference in the HS_VLIST defines a
member of the administrator group and the HS_VLIST value identifies
the group as a whole. Client software must be careful, however, to
avoid cyclic definition of value references.
4. Handle System Service Model
The Handle System is a distributed global name service. It consists
of a single distributed Global Handle Registry (GHR) and unlimited
number of Local Handle Services (LHS). These service components
provide the name service (both resolution and administration) on
behalf of Handle System client components. Handle System client
components may also choose to use Handle System middle-ware
components (e.g., the Handle System caching service) for efficiency.
This section describes these components and their relationships to
each other.
4.1. Handle System Service Components
The Handle System defines a hierarchical service model. At the top
level is the single distributed global handle service, also known as
the Global Handle Registry (GHR). Underneath the GHR, there can be
any number of Local Handle Services (LHSs). Each LHS must be
registered with the GHR to manage handles under a distinct set of
naming authorities. Naming authorities are managed by the GHR via
naming authority handles (i.e., handles under the naming authority
"0.NA"). A naming authority handle can also be used to locate the
service information (in terms of HS_SITE values) that describes the
handle service responsible for handles under the naming authority.
From the service information, clients can choose a service site and
locate the responsible server for their handle requests.
Handle System service components are scalable and extensible to
accommodate any large amount of service load. A handle service,
global or local, may consist of multiple service sites, replicating
each other. Each service site may also consist of a cluster of
computers working together to serve its respective namespace. Having
multiple service sites avoids any single point of failure and allows
load balancing among these service sites. Using multiple servers at
any service site distributes the service load into multiple server
processes and allows less powerful computers to be utilized for the
name service.
4.1.1. Global Handle Registry (GHR)
The Global Handle Registry (GHR) is mainly used to manage naming
authority handles and to provide service information for every naming
authority under the Handle System. The GHR may also be used to
manage and provide resolution and administration service to non-
naming-authority handles. Unlike any LHS, which mostly manages
handles under a few naming authorities, the GHR is primarily used to
register naming authorities and provide service information for every
LHS. In other words, the GHR is the single root service that
registers every LHS and provides their service information via the
use of naming authority handle(s). Every naming authority under the
Handle System must be registered under the GHR as a naming authority
handle. The naming authority handle provides the service information
of the handle service that manages all the handles under the naming
authority. The service information may be provided in terms of a set
of HS_SITE values, or an HS_SERV value that refers to a service
handle, as described earlier.
The GHR may consist of multiple service sites, each described in a
HS_SITE value. These HS_SITE values are assigned to the designated
naming authority handle "0.NA/0.NA", also called the root handle. The
root handle is the naming authority handle that maintains the service
information for GHR. Top level naming authorities can only be
created by administrators of the root handle.
In order to communicate with the GHR, client software needs the GHR
service information beforehand. The service information may be
distributed initially with the client software, or obtained from some
other secure sources (e.g., postal mail, secure web site, etc.).
Client software may keep the service information to communicate with
the GHR until the service information becomes expired (according to
its TTL). The GHR must update its service information (assigned to
the root handle) every time it changes its configuration. Client
software with out-dated service information will be notified of the
update every time it communicates with the GHR. The GHR must be
maintained in such a way that any client software with out-dated GHR
service information can still query the root handle for the latest
update.
Fig. 4.1.1 shows the GHR service information in terms of a set of
HS_SITE values. The GHR may consist of a number of service sites,
each described in a HS_SITE value. The figure shows a GHR service
site located in US East Coast, as indicated in the <AttributeList>.
------------------------------------------------------------
------------------------------------------------------------ |
----------------------------------------------------------- | |
| | | |
| <index>: 3 | | |
| <type>: HS_SITE | | |
| <data>: | | |
| Version: 1 | | |
| ProtocolVersion: 2.1 | | |
| SerialNumber: 1 | | |
| PrimaryMask: | | |
| MultiPrimary: TRUE | | |
| PrimarySite: TRUE | | |
| HashOption: HASH_BY_HANDLE | | |
| HashFilter: {empty UTF8-String} | | |
| AttributeList: 1 | | |
| Description: Service site at US East Coast | | |
| NumOfServer: 3 | | |
| | | |
| ------------------------------------------ | | |
| ------------------------------------------ | | | |
| ------------------------------------------ || | | |
| | ServerID: 1 ||| | | |
| | Address: :FFFF:132.151.2.150 ||| | | |
| | PublicKeyRecord: HS_DSAKEY, iQCuR2Rnw... ||| | | |
| | ServiceInterface ||| | | |
| | ServiceType: Resolution & Admin ||| | | |
| | TransmissionProtocol: TCP & UDP || | | |
| | PortNumber: 2641 | | | |
| ------------------------------------------ | | |
| | | |
| <TTL>: 24 hours | | |
| <permission>: PUBLIC_READ, ADMIN_WRITE | | |
| <reference>: {empty} | |-
| |-
-----------------------------------------------------------
Figure 4.1.1: GHR service information
The GHR and its service information provide an entry point for any
client software to communicate with the Handle System. For any given
handle, client software can query the GHR for its naming authority