CA2465997A1 - Peer-to-peer name resolution wire protocol and message format data structure for use therein - Google Patents

Abstract

An extensible data structure for messages in a peer to peer name resolution protocol is presented. This message data structure utilizes a number of fields, each containing a message element. Preferably, the first field is the message header that includes protocol information and identifies the type of message. Each message element contain s a number of fields. These message element fields include a type field, a length field , and the content or payload of the message element. In one embodiment, at least ten messages are formed for proper operation of a Peer To Peer Name Resolution Protocol (PNRP), including RESOLVE, RESPONSE, SOLICIT, ADVERTISE, REQUEST, FLOOD, INQUIRE, AUTHORITY, ACK, and REPAIR messages.

Description

PEER-TO-PEER NAME RESOLUTION WIRE PROTOCOL
AND MESSAGE FORMAT DATA STRUCTURE F OR USE THEREIN
FIELD OF THE INVENTION
[0001] The present invention relates generally to communication protocols in a peer-to-peer infrastructure, and more particularly to message format data structures to allow structured communication in a peer-to-peer graph.

[0002] Various communication technologies on the Internet allow users with common interest to collaborate, share files, chat with one another, multi-cast audio and video for presentations and group meetings, and engage in mufti-player gaming.
Currently, however, most communication on the Internet takes place in a server centric environment whereby all communication flows to or through large central servers to which individuals may connect to join and participate in such communication.

[0003] With the reemergence of peer-to-peer technology, the current server centric model of Internet communication is quickly being replaced. Indeed, peer-to-peer technologies enable users to contact one another in a serverless environment, free from the constraints of server based Internet communication. In a peer-to-peer based system, a users anonymity and privacy may be maintained since communication occurs dir~tly between peers within the network. However, while individual communication and file sharing is relatively well established in peer-to-peer networks, establishing, discovering, joining, maintaining, and sharing information in a peer-to-peer environment is not well established.

[0004] Peer-to-peer communication, and in fact all types of communication, depend on the possibility of establishing valid connections between selected entities or nodes. These entities or nodes may be peers (e.g., users or machines) or groups formed within a peer-to-_._. ___ __.._. _....._.~ ~F w,~,~".,"~. z"~,~,~.. .. ~.~~. . ri.._ . _ .....

peer network. The connections between the nodes form the peer-to-peer graph that enables communication and information to be passed to and between the nodes. However, entities may have one or several addresses that may vary because the entities move in the network, because the topology changes, because an address lease cannot be renewed, because the group function or purpose has changed, etc. A classic architectural solution to this addressing problem is thus to assign to each entity a stable name, and to "resolve" this name to a current address when a connection is needed. This name to address translation must be very robust, and it must also allow for easy and fast updates.

[0005] To increase the likelihood that an entity's address may be found by those seeking to connect to it, many peer-to-peer protocols allow entities to publish their individual or group addresses) through various mechanisms. Some protocols also allow a client to acquire knowledge of other entities' addresses through the processing of requests from others in the network. Indeed, it is this acquisition of address knowledge that enables successful operation of these peer-to-peer networks by maintaining a robust graph. That is, the better the information about other peers and groups in the network (i.e. the more robust the graph), the greater the likelihood that a search for a particular resource or record will converge.

[0006] As with a server centric environment, the peer-to-peer graphs may be entirely open to allow Internet file searching and sharing within the graph. However, because peer-to-peer networks are formed as a graph of distributed users or peers, it is necessary that communication and data (records) be passed from one peer to another before all peers within a network may become cognizant of the shared information. Systems that provide such routing include Usenet and OSPF. However, such current systems suffer from limitations that have, to date, limited the full development of peer-to-peer technology.
Additionally, peer-to-peer networks currently suffer from a lack of adequate graph management that, at times allows the graphs to "break" or become split when one of the members leaves the group. In such an instance, information from one part of the graph may no longer be passed to peer members on the other side of the partition created by the departure of one of the peers.
As a further disadvantage, no adequate mechanism exists for the detection of such partition.

[0007] In addition to the function problems existing in the art, the amount of network traffic can easily overwhelm the peers participating within the cloud. Message size and structure complicates a peers ability to rapidly process messages, and results in delayed or dropped communications as the size of the cloud grows.

[0008] There exists, therefore, a need in the art for a peer-to-peer messaging protocol and data structure that addresses the above-described and other problems existing in the art.
BRIEF SUMMARY OF THE INVENTION

[0009] The inventive concepts disclosed in this application involve an extensible data structure for messages suitable for use in a peer to peer name resolution protocol. This message data structure utilizes message data fields to construct various messages of use to the PNRP. Each of the message data fields contain a message element. Preferably, the first field is the message header element that includes protocol information and identifies the type of message.

[0010] As with the messages themselves, each message element contains a number of message element data fields. These message element fields include a type field, a length field, and the content or payload of the message element. The type field includes an identifier that designates the type of message element. The length field identifies the length of the message element, including the field type and the length fields.

[0011] In one embodiment, at least ten messages are formed for proper operation of a Peer To Peer Name Resolution Protocol (PNRP). These ten messages including a RESOLVE
message, a RESPONSE message, a SOLICIT message, an ADVERTISE message, a REQUEST message, a FLOOD message, an INQUIRE message, an AUTHORITY message, an ACK message, and a REPAIR message. These messages are constructed from twenty-two different message elements existing in a preferred embodiment.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] The accompanying drawings incorporated in and forming a part of the specification illustrate several aspects of the present invention, and together with the description serve to explain the principles of the invention. In the drawings:

[0013] FIG. 1 is a block diagram generally illustrating an exemplary computer system on which the present invention resides; and

[0014] FIG. 2 is a simplified block diagram illustrating the functional elements of the Peer to Peer Name Resolution Protocol (PNRP);

[0015) FIG. 3 is a protocol message .flow diagram illustrating an aspect of the present invention;

[0016] FIG. 4 is a protocol message flow diagram illustral:ing another aspect of the present invention;

[0017] FIG. 5 is a data structure diagram illustrating the extensible data structure model of the present invention that allows for construction of the messages of the present invention;
and

[0018] FIG. 6 is a simplified data structure diagram illustrating the construction of an exemplary message of the present invention.

[0019] While the invention will be described in connection with certain preferred embodiments, there is no intent to limit it to those embodiments. On the contrary, the intent is to cover all alternatives, modifcations and equivalents as included within the spirit and scope of the invention as defined by the appended claims.

,_ ..... .. m,.~ _.. ,m,T~_~~.kv~~,~ » ..~.., ._._ __.._._ . .....~
...~,.~.~..~~. ~~ ~~. _..._ _..___

[0020] Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable computing environment.
Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer.
Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types.
Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, rnulti-processor systems, microprocessor based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

[0021] Figure 1 illustrates an example of a suitable computing system environment 100 on which the invention may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100.

[0022] The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

[0023] The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer.
Generally, program modules include routines, programs, objects, components, data structures, etc.
that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

[0024] With reference to Figure 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 110.
Components of computer 110 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not (imitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Associate (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.

[0025] Computer 110 typically includes a variety of computer readable media.
Computer readable media can be any available media that can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes Goth volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage ~f ,information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal"
means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above should also be included within the scope of computer readable media.

[0026] The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation, Figure 1 illustrates operating system 134, application programs 135, other program modules 136, and program data 137.

(0027] The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, Figure 1 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cas settes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive 141 is typically connected to the system bus 12 l through a non-removable memory interface such as interface 140, and magnetic disk drive 1 S l and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.

g

[0028] The drives and their associated computer storage media discussed above and illustrated in Figure l, provide storage of computer readable instructions, data structures, program modules and other data for the computer 110. In Figure 1, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146, and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers hereto illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 110 through input devices such as a keyboard 162 and pointing device 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. In addition to the monitor, computers may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through a output peripheral interface 195.

[0029] The computer 110 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 180.
The remote computer 180 may be another personal computer, a server, a muter, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the personal computer 110, although only a memory storage device 181 has been illustrated in Figure 1. The logical connections depicted in Figure 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

[0030] When used in a LAN networking environment, the personal computer 110 is connected to the LAN 171 through a network interface or adapter 170. When used in a WAN
. , . , . . .. .. . _.~~ ., e._. n ~.~ . ~ sr"~~w~.~u~, ~.,~e,ri .». .~_ _ ...... _ . ..._..~ ~..~ .x. .Mw,.~,w_~,. . ~,n,~ __ _ _~._ .. _ networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160, or other appropriate mechanism. In a networked environment, program modules depicted relative to the personal computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, Figure 1 illustrates remote application programs 185 as residing on memory device 181.
It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

[0031] In the description that follows, the invention will be, described with reference to acts and symbolic representations of operations that are performed by one or more computer, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computer of electrical signals representing data in a structured form.
This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be limiting as those of skill in the art will appreciate that various of the acts and operation described hereinafter may also be implemented in hardware.

[0032] As introduced above, the success of a peer-to-peer (P2P) protocol depends on the protocol's ability to establish valid connections between selected entities.
Likewise, the formation of groups in such a P2P network relies on this ability. Because a particular user may connect to the network in various ways at various locations having different addresses, a preferred approach is to assign a unique identity to the user or the group, and then resolve that identity to a particular address or addresses through the protocol. Such a peer-to-peer name resolution protocol (PNRP) to which the identity management system and method of the instant invention fords particular applicability is described in co-pending Application No.
09/942,164, entitled Peer-To-Peer Name Resolution Protocol (PNRP) And Multilevel Cache For Use Therewith, filed on August 29, 2001, in co-pending Application No.
10/122,863, entitled Multi-Level Cache Architecture and Cache Management Method for Peer-To-Peer Name Resolution Protocol, filed April I5, 2002, and in co-pending Application No.
09/955,923, entitled Peer-To-Peer Group Management and Method For Maintaining Peer-To-Peer Graphs, filed on September 19, 2001, the teachings and disclosure of which are hereby incorporated in their entireties by reference thereto.

(0033] Likewise, co-pending Application No. 09/956,260, entitled Peer-To-Peer Name Resolution Protocol (PNRP) Security Infrastructure And Method, filed on September 19, 2001 describes an underlying security infrastructure that ensures that the identities of the various entities within the network are valid, without unnecessary burdening the network with excess traffic. In the P2P grouping environment, co-pending Application No.
09/955,924, entitled Peer-To-Peer Name Resolution Protocol (PNRP) Group Security Infrastructure and Method, filed on September 19, 2001, describes the underlying security infrastructure used for such groups. The teachings and disclosure of these applications are also incorporated in their entireties by reference thereto. However, while the interfaces and methods of the present invention find particular applicability to and interaction with such PNRP, one skilled in the art will recognize that the present invention is not limited thereby, but has applicability to any P2P system or protocol that desires to provide P2P graph management functions.

[0034] As discussed in the above-incorporated co-pending application describing the PNRP and to provide some useful background, the peer name resolution protocol (PNRP) is a peer-based name-to-address resolution protocol. Peer resources can be given a Peer Name.
An application can register a Peer Name with PNRP to make it discoverable to other peers.
Other applications can use PNRP to resolve a Peer Name to get the corresponding IP address and port of the registering application, PNRP does not provide any mechanism to find or browse for Peer Names. The mechanism of distributing Peer Names must be done via other means. Resolution of Peer Names to addresses is done by having the participating peers co-operate in forwarding messages to one another, and maintaining a distributed cache of the Peer Name to address mappings. The registration and resolution mechanism does not rely on the existence of servers, except for initialization. When a PNRP instance first comes up, it .~.,~,; _ _ . ,~~ . ._u,=n ,~m ".,"~. r..,..-_ .._ ..
nr.zs<,.:ervnc,.,~.-"n",n,.r.. ._,..,."...,". ~.._._.......

needs to find the address of some other PNRP instances with which to exchange data. If no other means are available, then well known servers are used to obtain a list of other PNRP
instances.

(0035] In other words, PNRP allows peer applications to register a Peer Name to endpoint mapping, and to resolve a Peer Name to obtain the endpoint. At this point some definitions would be appropriate. A Peer Name is a string that identifies a peer resource. To be able to register a Peer Name, an application must have access to a public/private key pair.
The key pair is used to sign some of the messages to avoid tampering. A Peer Name may also be derived from the public key, to enable verification of identity ownership. An endpoint is one IPv6/IPv4 address, port, and protocol. In actual fact a list of endpoints may be registered with a single Peer Name, and the list is returned when the Peer Name is resolved.
A node is an instance of the PNRP protocol service. There is normally one node per computer. A cloud is a network of nodes that can reach each other. A single node may be connected to more than one cloud. A cloud has a scope property that is equivalent to the scopes defined in IPv6 - Global, Site Local, and Link Local. A node may have multiple Site Local clouds and multiple Link Local clouds. Communication between nodes should never cross from one cloud to another. Cloud names are used to distinguish clouds. A
Peer Name may be registered on more than one node. PN1ZP keeps each registration distinct. The endpoint list associated with each Peer Name instance will be different.
Within a node, it is also possible to register a Peer Name on more than one cloud to which the node is connected.
Each of these registrations is distinct. Normally, the endpoint list will be different in each of these instances as well. When a node tries to resolve a Peer Name, it does this on a selected cloud. The resolve will succeed only if the Peer Name is registered in the same cloud. It is possible to resolve a Peer Name on more than one cloud simultaneously, but these are treated as independent resolve requests.

[0036] The PNRP service is comprised of several modules that work together, as illustrated in FIG. 2. The Service Management component 200 deals with simple housekeeping such as starting and stopping the PN1RP service. The RPC server and stubs 202 provides the interface between client processes and the PNRP service. This manages the exposed interface, providing entry points for requests, and notifications of events and request completion. It also deals with recovering from client process termination. The Cloud Manager 204 maintains state of specific client requests and it maintains the list of available PNRP clouds. It is responsible for creating clouds and informing clients of changes to cloud states.
j0037] The Cache Manager 206 maintains the local PNRP cache, and the list of locally registered PNRP names for each cloud. It is part of the distributed PNRP
cache. It provides lookup and next hop selection for resolve requests coming from other computers. It performs maintenance on its own cache by periodically initiating resolve requests to ensure a well structured cache. It performs detection of cloud splits, and tries to repair them. It provides the ability to have multiple registered Peer IDs, and structures the cache to support each one.
The Protocol Manager 208 deals with creating and sending valid PNRP messages, and processing received PNRP messages. It works together with the Cache Manager 206 to implement the PNRP protocol. Finally, the Message Transport 210 deals with the actual sending and receiving of messages. It handles multiple network interfaces and addresses, and detects changes in the set of local addresses. If multiple protocols are required (lPv4 and IPv6) then this component will deal with both protocols.
[0038] Each PNRP node maintains a cache of Peer Name to endpoint mappings for some other nodes in a cloud. Messages constructed in accordance with the present:
invention are exchanged between nodes to distribute information about Peer Names to nodes in the cloud.
It is the responsibility of each node to maintain its cache properly. As described by the above identified applications, the PNRP protocol defines a numerical namespace. Each Peer Name is converted to a number, and the numbers can be compared to determine proximity in the namespace. When a request to resolve a Peer Name arrives at a node, it can compare the number with numbers in its cache to find a node that is numerically closer to the desired node. In this way the resolve request is passed from node to node, getting closer to its target with each hop.
[0039] Peer Names are converted into 128-bit numbers called P2P ID's by using hashing functions described in the above incorporated applications. The same Peer Name will always produce the same P2P ID. A specific instance of a Peer Name registration also has a 128-bit number called a service location. The two together make a 256-bit number called the PNRP
ID. The service location portion of the PNRP ID makes the specific instance of the Peer Name registration unique in the network.
[0040] An application may register a Peer Name with PNRP. A PNRP ID is created from the name, and messages are sent informing other nodes of the registration. The same Peer Name may be registered on more than one node. The P2P ID will be the same on each node, but the PNRP ID should be unique for each node. An application may ask to resolve a Peer Name to an address. A P2P ID is derived from the Peer Name, and messages are sent to other nodes to locate a node that has this P2P ID registered. When a P2P ID is resolved into an address, a certified peer address (CPA) is returned. This CPA includes the service location part of the target's PNRP ID, current IP addresses, public key, and many other fields.
The CPA is signed to prevent tampering.
[0041) A given P2P ID may be registered by many different nodes. PNRP uses a 'service location' suffix to ensure each registered instance has a unique PNRP ID. A
'service location' is a 128-bit number corresponding to a unique network service endpoint. The value is created by combining the IPv6 address, port, protocol, and part of the public key. Service locations should be considered opaque by PNRP clients. A service location has two important properties. At any moment, a service location identifies a unique instance of a Peer name. When two service locations are compared, the length of the common prefix for each is a reasonable measure of network proximity. Two service locations which start with the same four bits are usually no further apart than two which start with the same three bits. These benefits may apply only for Global scope native unicast IPv6 addresses.
[0042] Creation and registration of PNRP ID's is only one part of the PNRP
service.
PNRP service execution can be divided into four phases. The first is PNRP
cloud discovery.
A new node must find an existing node in the cloud it wishes to join. The cloud may be the global PNRP cloud, a site local (enterprise) cloud, or a link local cloud. The second phase is the joining of a PNRP cloud. Once the new node has found an existing node, it performs the SYNCHRONIZE procedure to obtain a part of the existing nodes top cache level.
A subset of a single cache level provides enough information for a new node to start participating in the cloud. The third phase contemplates active participation in the cloud.
After initialization has completed, the node may participate in PNRP ID registration and resolution. During this phase, the peer also performs regular cache maintenance. The final phase relates to a peer leaving the cloud. The node un-registers any locally registered PNRP ID's, then terminates.
[0043] The PNRP protocol of the present invention, to effectuate the various functions of PNRP, comprises ten different types of messages. At a high level the messages include a RESOLVE message that is used to request resolution of a target PNRP ID inl;o a CPA. A
RESPONSE message is used as the result of a completed RESOLVE request. A FLOOD
message contains a CPA intended for the PNRP cache of the recipient. A SOLICIT
message is used to ask a PNRP node to ADVERTISE its top level cache. An ADVERTISE
message contains a list of PNRP IDs for CPAs in a node's top level cache. A REQUI~;ST
message is used to ask a node to flood a subset of ADVERTISE'd CPAs. An INQUIRE message is used to ask a node whether a specific PNRP ID is registered at that node. An AUTHORITY
message is used to confirm local registration of a PNRP ID, and optionally provide a certificate chain to help validate the CPA for that ID. An ACK message is used to acknowledge receipt and/or successful processing of certain messages. Finally, a REPAIR
message is used to try to merge clouds that may be split.
[0044] A node may initiate six basic types of transactions in PNRP during which the messages of the present invention are utilized. These transactions include cloud discovery, synchronization, resolution, flooding, identity validation, and repairing. To provide a basic understanding of these transactions, the details of which are explained in the above identified applications, a brief description of these transactions as they relate to the messages and the message structures of the present invention.
[0045] The cloud discovery transaction allows a peer to discover a peer cloud.
In a preferred embodiment, each node may join some number of clouds. The set of clouds that can be joined depends on the network connectivity that the node has. If a node computer has multiple interface adapters, then it may join multiple Link Local clouds. If a node is part of a site that supports IPv6, then it may have access to a Site Local cloud. If a node has connections to more than 1 such site (perhaps through VPN) then it may have access to " . ~. ~.. .ux,... .~~,~ ..~.,_ ...M.. . , . ,~w.__._.~ _ .._ . .. _,. ,~~,~
2~,"~,~~~m. _.~. ~~. wee.__~.. _.._ _...

multiple Site Local clouds. If a node is connected to the Internet, it may have access to the Global cloud.
[0046] A node may choose to join or not join a cloud it has access to. When an application first requests to either Register a Peer Name on a cloud, or Resolve a Peer Name on a cloud, then the node must join the cloud if it has not already done so.
To join the cloud it must try to locate at least one other node in the same cloud. If it cannot fmd another node, then it may assume that it is the first node in the cloud, and it will wait for other nodes to join later.
[0047] Each time a PNRP node joins a cloud, it must perform cloud discovery to find another node. Cloud discovery may also take place later if the PNRP
implementation determines that its cache is not healthy, and it needs to obtain more cache entries. If the initial Cache discovery attempt does not work, then further attempts may be made later.
Cloud discovery is performed using the following procedures. First, a peer can conduct discovery from persisted cache. In such a procedure, the peer first checks for persisted cache.
If no cache has been persisted, then the peer must attempt discovery by supplied node address discussed below. If cache entries have been persisted, for all cache entries the peer calculates a priority by giving preference to CPAs which have not expired, and then to CPAs which have a long lifetime, and then to CPAS whose expiration time is most recent.
The peer then attempts synchronization with the chosen nodes in sequence until one of them provides some cache entries.
[0048] As indicated above, if there is no persisted cache, the peer tries to perform discovery by supplied node address. In this procedure the peer checks if administrative configuration specifies a set of peers to which to connect. If not, then the peer tries multicast discovery discussed below. Otherwise, for each specified endpoint the peer attempts synchronization in sequence until one of them provides some cache entries.
[0049] For multicast discovery, if Simple Service Discovery Protocol (SSDP) is available, the peer issues an SSDP MSEARCH for a PNRP service instance in the desired cloud. The Search Target string to use in the SSDP Search message is "urn:Microsoft Windows Peer Name Resolution Protocol: <major>:<Protocol>:<Scope>" Where <major> is a number representing the version, Protocol is "IPV6", and Scope is one of "Global", SiteLocal", or "LinkLocal". The search may be issued in advance so that responses are available in time. If SSDP is not available, the peer can try these other discovery protocols. If there are none available, then the peer will have to try Directory Name Server (DNS) discovery described below. However, if responses are received, the responses are put into a list of nodes to be tried. If no responses are available within a short period of time, then the node may want to try other discovery protocols. The period of time may be determined by the implementation. The peer may attempt synchronization with the chosen nodes in sequence until one of them provides some cache entries.
[0050] For DNS discovery, the peer issues a DNS query for the well known name of a seed server. This name for the global cloud may be, e.g., SEED.PNRP.NET. If successful, the peer may conduct synchronization described below. If cloud discovery has not succeeded by this point, however, PNRP sets the cloud state to unable to discover other members of the cloud, and assumes it is the first node in the cloud. It may try later to synchronize again.
[0051] Synchronization allows a node to obtain a set of CPAs from another node's cache.
Synchronization is performed after cloud discovery. It is performed with a single node randomly selected from a set of nodes returned by cloud discovery.
Synchronization is secured to mitigate certain attacks. Synchronization may also be performed if the cache for a cloud becomes empty due to ageing, but this should happen only rarely. Before starting the Synchronization, the node must ensure that it has at least one locally registered CPA. If a Peer Name has not already been registered, then the node may generate a node ID for itself in the cloud. The synchronization process involves five types of the messages of the present invention, including SOLICIT, ADVERTISE, REQUEST, FLOOD, and ACK.
[0052] FIG. 3 illustrates a simple message exchange for synchronization. In this FIG. 3, suppose node A 212 is initiating synchronization with node B 214. In such a situation the message flow between the nodes would appear as illustrated in FIG. 3.
Specifically, the SOLICIT message 216 requests a list of PNRP IDs from a node 214 that was chosen during cloud discovery. This SOLICIT message 216 is filled in as described in Table 1.
r.... ..r. ".. ,.~ ,. , "....~.~.~,.~.:~,»~r~«.,. :,~>~~ ~.,._,r»....___ . ,..
_~,.. ",.K,A . . ... ,....

SOLICIT message values fields Nonce ~ Value of hashed Nonce Source CPA CPA for a locally registered Peer Name or generated node ID

[0053] The node keeps track of the Nonce value used to create the hashed Nonce. Timers are associated with this state, as well as a retry count. If an ADVERTISE
message 218 is not received in response to the sent SOLICIT 216, the SOLICIT 216 will be resent.
If the retry count is exceeded, then the state is released and the transaction is terminated.
[0054] The node 214 that receives a SOLICIT 216 responds with an ADVERTISE
message 218. The ADVERTISE 218 contains an array of PNRP IDs. The node 214 first applies throttling heuristics to determine if it is willing to engage in a synchronization transaction. If it is busy, it responds with an ADVERTISE message 218 with no PNRP IDs in the array. Otherwise it selects a well distributed set of PNRP IDs from its cache. This could be done by using the top level cache entries, or by random selection. If there are not enough entries in the cache, the node 214 should' include its own locally registered IDs as well. The ADVERTISE message 218 includes the hashed Nonce from the SOLICIT
message 216. The ADVERTISE 218 is considered to be an acknowledgement for the SOLICIT
216.
[0055] If the array of PNRP IDs was not empty, the node 214 also keeps state that an ADVERTISE 218 with the hashed Nonce value was sent. This state may be a bit in a bitmap.
A timer is associated with this state, so if a matching message is not received within, e.g., 15 seconds, the transaction is aborted and the state is released. The node 214 may also add the Source CPA from the SOLICIT message 216 to its cache. The ADVERTISE message 218 is filled in as indicated in Table 2.
ADVERTISE message values fields Nonce Value of hashed Nonce copied from SOLICIT

. , _ . . . ~ , ..a , _.. _ . .... . _. . _ ID array ~ ist of PNRP IDs [0056] When a node 212 receives the ADVERTISE 218, it first ensures that it had sent a corresponding SOLICIT 216. If not, it drops the message. The ADVERTISE 218 is treated as an acknowledgement for the SOLICIT 216. If the array of PNRP IDs in the ADVERTISE
218 is empty, the transaction is complete. Otherwise the node 212 goes through the array of PNRP IDs in the ADVERTISE 218 and selects the ones it wants to include in its cache. It sends a REQUEST message 220, including an array of the selected PNRP IDs. In the REQUEST message 220 it places the original Nonce value used to create the hashed Nonce for the SOLICIT message 216. The REQUEST message 220 is filled in as indicated in Table 3.
REQUEST message values fields Nonce Value of Nonce used to create hashed Nonce in SOLICIT

ID array List of PNRP IDs [0057] The REQUEST message 220 is sent to node B 214, which responds with an ACK
222 to indicate receipt and avoid retransmissions. If an ACK 222 is not received in a timely fashion, node A 2I2 will retransmit the REQUEST. If all retransmits are exhausted without receiving an ACK for the REQUEST, the transaction fails and is terminated.
[0058] If the transaction is successful, i.e. node 212 received the ACK 222 from node 214, the node 214 then verifies that the Nonce is valid. It does this by hashing the received Nonce, and checking if it matches the state saved above. If it does not match, no further processing takes place. If it is valid, then for each PNRP ID in the array that it still has in its cache, it sends a FLOOD message 224, 2242, . . . 224. The FLOOD message 224 includes the CPA for the PNRP ID. It should be noted that the FLOOD messages 224 are not synchronous. That is, FLOOD(ID=1) 2241 does not need to be acknowledged before FLOOD(ID=2) 224 is sent. Upon receiving the FLOOD 224 by peer 212, normal processing ~. . w,r " .. ~,.. . ...,. .. ., ,.., .~~ ~.d..~ ~ "~~ ~, ~~,.~ . ~~
..~,.".~,.~ . ... .. _... __ ..._.~,.mm , ~~, "",~~ , ",.. TT ........ __...._ of the FLOOD message 224 takes place. This includes sending an ACK 226 and verifying the validity of the CPA.
[0059] The soliciting node 212 may decide to repeat this procedure if the number of selected IDs is not large enough. In this case it should use a different node with which to synchronize so that it will get a different list of IDs.
[0060] The Resolution process is initiated by a node by sending a RESOLVE
message.
A RESOLVE may be initiated because an application is requesting to resolvc a Peer name to an address, as part of Registering a PNRP ID, as part of cache maintenance, or to detect cloud splits. A RESOLVE message contains some flags and codes to tune the resolve processing, to set a limit on how many nodes to visit in attempting the resolve, and to guide the accuracy of the ID matching. It specifies the desired target PNRP ID. At each hop the ID of the next hop is inserted, as well as the best match CPA found so far. In addition, an array of visited node endpoints is included to track the path of the RESOLVE message from hop to hop. The originator of the RESOLVE adds itself as the first entry in the path. The resolution transaction resolves a PNRP ID into a Certified Peer Address. Only the CPA
owner may authoritatively fulfill a resolution request for its CPA. Cached CPAs may only be used as hints for routing RESOLVE requests. They cannot be used to set the "best match" field of a RESOLVE or RESPONSE.
[0061] A RESOLVE message is terminated when the node hosting the target PNRP
ID is reached, or when the number of nodes visited equals the Max I-lops set in the RESOLVE, or when it is no longer possible for any node in the path to forward the RESOLVE
to a better node. Upon termination, select contents from the RESOLVE are transferred into a new RESPONSE message, which is forwarded back toward the RESOLVE initiator. The RESPONSE contains the 'best match' CPA from the RESOLVE, as well as the list of visited nodes. Once the RESPONSE reaches the RESOLVE originator, the originator can easily verify whether they found the target CPA by comparing the 'best match' CPA's PNRP ID to target.
.. . . . . ,. ..., n. ,.~..... , _~w.,... ~,a~,>,~.~~ ~~,~,~.,. ~-~,.,~~:~.~~~. .~.,w.. x .. v. ~~,, y.da:.,.~~,, w~,~~>. ~~..,..~.n.ro_ ... __.
.

2~
[0062] A three node example of a RESOLVE/RESPONSE transaction is illustrated in FIG. 4. In this simplified example, node A 228 is attempting to resolve for node T 232 via node B 230. There are 3 messages involved in the Resolve transaction besides the ACK, to wit RESOLVE, RESPONSE, and AUTHORITY. Once the resolution is complete, the node A 228 can send node T 232 an INQUIRE message directly as will be discussed below.
[0063] For the RESOLVE messages, there are three cases to consider, the first two of which are illustrated in FIG. 4. The three cases are initiating a RESOLVE 234 at node A
228, forwarding a RESOLVE 236 from node A 228 to another node B 230, and having a RESOLVE sent back from a node (not shown in FIG. 4). Each of these scenarios are discussed in turn.
(0064] Initiating a RESOLVE at node A 228 is discussed first. As illustrated in FIG. 4, node A 228 initiates a RESOLVE for some reason. These reasons include an application resolve request, registration advertisement, cache breadth maintenance, or cloud split detection. The initiator 228 also specifies an operation code, indicating if the RESOLVE
may be satisfied by a locally registered ID. If it can be, then node A 228 scans the set of locally registered IDs for a match. If one is found, the RESOLVE is completed within node A 228 itself with the matching ID. If a locally registered ID is not acceptable, or if none of the local IDs are a match, then a RESOLVE message 234 is created with the fields shown in Table 4. This RESOLVE message 234 is then forwarded to some other node 230 for processing as described below.
Target ID Set to desired ID

NextHop PNRP ID selected from cache.

MaxHops May be constant or relative to estimated cloud size BestMatch CPA for a locally registered Peer Name Path 1 entry, contains best source address and port ReasonCode, Values depend on Resolve OperationCode, initiator Precision (0065] When node A 228 wants or needs to forward a RESOLVE 234 to another node B
230, this next node must first be chosen. To choose the next hop, the node A
228 makes a list L of the three cached CPA's with PNRP IDs that are closest to the Target ID
(node T 232), excluding any whose address is already listed in Path, and those which are not closer to the Target ID than A's closest locally registered ID. If the Target ID is in list L, that entry is chosen as the next hop. Otherwise, if the list L is not empty, then one entry is chosen at random. In other words, node A 228 finds some new nodes that are closer to the target than this node, and chooses one of them to which to forward the RESOLVE message 234.
[0066] If node A 228 is able to select a next hop, then node A 228 inserts an appropriate entry in the 'received bitmap'. Node A 228 adds itself to the Path, choosing its best address for the selected next hop, and marking the entry Accepted. The node A 228 sets NextHop to the selected destination's expected PNRP ID, and forwards the RESOLVE message 234 to node B 230. If the RESOLVE message 234 is successfully sent, then the sending node 228 expects to receive an acknowledgement in the form of an AUTHORITY message 238.
If the AUTHORITY 238 is received, then the node 228 maintains a context for the RESOLVE 234, and waits up to a time out value for a RESPONSE 240 message to be returned. If the AUTHORITY 238 is not received after some time, the RESOLVE 234 is sent again.
A total of N retires will occur before it is assumed that the NextHop is invalid. In a preferred embodiment, N=3. If the retry count is exceeded, then the NextHop CPA is removed from the local cache, and the entry is added to Path as a failed hop. :(f the hop count is not exceeded, then another NextHop is selected from the local cache, and the process is repeated.
If the number of entries in Path equals or exceeds MaxHops, then a RESPONSE
message is generated with a Response code of RESULT MAX HOP LIMIT HIT, and sent to the most recent entry in Path that was marked as Accepted.
[0067] If the node was not able to find a next hop, it checks if the Target ID
should be in the lowest cache level. If it should be, then the node suspects that the Target ID may not exist. The node checks the existing Path entries and counts the ones that are marked as Suspicious. If this count exceeds a threshold, then a RESPONSE message is generated with a Response code of RESULT TOO MANY MISSES, and is sent to the most recent entry in Path that was marked as Accepted. If the node was not able to find a next hop, but the Suspicious count is not exceeded, the node sends the RESOLVE back to the last node in Path that is marked as Accepted. The node first adds itself to the Path, choosing its best address for the destination node, and marking the entry Rejected. It sets NextHop to 0, and sets the RF IGNORE NEXTHOP flag to indicate backtracking. If the Target ID should be in the lowest cache level of the node, then it suspects that the Target ID may not exist. In this case the node also marks its Path entry as Suspicious. If the node was not able to fmd a next hop, and there are no nodes in the Path (besides itself), then it is the originator of the RESOLVE
message. In this case it returns a result to the caller, indicating failure to resolve, with Response Code of RESULT NO BETTER PATH FOUND. The BestMatch CPA is made available to the caller.
[0068] Node B 230 receives a RESOLVE message 234 containing a target PNRP ID, a BestMatch CPA, a Next Hop PNRP ID, and a Path listing the address of all nodes which have processed the RESOLVE. If the flags field does not have RF IGNORE NEXTHOP set and the BestMatch CPA may have a CPA or it may be empty, node B 230 checks its local processing load. If the load is too high to process new RESOLVE requests, it responds with an AUTHORITY 23 8 with the flags field set to 'AF REJECT TOO BUSY', and processing is complete. The AUTHORITY receiver is responsible for adding the rejecting node endpoint to the path array and re-routing the RESOLVE request elsewhere.
[0069] The receiving node 230 checks that the Path array contains at least 1 address marked as Accepted, and that the last such address is the same as the source of the message.
If not, no further processing is done. The receiving node also checks the parameters in the received request. If some parameters are not in a valid range, then it responds with an AUTHORITY messages with the flags field set to 'AF INVALID REQUEST', and processing is complete. An example of an invalid parameter is if MaxHops is too large. The AUTHORITY receiver is responsible for adding the rejecting node endpoint to the path array and re-routing the RESOLVE request elsewhere.
[0070] The receiving node (node B 230 for example) checks if the NextHop ID is registered locally. A seed server may skip this test. If this fails, it responds with an AUTHORITY with the flags field set to "AF UNKNOWN ID", and processing is complete.
The AUTHORITY receiver is responsible for re-routing the RESOLVE request elsewhere.
The AUTHORITY receiver should also remove the AUTHORITY sender's PNRP ID from its cache when AF UNKNOWN ID is received. If the BestMatch CPA is included in the message, the node validates the BestMatch, as far as it is able. If the CPA is not valid, the node removes the BestMatch CPA from the message. If the BestMatch CPA is valid, then the node follows the usual rules for deciding whether to add the CPA to its cache.
[0071] The node also checks if there is already an entry for it in the Path.
If there is, then there is a loop since this is not a backtracked RESOLVE. The node then responds with an AUTHORITY with the flags field set to "AF REJECT LOOP", and processing is complete.
The AUTHORITY receiver is responsible for adding the rejecting node endpoint to the Path array and re-routing the RESOLVE request elsewhere.
[0072] If all of the previous checks passed, the node B 230 sends an AUTHORITY

to acknowledge the RESOLVE message 234. If the RESOLVE flag RF SEND CHAIN was set, then the certificate chain for the NextHop is included in the AUTHORITY
23 8. The Classifier string portion of the Peer Name corresponding to the next hop PNRP
ID is included in the AUTHORITY message.
[0073] Node B 230 checks whether it has a locally registered CPA that is a better match than the current BestMatch. If it does it replaces the BestMatch with this one. The node also checks whether it has a locally registered CPA that satisfies the RESOLVE
criteria, based on the OpCode, Precision, and TargetID. If it has a match, or if the number of entries in the path >= MaxHops, then the node creates a RESPONSE message with the current BestMatch. The RESOLVE message's path is copied to the RESPONSE message's path. The node sets the ResponseCode to indicate either RESULT FOUND MATCH or RESULT MAX HOP LIMIT HIT. The node then removes its address from path as well as subsequent entries marked Rejected, and sends the RESPONSE to the most recent entry in path that is marked Accepted.

[0074] If the node B 230 did not send a RESPONSE (as illustrated FIG. 4), then it tries to forward the RESOLVE message 236 to the next node T 232. This forwarding follows the procedure described above. That is, node T 232 responds initially with an AUTHORITY
message 242. It then performs the checks discussed above and, determining that it matches the Target, responds to node B 230 with a RESPONSE message 244 identifying itself as the BestMatch. In response to the RESPONSE message 244, node B 230 sends back an ACK
message 246. Node B 230 then checks the path and forwards the RESPONSE message to node A 228, which responds with an ACK message 248.
[0075] As indicated above, a node may also have to handle a backtracked RESOLVE.
When a node receives a RESOLVE message R it contains a Target ID PNRP ID, a BestMatch CPA, a NextHop PNRP ID, and a Path listing the address of all nodes which have processed the RESOLVE. For a backtracked RESOLVE the flags field does have RF-IGNORE NEXTHOP set. The node first checks its 'received bitmap' to verify that it has previously forwarded this RESOLVE. If the bit is not set, the message is dropped. The node then checks the Path to ensure that its address is on the Path and that it is the top most entry that's marked Accepted in the Path. Otherwise the message is dropped. If the message is not dropped, the node sends an AUTHORITY back to the sender to ACK the message. It does not include a certificate chain.
[0076] If the number of entries in the Path >= Max Hops, then the node creates a RESPONSE message S with the current BestMatch. The RESOLVE message R's Path is copied to S's Path. The node sets the Response Code to indicate Max Hops exceeded. The node then removes its address from Path and sends the RESPONSE back to the most recent entry in Path that is marked Accepted. If the node did not send a RESPONSE, then it tries to forward the RESOLVE to the next hop. This follows the procedure described above with some exceptions: a) "Node B 230 checks whether it has a locally registered CPA
that is a better match than the current BestMatch. If it does it replaces the BestMatch with this one."
DOES NOT APPLY; and b) if the current node is the originator of the RESOLVE
transaction AND the reason is REASON REPAIR DETECTION, processing is complete.

[0077] As discussed briefly above, when a node receives a RESPONSE message 244, 240 it contains a TargetID PNRP ID, a BestMatch CPA, and a path listing the address of all nodes which have processed the RESOLVE. The receiving node also checks its 'received bitmap' to verify that it has previously sent a RESOLVE 234, 236 that matches this RESPONSE 240, 244. If the bit is not set, the message is dropped. The receiving node also checks the Path to ensure that its address is the last one (most recent) on the Path, and that it is marked as Accepted. Otherwise the message is dropped. If the message is not dropped this receiving node sends an ACK 246, 248 to acknowledge receipt. The node validates the BestMatch CPA as far as it is able, and adds it to its cache. Adding a CPA to a cache is subject to a set of rules that may require further messages being exchanged, so that P can validate the BestMatch CPA. This is described in the above identified applications.
[0078] Then node then removes itself from the Path. The node also removes the previous entries that are marked Rejected, until it encounters an entry marked Accepted or the list is depleted. If an entry marked as Accepted is found, then the node forwards the RESPONSE to this node. If the node having the REPONSE forwarded to it does not reply with an ACK, the node retransmits the RESPONSE up to N times. If retransmits time out, then the node removes the failed destination node from the path, and retries the RESPONSE
processing discussed in this paragraph. If there are no more entries in the Path, then the node is the originator of the original RESOLVE 234. The node 228 validates that it did originate the request. If it did not, the RESPONSE is dropped. If the Response Code indicates success, the node 228 then does an identity validation check on the source of the BestMatch CPA.
This involves sending an INQUIRE message 250 to the target node 232; and verifying the returned AUTHORITY message 252. If the identity validation fails, it changes the response code to IDENTITY FAILURE. It returns the results back to the caller.
[0079] An AUTHORITY message may be fragmented by the sender. It is up to the receiver to ensure it has received all the fragments before processing the AUTHORITY
message. If any fragment is not received within a reasonable amount of time, then the original message (INQUIRE or RESOLVE) should be resent, unless the retry count is exceeded. If the AUTHORITY message flags has AF CERT CHAIN set, the node should perform a chain validation operation on the cached CPA for the PNRP ID
specified in " ..<.-.-. ., ,..,. ,..,"", ~. ",y,r 5 y~,._~.,r3, "", ra~v" ., wr. a...a ..w...". . ..,..._ ._ ., ,.,..."~,z " ,..,..,........ ._.. ....__.._.

ValidateID. The chain should be checked to ensure all certificates in it are valid, and the relationship between the root and leaf of the chain is valid. The hash of the public key for the chain root should be compared to the authority in the CPA's Peer Name to ensure they match.
The public key for the chain leaf should be compared against the key used to sign the CPA to ensure they match. Finally, the P2P ID should be checked to see that it is the hash of the Authority and Classifier according to the rules for creating the P2P ID. If any of the above checks fail, the CPA should be removed from the cache, and the RESOLVE message should be modified by adding the address of the node that sent the AUTHORITY message to the RESOLVE message Path and marking the entry Rejected.
[0080] If AF UNKNOWN ID is set, the CPA should be removed from the cache. If AF CERT CHAIN was not set, but the CPA corresponding to the ValidateID PNRP ID
requires a cert chain to validate, the CPA should be removed from the cache, and the RESOLVE message should be modified by adding the address of the node that sent the AUTHORITY message to the RESOLVE message Path and marking the entry Rejected.
[0081] When the CPA corresponding to the ValidateID PNRP ID has been validated, it should be marked as fully validated. The Classifier string is extracted from the AUTHORITY message and kept with the CPA. If AF REJECT TOO BUSY, AF UNKNOWN ID, AF REJECT LOOP, and AF INVALID REQUEST are all clear, the RESOLVE has been accepted for processing, and AUTHORITY processing is done.
[0082] In some cases a node that receives a RESOLVE message may choose not to accept it for forwarding, but still provide a Next Hop suggestion to the sending node. In this case the node returns a suggested Referral Endpoint and Referral PNRP ID in the AUTHORITY message. In this case the AUTHORITY Flags value should contain AF REDIRECT. The node that receives an AUTHORITY with AF REDIRECT may choose whether or not to use the Referral Endpoint to send the RESOLVE
message. In either case the node that responded with the AUTHORITY is added to the Path. The only time that a node should use the Referral Endpoint is in the case where the node originating the RESOLVE was doing it to detect a cloud split, and had sent a RESOLVE to a PNRP
Seed Server with a Reason of REASON REPAIR. In other cases the node should ignore the Referral Endpoint.
(0083] PNRP uses directed flooding to propagate CPA cache entries between nodes.
Flooding is used in several cases. During synchronization in response to a REQUEST
message, the requested CPAs are flooded to the peer who sent the REQUEST'. The REQUEST message is only accepted after a SOLICIT message has been accepted and an ADVERTISE message has been sent. Whenever a CPA is added to the cache,'s lowest level, the added CPA is flooded to the n peers closest to the locally register ID.
The value of n may be tuned, and a value of 4 is preferred. If the reason for adding a CPA is due to receiving a FLOOD, then the CPA should not be flooded to nodes whose address is in the Flooded List of the received FLOOD. The addresses in the received Flooded List should be copied to the new FLOOD message Flooded List if there is enough room. Whenever a CP.A is removed from the cache's lowest level upon receipt of a FLOOD containing a CPA
revocation, the revoked CPA is flooded to the n closest peers to the locally register ID. Once again, the value of n may be tuned, but a value of 4 is preferred. The CPA should not be flooded to nodes whose address is in the Flooded List of the received FLOOD. The addresses in the received Flooded List should be copied to the new FLOOD message Flooded List if there is enough room. Finally, when a FLOOD is received for a new Peer, and the CPA is added to the cache's lowest level, a FLOOD message is then sent to the new Peer with the local node's ID. An exception is made if the source of the FLOOD is the new Peer.
[0084] PNRP does not create persistent neighbor relationships. In the loosest sense, every node represented by a CPA in the CPA cache may be considered a neighbor.
However, CPAs are added and removed from the cache without necessarily notifying the CPA issuer.
Having a peer's CPA in a node's cache does not ensure that that neighbor has that node's CPA
in its cache. The relationship is asymmetric. However, the final FLOOD
condition described above does try to create symmetry for IDs that are close to each other.
[0085] Every UDP FLOOD message is acknowledged by an ACK before any other action is taken on that FLOOD. The sender of a FLOOD maintains state for some time that a FLOOD was sent. If the ACK is received, the state is released. If an ACK is not received for a period of time, the FLOOD is resent and the timer is reset. The FLOOD is retried up to a given number of times, preferably 3. If no ACK is received after the last retry, then the state is released. In addition, if the destination of the FLOOD was in the cache of the sender, then the cache entry is removed to avoid trying to send messages to the unresponsive node in the future.
[0086] When a node receives a FLOOD message, it is processed by first acknowledging the FLOOD message by sending an ACK. The flags field is set to "KF NACK" if Validate ID was present and is not locally registered. Next, the FLOOD message is validated. This includes doing local verification of the CPA signature and contents. If the CPA is validated, then it is determined if the CPA will be added to the cache. If the CPA is for a PNRP ID that is registered locally on the same node, then there is no need to add it to the cache. If the identity used to sign the CPA cannot be verified by the CPA alone, and the CPA
would be added to one of the two lower levels of the cache view, then identity validation needs to be performed as will be discussed below. If the validation fails, the node drops the FLOOD
message. If it succeeds, the node continues processing the FLOOD. If the CPA
is already expired then the node drops the FLOOD. If the CPA is a revocation CPA, then the node removes the corresponding CPA from the cache if there is one. If one was found, the node forwards the revocation to other neighbors by sending FLOOD messages.
[0087] If the CPA is not a revocation CPA, then the node updates the cache. If a matching CPA is already in the cache, the node updates the cache entry with the new CPA
data. If this is a new entry, then the node creates a new entry and tries to add it to the cache.
The entry may not be added if another entry needs to be removed to make room for it, but the existing entries are preferred to the new entries due to higher trust levels or better proximity metrics. If the entry belongs to the lowest cache level, then it should be added. If the CPA
belongs to the lowest cache level, then it should be forwarded to some neighbors, even if it failed to be added to the cache. If the FLOOD was received during synchronization, then forwarding of FLOOD messages is suppressed, as it is assumed that all discovered CPAs are already known by other nodes. If the FLOOD needs to be forwarded, then a set of n PNIRP
IDs that are closest to the locally registered ID are chosen. A FLOOD message is sent to each of these with the new CPA, and a Flooded List that includes the n neighbors, plus contents of the Flooded List received in the FLOOD message that was received.
[0088] Identity Validation is a threat mitigation device used to validate CPAs. It has two purposes. First, identity validation ensures that the PNRP node specified in a CPA has the PNRP ID from that CPA locally registered. Second, for secure PNRP IDs, identity validation ensures that the CPA was signed using a key with a cryptographically provable relationship to the authority in the PNRP ID. Details on how identity validation accomplishes these two goals can be found in the above identified pending applications.
[0089] An identity validation check happens at two different times. First, an identity validation occurs when adding a CPA to the lowest two cache levels. CPA
validity in the lowest two cache levels is critical to PNRP's ability to resolve PNRP IDs.
Performing identity validation before adding a CPA to either of these two levels mitigates several attacks.
In this case the CPA will be held in a list for up to, e.g., 30 seconds, waiting for the AUTHORITY message. Second, identity validation occurs opportunistically during RESOLVE. PNRP caches have a high rate of turnover. Consequently, most cache entries are overwritten in the cache before they are ever used. PNRP does not validate most CPAs until they are actually used. When a CPA is used to route a RESOLVE path, PNRP
piggybacks identity validation on top of the RESOLVE message. The RESOLVE contains a 'next hop' ID which is treated the same as the 'target ID' in an INQUIRE message. The RESOLVE is acknowledged with an AUTHORITY message, the same as is expected for an INQUIRE. If an opportunistic identity validation fails, the receiver of the RESOLVE is not who the sender believes they are. Consequently, the RESOLVE is routed elsewhere and the invalid CPA is removed from the cache.
[0090] To illustrate this validation, assume P is a node requesting an identity validation for PNRP ID 'T'. N is the node receiving the identity validation request. P
generates either an INQUIRE message with target ID = T, or a RESOLVE message with next hop = T
(and RF IGNORE NEXTHOP not set). N checks its list of PNRP ID's registered locally.
If T is not in that list, N responds with an AUTHORITY message indicating ID T is not locally registered. If the received message was a RESOLVE, the RESOLVE is discarded, as P will take care of forwarding it elsewhere. When T is in the list of PNRP IDs at N, N constructs an AUTHORITY message and sets the target ID to T. If the RF_SEND CHAIN flag was set, N
retrieves the certificate chain (if any) relating the key used to sign the CPA
to the authority for PNRP ID T. The certificate chain is inserted into the AUTHORITY message.
The Classifier part of the Peer Name is also added to the AUTHORITY message.
[0091] N sends the AUTHORITY message to P. If the AUTHORITY message is longer than 1216 bytes, then the message is split into multiple fragments of 1216 bytes or less, and each fragment is sent. If T is an unsecured ID, or if the CPA was already validated (sent RESOLVE with RF-SEND CHAIN clear), then processing is completed. P validates the relationship between the CPA signing key and the authority used to generate PNRP ID T. If validation fails, the CPA is discarded. If validation fails and the initiating message was a RESOLVE, P forwards the RESOLVE elsewhere.
[0092] As explained in the above identified applications and as discussed briefly above, it is possible that PNRP clouds may be split. This can happen in two ways. First, the clouds may have started out independently and need to be merged. Second, the clouds may have started out as one, but some fragment of the cloud became isolated from the rest of the cloud.
To bridge any possible splits, it is assumed that clouds will have designated seed servers.
These are the same servers used for bootstrapping via DNS. If there are multiple seed servers in a cloud, then the seed servers must communicate with each other periodically to ensure that they exchange IDs in their cache. This can be done using the Synchronisation process.
This will avoid the creation of islands.
[0093] Nodes in a cloud will periodically poll seed servers to test if the node has become isolated from the main cloud, and attempt to merge back if necessary. The frequency at which a node will test for a split is inversely proportional to its estimate of the cloud size.
This is to keep tests for splits from occurring too frequently. A node that has recently joined a cloud should wait for a period of time for its cache to have been populated before assuming that it is able to estimate the cloud size.

[0094] To enable merging of clouds, the PNRP REPAIR message is used. REPAIR
has a PNRP ID, the IP address of a node, and a Repair Level number. Cache levels are numbered with 0 being the top level (broadest number range), and each subsequent level (smaller range) being 1 higher. When a split is first detected, initialize a Repair Level value to 0. When a node decides that it should perform a test for a split code, the node will internally generate a REPAIR, using the address of a known Seed Server as the IP address, a PNRP ID
that is registered locally, and a level of 0. It processes this REPAIR itself.
[0095] When a REPAIR is processed, the node does a test for a split. It first fords a locally registered ID that is closest to the ID in the REPAIR message. Then it sends a RESOLVE for this ID + 1 to the IP address specified in the REPAIR message.
This RESOLVE should have a Reason Code of Repairing. If this resolves to a known node, then there is no split. If it resolves to a new node, then suspect a split. If the new node discovered falls in the bottom cache level (highest number), then flooding is performed as usual. A
Reason Code of Repairing is set in the FLOOD message. As well, if the node receiving the RESOLVE puts the source ID in its lowest cache level, then that node will flood entries to the source. All this flooding will result in exchanging of several IDs with the new cloud. All new nodes discovered via flooding are kept track in this way.
[0096] If the new node discovered is closer than previously known nodes, and there are cache entries at the received Repair Level, then the node sends the REPAIR
message to entries in the cache at the Repair Level. For each REPAIR sent, the node selects one of the newly discovered node lD and IP address, and pass in Repair Level + 1. If the new node discovered is further than previously known nodes, then the node sends a REPAIR to the new node, passing in some ID and address from the local cache, and the received Repair Level.
Each node that receives a REPAIR message processes them in the same way.
[0097] As will now be apparent, the PNRP protocol consists of ten message types. Each message begins with a PNRP header, followed by fields specific to that message type.
Overhead (such as the field description) is calculated separately in the 'length' column of each message field table. In the following description, a generic message data structure shared by all of these messages is described, followed by a detailed description of the message data structure for each of the ten messages included in the protocol of the present invention. Following this discussion, a description of each of the field data structures that are used to construct the messages of the present invention will be provided.
[0098] Illustrated in FIG. 5 is an exemplary data structure diagram that illustrates the basic message data structure 260 used to construct the ten messages of the PNRP of the present invention. As may be seen, the message data structure 260 comprises a number of fields 262~_N. In a preferred embodiment, the first field 2621 is reserved for the PNRP
Header. The field data structure 264 for each of the individual fields 262~_N
that are used to construct the message 260 includes a type component 266, a length component 268, and the actual content or payload 270 of the field data structure 264. The length component 268 is calculated as the length 272 of the entire field 264. In this way, the protocol is completely extensible.
(0099) In accordance with the data structure of the present invention, the RESOLVE
message is constructed. As may be seen from the simplified data structure diagram of FIG. 6, the RESOLVE message 280 is constructed from a number of fields 282-292. Also in accordance with the field data structure of the present invention, the various fields are constructed. For example, the PNRP HEADER field 282 comprises the field data structure 294. The components of this data structure 294 include the Type (Field ID
296), the length 298. The content of this PNRP HEADER data structure 294 includes a protocol component 300, a major version component 302, a minor version component 304, a message type component 306, and a message ID component 308. Similarly, the VALIDATE PNRP_ID
field 288 contains the filed data structure 310. As with all other field data structures, the VALIDATE PNRP ID data structure 310 begins with a type component (Field ID
312) and a length component 314. The content of this field data structure includes the component 316 and the service location component 318. Each of the different fields are constructed in a similar fashion as illustrated in FIG. 5, descriptions of each will be provided below.
[0100) As may now be apparent and as will be illustrated below, this RESOLVE
message contains a target PNRP ID to resolve, the CPA of the RESOLVE originator, the CPA of the 'best match', and a list of nodes which have processed the ~ES~IJ~E,. The I~ES~f_,, includes a 'flags' field. Tzvo fli:.gs are deflszed far the ~ fags suhfield e~f the Resolve ~or~~rols fiend: I~Z~'-Sl~NI3 ~iN - rx;a001, ~,-hich requests fhaf the receiver ;rend a certificate clcain (if any exists) in A~T'f~(~I~IT~' response; and I~f IGI~Tt~f~ N~~~~TI-IC3a -0x0004, vvf~ic:h is used an the backtracking patio of a I2ES~h'~IE. Irh a node is res~c.iving a RES~f,'IE as pa~-~ of backtracking, ~~he sender does ~~~~t kno~sj this node7s PNRP fI3. 'fhe 'next hop' field is set to zero, and IZF'-IGN~7RE NEN~'j-IMP is sea to indicate the ~,IJTi-I~I2f'h~ vial o~gly be used as an 'ack' for the RESC3L,~E. :~s discussed above, ;~ES~SL'~E r-c ceipt is acknowledged by an ~.IJ~'H~I~.IT'~ message. The I~l_essage ~ ype in the Deader is set to ~ i~~ a preferred embodiment of the present ir~ve;~tion. IJetails of the data strus,tu.te of the RES~LS~E message constructed in accordance wi.fh ~~lge teachi~~gs of the present invention ire presented in 'fade 5.
a z ~aa ~3~~
~

~'s ~
i~
[
~1 1~%;
., ~
I~1a ,~"?_-yy ~
F

,.,, ~~
'-;,~~
~~~
~
~~.
~~
i '.<
A~d~T
~~~~~~
N
l ~
~~~
~
~' ~
~
~~~
~
~~~

0 , , . a s F ffeader .~
, w ., i . :~
kf ""
; .
a,.3,. 3 ", . Ideader 4+~ ' .. J pNRP DE~~I~EI~

12 4+I Z I~ ES(W~IE-~Q~1 ~~ontrolsp'lags, unique al~C3IJS hops allowed for the RES~L,~IE request., opcode to control r resolve, and I precision for matches. also _ reason for resolve.

2~ ~ 4+3~ ~,~R~iE~' f'Nf_tP_f~'fa.~t t NP.P Il~
- to resolve ~~ ~ 4+32 ~ ~~~h,TI~~.TE Nextl~opExpected next ~l'~RI~ I~ hop _ I'NI~P I~

100 4+P ~ ~'~ )~FST_ ~1~~'f~~"I~f~~ st CI'~ for node with l~~atch ~NRP iI~ closes-t to ~:I~~. Tar et so far .
104 4+~+ fh~~ ~N~P~LNT__P,I~R!-~Yfl'aggedt~rray of nodes + -~ ~~'~0 Pal? v~hich processed I' the RES~I,~E.

ll~+

p ~_ A.'~20 rf~EL,E 5 3~
[IiIO~~ In this 'Table 5 P is t~~; Lengtl= ire bytes ~~fthe encoded ~P~, roa~nd~;d azp to the nearest I)~~RD boundary. ~, is the number of entries in the flagged array.
This should not exceed the Nlax I~op valve.
[~1fl2] A RESPC3NSE is ger;erated s~hen a RESGLVE reaches the node owning the target P~TRP LIB, or when tire flagged pair size eduals the RESOLVE I~ax Hops. When a RESPG1~SE is genes°ated, all entries vrogn the corresponding I~ESGL,~1E
flagged path are copied into the I~ESP~i~SE bath. RES~~i~ISE messages are 3~os~ted thLro~;gl°~ all addresses marked 'accepts in Path, from bottoa~y to top, until cach appropriate r~eL-work ~~ndpoir~t has processed the RESI~J.~JNSE and it is returned to the RES~3LVE originator. !~s discussed above, a I~ESPC~1VSE receipt is ackno~,vledged by an ~~~ message. In a preferred embodiment, the Message i'ype in the I-leader is set to 6, Details of the data structure of the RESP~Ti SE message constructed in accordance with the teachings of ~;he present invention are presented in 'Table 6.
~ ' ~ " ~'y S .
drat ~ ~. '3'3, ?t f~~i~ 4\N~~ ad. ~ ~ ~ A < <. 3A
~-1 ~ \y 1 t S R :~ '~ ~ .~ i t<s 'I M ~.- ~ D~~ g. \ -~Y , ;; s s ~ '. S a~, .s. '.. W ~ ~...-.. ,~, ' ~'~'~.,. _ ~a dt,. ., ~~ ~ .w a;s _ '~a,I a \. .,.,.~~ fiar~., a F . ' e' ~a~= ; ~a 0 4+8 - P'~Rp_I-IEr'~DER I-Ieader ,Header I~ 4+12 IWSGL,VE ~(:~~'I'RG ~:ontrol I Reason for original ~S ~~ s RES~LVE, and type of i ~~ RESP~NSE, 28 ~ 4+~2i 'T~.RGE ~ ~'NRP_1D r Target PIaTRP ID resolve __ re uested_for 64 4+P ~ ~P~ BES'.~_MA'T~:FI Best ~P~ closest to 'Target (latch ~PA_ _ f 8 + P 4 Il3VS E~II~POII~~"_t~ P lagged l~rray of nodes which + P-'~' ~ Path processed the B"20 ~ RESOLV.~I before the current node.
80+P ~,~,Iw° i~ ~b~.: ~ a. ~,~~; ~~L~ ,I,,. ~ r"L, I~~ ii ~~ j +B~'20 ~~ ~ ~s i s,l ~ r ~, ~~u~, ~'t~l3LE 6 [ID~03~ Tn this 'fable 6, F is the length in bytes of the encoded sour ce ChA, rounded up to the nearest D'NORl3 boundary. B is the number of entries in ~~he endpoint array.

[OL04~ The S~LICIT message requests the recipient to ADVERTISE some entries from its cache to the sender. The sender includf;s a CPA that the receiver may add to its cache.
The I-IashedNonce must be returned in the ADVERTISE message. SD:LICIT receipt is acknowledged by an ADV ER T i ~iE. message. In a prcferred erruodiment, the MessageType in the Deader is set to 1. Details of the da~:~ st~~acture of the SC~L,ICIT
message consl~ructed in accordance with the teachings o~ the present invention are presented in Table 7. In this table P is the length in bytes of the e~~coded source ~"hA, ro~r~ded up to t~~e a~earest L~Wt~RD
boundary.
T AI~LI7 ~0~0~] The ADVERTISE' Message is generated in avspoa~s~ to a Sl'~LICIT. The ADVEIZ.TISE lists some of t(~e ~NRP ID's from in the advertiser's cache. This allows the ADVERTISE recipient to selectively IiE~UEST CP.~'s to populate its cache.
ADVERTISE
receipt acts as an acknowledgement o> a SCLIClT. No acknowledgement for the ADVERTISE is generated. Any ADVERTISE a~~hicl~ is not acting as an acknowledgement of a S~LICIT should be silently discarded. 'hhe Da~shedNonce vale rr:ust be identical to the one received in the S~LICIT rr~essage. A node that ~-eCeives a~H. ADVERT.1S~E, mnst be; able vo validate that ghe hashed I~lor~ce is valid. Ig-t a lsre~erred embodiment, tire n~iessageType in the header is set to 2. Details oI'the data struetiire o~the ADVI;RTIS.E
message constructed in accordance with the teachings of the present ismention are presented in Table ~. In this table A is the # of entries in tl~e ID array.

~'t~

[I3106~ The RE.Q~JEST r-~essage is used to request an advertiser to FLOOD a subset of ~D~ERTISE°ed ChAs. The Nonce should be hashed and co~n;~ared with the I-Iashed~donce received in the original SOL'~CIT. 'The ID Array contains h1~1I~P IDs that the sender would life to be Flooded back to the sender so drat it can get tl~e CP~~s.
I~~~QtJEST' receipt is acknowledged by an ACK message. In a prefewed era~r,bcdirnent of the preseoat invention, the Il~IessageType in the I-leader is set to ~. Details of the data struct~z~~e oI'the IZ~QUES'T
message constructed in accordance with tl~e teachings w"the present inventicsn are presented in Table 9. In this table A is the # of entries in the III array.
T~A~L~, 9 [Ot07~ The .FLOOD rrEessage is ~xsc,d by hII~l7~P to propaga.~~; cached Cl'I~,s to select peers.
FLOOI~s are initiated in reslaonse to ~ REQUEST message, ~Tlqei: adding a new CI'A to the lowest cache level, or when processing a revoked CAA with ~.n earlier version in the lowest cache level. ~LOODs include a list of addresses to help prevent redundant I~LOODs, called J
the 'flooded list'. T he Flooded List co;mains tl:~e address of the scr~.der, ever<J destination the sender is going to directly traa~srr~it the i~L~30I~ to, and flee address of away other Pl'~1'~.I? nodes the sender icno~~s already rec:ived the aaL~~D. A 'Flooded List' has a rr~a~:irn~arrY number oi-entries. If the list becomes full, entries are replaced according i.n a Fli~'D
man ner. Tlzis assumes that i'L~~D recipients are more likely to propagate boat FL~~I3 to 'nearby' neighbors than more distant ones. F'L~DI~ receipt is acl~:nosvledned by an AC',I~ message. The ~lalidate ID is an optional fee ld. If present., it requests that the recipient respond with an ACS
if a CPA with the specified P?~ItP ID is locally cached, else a I'~A~:I~ if it is not In a preferred embodiment, the IVIessageType in the i-Ieader is set to 4. Details afthe data structure of the FLDGD message constructed in accordance with the teachings of the present invention are presented in Table 1 ~. In this table P is the length in bytes of the encoded CI'A, rounded up to the nearest D~~RD boundary, and A is the number of entries in the array.

i.< y .., ~ ~ ~. :, ~. ~ (R 7P ~ ~ "Nt 9 t, . ' 7 a::, .~e ,. _ ~t ~
,v~..,Y.: _~~~ 1 ~ ., 3 . '"
v ~ ~
;ig t .1i i7 rW
_~

J 4+~ P1~1~P ~eader lIeader 1~~,ADI?t2 12 4+2+2 FL.~DD Controls Code that ~Ct3NTRDLfi describes reason i;or FL'~~I3.
May be used it processing ;FLfl~D.
Also, ' padding to move to 4-byte - boundary 2(3 (4+32)'tIAL.:IL~AT~ ~Ialidate ~7ptional PT~tI~P'1D I'i'~1I~P

i D YIN to ~,~~;ri 20 (+36)t 4+P i C1'A CI'A being CPA -ICES
T_IVIATCI-I

~ flooded 24+P(+36)4+~;- IPW~
I?hiDP~l~I~f_AId~A'Y
~
:flooded '~

A~'2~ ~BSt 36+P+

A*20(+36 '~A~I_,~ I ~
~010~~ The INQ~Imessage is used by P~!RP nodes to perforrx~ identity validation on select CPA's beforL entering them into the local cache. An identity validation conlirrns a CPA is still valid at its origiF~atii~g node, and reciuests informatio~s to i~elp validate authority of the originating rFode to register that CyA. one flag is dean ed for the 'flags' field:

Rn~ SENL; CHAIN, which recauest for receiver to send a cart chain ~if any exists in ATJTIIflRIT~' response. IN~LJIRE receipt is acknowledged wirlwi~ I~UTI~()RIT'~
message if the ~NRP lIa is locally registered. C'tllerwise tile INQ!UTRE s~mssage is silently ignored. In a preferred elllbodiment, the ~,~ess~geType in tile I3eadei~ is set to 7.
I~e,tails of the dazta si~ucture of tile INQUIRE message constructed ill accordance ~~.~ith the teachings of the present invention are presented in Table 1 ~~. l~s vdill be apparent fhom this tae~le, there ire an additional 2 bytes after f'i~.~~'~~-T'IEI,I~ to pui the next :Geld on a ~'~W~l~l~ boundary.
- , ~ - _ ~3 . PNRh T-IE,~I;7EI~Deader 1-leader +
~

_ _ 'iI~ LACCS PIELI~1 FlagsIndicate whether 12 _ cart 4-~-2 +~ ~ Cllaill Or 51127p1e CoilfirmatlOn of local ~ registratiion is desired.

i Also, padding to move _ _ to 4-b t~; boizndar 20 4+32 ~"Jr~LIEA'h~ hNRPValidatePNRP II7 to validate I~

r esence; of ss rAI~L~;11 ~I810~~ The AUTHCRTT'~' message is used to confirm or deny that a PN.I~P I~ is still registered at the local node, and optionally provides a certificate chain to allow the AUTI-I6)RITY recipient to validate the node's right to lvgister the CPA
corresponding to the target III. The following flags are defined for the 'flags' field: AF
L7NICNC3~dN II3 -Ox0001, which indicates that the specive~~a 'validate' hrolRP TI1~ is not registered a% this host;
f~I~ INVAI,IIJ S~URCE -- T9x00G~, which is not used; AF I1'~1V~,Lrl3 BEST'-NIA'TCI-I -Ox000~, which is also not useel; AF lt~ivJECT TGCJ ~ZJSY - 0x000&, which is only valid il~
response to a R>;S~LVE an:I indicates that tile Host is too busy to accept a RES~L~.E, and 'r'ne sender should forward it eise~'al~ere; ~c~r processing; AF RE;IE~;T-I3FAI:~ENL~ - 0x0010, which is not l,lsed; AF REJr~"T' ~,CCP -.- 0x0020, which indicates that the vole has already processed the RESGLVE message and that it should not leave been sent here;
~~F 'TRACING CN - Ox00~0, which is :zsed fog debugging orxly; AIi REIJIRECT -Ox00~0, ~vliicll indicates that tile noc'ie is not fo:rw~~rding the I~pSCL,VF:
rrlessage, but has in eluded a Referral address in the AU'fDGRI'f~ message; AF lfetVALII~_RE(~1JEST - OxOI
00, which indicates that the RESC~I~VF, lriessage fails validation which could happen if the ll~Iax~Iops is too large; and A~ CERT'-CHI -- ~Jx80QJ, which indicates tl'~~t a certificate;
chain is included enabling validation ofthe relationship between the ~rax,idate P1lrI2P
Il~ and the public key ~zsed to sign its CPA.
[~1I~The ~falidate P~RP ID has the ID for which the AIJ'i,HO~T'Y is sent. The Cert Chain is optional. 'fhe AI~_CLf'~TaCI-lAl~~ flag indicates if it a present or not. The deferral Endpoint is also optional. This x=ield is used by a node that cannot forward a .'E~SOL~E
rnessage,'out knows of another node to which the IaESCeI~~IE c;~;uld be sent.
'lChe endpoint contains an IPv6 address and port of a peer node to E~rhich the ~ ESOI,'~JIJ
is to be sent.
Currently this f~.eld is ignored except when a node is trying to detect a cloud split via a seed server. The Classier field contain the actual Classifier string Tat is part of the Peer Isla~~e used to create the PNI~P II6. ~~~JT IOI~Yfh~'receipt is not explicitly acknowl~°dged.
AU't'I-IOl~lT1' is only sent as araclcnowledge~nent/response to either I.NQTJIIW or I~.ESOL~E, messages. If an AIJTHOIg.x'h~' is ever rcceived oufv of this context, it maast be discarded. In a preferred embodiment, the Message T ype in the Header is set to ~. Details of tlae data structure of the ALJTI~i~I~F'I'~ message constructed in accordance with the teachings of tlae present invention are preYented i~~ Fable 1~. In this table C is the Ieng~th in bytes of the eLlCOded cart chain, rounded up to the rxearest ~~Of~D boundary, and S is tl~se length in bytes of the Classifier string.

i F: ,t ~
s ' ~ !
, ~H~
~
~
i ~i ~~
~,.

~
~
;
.
~
~y3 ~ i ~I
'".
i5 ~~.
~~~
~' r~~~
~~i ~ f ~

~
.~"
, ~~
M

~~ srn . : e , .
, i ,a ,..: ~
: ,wY
' ...af 0 4+8 , PNRP ~IEAD.ER deader header 12 4-t-4 ~ PNRP~I-IEAI3ER ,~C~~d Fleader A~KEI~ ~Ieader from RESOLdIE
or E I INQUIRE
j j being ~
implicitly ACICd 20 4+4 ! SPl_,I'T_C'OI~ITROL~SSplitControlOptional Split control Iol _ _ bra ~ entation 20{+8)4+2+2 ;Flags Elags , ~L,AGS IIELI~ indicating i contents and possibly result o~
RE'SOL~1E
/

I1VQ~1IRE.

Also, padding to ! move t to 4-byte boulldar 28{+8)4+32 ' ~t~.LII~~IrI'E ~Ialidate PIvTRP
~ 1'NRP Il~ 1D
_ - AU'TIIORIT~I

i _ ~_ ertains i 64(-I-8)(4+20) I 1P~6_REEERRAIL_A1:9I~RE to ~ Iaelerral IPv6 endpoint.

~S ~ ~1'l.dpC7CntThls leld o tronal.

64(+32)(4+32) LP~6~REhERRAL-Il~ a Refer:aIPleIRP

for P~NRP II3 the IPv6 i endpoint.
This ' ; Meld ' is o tional.

64(+68)4+C ~~~ERT CIIA'1~T _ Cert ~elt Chainchain relating public key used to sign CPA
to tlae i re istered 68 {4+~+,~ CI,:ASSII=IER j ClassifierClassifier + string.
C

(+68) 'this ; Field is i o tional.

68+C ra';~,fqi ~~, n,~ ~r~.~r i ,lar; ~i~~~
~~,~~~w,~ ~~~,~~ p~~,-~ ~~~ r:~, via ~p~ ~i~~~
;

(+S ~d l -+- I I ~r ' i' 80) a ~l'AELE 12 ~aIII) The AUTI-IORIT~ message may be very long, as it contains a Certificate Chain and a Classifier string. ~'o Facilitate transmission through a network, it may be explicitly ~~roken into several a'~ragments ~oJlaen it is ~;cnt. The Receiver n~~ast'ae able to put the ~rag~nents together before processing the message. II' she message is split, then the Header and ~.ck'd I-deader gelds are repeated in each -agr~er~t. Each fragment also contains a Snlit Control held. In each fragment the Offset value in the Spilt Controls ~=~eld are changed to reflect the Qffset of the fragment. The Size value in Split Controls is the size of the entire message, minus the ~Ieader, ACI~'d Header and Split Control fielpa sizes. Each fragment except the last, must have the same size.. If the message is neat split, then tl~ze Split Controls field is options 1.
(i#fll2~ The ACID message is used by Pi'~TRP as it is a request/respo~ase protocol. In certain circumstances, using an ACID instead of a response simplifies tl~e protocol.
An ACID is always transmitted Ltpon receipt of RELIES T, R1JSPCI~1SE a.pad PL,C~CI) ,_-ns~ssagcs. ~ther messages are acknowledged ~~ the appc~op.~iate response messra~e type. 'I'hc .ACK may act as an ACS, or it the case of a ~L,(~t7I~ w3~th a Validate 11~ set, as a ldACR by setting the hlags f=old to I~F ~IACI~ = I. In a preferred °mbodiment the ~essage'8'ype in the Header is set to ~. TJetails of the data structure of the ACL~ message constructed in accordan ce with the teachings of th-a present invention are presented i~-~ Table 13.
rl~A13IJE I3 (~y~~~ The REPAIR message is used because., in same casks, hl~lRt clouds may experience a split. This message is used to test for a split and initiate a REIjAIR if necessary.
REPAIR will request other nodes to propagate the Rp.PAIR to other cache levels. In a preferred embodiment the l~ess~.ge ~ ypc i~~ the I leader is set to I d.
details of the data structure of the REPAIR messa;e constructed in accordance with the teachings of the present invention are presented in Table I~-. As ~.vill be appare,~t from this table, there arc an additional 2 bytes after CAC LEVEL to put the next field on a ~~rVORJ
boundary.

t.:.. 3 , q " 3 -itg , .3F~. ~~i w f. ~ , Cs .in . ~ I :,at t ~~.Pt ~ ø s,.'.'~~ ", ",. ~~~~I,a ~~ '.,.. . t~ ,,;~'..,'~"" ~ ~~ ,.;:.~n,y.nls a 3 i ~~ , n,.~&~~.r: ~:~~,t ~,.~~;33~~xw: "~~ t~E~~~:3:7 ' 0 ! 4+8 PNIgP I-~E~.DE~ t_-Ie_~der -leader 12 ~ 4+32 ~ ~'A~GE'1, i~I~IRP_1D PNID to locate __ _ ~7 48 4+2 ' ~.~~1 ~E_LE~EL lZepair ~acbe level to use far +~ ~ ~ ~,e6ae1 repair test. l~.lso9 padding to move to ~-_ b a bound 56 4+~0 ~ ~~~t76 ENDI'~lN'f Repair Il' f;ndpoint to,use for Address repair test aAl3LE 14 [0~1~~ ~avrng discussed the messages and their data structr~res, attention is now ta.~rned to tl~e message elements used tc, construct tl~use messages. The fioIowing details the I~yte codes o~ structures transmitted in I~~11~F rnessag3a. X11 nuerrbe,rs are transmitted in net~wo~°k byte order, and ail text is encoded as LJTF-~ be~ore tras~smisc>~on, unless other~is~; indicated.
These message elements aro the huildi~~g blocks for the Snessages just discussed.. The basic message element is a Field description. Each Field elerr~ent should start on a 4 byte boundary within a message. 'This rnear~s that there r:~ay gaps bet~,veen Fields.
~0~~~~ The MESSAGE-F1::EL D element is t3~e held description that is used to erasure PNRP will be easily extensible in the future. For each set of data in a message, it provides a I6-bit geld ID' identifying the yield type, and a 16-bit byte count for the held. Details of the data structure oa°the iVIESS~GE FIELD elen~eni constructed in accordance with the teachings of the present invorrtion ar-e presented in Table 15.
~~ I J
~0116~ The PNIZP t-IEl~i~E3~ - type Ox00I0 is used to start all PI~NP
messages.
~'rotocol+~lersion make a 4-byte identifier useful far determining whether a received message is truly intended for- PN~P. Details of th,, data structure; of the i'~:l~P 1-IEADER element ~r~
constructed in accordance witi~a the teaci~ings of tlic present invention are presented in 'fable 1~.
'i~~FL,F. 16 [~LZ7~ 'fhe Message II3 ;n ~i~e i"NI~~ ~IE1~~EIZ is used so that a node can ensure that a received message that purports to ire u: response to a message that the node sent, is in fact such a response. For example, suppose that a node sends a I~ESt7LVE message to another node. 'his first node expect to receive an I~LTTI ~~ItITY message in return, as iiiastrated in FIG. 4. I-Iowever, without any vvay tracking or tracing the response to the original ICES~I,~E, tlZere is no guarantee teat ~ received t'~LT'I'~-Il'~RI~'~r' r,~essage is legitimate or spoofed ~y a malicious node in the cloud. Ey including a ivlessagc ILK in the IRESC~I~,iIE
message, the node that generates tic ~il'l'I-ICI~I'7~Ir message can inclEade this l~Iessage I~7 in its response in the Pl~lRF FIz;~~ER ~ Ci~EI~ field discrassed iaelovd.
~1JI1~~ 'I'he i'N~P-I-IEAI~ER ~CKF~ - type 0x0018 is a~ entire PIVIaP message header, used to identify a message being ~C~'d. ~etaiis of the data. structure ofthe F~~-tE~S~EIg ,~CI~ED dle,~ae:Et constructcd in accordance with tl-~e tcac~ings of the present invention are preseufed in 'Fable i7.

~~le'~~L~ 3 ~~~~9~ The t~~I~ ~NIW~tT~IT-type ~~xG~21 clcrnerat is ~:5cd bcca~ase hhJlth is specified to v~or~ in ~v~ clouds. 'his str~~ct~.-c specifics an IPv6 nctvvoric cndpoint.
~fhcre is also a flag that gay be Tascd to indic~tc nodc T.~tiii~y for a Ttii~CRf,VE ii~E
progrcss. ~~e ~'ath ~dag is azsed to indicatc if a ~~L,~>r~ seat to the address mas ~cceptcd or I~e3cc~tcc~. tn addition if the address gas to a close neighbor, tie ~~spect t'~ag rnay be sc~, since the r~crdc s~onld lcnovv ail its ciosc neighbors. T'hc <~ddrcsse~-noqied indicator is ~scd. daring debugi;ing to mark an entry as reYnoved, avitho~t act,~saF~y rcmoviug it. 'Thesc indicators are as foliovas:
~T~1~~ ~i..!~~~ aI~ fi~I~It~~~ ~~: ~~~'~~~ - ~:~.fll;
~~i~' ~i_,~GB~~~ ~~~3~~~~ ~iJ.f~~;f~~I3 - ~~i32;
t'~1~~ ~'ir~Cy~~I~ ~T~~)i~~~~ tJi~l~~,~~,~~~t.~ - ~~~~.;
h'i~I~~ ~t.AG~i;I3 l~I~~~:~,~~ f,t'~~I~ - ~A~J~;
F'1~TI~ Ft_,A~'a~S~I~ ~~LIe~~'~ ~i'~~ ~CT~'~I - 0~ 1(i;
T~3~i~ ~'~A~i~~I~ Aiv3I3I~~~~ ~t:1 ~11~~,t~l~"i'E ~~ - fx~~;
f'~.1~P ~'~,~t~'r~'aE~7 ~'~'v~IW~;~ ~~~Z~~li,'~ - 0~~0; and ~t~l~P ~'~,A~~~~ ~LTSP~~; ~ I~.~~i~'f'~i~E~ i3~ - ~x4~. I~etaiis of the data str~ct~.~rc of the tP~I6 ~.hT~F'OII~1T clct~cnt constr~actcd in accordance vri~ih the t cachirlgs of the present invention .are ~resentcd in Table i 8.

~-5 AI3LIl I &
[~120~ The PNRP-iD - type O:x~030 element is a concatenation ~f a 12~-bit p2p ~D and a 1 ~~-hit service location. Details of the data structure of the PIE I~ ID
element constructed in accordance with the teachin s cf the pa~esc~t irweaition ~w a pre smated in 'I'abh: I9.
TAFLE t9 ~I9121~ The TARGET hNhP ID -type 0x0038 is ti'e target II; for a ~ZP,SOLVE
reciuest or its corresponding I~ESPOl~T~~. Details of the data structurc ofthe TARGET
PNRI' ID
element constructed in accordance wia tile teachings of the present invention are presented i~t Table 20.

4~
[f1122~ The VALIDATE pNl"ZI' 1D - type 0x0039 is the t'NI~ ~D for vrllich validation and an authority are requester. Detaii.s of the data structure of the '~lAt.IDA'fE PN~ ID
element constr~~cted in accordance v~itl~ the, teachings of the present invention are presented in Table 21.
'FABLE 21 [f~323] The FLAGS FIE~1~ - type 0x0040 identify flags that are a bit field used for context-specific purposes. t'setails ovthe data structure of the :F.I~A GS
FIELI' eiernent constructed in accordance pith the teachings of the present ine~ention are presented in T able 22.
'fAI~LE. 22 [0~24~ The I~ESOL~IE_~'~JNT~OI~S --type ~Jx0041 field contains information to =ae used in processing a RESOL''E or a 12ESPONSE. 1?lags are used to indicate if the I~ESOL~IE is baclctracKing or ifan ALlTa~~lZl TAI message is requested, The flags include I~F-IGN~3I~E I~TE3~r=HOp - 0x0001; Pte' SENF%~C~AIN- Oa:0004-;
RF DONT I~Eh!IO~IE PATS ENTRIES - 0x0008, vdhich is used for del7ug only; a.nd RF TRACING ~N - 0x0010, ~aa~hicl~ is used for debug only. l4flax t-Iops limits the number of hops before completing the 1~~~SO~~JE. Operatic>n Core describes hoev the matching should be performed. i~atehes may be only the top 128 bits (P23~ tD~ for ANA codes, or may consider the Service Locatiota as ~~°ll for 7~EAl~EST codes.
Ope_~°ation codes also determine if the match should conside~-1Ds registered on the same node as tl-ce originafc~r of the RESOL~IE. The operation codes includes SEARC~-1 'CODE. NOII.TE - 0;

SEARCH OPCODE ANY PEERNAME - l;
SEARCH OPCODE NEAREST PEERNAME - 2;
SEARCH OPCODE NEAREST64 PEERNAME - 4; and SEARCH OPCODE UPPER BITS - 8. Precision sets the precision on the ID matching to an actual number of bits. This value is used if the operation code is SEARCH OPCODE UPPER BITS.
[0125] Reason is used to indicate if the RESOLVE was sent as part of a Repair process, due to cache maintenance, as part of a Register, or due to an application request. The Reasons include: REASON APP REQUEST - 0; REASON REGISTRATION - l;
REASON CACHE MAINTENANCE - 2; REASON REPAIR DETECTION - 3;
REASON SYNC REQUEST - 4; REASON CPA VIA RESOLVE - 5;
REASON CPA VIA FLOOD - 6; REASON REPAIR - 7; and REASON CPA VIA BACK FLOOD - 8.
[0126] The Result Code indicates why the RESOLVE was completed and converted to a RESPONSE. This may indicate success or failure due to Hop count exceeded, no better path found, or too many neighbors failed to locate the target. These Results Codes include:
RESULT NONE - 0; RESULT FOUND MATCH - I; RESULT MAX HOP LIMfT-HIT
- 2; RESULT NO BETTER PATH FOUND - 3; and RESULT TOO MA1VY-MISSES -4. The transaction ID is used by the originator of a request to correlate the RESPONSE. The RESOLVE originator sets the Trans ID value, and the node that initiates the RESPONSE
echoes the value in the RESPONSE message. Intermediate nodes should not alter this value.
Details of the data structure of the RESOLVE CONTROLS element constructed in accordance with the teachings of the present invention are presented in Table 23.

Ldp yi a . '~~ a4gaE '~s ~i H~~"> :~~a~
~ , .~:':.,.~ 3_< ' I
~~ i ' I:~ ~ ~ t3 's ~ k t~ ~
3 ~' '~~
r~ ~ " ~ ' ' ~
~

,c ~ ,, sa"..,~
. a 1, I .
x . I , . , ",;v': 1 b ~ , .
e~

0 ~JS~!ORT Flags fit field for context-specific flaws z ; ~ ; ~~T~ Flax ~r~~nber ~~ ~rr~.~
~-~~ps nodes a I I ~ ~riessa a can visa 3 1 I ~YT~ Dperation Codes to control resolve Code operation. Should RESC9L~E
be f sc~r~t to orsgiaaator?
Should upper 1~8 bits of iI? be treated as s ecial?

4 ~ 2 ~ VJSfII~R'"~ ~furs~ber of significant T'recisaor~ bits to 1 i i ~"dli~tCh.

6 1 __ Reason Code that describes ~ ~1'TE Code reason for initiating R~SOL~IE
-application request, repair detectao~, registration, cache i maintenance,etc.

7 1 ~~''~'~ Result Code that describes Code reason for r c~turning the Response - found I
match, flax hop limit hit, no i - _be_tt_er bath found, etc.

8 4 I ~.1L~hrClTrans T'ransaetion IFD value.

TA~L~ 23 ~~~27The CA~: ICE I~L'~aF;L -- v~pe 0x0042 eleme~<t describes which cache level is to be used when executi~~g a RFFAiR. 'This is used when doing a split oache repair.
Details ofthe data structure of the CAC~~, LG~JL~ element c~:~nstrurted in a,ccorda~ace with the teachings of the present invention are presented in A'able ~.4.
'hAI~L~~ 24 ~~~2~] The f'L~~D-CCl~i a'RD~S - type 0x043 ele~~ent contains information to be used in processing a FL~OD. The Reason that tlae FLOOD vans sent is the only code used.
r3etails of the data structure or the 1~L~:>(~L~ C~~J'~'RC)LS element constr~actf,d in accordance ~~ith the teachings of the present iE~vention are presented in Table 25.

[~~~9~ The ~h~ SC~tJI~~~.- type i3x~Q5~ is the CI~~ used as the source ~P~ in a S~L~ICtT message. The ~P~ is encoded for t~et~voric tr~~.nsrya~ission.'~~;tails of the data structure of the ~P~ S~~,JI~~':$ element constructed in accord~.~2ce ~r~i~h the teachings of the present invention are presentLd in Tab'se 2.
T A~L,E z6 ~1I~~0~ The ~P~ ~~,5'f' u~~'T~I~ - t~y~~e ~x005~ element ~ > the ~P~
use°,d as the 'pest match' iv a R.ES~L~1E o~° T~:~'Sf~~aTSL. ~ he ~P~, is encoded for netv~or~ trausa~ission.
Details ofthe data structure esg the CP,~b~ ~LS'a I~IATC;~ elerrtent constructed n accordance with the teachings of tlm present icrver~tioe ~ are preser~tea~~ in Table 27.
TI~F~L~ 27 ~0~31~ The PNI~P I~ ~I~.l~~,~l -t~~ype tixa~0~0 element inc;l~ades the P~TP:P
ID's fo~-f'~I~VLItTIS~ aid I~FC2tJ~S :j messages stored in an array. The data, includin; the array sizes is descr ibed below. Details of the data structure of the t l.~il~P I~~
~ R~lIY ele~rnent JV
constructed in accordance with the ~cae~'~i~gs o~the present in~~e~tiorg are presented ire Table 2~.
'a:Al~t,~ 2~
~0~~~] The ~P~16~B1~I~P(~~~T Al~~~'1' type x(11171 is ~~ array oPall codes already visited. Blooded mcssa~es visi~ a e~ariety ofncdes. ~,acl-~ node ~.lready visited or transmitted to is entered into this array. T he data ia~cl~~dirg t~~te array sizes is described below. ~9etails of the data structure o~the ~P~ld ~NI'PC~IT~I'1' AR~A~ element constructed in accordance with the teaclaiugs o~'the present i~~ entio~~ are presented ire Table z~.

JI
"I'~Bs_,E 29 ~0L~3~ The IP~b I~IJF'EPaP.~L,_A=~~RF'~S -type 0x007'? cleme~~ is an EPv6 E9,~dpoint used specifically to provide av alternate address ~'or sending a i~E~(~L,~IE.
This held is used irz an A~JTI-IDRIT~ message s~-ize~~ a rzodv does riot rvas~t to foa~varc~ a RE~~I:'~JE, hut wants 9:o provide are address that some ~~izer ~~ode rnay ~ry. ~e~ails of the da~:a straacsture of the IPVS REFERR.~L ADDRESS element constructed in accordance with the teachings of the preseazt inwe~ztio~ are prese~zted in'i-'alzie. ~0.
'f'AELI30 ~Oi34~ The .IPjT~ REI~ c.R~I~~ II~ -type 00073 element ~s used together with IPv~ Referral address to i~zdicate the PI~RP IF3 that is being ~gsed for the referral. details of the data structure of the Ip~l~ I~IJp'EI~I~.AIJ III element c,onst~ucted it accordance with the teachings of the present iiwe_~tion are presented in Table 3 I.
'i'AEL E 3I
~~135~, The Cert Chain (~E~T (.".H~I~:I) - ty?~e fIx00~lI elei~e~t is built by using the ~lindows CAhI API. First the certificates that make up the chain are put into a CAPI in-memory cart store, and then cxlaor'~ed ats a 1'I~~ST encoded ce~l store. This exported store is sent without m~diircat~o~i.
[136 The C~IAI~- typa ~xOd~~ element is der'ned to hold a single IlNICD~?E
character. It is only used as dart o~'~11~II~CT~~ array fie,ld5 such as Classier.
~~137~ The CLASSIPIEI~-type t3x~085 element is tl~e UhlIC~3DE Classifier string that ~~as used as a basis for the g vi;r IvTame. It is encoded as an array ~f ~~I-IAI~ elements.
L'~etails of the data stricture ~.= the CLASSIpIEI?, elen-ic.rat constructed in accordance with the teachings ofthe present invention are presented iri Table 32.

'hAEf,h. 3~
~013~~ T'he ~ASI~EI3 ~~~I~E - type Ox00~~ eieruent is an encrypted 1lronce value that is included in an AL9'7E1~'i'rg~',~~. ~~~essagc;. '~"he rec;ipient is expected to nave tlae key to dcc;rypt the Nonce. details of the data structure of the I~..~SI~Ef3 I~IC)~~E element constructed in accordance with the teachings of the present i~~vention z~re presented it T'a171e 33.
'I"AEL;~33 '0139 Tl~e N~NCE - ta.°pe Ox009v a=erraent es a decrypted :once value that is included in a I~EC~tJES g j~essage. ~'he aec.~pient is e:~pectec~ to validate tll~E~tthe decrypted Nonce ~natehes the value sent before, i° gas er~cr'ypted. '~~eta.ils of the data structure of the NOhT~E
element constructed in actor dance with tl:xe teachings es~~tl~e pr~;sent invention are preseraed in 'fal3le 34.

J
'~,I~ELE 34 ol4~j The iPLIT C~i~TR~L~ -t,~pe 0~~0~1~ element is ~e~sed when a long message is sent as a series of fragments, rather than as a single message. Each fi-agrrrent includes the Split ~or~trols held so that the message can be constructed by tl~e receiver.
I'setails of the data structure of tire SPLIT' ~~h~'fR~L~ elear~ent constructed in accordance ~~~ith tire teachings of t9~ae present invention are prese~~red in 'lab3e 35.
T~I~L35 ~~D14~~ The pNRP TRl~~E - type t~x309~ element is used during debugging to hold data that can be carried from hop to hop between RES~L~IE and RESI'OI~SE messages.
It is ~.~sed to store tracing data. Via; ~~ot be supported in final version ofprotocol.
rd>i~~~ The foregoing description of~;ario~rs mnbodirrrents, of the inventia~n lras been presented for purposes of °~lustr~.tion acrd description. It is not intended to be exhaustive or to limit the invention to the precise embodiments disclosed. l~lur:~ero'.rs modifications or variations are possible in light of the above teachings. 'i,he err~fbodiments discussed rvere chosen and described to provide; the best iilrastration of the principles of the invention and its practical application to thereby enable o_~e of ordinary ;9lcill ir-~ the art to utili;~e the invention in various embodiments and vaith various a-r-~odillcations as are suited to the particular ~tse contemplated. X11 such moth acations and variations are within the scope of the invention as determined by the appended claims when interpreted in accordance with the breadth to which coey are fairly, legally, and eqnatably entitled.

Claims (100)

WHAT IS CLAIMED IS:

1. A computer-readable medium having stored thereon a data structure for use in a peer to peer name resolution protocol (PNRP), comprising:
a first message field having a first message element stored therein; and at least a second message field having a second message element stored therein;
and wherein each message element comprises a message element data structure comprising a field identification field, a length field, and a payload.

2. The computer-readable medium of claim 1, further comprising a plurality of message fields each having a message element stored therein.

3. The computer-readable medium of claim 1, wherein the first message element stored in the first message field comprises a header message element.

4. The computer-readable medium of claim 3, wherein the payload of the header message element includes information identifying a message type as being one of a RESOLVE, RESPONSE, SOLICIT, ADVERTISE, REQUEST, FLOOD, INQUIRE, AUTHORITY, ACK, and REPAIR message.

5. The computer-readable medium of claim 3, wherein the payload of the header message element includes information identifying a message type as being a RESOLVE message, wherein the second message element stored in the second field comprises a resolve controls message element, the RESOLVE further comprising a third message field containing a PNRP target identification message element, a fourth message field containing a validate PNRP identification message element, a fifth message field containing a certified peer address (CPA) best match message element, and a sixth message field containing an IPV6 endpoint array message element.

6. The computer-readable medium of claim 5, wherein the payload of the resolve controls message element comprises a bit field for context-specific flags, a maximum number of nodes that the RESOLVE message can visit, operation codes to control resolve operation, a precision number of significant bits to match, a reason code that describes a reason for initiating a RESOLVE, a result code that describes a reason for returning a response, and a transaction identification value.

7. The computer-readable medium of claim 5, wherein the payload of the target PNRP identification message element comprises a hash of a peer name of a target peer and a service location derived from an advertised service address.

8. The computer-readable medium of claim 5, wherein the payload of the validate PNRP identification message element comprises a hash of a peer name of a node for which validation and an authority are requested and a service location derived from an advertised service address of the node for which validation and an authority are requested.

9. The computer-readable medium of claim 5, wherein the payload of the CPA best match message element comprises an encoded CPA.

10. The computer-readable medium of claim 5, wherein the payload of the IPV6 endpoint array message element comprises a number of entries in an array, a total length of the array, an identifier for a type of each array entry, a length of each array element, and an array of addresses for each node already visited or to which the RESPONSE message was transmitted.

11. The computer-readable medium of claim 3, wherein the payload of the header message element includes information identifying a message type as being a RESPONSE message, wherein the second message element stored in the second field comprises a resolve controls message element, and wherein the RESPONSE message further comprises a third message field containing a resolve controls message element, a fourth message field containing a target PNRP ID message element, a fifth message field containing a CPA best match message element, and an IPV6 endpoint array message element.

12. The computer-readable medium of claim 11, wherein the payload of the resolve controls message element comprises a bit field for context-specific flags, a maximum number of nodes that the RESOLVE message can visit, operation codes to control resolve operation, a precision number of significant bits to match, a reason code that describes a reason for initiating a RESOLVE, a result code that describes a reason for returning a response, and a transaction identification value.

13. The computer-readable medium of claim 11, wherein the payload of the target PNRP identification message element comprises a hash of a peer name of a target peer and a service location derived from an advertised service address.

14. The computer-readable medium of claim 11, wherein the payload of the CPA best match message element comprises an encoded CPA.

15. The computer-readable medium of claim 11, wherein the payload of the IPV6 endpoint array message element comprises a number of entries in an array, a total length of the array, an identifier for a type of each array entry, a length of each array element, and an array of addresses for each node already visited or to which the RESPONSE message was transmitted.

16. The computer-readable medium of claim 3, wherein the payload of the header message element includes information identifying a message type as being a SOLICIT
message, wherein the second message element stored in the second field comprises a CPA
source message element, and wherein the SOLICIT message further comprises a third message field containing hashed nonce message element.

17. The computer-readable medium of claim 16, wherein the payload of the CPA source message element comprises an encoded source CPA.

18. The computer-readable medium of claim 16, wherein the payload of the hashed nonce message element comprises an encrypted nonce value.

19. The computer-readable medium of claim 3, wherein the payload of the header message element includes information identifying a message type as being a ADVERTISE message, wherein the second message element stored in the second field comprises a PNRP header acknowledged message element, and wherein the ADVERTISE
message further comprises a third message field containing a PNRP ID array message element, and a fourth message field containing a hashed nonce message element.

20. The computer-readable medium of claim 19, wherein the payload of the PNRP header acknowledged message element comprises a message identification of a message that is being acknowledged.

21. The computer-readable medium of claim 19, wherein the payload of the PNRP ID array message element comprises a number of entries in a PNRP ID
array, a total length of the array, an identifier for a type of each array entry, a length of each array element, and an array of PNRP IDs.

22. The computer-readable medium of claim 19, wherein the payload of the hashed nonce message element comprises an encrypted nonce value.

23. The computer-readable medium of claim 3, wherein the payload of the header message element includes information identifying a message type as being a REQUEST message, wherein the second message element stored in the second field comprises a nonce message element, and wherein the REQUEST message further comprises a third message field containing a PNRP ID array message element.

24. The computer-readable medium of claim 23, wherein the payload of the none message element comprises a decrypted nonce value.

25. The computer-readable medium of claim 23, wherein the payload of the PNRP ID array message element comprises a number of entries in a PNRP ID
array, a total length of the array, an identifier for a type of each array entry, a length of each array element, and an array of PNRP IDs.

26. The computer-readable medium of claim 3, wherein the payload of the header message element includes information identifying a message type as being a FLOOD
message, wherein the second message element stored in the second field comprises a flood controls message element, and wherein the FLOOD message further comprises a third message field containing a CPA best match message element, and a fourth message field containing an IPV6 endpoint array message element.

27. The computer-readable medium of claim 26, wherein the payload of the flood controls message element comprises a bit field for context-specific flags, and a reason code that describes the reason for initiation of the FLOOD message.

28. The computer-readable medium of claim 26, wherein the payload of the CPA best match message element comprises an encoded CPA.

29. The computer-readable medium of claim 26, wherein the payload of the IPV6 endpoint array message element comprises a number of entries in an array, a total length of the array, an identifier for a type of each array entry, a length of each array element, and an array of addresses for each node already visited or to which the RESPONSE massage was transmitted.

30. The computer-readable medium of claim 3, wherein the payload of the header message element includes information identifying a message type as being a INQUIRE message, wherein the second message element stored in the second field comprises a flags field message element, and wherein the INQUIRE message further comprises a third message field containing a validate PNRP identification message element.

31. The computer-readable medium of claim 30, wherein the payload of the flags field message element comprises a fit field for context-specific flags.

32. The computer-readable medium of claim 30, wherein the payload of the validate PNRP identification message element comprises a hash of a peer name of a node for which validation and an authority are requested and a service location derived from an advertised service address of the node for which validation and an authority are requested.

33. The computer-readable medium of claim 3, wherein the payload of the header message element includes information identifying a message type as being a AUTHORITY message, wherein the second message element stored in the second field comprises a PNRP header acknowledged message element, and wherein the AUTHORITY
message further comprises a third message field containing a split controls message element, a fourth message field containing flags field message element, a fifth message field containing a validate PNRP ID message element, a sixth message field containing a certifcate chain message element, a seventh message field containing an IPV6 referral address message element, an eighth message field containing an IPV6 referral identification message element, and a ninth message field containing a classifier message element.

34. The computer-readable medium of claim 33, wherein the payload of the PNRP header acknowledged message element comprises a message identification of a message that is being acknowledged.

35. The computer-readable medium of claim 33, wherein the payload of the split controls message element comprises information of a size of fragmentation and an offset of the fragmentation.

36. The computer-readable medium of claim 33, wherein the payload of the flags field message element comprises a fit field for context-specific flags.

37. The computer-readable medium of claim 33, wherein the payload of the validate PNRP identification message element comprises a hash of a peer name of a node for which validation and an authority are requested and a service location derived from an advertised service address of the node for which validation and an authority are requested.

38. The computer-readable medium of claim 33, wherein the payload of the certificate chain message element comprises a PKCS7 encoded certificate store.

39. The computer-readable medium of claim 33, wherein the payload of the IPV6 referral address message element comprises a path flag for a node endpoint, an IP
protocol number, an IPV6 port, and an IPV6 address as an alternate node's address.

40. The computer-readable medium of claim 33, wherein the payload of the IPV6 referral identification message element comprises a hash of a peer name and a service location for a node to which a referral is being made.

41. The computer-readable medium of claim 33, wherein the payload of the classifier message element comprises a Unicode classifier string that was used as a basis for a peer name, encoded as an array of WCHAR elements including a number of entries in an address array, a total length of the array, an identifier for a type or each array entry, a length of each array element, and an array of Unicode characters.

42. The computer-readable medium of claim 3, wherein the payload of the header message element includes information identifying a message type as being a ACK
message, wherein the second message element stored in the second field comprises a PNRP
header acknowledged message element.

43. The computer-readable medium of claim 42, wherein the payload of the PNRP header acknowledged message element comprises a message identification of a message that is being acknowledged.

44. The computer-readable medium of claim 3, wherein the payload of the header message element includes information identifying a message type as being a REPAIR
message, wherein the second message element stored in the second field comprises a target PNRP identification message element, and wherein the REPAIR message further comprise a third message field comprising a cache level message element, and a fourth message field comprising an IPV6 endpoint message element.

45. The computer-readable medium of claim 44, wherein the payload of the target PNRP identification message element comprises a hash of a peer name of a target peer and a service location derived from an advertised service address.

46. The computer-readable medium of claim 44, wherein the payload of the cache level message element comprises a cache level number identifying which cache level is to be used when executing a repair.

47. The computer-readable medium of claim 4, wherein the payload of the header message element further includes information identifying a particular message to allow tracking of responses to the particular message.

48. The computer-readable medium of claim 1, wherein the length field contains information identifying a length of the message element, including the length of the field identification field, the length field, and the payload.

49. A computer-readable medium having stored thereon a RESOLVE
message data structure for use in a peer to peer name resolution protocol (PNRP), comprising:
a first message field having a PNRP header message element;
a second message field having a resolve controls message element;
a third message field containing a PNRP target identification message element;
a fourth message field containing a validate PNRP identification message element;
a fifth message field containing a certified peer address (CPA) best match message element; and a sixth message field containing an IPV6 endpoint array message element.

50. The computer-readable media of claim 49, wherein each message element comprises a message element data structure comprising a field identification field, a length field, and a payload.

51. The computer-readable medium of claim 50, wherein the payload of the resolve controls message element comprises a bit field for context-specific flags, a maximum number of nodes that the RESOLVE message can visit, operation codes to control resolve operation, a precision number of significant bits to match, a reason code that describes a reason for initiating a RESOLVE, a result code that describes a reason for returning a response, and a transaction identification value.

52. The computer-readable medium of claim 50, wherein the payload of the target PNRP identification message element comprises a hash of a peer name of a target peer and a service location derived from an advertised service address.

53. The computer-readable medium of claim 50, wherein the payload of the validate PNRP identification message element comprises a hash of a peer name of a node for which validation and an authority are requested and a service location derived from an advertised service address of the node for which validation and an authority are requested.

54. The computer-readable medium of claim 50, wherein the payload of the CPA best match message element comprises an encoded CPA.

55. The computer-readable medium of claim 50, wherein the payload of the IPV6 endpoint array message element comprises a number of entries in an array, a total length of the array, an identifier for a type of each array entry, a length of each array element, and an array of addresses for each node already visited or to which the RESPONSE message was transmitted.

56. A computer-readable medium having stored thereon a RESPONSE
message data structure for use in a peer to peer name resolution protocol (PNRP), comprising:
a first message field having a PNRP header message element;
a second message field having a resolve controls message element;
a third message field containing a resolve controls message element;
a fourth message field containing a target PNRP ID message element;
a fifth message field containing a certified peer address (CPA) best match message element; and a sixth message field containing an IPV6 endpoint array message element.

57. The computer-readable media of claim 56, wherein each message element comprises a message element data structure comprising a field identification field, a length field, and a payload.

58. The computer-readable medium of claim 57, wherein the payload of the resolve controls message element comprises a bit field for context-specific flags, a maximum number of nodes that the RESOLVE message can visit, operation codes to control resolve operation, a precision number of significant bits to match, a reason code that describes a reason for initiating a RESOLVE, a result code that describes a reason for returning a response, and a transaction identification value.

59. The computer-readable medium of claim 57, wherein the payload of the target PNRP identification message element comprises a hash of a peer name of a target peer and a service location derived from an advertised service address.

60. The computer-readable medium of claim 57, wherein the payload of the CPA best match message element comprises an encoded CPA.

61. The computer-readable medium of claim 57, wherein the payload of the IPV6 endpoint array message element comprises a number of entries in an array, a total length of the array, an identifier for a type of each array entry, a length of each array element, and an array of addresses for each node already visited or to which the RESPONSE message was transmitted.

62. A computer-readable medium having stored thereon a SOLICIT
message data structure for use in a peer to peer name resolution protocol (PNRP), comprising:
a first message field having a PNRP header message element;
a second message field having a CPA source message element; and a third message field containing a hashed nonce message element.

63. The computer-readable media of claim 62, wherein each message element comprises a message element data structure comprising a field identification field, a length field, and a payload.

64. The computer-readable medium of claim 63, wherein the payload of the CPA source message element comprises an encoded source CPA.

65. The computer-readable medium of claim 63, wherein the payload of the hashed nonce message element comprises an encrypted nonce value.

66. A computer-readable medium having stored thereon a ADVERTISE
message data structure for use in a peer to peer name resolution protocol (PNRP), comprising:
a first message field having a PNRP header message element;
a second message field having a PNRP header acknowledged message element;
a third message field containing a PNRP ID array message element; and a fourth message field containing a hashed nonce message element.

67. The computer-readable media of claim 66, wherein each message element comprises a message element data structure comprising a field identification field, a length field, and a payload.

68. The computer-readable medium of claim 67, wherein the payload of the PNRP header acknowledged message element comprises a message identification of a message that is being acknowledged.

69. The computer-readable medium of claim 67, wherein the payload of the PNRP ID array message element comprises a number of entries in a PNRP ID
array, a total length of the array, an identifier for a type of each array entry, a length of each array element, and an array of PNRP IDs.

70. The computer-readable medium of claim 67, wherein the payload of the hashed nonce message element comprises an encrypted nonce value.

71. A computer-readable medium having stored thereon a REQUEST
message data structure for use in a peer to peer name resolution protocol (PNRP), comprising:
a first message field having a PNRP header message element;
a second message field having a nonce message element; and a third message field containing a PNRP ID array message element.

72. The computer-readable media of claim 71, wherein each message element comprises a message element data structure comprising a field identification field, a length field, and a payload.

73. The computer-readable medium of claim 72, wherein the payload of the none message element comprises a decrypted nonce value.

74. The computer-readable medium of claim 72, wherein the payload of the PNRP ID array message element comprises a number of entries in a PNRP ID
array, a total length of the array, an identifier for a type of each array entry, a length of each array element, and an array of PNRP IDs.

75. A computer-readable medium having stored thereon a FLOOD
message data structure for use in a peer to peer name resolution protocol (PNRP), comprising:
a first message field having a PNRP header message element;
a second message field having a flood controls message element;
a third message field containing a CPA best match message element; and a fourth message field containing an IPV6 endpoint array message element.

76. The computer-readable media of claim 75, wherein each message element comprises a message element data structure comprising a field identification field, a length field, and a payload.

77. The computer-readable medium of claim 76, wherein the payload of the flood controls message element comprises a bit field for context-specific flags, and a reason code that describes the reason for initiation of the FLOOD message.

78. The computer-readable medium of claim 76, wherein the payload of the CPA best match message element comprises an encoded CPA.

79 . The computer-readable medium of claim 76, wherein the payload of the IPV6 endpoint array message element comprises a number of entries in an array, a total length of the array, an identifier for a type of each array entry, a length of each array element, and an array of addresses for each node already visited or to which the RESPONSE message was transmitted.

80. A computer-readable medium having stored thereon a INQUIRE
message data structure for use in a peer to peer name resolution protocol (PNRP), comprising:
a first message field having a PNRP header message element;
a second message field having a flags field message element; and a third message field containing a validate PNRP identification message element.

81. The computer-readable media of claim 80, wherein each message element comprises a message element data structure comprising a field identification field, a length field, and a payload.

82. The computer-readable medium of claim 81, wherein the payload of the flags field message element comprises a fit field for context-specific flags.

83. The computer-readable medium of claim 81; wherein the payload of the validate PNRP identification message element comprises a hash of a peer name of a node for which validation and an authority are requested and a service location derived from an advertised service address of the node for which validation and an authority are requested.

84. A computer-readable medium having stored thereon a RESOLVE
message data structure for use in a peer to peer name resolution protocol (PNRP), comprising:
a first message field having a PNRP header message element;
a second message field having a PNRP header acknowledged message element;
a third message field containing a split controls message element;
a fourth message field containing a flags field message element;
a fifth message field containing a validate PNRP ID message element;
a sixth message field containing a certificate chain message element;
a seventh message field containing an IPV6 referral address message element;
an eighth message field containing an IPV6 referral identification message element; and a ninth message field containing a classifier message element.

85. The computer-readable media of claim 84, wherein each message element comprises a message element data structure comprising a field identification field, a length field, and a payload.

86. The computer-readable medium of claim 85, wherein the payload of the PNRP header acknowledged message element comprises a message identification of a message that is being acknowledged.

87. The computer-readable medium of claim 85, wherein the payload of the split controls message element comprises information of a size of fragmentation and an offset of the fragmentation.

88. The computer-readable medium of claim 85, wherein the payload of the flags field message element comprises a fit field for context-specific flags.

89. The computer-readable medium of claim 85, wherein the payload of the validate PNRP identification message element comprises a hash of a peer name of a node for which validation and an authority are requested and a service location derived from an advertised service address of the node for which validation and an authority are requested.

90. The computer-readable medium of claim 85, wherein the payload of the certificate chain message element comprises a PKCS7 encoded certificate store.

91. The computer-readable medium of claim 85, wherein the payload of the IPV6 referral address message element comprises a path flag for a node endpoint, an IP
protocol number, an IPV6 port, and an IPV6 address as an alternate node's address.

92. The computer-readable medium of claim 85, wherein the payload of the IPV6 referral identification message element comprises a hash of a peer name and a service location for a node to which a referral is being made.

93. The computer-readable medium of claim 85, wherein the payload of the classifier message element comprises a Unicode classifier string that was used as a basis for a peer name, encoded as an array of WCHAR elements including a number of entries in an address array, a total length of the array, an identifier for a type or each array entry, a length of each array element, and an array of Unicode characters.

94. A computer-readable medium having stored thereon a ACK message data structure for use in a peer to peer name resolution protocol (PNRP), comprising:
a first message field containing a PNRP header message element; and a second message field containing a PNRP header acknowledged message element.

95. The computer-readable media of claim 94, wherein each message element comprises a message element data structure comprising a field identification field, a length field, and a payload.

96. The computer-readable medium of claim 95, wherein the payload of the PNRP header acknowledged message element comprises a message identification of a message that is being acknowledged.

97. A computer-readable medium having stored thereon a REPAIR
message data structure for use in a peer to peer name resolution protocol (PNRP), comprising:
a first message field containing a PNRP header message element;
a second message field containing a target PNRP identification message element;
a third message field containing a cache level message element; and a fourth message field containing an IPV6 endpoint message element.

98. The computer-readable media of claim 97, wherein each message element comprises a message element data structure comprising a field identification field, a length field, and a payload.

99. The computer-readable medium of claim 98, wherein the payload of the target PNRP identification message element comprises a hash of a peer name of a target peer and a service location derived from an advertised service address.

100. The computer-readable medium of claim 98, wherein the payload of the cache level message element comprises a cache level number identifying which cache level is to be used when executing a repair.