BACKGROUND [0001] Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, and database management) that prior to the advent of the computer system were performed manually. More recently, computer systems have been coupled to one another and to other electronic devices to form both wired and wireless computer networks over which the computer systems and other electronic devices can transfer electronic data. As a result, many tasks performed at a computer system (e.g., voice communication, accessing electronic mail, controlling home electronics, Web browsing, and printing documents) include the exchange of electronic messages between a number of computer systems and and/or other electronic devices via wired and/or wireless computer networks. [0002] However, to utilize a network resource to perform a computerized task, a computer system must have some way to identify and access the network resource. Accordingly, resources are typically assigned unique identifiers, for example, network addresses, that uniquely identify resources and can be used to distinguish one resource from other resources. Thus, a computer system that desires to utilize a resource can connect to the resource using the network address that corresponds to the resource. However, accessing a network resource can be difficult if a computer system has no prior knowledge of a network address for a network resource. For example, a computer system can not print a document at a network printer unless the computer system (or another networked computer system) knows the network address of the network printer. [0003] Accordingly, various mechanisms (e.g.. Domain Name System ("DNS"), Active Directory ("AD"), Distributed File Systems ("DFS")) have been developed for computer systems to identify (and access) previous unknown resources. However, due to the quantity and diversity of resources (e.g., devices and services) that are accessible via different computer networks, developers are often required to develop applications that implement a variety of different resource identification and access mechanisms. Each different mechanism may have different coding requirements and may not provide a developer with all the functionality that is needed in an application. [0004] For example, although DNS has a distributed administration architecture (i.e., centralized management is not required), DNS is not sufficiently dynamic, not self-organizing, supports a weak data and query model, and has a fixed set of roots. On the other hand, AD is sufficiently dynamic but requires centralized administration. Further, aspects of different mechanisms may not be compatible with one another. For example, a resource identified using DNS may not be compatible with DFS routing protocols. Thus, a developer may be forced to choose the most suitable mechanism and forgo the advantages of other mechanisms. [0005] Mechanisms for identifying resources can be particularly problematic in peer-to-peer networks. DNS provides a lookup service, with host names as keys and IP addresses as values, that relies on a set of special root servers to implement lookup requests. Further, DNS requires management of information (NS records) for allowing clients to navigate the name server hierarchy. Thus, a resource must be entered into DNS before the resource can be identified on a network. On larger scale networks where nodes frequently connect and disconnect form the network relying on entry of information is not always practical. Additionally, DNS is specialized to the task of find hosts or services and is not generally applicable to other types of resources. [0006] Accordingly, other mechanisms for resource identification and access have been developed to attempt to address these shortcomings. A number of mechanisms include distributed lookup protocols that are more scalable than DNS. These mechanisms use various node arrangements and routing algorithms to route requests to corresponding resources and to store information for lookup. [0007] At least one of these mechanisms utilizes local multi-level neighbor maps at each node in a network to route messages to a destination node. This essentially results in an architecture where each node is a "root node" of a corresponding tree of nodes (the nodes in its neighbor map). Messages are incrementally routed to a destination ID digit by digit (e.g., ***6 => **46 =>, *346 => 2346, where *s represent wildcards). The routing efficiency of these types of mechanisms is 0(log N) routing hops and require nodes to maintain a routing table of O(logN) size. [0008] At least one other of these mechanisms assigns nodes a unique ID that is taken from a linear ring of numbers. Nodes maintain routing tables that contain pointers to their immediate successor node (according to ID value) and to those nodes whose ID values are the closest successor of the value ID + 2^. The routing efficiency of these types of mechanisms is also 0(log N) routing hops and require nodes to maintain a routing table of 0(log N) size. [0009] At least one further mechanisms requires 0(log N"'') routing hops and requires nodes to maintain a routing table of 0(D) size. Thus, the routing efficiency of all of these mechanisms depends, at least in part, on the number of nodes in the system. [0010] Further, since IDs (for at least some of the mechanisms) can be uniformly distributed around a ring, there is always some possibility that routing between nodes on the ring will result in some inefficiency. For example, routing hops can cross vast geographic distances, cross more expensive links, or pass through insecure domains, etc. Additionally, when message routing involves multiple hops, there is some chance that such events will occur multiple times. Unfortunately, these mechanisms do not take into account the proximity of nodes (physical or otherwise) with respect one another. For example, depending on node distribution on a ring, routing a message from New York to Boston could involve routing the message from New York, to London, to Atlanta, to Tokyo, and then to Boston. [0011] Accordingly, at least one other more recent mechanism takes proximity into account by defining proximity as a single scalar proximity metric (e.g., IP routing hops or geographic distance). These mechanisms use the notion of proximity-based choice of routing table entries. Since there are many "correct" node candidates for each routing table entry, these mechanisms attempt to select a proximally close node from among the candidate nodes. For these mechanisms can provide a function that allows each node to determine the "distance" of a node with a given IP address to itself Messages are routed between nodes in closer proximity to make progress towards a destination before routing to a node that is further away. Thus, some resources can be conserved and routing is more efficient. [0012] Unfortunately, these existing mechanisms typically do not provide for, among other things, symmetric relationships between nodes (i.e., if a first node considers a second node to be its partner, the second node considers the first node as a partner as well), routing messages in both directions (clockwise and counterclockwise) on a ring, partitioning linked lists of nodes based on a plurality of proximity metrics, and routing messages based on a plurality of proximity metrics. These deficiencies can limit dynamic, distributed, and efficient transfer of data between nodes of a network, such as, for example, when broadcasting data to all nodes of the network. BRIEF SUMMARY [0013] The present invention extends to methods, systems, and computer program products for facilitating inter-proximity communication within a rendezvous federation. In some embodiments, a collateral ring set entry table for a node is maintained. A node accesses a collateral ring set entry table configured to store collateral ring set entries for the node. Each collateral ring set entry is configured to indicate a collateral ring of the node and at least one corresponding entry node into the collateral ring of the node. Collateral ring set entry table information from available resources that maintain information related to the configuration of the tree of rings is discovered. The collateral ring set entry table is updated with appropriate collateral ring set entry state based on the discovered collateral ring set entry table information. The appropriate collateral ring set entry state including a collateral ring of the node and at least one corresponding entry node into the collateral ring of the node [0014] In other embodiments, inter-proximity communication is sent in a tree of rings. In one embodiment of inter-proximity communication, it is determined that a node is to send a message to a specified collateral ring of the node. The node accesses a collateral ring set entry table configured to store collateral ring set entries for the node. Each collateral ring set entry is configured to indicate a collateral ring of the node and a corresponding at least one entry node into the collateral ring of the node. At least one collateral ring set entry for the specified collateral ring is identified from the node's collateral ring set entry table. Each of the at least one collateral ring set entries indicates at least one an entry node of the specified collateral ring. The message is sent to at least one indicated entry node. [0015] In another embodiment of inter-proximity communication, it is determined that an originating node intends to route a message to a destination node that is closest to a given node ID in a target proximity ring within the tree of rings. One or more entry nodes known to be member nodes of at least one of the target proximity ring and an ancestor ring of the target proximity ring are identified. The message is sent to an identified entry node. The message indicates that the identified entry node is to resolve the message to the node which has a node ID closest to an indicated destination node in the target proximity ring. [0016] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. [0017] Additional features and advantages will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by the practice of the teachings herein. Features and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims. Features of the present invention will become more fully apparent from the following description and appended claims, or may be learned by the practice of the invention as set forth hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS [0018] In order to describe the manner in which the above-recited and other advantages and features can be obtained, a more particular description of the subject matter briefly described above will be rendered by reference to specific embodiments which are illustrated in the appended drawings. Understanding that these drawings depict only typical embodiments and are not therefore to be considered to be limiting in scope, embodiments will be described and explained with additional specificity and detail through the use of the accompanying drawings in which: [0019] Figure 1 illustrates an example of a federation infrastructure. [0020] Figure 2 illustrates an example of a computer architecture that facilitates routing request indirectly to partners. 10021] Figure 3 illustrates an example binary relationship between nodes in a federation infrastructure in the form of a sorted list and corresponding ring. [0022] Figure 4 illustrates an example ring of rings that facilitates proximal routing. [0023] Figure 5 illustrates an example proximity induced partition tree of rings that facilitates proximal routing. [0024] Figure 5A illustrates the example proximity induced partition tree of rings of Figure 5 with additional detail in portions of the partition tree of rings of Figure 5. [0025] Figure 6 illustrates a suitable operating environment for the principles of the present invention. [0026] Figure 7 illustrates an example flow chart of a method for populating a node routing table that takes proximity criteria into account [0027] Figure 8 illustrates an example flow chart of a method for partitioning the nodes of a federation infrastructure. [0028] Figure 9 illustrates an example flow chart of a method for populating a node routing table. [0029] Figure 10 illustrates an example flow chart of a method for numerically routing a message towards a destination node. [0030] Figure 11 illustrates an example flow chart of a method for proximally routing a message towards a destination node. [0031] Figure 12A illustrates an example of a node establishing membership within an existing federation. [0032] Figure 12B illustrates an example of nodes in a federation infrastructure exchanging messages. [0033] Figure 13 illustrates an example flow chart of a method for establishing membership within a federation infrastructure. [0034] Figure 14 illustrates an example flow chart of a method for maintaining membership within a federation infrastructure. [0035] Figure 15 illustrates an example flow chart of a method for discovering liveness information for another node. [0036] Figure 16 illustrates an example of a message model and related processing model. [0037] Figure 17 illustrates an example of a number of liveness interactions that can occur between a function layer and an application layer. [0038] Figure 18 illustrates an example of messages forming part of a request-response message exchange pattern are routed across nodes on a ring. [0039] Figure 19A illustrates an example proximity induced partition tree of rings that facilitates inter-proximity communication. [0040] Figure 19B illustrates another view of the example proximity induced partition tree of rings from Figure 19A. [0041] Figure 19C illustrates a partitioned view of a portion of the example proximity induced partition tree of rings from Figure 19A. [0042] Figure 19D illustrates an expanded view of an intermediate ring from the example proximity induced partition tree of rings from Figure 19A. [0043] Figure 19E illustrates yet another view of the example proximity induced partition tree of rings from Figure 19A. [0044] Figure 19F illustrates a further view of the example proximity induced partition tree of rings from Figure 19A. [0045[ Figure 19G illustrates an expanded view of a portion of Figure 19F. [0046] Figure 20 illustrates an example flow chart of a method for maintaining a collateral ring set for a node in tree of rings. [0047] Figure 21 illustrates an example flow chart for a method for sending inter-proximity communication in a tree of rings. [0048] Figure 22 illustrates an example flow chart for another method for sending inter-proximity communication in a tree of rings. DETAILED DESCRIPTION [0049] The present invention extends to methods, systems, and computer program products for facilitating inter-proximity communication within a rendezvous federation. In some embodiments, a collateral ring set entry table for a node is maintained. A node accesses a collateral ring set entry table configured to store collateral ring set entries for the node. Each collateral ring set entry is configured to indicate a collateral ring of the node and at least one corresponding entry node into the collateral ring of the node. Collateral ring set entry table information from available resources that maintain information related to the configuration of the tree of rings is discovered. The collateral ring set entry table is updated with appropriate collateral ring set entry state based on the discovered collateral ring set entry table information. The appropriate collateral ring set entry state including a collateral ring of the node and at least one corresponding entry node into the collateral ring of the node [0050] In other embodiments, inter-proximity communication is sent in a tree of rings. In one embodiment of inter-proximity communication, it is determined that a node is to send a message to a specified collateral ring of the node. The node accesses a collateral ring set entry table configured to store collateral ring set entries for the node. Each collateral ring set entry is configured to indicate a collateral ring of the node and a corresponding at least one entry node into the collateral ring of the node. At least one collateral ring set entry for the specified collateral ring is identified from the node's collateral ring set entry table. Each of the at least one collateral ring set entries indicates at least one an entry node of the specified collateral ring. The message is sent to at least one indicated entry node. [0051] In another embodiment of inter-proximity communication, it is determined that an originating node intends to route a message to a destination node that is closest to a given node ID in a target proximity ring within the tree of rings. One or more entry nodes known to be member nodes of at least one of the target proximity ring and an ancestor ring of the target proximity ring are identified. The message is sent to an identified entry node. The message indicates that the identified entry node is to resolve the message to the node which has a node ID closest to an indicated destination node in the target proximity ring. [0052] Embodiments within the scope of the present invention include computer-readable media for carrying or having computer-executable instructions or data structures stored thereon. Such computer-readable media may be any available media, which is accessible by a general-purpose or special-purpose computer system. By way of example, and not limitation, such computer-readable media can comprise physical storage media such as RAM, ROM, EPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other media which can be used to carry or store desired program code means in the form of computer-executable instructions, computer-readable instructions, or data structures and which may be accessed by a general-purpose or special-purpose computer system. [0053] In this description and in the following claims, a "network" is defined as one or more data links (of possibly different speeds) that enable the transport of electronic data between computer systems and/or modules (e.g., hardware and/or software modules). When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination of hardwired or wireless) to a computer system, the connection is properly viewed as a computer-readable medium. Thus, any such connection is properly termed a computer-readable medium. Combinations of the above should also be included within the scope of computer-readable media. Computer-executable instructions comprise, for example, instructions and data which cause a general-purpose computer system or special-purpose computer system to perform a certain function or group of functions. The computer executable instructions may be, for example, binaries, intermediate format instructions such as assembly language, or even source code. In some embodiments, hardware modules, such as, for example, special purpose integrated circuits or Gate-arrays are optimized to implement the principles of the present invention. [0054] In this description and in the following claims, a "node" is defined as one or more software modules, one or more hardware modules, or combinations thereof, that work together to perform operations on electronic data. For example, the definition of a node includes the hardware components of a personal computer, as well as software modules, such as the operating system of the personal computer. The physical layout of the modules is not important. A node can include one or more computers coupled via a network. Likewise, a node can include a single physical device (such as a mobile phone or Personal Digital Assistant "PDA") where internal modules (such as a memory and processor) work together to perform operations on electronic data. Further, a node can include special purpose hardware, such as, for example, a router that includes special purpose integrated circuits. [0055] Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of node configurations, including, personal computers, laptop computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, pagers, routers, gateways, brokers, proxies, firewalls, redirectors, network address translators, and the like. The invention may also be practiced in distributed system environments where local and remote nodes, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks. In a distributed system environment, program modules may be located in both local and remote memory storage devices. [0056] Federation Architecture [0057] Figure 1 illustrates an example of a federation infrastructure 100. The federation infrastructure 100 includes nodes 101, 102, 103, that can form different types of federating partnerships. For example, nodes 101, 102, 103 can be federated among one another as peers without a root node. Each of nodes 101, 102, and 103 has a corresponding ID 171, 182, and 193 respectively. [0058] Generally, the nodes 101, 102, 103, can utilize federation protocols to form partnerships and exchange information (e.g., state Information related to interactions with other nodes). The formation of partnerships and exchange of information facilitates more efficient and reliable access to resources. Other intermediary nodes (not shown) can exist between nodes 101, 102, and 103 (e.g., nodes having IDs between 171 and 193). Thus, a message routed, for example, between node 101 and node 103, can be pass through one or more of the other intermediary nodes. [0059] Nodes in federation infrastructure 100 (including other intermediary nodes) can include corresponding rendezvous protocol stacks. For example, nodes 101, 102, and 103 include corresponding rendezvous protocol stacks 141, 142, and 143 respectively. Each of the protocols stacks 141, 142, and 143 includes an application layer (e.g., application layers 121, 122, and 123) and other lower layers (e.g., corresponding other lower layers 131, 132, and 133). Each layer in a rendezvous protocol stack is responsible for different functionality related to rendezvousing a resource request with a corresponding resource. [0060] For example, other lower layers can include a channel layer, a routing layer, and a function layer. Generally, a channel layer is responsible for reliably transporting a message (e.g., using WS-ReliableMessaging and Simple Object Access Protocol ("SOAP")) from one endpoint to another (e.g., from node 101 to node 103). The channel layer is also responsible for processing incoming and outgoing reliable messaging headers and maintaining state related to reliable messaging sessions. [0061] Generally, a routing layer is responsible for computing the next hop towards a destination. The routing layer is also responsible for processing incoming and outgoing addressing and routing message headers and maintaining routing state. Generally, a function layer is responsible for issuing and processing rendezvous protocol messages such as join and depart requests, pings, updates, and other messages, as well as generation of responses to these messages. The function layer processes request messages from the routing layer and sends back corresponding response messages, if any, to the originating node using the routing layer. The function layer also initiates request messages and utilizes the routing layer to have the requests messages delivered. [0062] Generally, an application layer processes non-rendezvous protocol specific data delivered from the function layer (i.e., application messages). The function layer can access application data from the application layer and get and put application data in rendezvous protocol messages (e.g., pings and updates). That is, the function layer can cause application data to be piggybacked on rendezvous protocol messages and can cause the application data to be passed back to the application layer in receiving rendezvous protocol nodes. In some embodiments, application data is used to identify resources and resource interests. Thus, an application layer can include application specific logic and state that processes data received from and sent to the other lower layers for purposes of identifying resources and resource interests. [0063] Federating Mechanisms [0064] Nodes can federate using a variety of different mechanisms. A first federating mechanism includes peer nodes forwarding information to all other peer nodes. When a node is to join a federation infrastructure, the node utilizes a broadcast/muhicast discovery protocol, such as, for example, WS-Discovery to announce its presence and issues a broadcast/multicast find to detect other nodes. The node then establishes a simple forwarding partnership with other nodes already present on the network and accepts new partnerships with newly joining nodes. Thereafter, the node simply forwards all application specific messages to all of its partner nodes. [0065] A second federating mechanism includes peer nodes that most efficiently transmit application specific messages to their destination(s). When a new node is to join a federation infrastructure, the new node utilizes a broadcast/multicast discovery protocol. such as, for example, WS-Discovery to announce its presence and issues a broadcast/multicast find to detect other nodes that are part of the federation infrastructure. Upon detecting another node, the new node establishes a partnership with the other node. From the established partnership, the new node learns about the presence of other nodes already participating in federation infrastructure. It then establishes partnerships with these newly-learned nodes and accepts any new incoming partnership requests. [0066] Both node arrivals/departures and registrations of interest in certain application specific messages are flooded through the federation infrastructure resulting in every node having global knowledge of other partner nodes and registrations of interest in application specific messages. With such global knowledge, any node can send application specific messages directly to the nodes that have expressed interest in the application specific message. [0067] A third federating mechanism includes peer nodes indirectly forwarding all application specific messages to their destination/s. In this third mechanism, nodes are assigned identifiers (ID's), such as, for example, a 128-bit or 160-bit ID. The node responsible for a maintaining registration of interest in a given application specific message can be determined to be the one whose ID is closest to the one obtained by mapping (e.g., hashing) the destination identity (e.g. URI) of the application specific message to this 128-bit or 160-bit ID-space. [0068] In this third mechanism, node arrivals and departures are flooded over the entire fabric. On the other hand, registrations of interest in certain application specific messages are forwarded to the nodes determined to be responsible for maintaining such registration information. For scalability, load balancing, and fault-tolerance, the node receiving registration of interest in certain application specific messages can reliably flood that registration information within its neighborhood set. The neighborhood set for a specified node can be determined to be the set of nodes having IDs within a predefined range on either side of the ID of specified node. [0069] Similar to the second mechanism, a newly-joining node utilizes a broadcast/multicast discovery protocol, such as, for example, WS-Discovery to announce its presence and issues a local broadcast/multi-cast find to detect a node that is already part of the federation infrastructure. The new node establishes a partnership with the discovered node and uses that partnership to learn about the presence of other new nodes participating in the federation infrastructure. The new node then establishes further partnerships with the newly discovered nodes and accepts any new incoming partnership requests. The new node accepts incoming registrations of interest in certain application layer specific resources from its partners for which it is responsible and may flood them over its neighborhood set. Thus, messages can generally be forwarded to their final destination via intermediary routing nodes (e.g., that a newly joining node has partnered with or that a partner node is aware of). [0070] In response to receiving an incoming application specific message, the new node forwards the message to the partner node that may be responsible for maintaining the registration information for the destination specified in the message. Thus, when using this third mechanism, every node in the federation infrastructure has global knowledge of all other nodes but the registration information is efficiently partitioned among the nodes. Application specific messages are transmitted to their final destination via only the partner's nodes that may have the responsibility for maintaining registration information of interest in those application specific messages. Thus, indirection is accomplished by forwarding only to the partner node that has global knowledge of the registration information of interest for the message being processed. This is in contrast to the first mechanism where the indirection is accomplished by forwarding to all the partner nodes. [0071] A fourth federating mechanism includes peer nodes that route messages to other peer nodes. This fourth mechanism differs from the third mechanism at least in that both node arrivals/departures and registrations of interest in certain application specific messages are all routed instead being flooded. Routing protocols are designed to guarantee rendezvous between application specific messages and the registration messages that express interest in those application specific messages. [0072] Figure 2 illustrates an example of a computer architecture 200 that facilitates routing requests indirectly to partners. Computer architecture 200 depicts different types of computer systems and devices potentially spread across multiple local discovery scopes participating in a federation infrastructure. [0073] Workstation 233 can include a registered PnP provider instance. To inform its partners of the presence of this PnP provider instance, workstation 233 routes registration request 201 over the federation infrastructure. Registration request 201 is initially forwarded to laptop 231, which in turn forwards registration request 201 to message broker 237, which in turn forwards registration request 201 to message gateway 241. Message gateway 241 saves the registration information registration request 201 in its database and returns success message 204 to workstation 233. [0074] Subsequently, another registered provider instance, this time that of running services, comes alive within the workstation 233. This time the node is aware that message gateway 241 is responsible for registrations and forwards registration request 205 to message gateway 241 directly. Message gateway 241 saves the registration information registration request 205 in its database and returns success message 206 to workstation 233. [0075] Subsequently, the printer 236 (e.g., a UPnP printer) is powered on and sends announcement 207. Server 234 detects announcement 207 and routes registration request 208 to message broker 237. Message broker 237 forwards registration request 208 to message gateway 241. Message gateway 241 saves the registration information registration request 208 in its database and returns success message 210 to server 234. [0076] Subsequently, personal computer 242 issues lookup request 211 to discover all devices. Since personal computer 242 doesn't know where to forward lookup request 211, it routes lookup request 211 through workstation 243. As registration and lookup requests are routed to the same destination, the routing protocol essentially guarantees rendezvous between the two requests resulting in workstation 243 forwards find request 211 to message gateway 241. Message gateway 241 looks up the registration information maintained by it and forwards find request 211 to both the workstation 233 and server 234. Workstation 233 and server 234 send response messages 214 and 216 respectively to personal computer 242. [0077] This fourth mechanism works by routing (instead of flooding) a request to the node (message gateway 241) that has global knowledge of the registrations specified in a request. This fourth mechanism, as will be described in further detail below, essentially guarantees that routing can be accomplished in 0(log N) hops, where N is the number of nodes participating in the federation infrastructure. Since this fourth mechanism efficiently partitions both node partnership and registration information, it scales to very large networks, even the Internet. [0078] Although a number of federating mechanisms have been described, it would be apparent to one skilled in the art, after having reviewed this description, that other federation mechanisms are possible. [0079] Relationship Between Nodes In A Federation [0080] Accordingly, a federation consists of a set of nodes that cooperate among themselves to form a dynamic and scalable network in which information can be systematically and efficiently disseminated and located. Nodes are organized to participate in a federation as a sorted list using a binary relation that is reflexive, anti-symmetric, transitive, total, and defined over the domain of node identities. Both ends of the sorted list are joined, thereby forming a ring. Thus, each node in the list can view itself as being at the middle of the sorted list (as a result of using modulo arithmetic). Further, the list is doubly linked so that any node can traverse the list in either direction. [0081] Each federating node can be assigned an ID (e.g., by a random number generator with duplicate detection) from a fixed set of IDs between 0 and some fixed upper bound. Thus, adding 1 to an ID of the fixed upper bound results in an ID of zero (i.e., moving from the end of the linked list back to the beginning of the linked listed . In addition, a 1:1 mapping function from the value domain of the node identities to the nodes themselves is defined. [0082] Figure 3 depicts an example linked list 304 and corresponding ring 306. Given such a ring, the following functions can be defined: RouteNumerically(V, Msg): Given a value V from the value domain of node identities and a message "Msg," deliver the message to node X whose identity can be mapped to V using the mapping function. Neighborhood(X, S): Neighborhood is the set of nodes on the either side of node X with cardinality equal to S. [0083] When every node in the federation has global knowledge of the ring, RouteNumerically(V, Msg) is implemented by directly sending Msg to the node X, whose identity is obtained by applying the mapping function to V. Alternately, when nodes have limited knowledge of other nodes (e.g., only of immediately adjacent nodes), RouteNumerically(V, Msg) is implemented by forwarding the message to consecutive nodes along the ring until it reaches the destination node X. [0084] Alternately (and advantageously), nodes can store enough knowledge about the ring to perform a distributed binary search (without having to have global knowledge or implement routing between immediately adjacent nodes). The amount of ring knowledge is configurable such that maintaining the ring knowledge has a sufficiently small impact on each node but allows increased routing performance from the reduction in the number of routing hops. [0085] As previously described, IDs can be assigned using the "<" (less than) relation defined over a sufficiently large, bounded set of natural numbers, meaning its range is over a finite set of numbers between 0 and some fixed value, inclusive. Thus, every node participating in the federation is assigned a natural number that lies between 0 and some appropriately-chosen upper bound, inclusive. The range does not have to be tight and there can be gaps between numbers assigned to nodes. The number assigned to a node serves as its identity in the ring. The mapping function accounts for gaps in the number space by mapping a number falling in between two node identities to the node whose identity is numerically closest to the number. [0086] This approach has a number of advantages. By assigning each node a uniformly-distributed number, there is an increased likelihood that all segments of the ring are uniformly populated. Further, successor, predecessor, and neighborhood computations can be done efficiently using modulo arithmetic. [0087] In some embodiments, federating nodes are assigned an ID from within an ID space so large that the chances of two nodes being assigned the same ID are highly unlikely (e.g., when random number generation is used). For example, a node can be assigned an ID in the range of 0 to b" - 1, where b equals, for example, 8 or 16 and n equals, for example, 128-bit or 160-bit equivalent digits. Accordingly, a node can be assigned an ID, for example, from a range of 0 to 16'**^ - 1 (or approximately 1.461502E48). The range of 0 to \6'^° - \ would provide, for example, a sufficient number of IDs to assign every node on the Internet a unique ID. [0088] Thus, each node in a federation can have: An ID which is a numerical value uniformly distributed in the range ofOtob"-l;and A routing table consisting of (all arithmetic is done modulo b"): Successor node (s); Predecessor node (p); Neighborhood nodes (pk, ..., pi, p, s, si, ..., Sj) such that Sj.s.id>(id + u/2),j> v/2-1, and pk.p.id < (id-u/2), and k> v/2-1; and Routing nodes (r.(n.i), ..., r.i, ri, ..., rn-i) such that r±i = RouteNumerically(id ± b', Msg). where b is the number base, n is the field size in number of digits, u is the neighborhood range, v is the neighborhood size, and the arithmetic is performed modulo b". For good routing efficiency and fault tolerance, values for u and v can be u=b and v>max(log2(>J), 4), where N is the total number of nodes physically participating in the federation. N can be estimated from the number of nodes present on a ring segment whose length is greater than or equal to b, for example, when there is a uniform distribution of IDs. Typical values for b and n are b=8 or 16 and n= 128-bit or 160-bit equivalent digits. [0089] Accordingly, routing nodes can form a logarithmic index spanning a ring. Depending on the locations of nodes on a ring, a precise logarithmic index is possible, for example, when there is an existing node at each number in the set of id ± b' where i = (1, 2, . . . (n-1)). However, it may be that there are not existing nodes at each number in the set. fN those cases, a node closest to id ± b' can be selected as a routing node. The resulting logarithmic index is not precise and may even lack unique routing nodes for some numbers in the set. [0090] Referring again to Figure 3, Figure 3 illustrates an example of a binary relation between nodes in a federation infrastructure in the form of sorted list 304 and corresponding ring 306. The ID space of sorted list 304 is in the range 0 to 2^ - 1 (or 255). That is, b=2 and n=8. Thus, nodes depicted in Figure 3 are assigned IDs in a range from 0 to 255. Sorted list 304 utilizes a binary relation that is reflexive, anti-symmetric, transitive, total, and defined over the domain of node identities. Both ends of sorted list 304 are joined, thereby forming ring 306. This makes it possible for each node in Figure 3 to view itself as being at the middle of sorted list 304. The sorted list 304 is doubly linked so that any node can traverse the sorted list 304 in either direction. Arithmetic for traversing sorted list 304 (or ring 306) is performed modulo 2*. Thus, 255 (or the end of sorted list 304) + 1 = 0 (or the beginning of sorted list 304). [0091] The routing table indicates that the successor to ID 64 is ID 76 (the ID immediately clockwise from ID 64). The successor can change, for example, when a new node (e.g., with an ID of 71) joins or an existing node (e.g., ID 76) leaves the federation infrastructure. Likewise, the routing table indicates that the predecessor to ID 64 is ID 50 (the ID immediately counters clockwise from ID 64). The predecessor can change, for example, when a new node (e.g., with an ID of 59) joins or an existing node (e.g., ID 50) leaves the federation infrastructure. [0092] The routing table further indicates that a set of neighborhood nodes to ID 64 have IDs 83, 76, 50 and 46. A set of neighbor nodes can be a specified number of nodes (i.e., neighborhood size v) that are within a specified range (i.e., neighbor range u) of ID 64. A variety of different neighborhood sizes and neighbor ranges, such as, for example, V=4 and U = 10, can potentially be used to identify the set of neighborhood nodes. A neighborhood set can change, for example, when nodes join or leave the federation infrastructure or when the specified number of nodes or specified range is changed. [0093] The routing table further indicates that ID 64 can route to nodes having IDs 200, 2, 30, 46, 50, 64, 64, 64, 64, 76, 83, 98, 135, and 200. This list is generated by identifying the node closest to each number in the set of id ± 2' where i = (1, 2, 3, 4, 5, 6, 7). That is, b=2 and n=8. For example, the node having ID 76 can be identified from calculating the closest node to 64 + 2^, or 72. [0094] A node can route messages (e.g., requests for access to resources) directly to a predecessor node, a successor node, any node in a set of neighborhood nodes, or any routing node. In some embodiments, nodes implement a numeric routing function to route messages. Thus, RouteNumerically(V, Msg) can be implemented at node X to deliver Msg to the node Y in the federation whose ID is numerically closest to V, and return node Y's ID to node X. For example, the node having ID 64 can implement RouteNumerically(243, Msg) to cause a message to be routed to the node having ID 250. However, since ID 250 is not a routing node for ID 64, ID 64 can route the message to ID 2 (the closest routing node to 243). The node having ID 2 can in turn implement RouteNumerically(243, Msg) to cause the message to be routed (directly or through further intermediary nodes) to the node having ID 250. Thus, it may be that a RouteNumerically function is recursively invoked with each invocation routing a message closer to the destination. [0095] Advantageously, other embodiments of the present invention facilitate partitioning a ring into a ring of rings or tree of rings based on a plurality of proximity criteria of one or more proximity categories (e.g., geographical boundaries, routing characteristics (e.g., IP routing hops), administrative domains, organizational boundaries, etc.). It should be understood a ring can be partitioned more than once using the same type of proximity criteria. For example, a ring can be partition based on a continent proximity criteria and a country proximity criteria (both of a geographical boundaries proximity category). |0096| Since IDs can be uniformly distributed across an ID space (a result of random number generation) there is a high probability that any given segment of a circular ID space contains nodes that belong to different proximity classes provided those classes have approximately the same cardinality. The probability increases further when there are a sufficient number of nodes to obtain meaningful statistical behavior. [0097] Thus, neighborhood nodes of any given node are typically well dispersed from the proximality point of view. Since published application state can be replicated among neighborhood nodes, the published information can be well dispersed as well from the proximality point of view. |009S| Figure 4 illustrates a ring of rings 400 that facilitates proximal routing. Ring 401 can be viewed as a master or root ring, and contains all the nodes in each of the rings 402. 403, and 404. Each of the rings 402. 403, and 404 contain a subset of nodes from ring 401 that are partitioned based on a specified proximity criterion. For example, ring 401 may be partitioned based on geographic location, where ring 402 contains nodes in North America, ring 403 contains nodes in Europe, and ring 404 contains nodes in Asia. [0099| In a numerical space containing 65,536 (2'^) IDs, routing a message from a North American node having an ID 5,345 to an Asian node having an ID 23,345 can include routing the message within ring 402 until a neighbor node of the Asian node is identified. The neighbor node can then route the message to the Asian node. Thus, a single hop (as opposed to multiple hops) is made between a North American node and an Asian node. Accordingly, routing is performed in a resource efficient manner. (00100| Figure 5 illustrates an example proximity induced partition tree of rings 500 that facilitates proximal routing. As depicted, partition tree of rings 500 includes a number of rings. Each of the rings represents a partition of a sorted linked list. Each ring including a plurality a nodes having IDs in the sorted linked list. However for clarity due to the number of potential nodes, the nodes are not expressly depicted on the rings {e,g,, the ID space of partition tree 500 may be b=^ 16 and n= 40). jOOlOl] Within partition tree 500. root ring 501 is partitioned into a plurality of sub-rings, including sub-rings 511, 512, 513, and 514, based on criterion 571 (a first administrative domain boundary criterion). For example, each component of a DNS name can be considered a proximity criterion with the partial order among them induced per their order of appearance in the DNS name read right to left. Accordingly, sub-ring 511 can be further partitioned into a plurality of sub-rings, including sub-rings 521. 522. and 523. based on criterion 581 (a second administrative domain boundary criterion). |00102) Sub-ring 522 can be further partitioned into a plurality of sub-rings, including sub-rings 531, 532, and 533, based on criterion 572 {a geographic boundary criterion). Location based proximity criterion can be partially ordered along the lines of continents, countries, postal zip codes, and so on. Postal zip codes are themselves hierarchically organized meaning that they can be seen as further inducing a partially ordered sub-list of proximity criteria. |00103| Sub-ring 531 can be further partitioned into a plurality of sub-rings, including sub-rings 541, 542, 543, and 544, based on criterion 573 (a first organizational boundary criterion). A partially ordered list of proximity criterion can be induced along the lines of how a given company is organizationally structured such as divisions, departments, and product groups. Accordingly, sub-ring 543 can be further partitioned into a plurality of sub-rings, including sub-rings 551 and 552, based on criterion 583 (a second organizational boundary criterion). [0104] Within partition tree 500, each node has a single ID and participates in rings along a corresponding partition path starting from the root to a leaf For example, each node participating in sub-ring 552 would also participate in sub-rings 543, 531, 522, 511 and in root 501. Routing to a destination node (ID) can be accomplished by implementing a RouteProximally function, as follows: RouteProximally{V, Msg, P): Given a value V from the domain of node identities and a message "Msg," deliver the message to the node Y whose identity can be mapped to V among the nodes considered equivalent by the proximity criteria P. |0105| Thus, routing can be accomplished by progressively moving closer to the destination node within a given ring until no further progress can be made by routing within that ring as determined from the condition that the destination node lies between the current node and its successor or predecessor node. At this point, the current node starts routing via its partner nodes in the next larger ring in which it participates. This process of progressively moving towards the destination node by climbing along the partitioning path towards the root ring terminates when the closest node to the destination node is reached within the requested proximal context, as originally specified in the RouteProximally invocation. [0106| Routing hops can remain in the proximal neighborhood of the node that originated the request until no further progress can be made within that neighborhood because the destination node exists outside it. At this point, the proximity criterion is relaxed to increase the size of the proximal neighborhood to make further progress. This process is repeated until the proximal neighborhood is sufficiently expanded to include the destination node (ID). The routing hop made after each successive relaxation of proximal neighborhood criterion can be a potentially larger jump in proximal space while making a correspondingly smaller jump in the numerical space compared to the previous hop. Thus, only the absolutely required number of such (inter-ring) hops is made before the destination is reached. [0107| It may be the case that some hops are avoided for lookup messages since published application data gels replicated down the partition tree when it is replicated among the neighborhood nodes of the destination node. I0I08] To accomplish proximal routing, each federation node maintains references to its successor and predecessor nodes in all the rings it participates as a member (similar to successor and predecessor for a single ring) - the proximal predecessor, proximal successor, and proximal neighborhood. In order to make the routing efficient, the nodes can also maintain reference to other nodes closest to an exponentially increasing distance on its either half of the ring as routing partners (similar to routing nodes for a single ring). In some embodiments, routing partner nodes that lie between a pair of consecutive successor or predecessor nodes participate in the same lowest ring shared by the current node and the node numerically closest to it among the successor or predecessor node pairs respectively. Thus, routing hops towards a destination node transition into using a relaxed proximity criterion (i.e., transitioning to a higher ring) only when absolutely needed to make further progress. Accordingly, messages can be efficiently rendezvoused with a corresponding federation node. |0109| In some embodiments, nodes implement a proximal routing function to route messages based on equivalence criteria relations. Thus, given a number V and a message "Msg", a node can implement RouteProximally(V, Msg, P) to deliver the message to the node Y whose identify can be mapped to V among the nodes considered equivalent by proximity criterion P. The proximity criterion P identities the lowest ring in the partition tree that is the common ancestor to all the nodes considered proximally equivalent by it. It can be represented as a string obtained by concatenating the proximity criterion found along the path from the root ring to the ring identified by it separated by the path separator character '/'. For example, the proximity criterion identifying sub-ring 542 can be represented as ■'Proximity;/.COM/Corp2/LocationA/Div2". Each ring in the parthion tree 500 can be assigned a unique number, for example, by hashing its representational string with a SHA based algorithm. If the number 0 is reserved for the root ring, it can be inferred that RouteNumericalIy(V, Msg) ^ RouteProximally(V, Msg, 0). [0110| For example, a node in sub-ring 544 can implement RouteProximally to identify a closer node in sub-ring 531 (e.g.. to a node in sub-ring 513). In turn, sub-ring 531 can implement RouteProximally to identify a closer node in sub-ring 522. Likewise, sub-ring 522 can implement RouteProximally to identify a closer node in sub-ring 511. Similarly, sub-ring 511 can implement RouteProximally to identify a closer node in ring 501. Thus, it may be that a RouteProximally function is recursively invoked with each invocation routing a message closer to the destination. lOlllj Thus, when proximity criterion is taken into account, routing hops on a path to a final destination can remain within the proximity of a node that originates a request, while making significant progress between the originating node and the destination node in a numerical space, until either the destination node is reached or no further progress can be made under the chosen proximify criterion at which point it is relaxed just enough to make further progress towards the destination. For example, proximity criterion can be relaxed enough for a message to be routed from ring 531 up to ring 522, etc. |0112| Utilizing the above approach to proximity, it is possible to confine published information to a given ring. For example, organizations may like to ensure that organization specific information is not available to entities outside of their trust domains either (1) implicitly in the form of neighborhood replication to nodes outside of their domains or (2) explicitly in the form of servicing lookup requests for such information. The first aspect is satisfied by replicating published information only among the nodes neighboring the target ID within the specified ring. Because all messages originated by a node are routed by successively climbing the rings to which it belongs towards the root ring, there is a high likelihood that all lookup requests originated within an organization will be able to locate the published information confined to h thereby implicitly satisfying the second aspect. [0113] Also, organizations dislike nodes automatically federating with nodes outside of their trust domain. This can happen, for example, when a visiting sales person connects his/her laptop computer to the network in the customer premises. Ideally, the laptop computer belonging to the sales person wishes to locate information published in its home domain and/or federate with the nodes in its home domain starting at its lowest preferred proximity ring. It will typically not be permitted to federate with the nodes in the customer's domain. Supporting this scenario requires ability to locate seed nodes in the home domain. Such seed nodes can be used for locating information published in the home domain, to join the home federation, and selectively import and export published information across domains. Seed nodes are also sometimes referred as message gateways. [0114] In other embodiments, an entity publishes references to seed nodes in the root ring. Seed nodes can be published at the unique number (such as the one obtained by hashing its representational string) associated with the ring (as a target ID). Seed node information can further be on-demand cached by the nodes in various rings that are on the path to the corresponding target IDs in the root ring. Such on-demand caching provides for improved performance and reduction in hotspots that might occur when semi-static information is looked up quite frequently. Seed node information can also be obtained via other means such as DNS 10115] To provide fauh tolerance for confined published information, each node can maintain a set of neighborhood nodes in all of the rings it participates in. Given the above, the state maintained by a node can be summarized as follows: • An ID which is a numerical value uniformly distributed in the range of 0 to b"-l. • A routing table consisting of (all arithmetic is done modulo b"): o For each ring, say ring d, in which the node participates ■ Successor node (Sd) ■ Predecessor node (pd) ■ Neighborhood nodes (pi^d, ..., pid, Pd, s^, sid. .... Sjd) such that Sid-Sj.id > (id + u/2). j > v/2-1, pi:d-Pd-id < (id - u/2), and k > v/2-1. o Routing nodes (r.(n.||, ..., r_i, r\, ..., fn-i) such that r±i = RouteProx!maIly(id ± b', updateMsg, d) such that Sd < id + b' < sj+i or Pd+i 5 id - b' < pd as appropriate. where b is the number base, n is the field size in number of digits, u is the neighborhood range, and v is the neighborhood size. [0116] Note that a subset of the neighborhood nodes maintained by a given node in ring -'d" can appear again as neighborhood nodes in the child ring "d+l" in which the given node participates as well. As such one can derive the upper bound on the total number of neighborhood nodes maintained by a given node across all the D rings it participates as D*max(u,v}/2. This considers that only one reference to a given node is kept and the worst case upper bound is for a balanced tree. [0117] It should be noted that when a ring is partitioned into a plurality of corresponding sibling sub-rings, it is permitted for a specified node to simultaneously participate in more than one of the plurality of corresponding sibling sub-rings, for example, through aliasing. Aliasing can be implemented to associate different state, for example, from different sub-rings, with the specified node. Thus, although aliases for a given node have the same ID, each alias can have distinct state associated with them. Aliasing allows the specified node to participate in multiple rings having distinct proximity criteria that are not necessarily common ancestors of more specific proximity criteria. That is, the specified node can participate in multiple branches of the proximity tree. (0118] Kor example, a dual NIC (wired and wireless) laptop can be considered to be proximally equivalent to both other wireless and wired nodes sharing the same LAN segments as the laptop. But, these two distinct proximity criteria can be modeled as sub-criteria that are applicable only after application of a different higher priority proximity criterion, such as, for example, one based on organizational membership. As the laptop belongs to the same organization, the aliased nodes in the two sub-rings representing 1) membership in the wired and 2) membership in the wireless LAN segments merge into a single node in the ring representing the organization to which the laptop belongs. It should be understand that the Route Proximally works as expected without any modifications in the presence of aliasing. |0119] Each proximal ring can be configured in accordance with (potentially different) ring parameters. Ring parameters can be used to define a neighborhood (e.g., ring parameters can represent a neighborhood range, a neighborhood size, ping message and depart message timing and distribution patterns for ping and depart messages), indicate a particular federating mechanisms (e.g., from among the above-described first through fourth federating mechanisms previously described or from among other federating mechanisms), or define communication specifics between routing partners in the same proximal ring. Some ring parameters may be more general, applying to a plurality of different federating mechanisms, while other ring parameters are more specific and apply to specific type of federating mechanism. [0120] Ring parameters used to configure a higher level proximal ring can be inherited in some embodiments by lower level proximal rings. For example, it may be that ring 543 inherits some of the ring parameters of ring 531 (which in turn inherited from ring 522. etc.). Thus, a neighborhood size and neighborhood range associated with ring 531 is also associated with ring 541. [0121| However, inherited ring parameters can be altered and/or proximal rings can be individually configured in accordance with different ring parameters. For example, it may be that ring 511 is for an administrative domain that contains a large number of nodes and thus the above-described fourth federating mechanism is more appropriate for ring 511. On the other hand, it may be that ring 521 is for a small business with a relatively smaller number of nodes and thus the above-described second federating mechanism is more appropriate for ring 521. Thus, the ring parameters associated with ring 521 can be set to (or inherited parameters changed to) different values than the ring parameters associated with ring 511. For example, a ring parameter indicating a particular type of federating mechanisms can be different between rings 511 and 521. Similarly parameters defining a neighborhood can be different between rings 511 and 521. Further, ring 521 can be configured in accordance with specific parameters that are specific to the above-described second federating mechanism, while ring 511 is configured in accordance addhional with specific parameters that are specific to the above-described fourth federating mechanism. [0122] Accordingly, proximal rings can be flexibly configured based on the characteristics (e.g., number, included resources, etc.) of itodes in the proximal rings. For example, an administrator can select ring parameters for proximal rings using a configuration procedure (e.g., through a user-interface). A configuration procedure can facilitate the configuration of inheritance relationships between proximal rings as well as the configuration of individual proximal rings, such as, for example, to override otherwise inherited ring parameters. |0123| Figure 8 illustrates an example flow chart of a method 800 for partitioning the nodes of a federation infrastructure. The method 800 will be described with respect to the rings of partition a tree 500 in Figure 5. Method 800 includes an act of accessing a sorted linked list containing node IDs that have been assigned to nodes in a federation infrastructure (act 801). For example, the sorted linked list represented by ring 501 can be accessed. The node IDs of the sorted linked list (the nodes depicted on ring 501) can represent nodes in a federation infrastructure (e.g., federation infrastrucrelOO). [0124] Method 800 includes an act of accessing proximity categories that represent a plurality of different proximity criteria for parthioning the sorted linked list (act 802). For example, proximity criterion representing domain boundaries 561, geoaraphical boundaries 562, and organizational boundaries 563 can be accessed. However, other proximity criteria, such as. trust domain boundaries, can also be represented in accessed proximity criterion. Proximity categories can include previously created partially ordered fists of proximity criteria. A ring can be partitioned based on partially ordered lists of proximity criteria. |0125] Method 800 includes an act of partitioning the sorted link list into one or more first sub lists based on a first proximity criterion, each of the one or more first sub lists containing at least a subset of the node IDs from the sorted linked list (act 803). For example, ring 501 can be partitioned into sub-rings 511, 512, 513, and 514 based on criterion 571. Each of sub-rings 511, 512, 513, and 514 can contain a different sub-set of node IDs from ring 501. |0I26] Method 800 includes an act of partitioning a first sub list, selected from among the one or more first sub lists, into one or more second sub lists based on a second proximity criterion, each of the one or more second sub lists containing at least a subset of node IDs contained in the first sub list (act 804). For example, sub-ring 511 can be partitioned into sub-rings 521. 522, and 523 based on criterion 581. Each of he sub-rings 521, 522, and 523 can containadifferent sub-set of node IDs from sub-ring 511. |0127] Figure 9 illustrates an example flow chart of a method 900 for populating a node's routing table. The method 900 will be described with respect to the sorted linked list 304 and ring 306 in Figure 3. Method 900 includes an act of inserting a predecessor node into a routing table, the predecessor node preceding a current node relative to the current node in a first direction of a sorted linked list (act 901), For example, the node having ID 50 can be inserted into the routing table as a predecessor for the node having ID 64 (the current node). Moving in a clockwise direction 321 (from end A of sorted linked list 304 towards end B of sorted linked list 304), the node having ID 50 precedes the node having ID 64. Inserting a predecessor node can establish a symmetric partnership between the current node and the predecessor node such that current node is a partner of predecessor node and the predecessor node is a partner of the current node [0128| Method 900 includes an act of inserting a successor node into the routing table. the successor node succeeding the current node relative to the current node in the first direction in the sorted linked list (act 902). For example, the node having ID 76 can be inserted into the routing table as a successor for the node having ID 64 (the current node). Moving in a counter-clockwise direction 322, the node having ID 76 succeeds the node having ID 64. inserting a successor node can establish a symmetric partnership between the current node and the successor node such that current node is a partner of the successor node and the successor node is a partner of the current node. (01291 Method 900 includes an act ofinserting appropriate neighborhood nodes into the routing table, the neighborhood nodes identified from the sorted linked list in both the first direction and in a second opposite direction based on a neighborhood range and neighborhood size (act 903). For example, the nodes having IDs 83, 76, 50, and 46 can be inserted into the routing table as neighborhood nodes for the node having ID 64 (the current node). Based on a neighborhood range of 20 and a neighborhood size 4, the nodes having IDs 83 and 76 can be identified in clockwise direction 321 and the nodes having IDs 50 and 46 can be identified in counter-clockwise direction 322 (moving from end B of sorted linked list 304 towards end A of sorted linked list 304). it may be that in some environments no appropriate neighborhood nodes are identified. Inserting a neighborhood node can establish a symmetric partnership between the current node and the neighborhood node such that current node is a partner of the neighborhood node and the neighborhood node is a partner of the current node. [0130] Method 900 includes an act of inserting appropriate routing nodes into the routing table, the routing nodes identified from the sorted linked list in both the first and second directions based on the a number base and field size of the ID space for the federation infrastructure, the routing nodes representing a logarithmic index of the sorted link list in both the first and second directions (act 904). For example, the nodes having IDs 200, 2, 30, 46, 50. 64, 64, 64, 64, 64, 76, 83, 98, 135 and 200 can be inserted into the routing table as routing nodes for the node having ID 64. Based on the number base 2 and field size of 8 the nodes having IDs 64. 64, 76, 83, 98, 135 and 200 can be identified in direction 321 and the nodes having IDs 64, 64, 50, 46, 30, 2, and 200 can be identified in direction 322. As depicted inside ring 306, the routing nodes represent a logarithmic index of the sorted link list 304 in both clockwise direction 321 and counter-clockwise direction 322. Inserting a routing node can establish a symmetric partnership between the current node and the routing node such that curtent node is a partner of the routing node and the routing node is a partner of the current node. |0131] Figure 7 illustrates an example flow chart of a method 700 for populating a node routing table that takes proximity criteria into account. The method 700 will be described with respect to the rings in Figure 5. Method 700 includes an act of inserting a predecessor node for each hierarchically partitioned routing ring the current node participates in into a routing table (act 701). Each predecessor node precedes the current node in a first direction (e.g., clockwise) within each hierarchically partitioned routing ring the current node participates in. The hierarchically partitioned routing rings are partitioned in accordance with corresponding proximity criteria and contain at least subsets of a bi-directionally linked list {and possibly the whole bi-directionally linked list). For example, it may be that a specified node participates in root ring 501 and sub-rings 511, 522, 523, 531, and 542. Thus, a predecessor node is selected for the specified node from within each of the rings 501 and sub-rings 511, 522, 523, 531, and 542. [0132J Method 700 includes an act of inserting a successor node for each hierarchically partitioned routing ring the current node participates in into the routing table (act 702). Each successor node succeeding the current node in the first direction within each hierarchically partitioned routing ring the current node participates in. For example, a successor node is selected for the specified node from whhin each of the rings 501 and sub-rings 511, 522, 523, 531, and 542. 10133) Method 700 includes an act of inserting appropriate neighborhood nodes for each hierarchically partitioned routing ring the current node participates in into the routing table (act 703). The neighborhood nodes can be identified in both the first direction (e.g., clockwise) and in a second opposite direction (e.g.. counter clockwise) based on a neighborhood range and neighborhood size from the hierarchically partitioned routing rings the current node participates in. For example, neighborhood nodes can be identified for the specified node from within each of the rings 501 and sub-rings 511, 522, 523, 531, and 542. [0134] Method 700 includes an act of inserting appropriate routing nodes for each hierarchically partitioned routing ring the current node participates in into the routing table (act 704). For example, routing nodes can be identified for the specified node from within each of the rings 501 and sub-rings 511, 522, 523, 531, and 542. (01351 '"^ some embodiments, appropriate routing nodes are inserted for each proximity ring d except the leaf ring (or leaf rings in embodiments that utilize aliasing), in which the node Y participates. Appropriate routing nodes can be inserted based on the following expression(s): if Y.Sd-id < Y.id + b' < Y.Sd+i-id is true, then use ring d; or if Y.pd.id < Y.id - b' < Y.pd+i.id is true, then use ring d. [0136| If a ring has not been identified in the previous step, use the lead (e.g., ring 501) ring as ring d. Now, ring d is the proximity ring in which node Y should look for the routing partner closest to z. (0137] Figure 10 illustrates an example flow chart of a 1000 method for routing a message towards a destination node. The method 1000 will be described with respect to the sorted linked list 304 and ring 306 in Figure 3. Method 1000 includes an act of a receiving node receiving a message along with a number indicating a destination (act 1001). For example, the node having ID 64 can receive a message indicating a destination of212. [0138) Method 1000 includes an act of determining that the receiving node is at least one of numerically further from the destination than a corresponding predecessor node and numerically further from the destination than a corresponding successor node (act 1002). For example, in direction 322, ID 64 is fuilher from destination 212 than ID 50 and. in direction 321. ID 64 is further from destination 212 than ID 76. Method 1000 includes an act of determining that the destination is not within a neighborhood set of nodes corresponding to the receiving node (act 1003). For example, the node with ID 64 can determine that destination 212 is not whhin the neighborhood set of 83, 76, 50, and 46. [0139] The method iOOO includes an act of identifying an intermediate node from a routing table corresponding to (he receiving node, the intermediate node being numerically closer to the destination than other routing nodes in the corresponding routing table (act 1004). For example, the node having ID 64 can identify the routing node having ID 200 as being numerically closer to destination 212 that other routing nodes. The method 1000 includes an act of sending the message to the intermediate node (act 1005). For example, the node having ID 64 can send the message to the node having ID 200. [0140) Figure 11 illustrates an example flow chart of a method 1100 for routing a message towards a destination node based on proximity criteria. The method 1100 will be described with respect to the rings in Figure 4 and Figure 5. Method 1100 includes an act of a receiving node receiving a message along with a number indicating a destination and a proximity criterion (act 1101). The proximity criterion defines one or more classes of nodes. The receiving node receives the message as part of a current class of nodes selected form among the one or more classes of nodes based on the proximity criterion. For example, the node having ID 172 can receive a message indicating a destination of 201 and proximity criterion indicating that the destination node be part of classes represented by ring 401. The node having ID 172 can receive the message as part of ring 404. |0141| Method 1100 includes an act of determining that the receiving node is at least one of. numerically further from the destination than a corresponding predecessor node and numerically further from the destination than a corresponding successor node, among nodes in a selected class of nodes (act 1102). For example, within ring 404, the node with ID 172 is further from destination 201 than the node having ID 174 in the clockwise direction and is further from destination 20] than the node having ID 153 in the counterclockwise direction. [0142] Method 1100 includes an act of determining that the destination is not within the receiving node's neighborhood set of nodes for any of the one or more classes of nodes defined by the proximity criterion (act 1103). For example, the node having ID 172 can determine that destination 201 is not in a corresponding neighborhood set in ring 404 or in ring 401. [0143] Method 1100 includes an act of identifying an intermediate node from the receiving node's routing table, the intermediate node being numerically closer to the destination than other routing nodes in the routing table (act 1104). For example, the node having ID 172 can identify the node having ID 194 as being numerically closer to destination 201 than other routing nodes in ring 404. The method 1100 includes an act of sending the message to the intermediate node (act 1105). For example, the node having ID 172 can send the received message to the node having ID 194. The node having ID 172 can send the received message to the node having ID 194 to honor a previously defined partially ordered list of proximity criterion [0144J Node 194 may be as close to destination 201 as is possible within ring 404. Thus, proximity can be relaxed just enough to enable further routing towards the destination to be made in ring 401 in the next leg. That is, routing is transitioned from ring 404 to ring 401 since no further progress towards the destination can be made on ring 404. Alternately, it may be that the node having ID 201 is within the neighborhood of the node having ID 194 in ring 401 resuHing in no further routing. Thus, in some embodiments, relaxing proximity criteria to get to the next higher ring is enough to cause further routing. [0145] However, in other embodiments, incremental relaxation of proximity criteria causing transition to the next higher ring continues until further routing can occur (or until the root ring is encountered). That is, a plurality of transitions to higher rings occurs before further routing progress can be made. For example, referring now to Figure 5, when no further routing progress can be made on ring 531, proximity criteria may be relaxed enough to transition to ring 511 or even to root ring 501, [0146] Node Phases [0147] A node participating in a federation infrastructure can operate in different operational phases. Valid phase values for a node can be defined to be members of an ordered set. For example. {NodeId}.{lnstancelds}.{Phase Value [Phase-State Values: Inserting, Syncing, Routing, Operating]. [Phase.Unknown Indication: phase known at time of transmission, phase unknown at time of transmission]} defines one possible ordered set representing a phase-space of a given node within a federation infrastructure. A node instance can transition (or advance) through the node phase-states from Inserting to Syncing to Routing to Operating in order. Further, in some embodiments, a node instance can be configured such that the node instance is prevented from transitioning back to a prior node phase-state. In some embodiments, a node advances its instance ID each time the node comes up. [0148] For example, a node instance can prevented from transitioning from Routing back to Syncing (or back to Inserting), etc. Accordingly, in some embodiments, when it is known that a given node instance (e.g., identified by (Nodeld, Instanceld)) has advanced to a particular node phase-state (e.g.. Operating), it is also known that the given node instance is not likely to (and in some embodiments will not) revert to a prior node phase-state (e.g., back to Routing. Syncing, or Inserting). Thus, there is a significant likelihood that any node instance in a node phase prior to the particular node phase-state is a neu (and advanced) instance of the node. [0149) In some embodiments, phase information and corresponding instance Ids (which advance as a node comes up) are transferred together. Thus, it is possible to determine that a lesser node phase-state for the same instance is older. Further, when a newer node instance is known (at any phase-state values) any information about older instances is considered out of date. [01501 From time to time, nodes can reboot or lose communication with one another, such as, for example, when first starting up, through a graceful departure, or as a result of abnormal termination (crash). Thus, there is the potential for a node in any node phase-state to reboot or lose communication with other nodes. For example, a crash can cause a node in a Routing phase-state to reboot. During a reboot or lose of communication, there may be no way to determine what node phase-state a node is in. Accordingly, when a node is rebooting or communication to a node is lost, a [Phase.Unknown Indication] can be set to indicate that the phase-state for the node is currently not known. However, any previously expressed and/or detected phase-state for the node can be maintained and is not lost. [0151| The [Phase.Unknown Indication] can be used to indicate whether a phase-state was known at the time a phase-state value was transmitted (e.g phase value with phase.unknown not set) or if a phase-state is a previously expressed phase-state and the phase-state was not known at the time the phase-state was transmitted (e.g., phase value with phase.unknown set). Thus, the phase of a node {its phase value) can be represented using both a phase-state value and a phase.unknown indication. (0152) Join Protocol |01S3| From time to time, nodes can join to and depart from existing federations. The nodes can implement appropriate protocols for joining and departing federations. For example, a node can implement a Join() function to become pan of an existing federation. A node implementing the Join() function can transition through three ordered phase-states; an inserting phase-state, a synchronizing phase-state, and a routing phase-state before reaching the final operating phase-state. In other embodiments these specific order phase-states may not exist while others may be defined. Figure I2A illustrates an example of a node establishing membership within a federation infrastructure. Figure I2B illustrates an example of nodes in a federation infrastructure exchanging messages. |0154] Insertion Phase: A node. Y, enters this phase-state by issuing a join message, including at least its node ID and indicating a join action to the federation. A join message can be a routed message sent by a newly joining node (node Y) with its destination property set to the identity of the newly joining node. In this phase-state, a newly-joining node is inserted between its predecessor and successor nodes in the federation. The insertion phase-state can be implemented according to the following algorithm (All arithmetic is performed modulo b"): 10155) IPl Y identifies an existing node that is already part of a lowest ring from which the joining node wishes to participate in the federation. This can either be statically configured or dynamically discovered using DHCP and/or DNS and/or WS-Discovery or a (potentially well-known) constant. Let this existing federation node be E. [0156] IP2. Y invokes E.RouteNumerically(Y, joinMsg) to determine the node X whose ID is numerically closest to Y.id in every proximity ring thai the node Y participates. This can include routing a join message to multiple nodes. 10157] IP3. Determine the numerical successor (s) and predecessor (p) nodes. (Note that the data needed to do the following insertion can be carried in the join message and ils response. As such, there are no additional roundtrips needed.) Case I: X.id > Y.id Y.s = X. Y.p = X.p, X.p.s = Y, and X.p = Y Case 2: X.id (Y.id + u/2), j > v/2-1, p^.p-id < (Y.id - u/2),andk>v/2-l |0I64| SP2. Referring briefly to Figure 16, query Y's local application layer (e.g., application layer 1652) via a neighborhood state request (e.g., neighborhood state request) 1604 to obtain optional application specific neighborhood data (e.g., application specific data 1607). [01651 SP3. Send synchronize message to at least the proximal successor and predecessor nodes including at least liveness state information of each proximal neighborhood and routing partner node from Y's perspective. Any optional application specific neighborhood data (e.g., application data 1607) accessed via SP 2 is included in the sync request 1631. |0166] SP3. Y receives sync response messages back from those nodes processing sync messages sent in SP2, For example, node Y can exchange synchronize messages (request/response) with one or more nodes within its computed neighborhood. After synchronize messages are exchanged with at least one and potentially all of a node Y's neighborhood nodes, the computed neighborhood nodes can exchange further messages to propagate synchronized data. A synchronization message {request or response) can be a non-routed message sent by a node to proactively synchronize its data with a target node that is, for example, in the nodes neighborhood. [0167] SP4. As sync response message in SP3 are received (e.g., sync response message 1641) , any optional application specific neighborhood data present in these received sync response messages (e.g., application data 1622) can be offered to Y's application layer 1652 via neighborhood stale sync event 1603. [0168] As part of the synchronizing phase-state, the proximal successor (e.g., Y.s) and predecessor (Y.p) nodes exchange their routing tables with the newly-inserted node (e.g., Y). Nodes that receive sync messages can respond by sending sync responses. Sync responses carry data similar to synchronize messages except from the perspective of the responding node. Both sync messages and sync responses can carry (or piggyback) application data. Thus, application data can be propagated between nodes during the synchronizing phase-state. When the synchronize phase-state is complete, the node can process messages destined for it, instead of simply forwarding them either to a successor or predecessor. However, the node may still be viewed as a weak routing participant because its routing table is not populated. [0169] Routing Phase: After the synchronizing phase-state is completed, a node transitions into the routing phase-state. In the routing phase-slate, the newly-synchronized node (e.g., node Y) computes its routing nodes. The routing phase-state can be implemented according to the following algorithm (All arithmetic is performed modulo b"): |0170] RP! If the routing phase-state is being executed as part of the balancing procedure (explained later), ensure that the successor node (Y.s) and the predecessor node (Y.p) are alive in every proximity ring the node Y participates. If either is not alive, determine the replacement node for the failed one(s) by choosing a next best successor or predecessor node among the neighborhood nodes in the ring under consideration, |0I71] RP2. For 1 1) increasing, o Sequence ID (e.g.. a URI) identifying the particular sequence generated by an owner. This component allows the same owner to generate multiple independent seijuences o Ordinal number (e.g., an unsigned-integer) identifying the offset within the identified application sequence ID. (0228| Item timestamps arc used to detect latest information associated with the corresponding item during replication because item timestamps generate at least a partial-order with triples. The timestamp associated with an item being replicated is compared against the local one, if any, to detect the latest one. Item timestamps are also used to support idempolent semantics of create/update/delete operations. For example, when a node receives a request to update an existing item in the application state, the update is accepted only if the timestamp associated with the update request is higher than the one associated with the local item. Confiict resolution techniques based on vector timestamps can be utilized where items cannot be assigned a single owner. Application state replication provides fault-tolerance and facilitates load-balancing requests across neighborhood nodes. [0229| As an optional behavior. Nodes not detecting (after a period of time) an expected Update or Ping from (origin) other partner (routing and/or partner) nodes can consider the phase-state unknown, set a phase.unknown indication to true, and report it as such to other 3"* party nodes. In other words periodic generation of updates and pings can be required. This requirement and actual timeout values can be an attribute of various proximal rings, l-'or example, a ring can have more restrictive timing requirements for some sub-rings {e.g., in a LAN segment) and node failure detection/reporting is relatively quick. On the other hand, a ring can have less restrictive timing requirements (or even no timing requirements) for other sub-rings (e.g., on the internet) and proactive node failure detection/reporting is relative long (or doesn't exist). [0230| Figure 15 illustrates an example flow chart of a method 1500 for discovering liveness information for another node. The method 1500 will be described with respect to ring 1206 in Figures I2A and I2B. Generally, any message, such as, for example, sync 1203, sync response. 1204. update 1216, update response 1207, etc., can include at least one liveness header. In some embodiments, a liveness header includes a for a node. In other embodiments, a liveness header includes . In these other embodiments, liveness headers can be used to augment addressing headers that already include node ID and instance ID for sender and origin nodes. Since the addressing headers already include node ID and instance ID, this information can be omitted from the liveness header. [0231] Method 1500 includes an act of receiving a liveness header representing state information for a node participating in a federation infrastructure (act 1501). The liveness header includes at a least a received participating node ID, a received node's instance ID, a received phase value, and a received freshness value. For example, the node having ID 144 can receive a first liveness header in sync response 1204 from the node having ID 151. The first liveness header can include a for the node having ID 174. The phase-state value (e.g., Inserting, Syncing. Routing, Operating) identifies the expressed phase of the node having ID 174 at the time of the first freshness value. The phase value (e.g., phase-state: [Inserting, Syncing, Routing, Operating], and phase.unknown) identifies the expressed and/or detected phase information of the node having ID 174 at the time indicated by the first freshness value. 10232] However, a freshness value can be discounted due to communication delay. A freshness value can also decay with the passage of time. The decay curves for a freshness value can differ (and maj not be linear or symmetric) for the different phase slates (including unknown). Thus, across different node phases, the decay of a freshness value can be non-linear and/or as\mmetric. 10233] Method 1500 includes an act of accessing at least a current instance ID. current phase value, and current freshness value for the participating node maintained at the current node (act 1502). For example, the node having ID 144 can access a previous received and stored instance ID, phase value [phase-sate value.][phase,unknown indication], and freshness value for the node having ID 174. [0234] Method 1500 includes an act of comparing at least the received instance ID, received phase value, and received freshness value to the current instance ID, the current phase value, and the current freshness value respectively at a current node (act 1503). For example, the node having ID 144 can compare the previously received and stored instance ID, phase value [phase-sale value.][phase.unknown indication], and freshness value for the node having ID 174 to the instance ID, phase value [phase-sate value.][phase.unknown indication], and freshness value received in the liveness header. [0235] The node having ID 144 can determine that current state information for the node having ID 174 (e.g., received from the node having ID 151) is stale based on (in order) the first instance ID being greater than the currently stored instance ID for the node having ID 174, based on first phase-slate value being more advanced than the currently stored phase-state value for the node having ID 174, or based on the first freshness value being a value greater than the freshness value currently stored for the node having ID 174. The node having ID 144 can also determine that at least one phase.unkown indication (either currently stored or received in the liveness header) indicates that a phase-state was known at the time the phase-state was detected/transmitted. |0236| Method 1500 includes an act of determining if state information for the participating node is to be updated at the current node based on the comparison (act 1504). For example, based on the comparison of values for the node having ID 174, the node having ID 144 can determine that state information for the node having ID 174 is to be updated. Updating outdated state information for the node having ID 174 can include replacing current stored values (e.g., for instance ID, phase-state value, phase.unknown indication, or freshness value) with values included in the liveness header. For example, the node having ID 144 can update state information for the node having ID 174 to indicate that the node having ID 174 has transitioned to a more advanced phase-state. |0237| In some embodiments, it can be detected that communication with the participating node may have been lost. For example, the node having ID 144 can detect that communication with the node having ID 151 has been lost. Referring briefly to Figure 17, in response to a prior subscription for liveness events 1701 (with an endpoint of the node having ID 151), application layer 1752 can send endpoint down event 1703 (with an endpoint of the node having ID !5l) to function layer 1751. In these embodiments such detected liveness conditions can be indicated in Hveness information with the Phase.Unknown indicator being set to true along with the last known Phase state value. |0238] Method 1500 can further include an act of receiving a message that includes a second liveness header from a second different node in the federation infrastructure For example, the node having ID 144 can receive a status message (from the node having ID 103 or some other node of ring 1206) that includes a second liveness header. The second liveness header can include for the node having ID 174. The second phase value (e.g., phase-slate: [Inserting, Syncing, Routing, Operating], and phase.unknown indication) identifies the expressed/delected phase of the node having ID 174 at the time of the second freshness value. |0239| Alternately, subsequent to receiving the first liveness header, the node having ID 144 can attempt to communicate directly with the node having ID 174. If communication is successful, the node having ID 174 can return a message (e.g., sync response) having the node ID and second instance ID in an addressing header and having a liveness header including . If a failure is detected, the node having ID 144 generates an internal liveness state change (e.g. freshness = max, and phase.unknown indication = true) and processes the state change as if the state change were received from another node. Such a state change has highest freshness value. [0240] Method 1500 can also include an act of comparing the second instance ID, the second phase value, and the second freshness value lo the current instance ID, the current phase value, and the current freshness value respectively (act 1506). For example, after receiving a status message from the node having ID 103, the node having ID 144 can determine that current state information for the node having ID 151 is stale based on (in order) the second instance ID being greater than the first instance ID, the second phase being more advanced than the first phase value, or the second freshness value being greater than the first phase value. |0241| Method 1500 can also includes an act of determining if state information for the participating node is to be updated based on the comparison. For example, based on the comparison of values for ihe node having ID 174. the node having ID 144 can determine that state information for the node having ID 174 is to be updated. Updating outdated state information for the node having ID 174 can include replacing current stored values (e.g., for instance ID. phase-state value, phase.unknown indication, or freshness value) with values included in the second tiveness header. For example, the node having ID 144 can update state information for the node having ID 174 to indicate that the node having ID 174 has transitioned to a more advanced phase-state. [0242] In some embodiments, phase values are compared within the context of equal color values. As previously described, a node can participate in multiple proximity rings. Participation in multiple proximity rings can occur as a result of participation in a more specific ring implying participation in a more general ring (along a common spine). For example, referring back to Figure 5, a node's participation in ring 532 also implies that the node is participating in rings 522. 511, and 501. Thus, a color for a more specific ring also represents all parent proximal rings. Also as previously described, participation in multiple proximity rings can occur when a node in one ring is aliased into one or more other rings (potentially along different spines). For example, still referring to Figure 5. a node participating in ring 532 can be aliased into ring 531 (or even ring 541 that would imply participation in rings 53 I, 522, 511, and 501). Thus, a color for one ring (e.g.. ring 531) can be viewed as a peer color (or proximity) of another ring (e.g., ring 532). |0243| When a node participates in a plurality of proximity rings in an aliased fashion, there is some potential that phase values (e.g., phase-state values and/or phase.unknown indications) for the node will differ between different proximity rings. Thus, a node that receives state information for another node, identifies the corresponding proximity ring for the state information (color) before determining if current state information is to be updated for that node and color. For example, the node having ID 144 can identify the corresponding proximity ring for received state information corresponding to the node having ID 174 before comparing the received state information to current state information. [0244| Identifying an appropriate proximity ring can include comparing a received color value to one or more current color values. When the received color value and a current color value are equal. other state information, such as, for example, a current instance ID, a current phase value, and a current freshness value, can be compared to corresponding received state information, such as. for example, a received instance ID, a received phase value, and a received freshness value. On the other hand, when the received color value and a current color value differ, further comparisons do not occur. |0245| Equality between color values can result in a variety of ways. For example, equality between color values can result when a current color value and a received color value indicate the same proximity ring (e.g.. ring 532). Further, equality between color values can result when a more specific color value is compared to a corresponding parent color value (e.g., another ring along the same spine). For example, comparing the color value for ring 532 to the color value for ring 511 (or ring 522 or 501) can result in equality. Thus, the child proximity is the parent proximity but is more specific. [0246] Thus generally, currently operational nodes in a federation infrastructure can exchange expressed and detected livencss state information for other nodes even when communication with those other nodes appears to be lost. |0247] Bootstranping Mechanisms 10248] Generally, in order fbr a node to become an active member of a federation (e.g., join), the node has to communicate with at least one other node that is already an active member of the leaf ring it intends to join. To help insure this initial form of communication is available, federations can utilize a bootstrapping mechanism. A bootstrapping mechanism can be used as a last resort when other types of communication fail to identify an active member of a leaf ring or security constraints require a newly jotntng node to initially communicate with at least one of a set of special nodes such as seed nodes. That is when other types of communication fail or because of security requirements, a bootstrapping mechanism can be used to identify an active member node of a leaf ring. |0249| in some embodiments, seed nodes are used to bootstrap communication with a federation. Seed nodes provide well known points of entry for some types of cross (inter) proximity communication). Seed nodes help heal ring partitions due to infrastructure failure/recovery and general dynamism. Rach ring can have at least one operational seed node in order to provide basic bootstrapping properties for a federation. |0250] Peer seed nodes can communicate amongst themselves to maintain a ring structure (e.g.. a doubly linked list) for a proximity that consists of at least all active seed nodes for that proximity. A dedicated seed node synchronization protocol can be used to provide each seed node wilh al least total knowledge of all other seed nodes' presence (active) state. An active seed node is a member node of the proximity leaf ring in which it is homed as well as all other ancestral rings of the leaf ring. Thus, a seed node can represent an entire spine of proximity rings, for example, from the seed node's leaf ring to the root ring. Accordingly, seed nodes can function as highly available and well known entry nodes in each of those proximity rings. As a result, presence state about seed nodes can be useful for various forms of communication (e.g., inter-proximal communication) within a federation. Accordingly, seed nodes can provide a number of special properties, such as, for example, acting as well known "join points" for joining nodes, acting as a secure ring authority, aiding in healing infrastructure partitions, and acting as a stable ■'entry node" for each of their proximities, |0251) To provide presence data, a seed node's arrivals and orderly departures can be registered as a stable entry node at a rendezvous point in each of their proximities. For example, registration mes.sages can be routed to a fixed URI whose destination ID is the SHA-1 hash of the string "Proximity:/". While in one embodiment seed nodes acting as stable entry nodes register themselves in this manner there are other embodiments where selected non-seed nodes may also register themselves in the same manner and with the same or similar protocols described here for seed node. When a stable entry node (such as a seed node) registers, the stable entry node can indicate each ring it is a member of. Thus, information maintained at the rendezvous point identified by this fixed URI is essentially a list of stable entry nodes and their corresponding ring memberships. Accordingly, any node can refer to the rendezvous point identified by this fixed URI to obtain a list of available stable entry nodes and their ring memberships. [0252] In one embodiment the stable entry node directly registers these arrival and departure events. In another embodiment, the stable entry node registers these events directly at a rendezvous point within it's immediate proximity ring and that rendezvous point transparently facilitates (directly or indirectly) updating of all other appropriate rendezvous points in each of the remaining proximities rings to which the register!ng/unregislering stable entry node belongs. The application state sequencing and propagation properties of a federation can be used to maintain and propagate this stable entry node registration information, i-or example, a reliable-flooding protocol can be used to replicate saved application state among a node's Neighborhood nodes. [0253] The promotion of stable entry node's presence data towards the root ring allows other nodes in a federation to look up at least one entry node in every proximity. Entry Node Lookup can be facilitated by routing a node lookup message towards the above determined rendezvous point in the Lowest Common Ancestor Ring ("LCAR") of the leaf ring of the node performing the lookup and the desired proximity ring. For example, referring to Figure 5. a node in ring 541 may desire to communication with a node in ring 533. However, the node in ring 541 may have no direct knowledge of any node in ring 533. Thus, the node in ring 541 can send a Node Lookup Message to ring 522 (the LCAR of ring of ring 541 and ring 533). A rendezvous point node in ring 522 that processes entry node presence information (e.g. caused to exist in the system because of a registration message originated by that entry node) can return a Loolcup Response Message with contact information for at least a registered stable entry node in ring 533. |0254] In some embodiments, stable entry nodes are seed nodes configured specifically as stable entry nodes for maintaining presence data for various proximities. In other embodiments, other types of nodes can also function as stable entry nodes maintaining presence data for various proximities and may also be configured to perform other operations. For example, certain other types of nodes may be configured (e.g., by an administrator) as being highly available and thus suitable as a stable entry node (i.e. to be registered as described above). However, the other types of nodes may not include additional seed node functionality (e.g.. may not be trusted as a security ring authority). In some embodiments, rendezvous points that maintain entry node presence state for their immediate proximity may register themselves as a stable entry node in the ancestral ring or rings. [0255] Inter-Proxiinit\' Communication [0256] Embodiments of the present invention can also facilitate inter-proximity communication, such as, for example, between nodes in different proximal branches of a tree of rings. Inter-proximity communication can be used to communicate to and/or between one or more, and potentially all, proximity rings in a proximally partitioned ring infrastructure. Referring now to Figure 5A, Figure 5A illustrates the example proximity induced partition tree 500 with additional levels of detail in portions of partition tree 500. Inter-proximity communication can occur between various nodes in Figure 5A. [0257] As depicted in Figure 5 A, partition tree of rings 500 addition includes various sub-rings under ring 513. Bach of the additional sub-rings represents a partition of a sorted linked list. As previously described for Figure 5, within partition tree 500, root ring 501 is partitioned into a plurality of sub-rings, including sub-rings 511. 512, 513, and 514, based on criterion 571 (a fir.st administrative domain boundary criterion). Also ar previously described for Figure 5. sub-ring 5 11 can be further partitioned into a plurality of sub-rings, including sub-rings 521, 522, and 523, based on criterion 581 (a second administrative domain boundary criterion). Other sub-rings under sub-ring 522 are further portioned based on other criterion. [0258] As previously described, within partition tree 500, each node has a single ID and participates in rings along a corresponding partition path (a spine) starting from the root to a leaf. For example, each node participating in sub-ring 552 would also participate in sub-rings 543, 531, 522, 5 il and in root 501. [0259] In Figure 5A, sub-ring 513 can also be further partitioned into a plurality of sub-rings, including sub-rings 561 and 562 based on other criterion, such as, for example, state jurisdiclion. Sub-ring 562 can be further portioned into a plurality of sub-rings, including sub-rings 571 and 572 based on other criterion, such as, for example, city jurisdiction. Accordingly, within Figure 5A, inter-proximity communication can be used to send a message from a node of ring 541 to a node of ring 572. without requiring communication up a spine from ring 541 to root ring 501 and then back down from root ring 501 to ring 572. [0260] Inter-proximily communication can be included as part of a communication pattern, such as, for example, broadcasting, multicasting, or any- casting, being implemented in a tree of rings. Broadcasting can include sending a message to all active nodes in a tree of rings, Muhicasting can include sending a message to a group of nodes in a tree of rings. Any-casting can include sending a message to at least one node in a tree of rings. [0261] Figure I9A illustrates an example proximity induced partition tree of rings 1900 that facilitates inter-proximity communication. Within partition tree of rings 1900, root ring 1901 is partitioned into a plurality of sub-rings, including sub-rings 1, 2, 3, and 4. based on selected criterion (e.g.. a first administrative domain boundary criterion). Sub-ring I is further partitioned into sub-rings II, 21, 31. and 41. Sub-ring II is further partitioned into sub-rings 111,211. and 311. Sub-ring 21 is further partitioned into sub-rings 121, 221, 321, 421. and 521. Although not expressly depicted, other sub-rings, such as, for example, sub-rings 2, 3. 4, 31, and 41, can also be further partitioned. [0262] The numbering convention of the rings in proximity induced partition tree of rings 1900 is configured such that any digits after the first digit indicate a ring's parent ring. For example, the "11" in ring "311 "* indicates that ring 11 is the parent ring of ring 311, Similarly, the "I" in ring ■■41" indicates that ring 1 is the parent ring of ring 41, Global ring 1901 is the parent ring for any rings numbered with a single digit, such as, for example, rings 1, 2. 3 and 4, Similar to proximity induced partition tree of rings 500 in Figure 5A, partition tree of rings 1900 can be partitioned based upon various proximity criterion, 10263] Within the description and following claims the annotation R[""] is used to refer to a ring number. For example. R("ir'] refers to ring 11. Within thr description and loliowing claims the annotation N|] is used to refer to a node number. For example. N[ 1 _■? 11 ] refers to node 1311, [0264] To facilitate communication in a tree of rings, nodes can maintain an entr>' table that matches rings to corresponding entry nodes in those rings. As previously described, based on the configuration of partition tree of rings 1900 a parent ring contains all of the nodes from each of its child rings. For example, ring 11 contains all the nodes from R["M IT'], R["211"], and R['"311"']. Thus, sending a message to ring 1! is sufficient to get the message to any node in ring R["l 1 V], R["211"], and R["31 t"j. Accordingly, in some embodiments, a node's entry tabic can be reduced to entries for those rings that are relatively different from the perspective of the ring the node resides in. For example. N[l 111] can simply maintain an entry for R["2r'] - N[l 121] - since maintaining entries for multiple child rings or R["2r'] would be redundant. [0265] Creation and Maintenance of Collateral Ring Sets [0266] Within this description and in the following claims any peer ring of a specified ring is defined as a ""coliateral ring" of the specified ring. Within this description and in the following claims any peer ring of a specified ring's ancestor rings is also defined as a "'collateral ring" of the specified ring. Any collateral ring of a specified ring is also collateral ring of all the nodes included in the specified ring. (0267] Thus, for example, still referring to Figure 19A, R["211"] is a collateral ring ot R['T 11"] since Rnif] is a peer of R[-M 11"]. R["21i"] is also a collateral ring of any node included in R["l 11"]. such as. for example N[1311]. Further, R["21"] is a collateral ring of R[-'1H"] since R[-'2r'] is a peer of R[-M I"] (i.e., an ancestor of R["lir']). R["2r'] is also a collateral ring of any node included in R['Tir'], such as, for example Nfllll]. [0268] Within this description and in the following claims a "collateral ring set" ("CRS") is defined as a set of one or more collateral rings from the perspective of a specified ring or nodes within a specified ring. For example, in Figure 19A, a collateral ring set for R["221"], as well as any nodes in R["221"], such as, for example, N|8221|, includes R["\ i"J. R|-T21"|. R["3r-1. R["4r']. Rr-2"], R[-'3"], and R[-^4"]. [0269] Thus, to facilitate intcr-proximity communication, a node can maintain a CRS entry table that includes one or more collateral rings and one or more corresponding entry nodes into the one or more collateral rings. A CRS entry table can be a data structure including one or more items, where N is some integer. For example, the data structure can be of the format . where the ellipsis represents one or more additional entry nodes intocollatera) ringOI. [0270] To create a CRS entry table, a node can make use of local knowledge, rendezvous protocol messages (e.g., ping messages, update messages, and update responses) used to propagate state in a tree of rings, application messages, and messages used to facilitate specified communication patterns (e.g., broadcasting, multicasting, and any-casting) in a tree of rings. |0271] A node can use local knowledge, such as, for example, routing table information, from all levels of rings a node participates. For example, still referring to Figure 19, N[li21| may be a neighbor of NE131I] in Rf'l"]. One collateral ring of N[I311] from the perspective of N| 112!] is R|-2!l. Accordingly, N[] 311] can insert the pair(Rf"2l"], N[1I21]) (in this case an item having a single entry node) into N[13!l]'s CRS entry table. By making use of this type of local knowledge, a node can insert entries into a CRS entry table (02721 Nodes can, m uddition to specifically intended messages, propagate their CRS entry table information to other nodes in messages that are otherwise used for other purposes, such as, for example, to propagate neighborhood and routing partner state information. For example, nodes can include CRS entry table state in ping messages sent to neighborhood nodes and in update messages and update responses exchanged between routing partner nodes. Nodes that receive a CRS entry table state from another node can use the received CRS entry table state to augment and/or maintain their own CRS entry table. |0273| For example, when a node exchanges Rendezvous Ping/Update messages with its neighbor/partner nodes (e.g.. at a rendezvous protocol layer), the node can also exchange (at least part of and potentially all of) its CRS entry table {and use the CRS entry table stale received from its neighbors/partners to update its own table. Suppose, for example, that N[131 Ij does not have prior knowledge of any node in R["3"] (within the context of or ring 1901). However. N( 1311] does has a neigJjbor N[S22]] (in Rp'l"]) and N[82211's CRS entry tabic has an entry (R["3^'|, N[8223]). At least because N[1311) and N[822l] are neighbors, N| 1311] and N[8221] can. from time to time, send ping messages to one another. N[8221] can include (at least part of and potentially all of) its CRS entry table in ping messages that are sent to N[I311]. Thus, when N[I3I1] receives a ping message from N[822l|, then ping message can include N|822l]'s CRS entry table. From N[822l]'s CRS entry table. N[13111 can identify the item and include the item J|8223|, ...>) in its own CRS entry table, N[131l] can also identify other items for other rings in its CRS and include those other items in its own CRS entry table. [0274] CRS entry table state can be similarly exchanged in update messages and update responses exchanged between routing partners in a ring. Also, any routing protocol message can use to learn (e.g., [ivcness information) about CRS entry nodes. Also, specific messages, intended to maintain CRS entry tables, can be used. [0275] CRS entry table stale can also be discovered in messages that facilitate specified communication patterns (e.g.. broadcasting, multicasting, and any-casting) in a tree of rings. For example, to broadcast a message to every node in a tree of rings, a broadcasting algorithm may use various types of messages that are specific to broadcasting. Nodes thai send these broadcast specillc messages can include CRS entry table state within the broadcast specific messages. Similarly, when multicasting a message to every node in a group of nodes, a muUicasling algorithm may use various types of messages that are specific to multicasting. Nodes that send these muhicast specific messages can include CRS entry tabic state within the multicast specific messages. Likewise, when any-casting a message to at least one node, an any-casting algorithm may use various types of messages that are specific to any-casting. Nodes that send these any-cast specific messages can include CRS entry table stale within the any-cast specific messages. Nodes that receive communication pattern specific messages can identify appropriate entries (e.g., items) and include some OJ all the state from these entries in their own CRS entry table. [02761 CRS state can also be discovered in application component messages that are exchange between applications. Referring briefiy to Figure I, application layers 121, 122, and/or 123 may exchange application component messages that include CRS state. Upon receiving an application component message including CRS state, an application layer can transfer the CRS state down to corresponding other lower layers, such as, for example, to a rendezvous protocol layer, to augment existing CRS slate. |0277| CRS stale can be application provided and/or hard v^ired. and is configurable by nodes within a tree of rings. [0278] Referring back to Figure 19A, if a node finds that it knows a plurality of entry nodes to the same ring, it may decide to retain two or more of the entry nodes for the ring. In some embodiments, the node randomly selects an entry node from among any retained entry nodes. In other embodiments, a policy is applied to aid in the selection of a specified entry node from among any retained enlry nodes. A policy can indicate that the selected entry node is to be the same entry node each time. Alternately, a policy can indicate that the selected entry node is to be varied among any retained entry nodes. For example, in some embodiments, entry nodes are selected in a round-robin manner so that the load can be distributed evenly among any retained entry nodes. |0279| Further, when multiple enlry nodes are retained, a node can efficiently transition to a different entry node, for example, if a first selected entry node fails, is busy. or for some other reason is not available. |0280] Alternately, a node may retain a single enlry node for the ring. |0281| From time to time a node may delect additional entry nodes for a ring. In some embodiments, when a node retains a single entry node or lacks memory to store additional entry nodes, Ihe node can determine if a newly received entry node is to replace an existing entry node. In some embodiments, a node can use a function to compute the rank for each candidate entry node with the following parameters: the distance of Ihe entry node, Ihe freshness of the entry node information, and the weight of the entry node (e.g.. configuration preference). An entry node with higher rank is retained. |0282| A CRS entry table may or may not be complete, A complete CRS entry table includes at least one enlry node for each ring in a node's CRS. For example, a complete CRS entry table for node 1311 would include at least one entry node into each of rings in,211,21.31.41,2,3,and4. 10283] Utilizing the above mechanisms it may possible lo construct complete CRS entry tables from the perspective of one or more rings and/or nodes in a proximal ring hierarchy. In some embodiments, it may be that routing table state information alone forms a complete CRS entry table for each node in the tree of rings. For example, routing table related information propagated (e.g., in ping messages, update request messages, and update response messages) in tree of rings 1900 may form a complete CRS entry table for every node in each of the depicted rings. [0284] However, in other distributed networking environments the dynamic nature of the ring and/or delay in the exchange of entry table related stale can hinder construction of a complete entry table. Put another way, in these other environments, there may be one or more rings from a ring's or node's collateral ring set that the node or ring is not aware of at any given lime. For example, referring again to Figure 19A. suppose N[8004J just joined, and prior to that there is no node belonging lo R["4"], most nodes will not have an entry node for R["4"] until message IratTic (e.g. the Ping/Update messages) or other activities cause distribution of that information across the entire ring infrastructure. Thus, maintaining a complete CRS entry table at a node is not always possible due to network dynamism (e.g., node failures, communication failures, communication delays, node additions, etc.}- Accordingly, in many environments a node maintains a partial CRS entry table including entry nodes for less than all of the rings in the node's CRS. [0285) Inter-nroximitv Communication Using CRS Entry Table [0286] A node can use information in a CRS entry table to send inter-proximity communication (e.g.. without having to route a message to a LCAR of the sending ring and the destination ring). Still referring to Pigiire 19A. based on appropriate entries in a CRS entry table, N|13tl| {e.g.. a publisher node) may be able to send inter-proximity communication directly to one or more of R["l 11"], R^l I"], R["21"], R["3r"], R["4r"]. R[''2"), R[''3"], and R["4"]. I'or example, at some point in time a CRS entry table for N[ 1311 ] may include the following entries: R["2"]:N[I112] Rt"3"] : N(8223] R[-71"]:N[I121] R[^'3I"] :N|1131] R["1H"1:N[1I1I1 Rp-2!1"]:NLI2I1]. |0287] These entries can be used for direct communication to R["1U"], R["2ir'], Rni"], Rr31|, R["2'"], and R[-3'^]. For example, N[1311] can send communication 52 to R[-ill"J, N|I311] can send communication 51 to R["2H"], N[]311] can send communication 53 to R|"2t"J (N[l 121] is a member of both R["2r'] and R["22r']), N[1311] can send communication 56 to R|'31"], N(t311] can send communication 57 to R["2"], and N|1311) can send communication 58 to R[--3n- Over time N[-M3H"] may identify entries (e.g., items) for R["41"] and R[''4"]. These entries can be identified from updated local knowledge, from CRS entry tables contained in rendezvous protocol messages (e.g., ping messages, update message, and update responses), through CRS entry table state contained in communication pattern specific messages, and through other mechanisms such as. for example, an application component. [0288] Downward Routing Algorithm [0289] In a rendezvous federation (with or without CRS entry tables), it may be that a message is to be routed to ihe node closest to a given node ID within a specified proximity ring that is not an ancestor to (or in) the leaf ring where the message originated (hereinafter referred to as "downward routing"). One example of this is facilitating inter-proximity communication from a node in an originating ring to a collateral ring when the node in the originating ring is not aware of an entry node for the collateral ring. Figure I9B illustrates another view of the example proximity induced partition tree of rings 1900. For example, referring now to Figure I9H. it may be that N[I3I!] is to send communication destined lo a node in R|"'4"J or Rf"4i"]. (0290] Given a rendezvous federation. Ihe tbikiwing function can be defined: RouteDown(M, P, ID): The federation is to deliver message M to the node closest to ID in the proximity P. Proximity P can be any proximity ring in the federation (leaf or intermediate) that is not an ancestor to (or in) the originating node's leaf ring. [0291] In some embodiments, message M is never routed above nodes within the LCAR of the originating node's leaf ring and the target proximity ring P. For example, to implement downward routing from Nf]3l 11 lo R[''4r'J there may be no need to route a message above RpT'l (the LCAR of Rl"3ir'] and Rp41"]). However, in other embodiments, if appropriate a message can be routed above a LCAR. [0292| The l, where N is some integer, for N[l 311]. Thus, CRS entry table 1904 can include zero or more items, each included item indicating a collateral ring of N|I3111 and one or more corresponding entry-nodes into that collateral ring. For example, as depicted in Figure I9C, CRS entry table 1904 includes the CRS emry indicative of N[865l] being one of the 1 to N entry nodes into RjSlKa coltaicral ring of N| 13II] and R["3ir"])-[0306] Method 2000 includes an act of discovering collateral ring set entry table information from available resources that maintain information related to the configuration of the tree of rings (act 2002). for example. N] 13 1! j can discover collateral ring set entry table informatioti form sources that maintain information related to the configuration of tree of rings 1900. As previously described, various different sources of CRS entry table information may be available to a node. For example, a node may have access to local knowledge, such as, for example local configuration and cache information, may access to CRS related state included in rendezvous protocol messages, such as, for example, ping messages, update messages, and update responses, used to propagate state in a tree of rings, may access CRS related state included in application messages, and may access CRS related state from messages used to facilitate specified communication patterns, such as, for example, broadcasting, multicasting, and any-casting, in a tree of rings. [0307] Thus, in Figure 19C. it may be thai N[13l 1 j accesses local configuration 1921. From local configuration 1921. N[1311 j can discover CRS entry indicative of N[l 111] being at least one of the entry nodes into Rj'M 1 V] (a collateral ring ofN[1311] and R["3ir']|. N[1311j may aLso receive application message 1971. From application message 1971 N| 13111 can discover CRS information 1972. CRS information 1972 may or may not contain CRS state for Kings in N[13I l]'s CRS. N[1311] may also receive communication pattern specific message 1973. From communication pattern specific message 1973 N| 13111 can discover CRS state 1974, CRS state 1974 may or may not contain CRS state for Rings in N[ 1311 j's CRS, [0308| Referring now to figure 19D. N| 1311] can discover and exchange CRS state in rendezvous protocol messages. Since Nj 111 I j is a member of R[" 111"], N[ 1211 ] is a memberofR[''2ir'].and N[I311] is a member of R|--311"], each of the nodes N[l 111], N[I211], N[1311] are also members of R|'"l I"]. As previously described, nodes that are members of a common ring can exchange ping messages, update messages, and update responses to maintain routing table information. Thus, the nodes of R["l 1"] can exchange ping messages, update messages, and update responses to maintain routing table information for R["l!"!- C'RS state can be included in exchanged ping messages, update messages, and update response, as well as other rendezvous protocol and application message traffic between nodes. 10309] For example. N|Ail| {a neighbor of N1I3111 in Rj"H"l) can send ping message 1931, including CRS slate 1932. to N)I3IIJ. from CRS state 1932, N[1311J can discover CRS entry indicative ofN[l 131] being an entry node into RL"31"1 (a collateral ring of Nf 1311J and R|-3I I'"]), CRS entries 1932 can be a complete or partial list of the CRS entries in N[A1 l]"s CRS entry table. N[1311] can also send ping messages including CRS state to its neighbors, for example, N[1311] can send ping message 1945, including CRS .stale 1934. !oN|CI]] (a neighbor of Nfl 311] inRp-|r"]). CRS entries 1934 can includt; a complete or partial list of CRS entries from CRS entry table 1904. |0310| N[131 IJ can also send and receive update messages and update responses that include CRS related information. For example. N|13l 1] can send update message 1933, including CRS entries 1934. to N[D( 11 (a routing partner of N[I3i i] in R["l i"]}. NfDMJ can respond by sending update response 1937. including CRS entries 1938, to N[]331]. CRS entries 1938 can be a complete or partial list of the CRS entries in N[Dl!|'sCRS entry table. Similarly. N| 1311 j can receive update message 1941, including CRS entries 1942, from N[CI 11 (a rouling partner of N| 13111 in Ki-H'"]). CRS entries 1942 can be a complete or partial list of the CRS entries in N|CI H's CRS entry table. N[133!] can respond by sending update response 1943, including CRS entries 1934, to N|"C11"]. [0311| A node can also receive collateral ring set entry table related information from available resources indicating (directh or indirectly) that a CRS entry may no longer be valid, for example, an indication that an entrv node can not be contacted. Any resource used to send CRS relaicd state can also be used to send an indication that can be interpreted to mean that a CRS entry ma\ no longer be valid. Thus, it may be that, from time to time, a node receives CRS related stale that causes one or more CRS entries to be added to its CRS entry tabic as well indications ibat may cause removal of one or more CRS entries that may no longer appropriate. |0312| Method 2000 includes an act of updating the collateral ring set entry table with appropriate collateral ring set entry slaic based on the discovered collateral ring set entry table information (act 2003). Kach appropriate collateral ring set entry state including a collateral ring of the node and at least one corresponding entry node into the collateral ring of the node. For example. N[I3I I] can include any CRS entries received in Figures 19C and 19D into CRS enlr\ table 1904. Ml 13111 can also remove any CRS entries from CRS entry table 1904 that arc indicated (c.j;.. in eontlgiiration. rendezvous protocol messages, applications messages, or communication pattern specific messages) as potentially no longer being appropriate. Accordingly, a node's CRS entry table can be updated to appropriately reflect the changing structure of a rendezvous federation. [0313] Figure 191: illustrates yet another view of the example proximity induced partition tree of rings 1900, Depicted in l-igure 191; is CRS entry Table 1904, which may have been populated, based on CRS siaic exchanged in Figures I9C and 19D. Figure 21 illustrates an example How chart of a method 2100 for sending inter-proximity communication in a tree of rings. "Fhe method 2100 will be described with respect to the nodes, rings, messages, and data in Figure I9F. |0314] Method 2100 includes an act of'deicrmining that a node is to send a message to a collateral ring of the nude (act 2101). 1 or example. N[I3I I] can receive an indication that it is to send a message 1976 to R|'"2"'|, .An indication that a message is to be sent to collateral ring can be received from another node, be implied as a function of routing logic, an application at N|131l]. a multicasting facility, a broadcasting facility, an any-casting facility, etc. [0315] Method 2100 includes an act of the node accessing a collateral ring set entry table configured to store collateral ring set entries for the node (aet 2102). Each collateral ring set entry configured to indicate a collalerat ring of the node and at least one corresponding entry node into the collateral ring of the node. For example, N[1311] can access CRS entry table 1904. Each CRS entry in CRS entry table 1904 can indicate a collateral ringof N(!3I 11 and at least one corresponding entry node into the collateral ring ofN[l31l]. For example, the entry indicates that R[-'lir"] is a collateral ring of N|i3ll| and N| 111! j is one of the at least one entry nodes into R[-Mir']. [0316| Method 2100 includes an act oj'identifying at least one collateral ring set entry for the collateral ring from the node's colliiteral ring set entry table (act 2(03). Each of the at least one collateral ring set entries indicating at least one entry node of the collateral ring. Forexample. N|l3ll]can identify ihe entry for R[-'2"] from CRS entry table 1094. fhe entry indicates that N[I1I2] (and potentially other nodes) is an entry node for R|'"2"J. |0317] Based on the number of corresponding entry nodes included in an identified collateral ring set entry (e.g., when there arc two or more entry nodes), method 2100 may also include an act of resolving from a plurality of entry nodes for a collateral ring to an appropriate subset of entr\ nodes and potentially to a single appropriate entry node. For example, a subset of appropriate entry nodes can be resolved based on closeness between originating and target proximity P, based on node weight can be selected, based on closeness to a destination I!), or can be selected randomly. |0318] Method 2 100 includes an act ol' sending the message to at least one indicated entry node (act 2104). i-'or example, N|13ll| can send message 1976 to N[lil2]. Sending a message to at least one node can include sending a message to all entry nodes in a plurality of nodes, to each entry node in a resolved appropriate subset of entry nodes, or to a single appropriate entry node. In .some embodiments, when a message failure occurs to one entry node, one or more other entrv nodes can be tried. It is also possible for a sending node to identify new nodes as a result of a failure. |03I9| Figure 22 illustrates an example How chart for a method 2200 for sending inter-proximity communication in a tree of rings. The method 2200 will be described with respect to the nodes, rings, messages, and data in Figures 19F and I9G. |0320| The method 2200 includes an act of determining that an originating node intends to route a message to a destination node That is closest to a given node ID in a target proximity ring vvithin a tree of rings (act 2201). The target proximity ring can be a collateral ring of the originating node or a sub-ring of a collateral ring of the originating node. For example. N| 1311 j can receive an indication that it is to route a message 1998 into R["l22l"] (the target proximiij ring) towards the ID 30. An indication that a message is to be sent to collateral ring or a sub-ring of a collateral ring can be received from another node, an application related to N|I3II]. a multicasting facility, a broadcasting facility, an any-casting facility, etc. 10321] Method 22(10 includes an act of idcniifving a one or more entry nodes known to be member nodes of at least one of the largel proximity ring and an ancestor ring of the target proximity ring (act 2202). For example. Nfl311] can identiiy N[4l221j, having node ID 56, as an entry node into R["122l"|. A variety of different mechanisms can be used to identify N|4122ll. N[]311] can refer lo local knowledge to attempt to identiiV an entry node into the proximity target ring. For example, N[1311] can refer to cache and configuration 1902 to attempt to identify an entry node into R["1221"]. 10322] N[1311| can also refer to a CRS entry table to identify entry nodes into ancestor rings of the proximity target ring (e.g.. when an entry node into the target proximity ring is not identified). It may be that sub-ring R["321"] contributes node N[432l] as an entr\ node into R|""2r"|, Likewise, it may be that R["222l"] contributes node N112221] as an entry node into R["22r'|. When an entry node into R[1221] is not identified, N[13] IJ can attempt to ideniil\ an entry node into R["221"], such as, for example, N[12221|. N|I33IJ may also attempt to identify an entry node into R["2I"], such as, for example. N|432ll. [0323] It may be that a node attempts to identify entry nodes in closer ancestor rings before attempting to identify entry nodes in further ancestors from the perspective of a specified target proximitv. when an entry node into the target proximity is not identified. For example, when an entry node into R|"l22r'] is not identified. N[1311] may first attempt to identify an entry node in R|"22r'|, If an entry node into R["221"] is not identified, Nt 1311] may then attempt to identify an entry node in R["2]"]. [0324] N[13l I] can also utilize bootstrapping mechanisms, such as, for example, seed nodes. For example. N|1311| can route an entr\ node lookup request to a known rendezvous point, such as. for example, rendezvous point N[765l|, requesting known (registered) entry nodes (seed nodes being an example). In response to a lookup request, a rendezvous point can return (send) a lookup response message including any known entry nodes. For example, lookup response 1997 can be returned from rendezvous point N[7651] lo N[13ll|. Lookup response 1997 can include locations of any entry nodes registered with rendezvous point N[765l ]. [0325) One or more of these mechanisms may identify N[4221] as an entry node into R|"22r']. |0326| In some embodiments, some entry node identification mechanisms for are utilized before other cntr\ node identification mechanisms. For example, a sending node may refer to local knowledge before attempting to identify entry nodes into ancestor rings of the target ring or routing an entry node lookup request, in these same embodiments, a sending node may also atlempl to identify entry nodes into ancestor rings of the target ring before routing entry node lookup request. I lowcvcr. in other embodiments, entry node identification mechanisms can be utilized in a different order or omitted. |0327| Method 2200 includes an act of sending the message to the identified entry node (act 2203). "fhc message indicating that the entry node is to resolve the message to the node which has a node ID clo.sesi to ihc indicated destination node in the target proximity ring, for example, as indicated by the solid line, N[1311] can send message 1998 to N[4I22I| (an entry node into R|-i22r'| and having Node ID 56) with an indication that the tnessago is to be resolved to node ID 30. N[41221] can access its routing table and/or neighborhood to determine the closest node ID to node ID 30 that it is aware of is N[6122l | having node ID 25. Likewise. N [61221] can access its routing table and/or neighborhood to determine the closest node ID to node ID 30 that it is aware of is N[71221] having node ID 28. N[7I22IJ can refer to its table and/or neighborhood to determine that its node ID. node ID 28. is the closet known node ID to node ID 30 and deliver the message. 10328] Previously described routing algorithms can be also be used to route message 1998 within R["22r-|, [0329] When a message is sent to an identiUcd entry node that is a member of an ancestor ring or the target proximity ring, method 2200 can be recursively applied at the identified entry node. Thai is, the identilied entry node into the ancestor ring can in turn attempt to identify an entry node into the target proximity ring. For example, as indicated by the dotted lines, it inaj' be that an application of method 2200 causes message 1998 to be sent to entry node Nj 12221 ] (an entry node for R["221 "| that is contributed by sub-ring R["2221"]}. N[I2221| (from the perspective of R|"222I"J) can then identify an entry node into R["l22r"j. fhus. a recursive application of method 2200 at N[12221] can cause message 1998 to be sent to N[4122l |. |0330| If an identified entry node in the ancestor ring is not aware of an entry node into the target proximity ring, the identiticd entry node can attempt to identify an entry node into another ancestor ring that is closer to the target proximity. The entry node into the ancestor ring can then forward the message to the entry node of the closer ancestor ring of the target proximity ring. [0331] For example, as indicated by the dashed lines, it may be that an application of method 2200 causes message 1998 to be sent to entry node N[432I] (an entry node for Rni"] that is coniribuicd by sub-ring R|-32r"|). However, N[432l] (from the perspective orR|'"321"|) may be unable lo idenlif) an entry node in R["l22r']. Thus. N[4321) (from the perspective of k|'"32r"|) ma> identify an entry node in R["22r"]. Accordingly, a tlrsi recursive application ot'method 2200 al Nf4321I can cause message 1998 to be sent to N| 122211. A second recursive application of method 2200 atN[1222l] can then cause message 1998 to be sent lo N|4122l ]. [0332] However, if N|4321] did idenlilN an entry node into R["122r'] it could send message 1998 direelly lo the entry node. I bus, an enlry node into an ancestor ring can forward a message to the larget proximity ring or an entry node of a closer ancestor ring of the target proximity ring (which is typicalK in tbc CRS of the forwarding entry node) as appropriate. As described, the entr> node into the closer ancestor ring can then forward the message to the largel proximity ring or \ct a closer ancestor ring of the target proximity ring (which is lypicalK in ihe CRS of the forwarding "yet closer" entry node) as appropriate. This process can repeal (e.g.. through recursively application of method 2200) until the targcl proximity ring enir\ node is reached. [0333] When the largel proximily ring is reached, previously described routing algorithms can be used !o loule ihe Jiies.siige n ithiii the targel proximity ring. [0334] Figure 6 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. Although not required, the invention will be described in the general context of compiiler-execuiabic instructions, such as program modules, being executed by computer systems. Generally, program modules include routines, programs, objects, components, data slructures. and the lilce. which perform particular tasks or implement particular abstract data types. Computer-executable instructions, associated data structures, and program modules represent examples of the program code means for executing acts of (he methods disclosed herein. [0335] With reference lo l-iyure 6. an example system for implementing the invention includes a general-purpose eoinpuiing de\ice in the form of computer system 620, including a processing unii 62 1. a system mcmor_\ 622. and a system bus 623 that couples various system components including ihe s\sicm memor> 622 to the processing unit 621. Processing unit 621 can e\ecule compulcr-t:\eculable instructions designed to implement features ofcompiiler s\slem 620, including Icalures of the present invention. The system bus 623 may be an\ of several types of bus slructures including a memory bus or memory controller, a peripheral bus. and a local bus using any of a variety of bus architectures. The system memor\ includes read only memory ("ROM'') 624 and random access memory ("RAM") 625. A basic input/output system (""HIOS") 626, containing the basic routines that help transfer information between elements within computer system 620. such as during start-up. ma> be stored in ROM 624. [0336] The computer ^yslem 620 may also include magnetic hard disk drive 627 for reading from and writing to magnetic hard disk 6.3'). magnetic disk drive 628 for reading from or writing to removable magnetic disk 629. and optical disk drive 630 for reading from or writing to removable optical disk 63!. such as, or example, a CD-ROM or other optical media. The magnetic hard disk drive 627. magnetic disk drive 628. and optical disk drive 630 are connected to the s\slem bus 623 b\ hard disk drive interface 632, magnetic disk drive-inlerlace 633. and optical drive interface 634, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-executable instructions, data siruciures. program modules, and other data for the computer system 620. Although tlie example environment described herein employs magnetic hard disk 63'>. removable magnetic disk 629 and removable optical disk 631, other types of computer readable media for storing data can be used, including magnetic cassettes, flash memory cards, digital versatile disks. Bernoulli cartridges, RAMs. ROMs, and the like. |0337| Program code means comprising one or more program modules may be stored on hard disk 639. magnetic disk 629. optical disk 631. ROM 624 or RAM 625. including an operating system 635. one or more application programs 636. other program modules 637, and program data 63S, A user ma\ enter commands and information into computer system 620 through keyboard 640. pointing device 642. or other input devices (not shown), such as, for example, a microphone, jo} slick, game pad, scanner, or the like. These and other inpLil devices can be connected to the processing unit 621 through input/output interface 646 coupled to system bus 623. Input/output interface 646 logically represents any of a \\id\: \ar'M\ ofdiClerenl mtcii'accs. such as, for example, a serial port interface, a PS/2 interface, a parallel pon interlace, a Universal Serial Bus ("USB") interface, or an Institute of lilectrical and lilcctronics Engineers ("IKCE") 1394 interface (i.e., a FireWire interface), or may even logically represent a combination of different interfaces. [0338) A monitor 647 or other displa\ device is also connected to system bus 623 via video interface 64S. Spcakcr^ 669 or other audio output device is also connected to system bus 623 via audio interface 649. Other peripheral output devices (not shown), such as, for example, primers. c:in a]so be coDoeeled !o eompulcr system 620. |0339| Computer system 620 is conneetable to networks, such as, for example, an office-wide or enterprise-\\ ide computer network, a home neUvork. an intranet, and/or the Internet, Computer s_\stcm 620 can exchange data with external sources, such as, for example, remote computer sjsiems, remote applications, and/or remote databases over such networks. |0340| Computer svstcm 621) includes network interface 653. through which computer system 620 receives data from external sources and/or transmits data to external sources. As depicted in Figure 6. network interface 653 facilitates the exchange of data with remote computer system 683 via link 65 I, Network interface 653 can logically represent one or more software and/or hardware modules, such as. for example, a network interface card and corresponding Network Driver Interface Speeificiilion {'"NDIS") stack. Link 651 represents a portion of a netv\ork (e,g.. an Ethernet segment), and remote computer system 683 represents a node of the network, |0341| Likewise, computer s\.stem 620 includes input/output interface 646, through which computer system 620 receives data from external sources and/or transmits data to external sources, input/output interface 646 is coupled to modem 654 (e,g„ a standard modem, a cable modem, or digital subscriber line (""DSL") modem) via link 659, through which computer system 620 receives data from and/or transmits data to external sources. As depicted in Figure 6. input/output interface 646 and modem 654 facilitate the exchange of data with remote computer system 693 via link 652, Link 652 represents a portion of a network and remote computer s\stem 693 represents a node of the network, [0342| While figure 6 represents a suitable operating environment for the present invention, the principles of the present invention may be employed in any system that is capable of, with suitable modiikation if necessary, implementing the principles of the present invention, I'he environment illustrated in figure 6 is illustrative only and by no means represents even a small portion of the wide variety of environments in which the principles of the present invention may be implemented. [0343] In accordance with the present invention, nodes, application layers, and other lower layers, as well as associated data, including routing tables and node IDs may be stored and accessed from an\ of the computer-readable media associated with computer system 620, For example, portions of such modules and portions of associated program data may be inchidcd in operatinj^ sysicin 6.>5. application programs 636, program modules 637 and/or projiraiii dala 63S. lor storage in system memory 622. [0344] When a mass slorage device, such as. for example, magnetic hard disk 639, is coupled to computer system 620. such modules aad associated program data may also be stored in the mass storage device. In a networked environment, program modules depicted relative to computer system 620. or portions thereof, can be stored in remote memory storage devices, such as, system memor\ and/or mass storage devices associated with remote computer s\stcm 683 and/or remote computer system 693. Execution of such modules may be performed in a distributed environment as previously described, [0345] The present invention ma\ be embodied in other specific forms without departing from its spirit or essential characteristics. I he described embodiments are to be considered in all respects onK as illustrative and not restrictive. The scope of the invention is, therefore, indicated b\ the appended claims rather than by the foregoing description. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope. i; WE CLAIM: 1. At a computer system a method for sending inter-proximity communication in a tree of rings (1900), the method comprising: 4. The method ;is recited in claim L wherein the act of determining that the node is to send a message to a spccilied coJIaieral ring comprises an act of the node accessing one or more collateral ring/ entry node items. 5. The method as recited in claim 1. wherein the act of identifying at least one collateral ring set entry for the specilicd collateral ring from the node's collaieral ring set entry table comprises an aci of identifying a collateral ring/entry node item that identifies the specified collateral ring and a plurality of entry nodes into the specified collateral ring. 1 6. The method as recited in claim 5 further comprising: an ac of resolving the plurality of entry nodes into an appropriate subset of entry nodes. destination node that is clo;,esi to a given node ID in a target proximity ring tliat is a collateral ringof \Ue sending node. 11. The method as rcciled in claim 9. wherein the act ol'the node accessing an indication that an originating node intends to route a message to a destination node that is closest to a given node ID in a target proximity ring within the tree ofrings comprises an act of the node receiving an indication that a sending node intends to route a message to a destination node that is closest to a given node ID in a target proximity ring that is a sub-ring of a collateral ring oithc sending node. 12. The method as rcciled in claim 9, wherein the act of accessing an indication Ihat an originating node intends to route a message to a destination node ihat is closest to a given node ID in a target proximity ring ihat is collateral ring of the node comprises an act of receiving an indiealion IVom an application related to the node. 13. The method as recited in claim 9, wherein the act of accessing an indication that an originating node intends lo roiUe a message to a destination node that is closest to a given node ID in a target proximity ring that is collateral ring of the node comprises an act of receiving an indication iii another message. 14. The method as recited in claim 13, wherein ihe act of receiving an indication in another message comprises an act of receiving an indication in a message from another node in the tree ofrings. 15. The method as rcciled in claim 9, wherein the act ol'a node accessing an indication that an originating node Inlend:^ to route a message to a dcsllnation node that is closest to a given node ID in a largei pro.^imiiy ring within the irce of rings comprises an act of receiving an iiidieaii.m liini asi origimitiii;; node iiileiids to route a message to a destination node ihat is clo->esi l{) a given node ID in a collateral ring of the originating node. 16. The method as rcciled in claim 4, wherein the act o( a accessing an indication that an originating node intends to route a message lo a destination node that is closest to a given node ID in a targei proximity ring within the tree ofrings comprises an act of receiving an indication thai an originating node intends to route a message to a destination node tliat is closest to a given node 10 in a sub-ring of a collateral ring of the originating node. 17. The method as recited in claim S. wherein the act of a node determining that an originating node intends lo route a message to a destination node that is closest to a given node ID in a target proximity ring within the tree of rings comprises an act of the originating node delermining that the originating node intends to route a message to a destination node that is closest to a given node ID in a target proximit\' ring within the tree of ring. 18. The method as recited in claim 8. wherein the act of identifying one or more entry nodes known lo be member nodes of at least one of the target proximity ring and an ancestor ring of ihc target proximit\ ring comprises an act of referring to local knowledge at the node to idcntit\' an\' nodes in the target proximity ring. 19. The method as recited in claim S. wherein the act of identifying one or more entry nodes known to be member nodes of at least one of the target proximity ring and an ancestor ring of the target proximity ring comprises an act of identifying an entry node that is a member of the target proximity ring. 20. The method as recited in claim 8. wherein the act of identifying one or more entry nodes known to be member nodes of at least one of the target proximity ring and an ancestor ring ol'lhc largct proximity ring comprises an act of identifying an entry node that is a member of an ancestor ring of the target proximin ring. 21. The method as recited in claim 20. wherein the act of identifying an entry node that is a member of an ancestor ring of the target proximity ring comprises an act of identifying an entry node that is a member of an ancestor ring of the target proximity ring that is the closest ancestor ring of the target proximity ring 22. The method as recited in claim 8. wherein the act of identifying one or more entry nodes known to be member nodes oi'at least one of the target proximity ring and an ancestor ring of the target proximity ring comprises: an act of the mode referring to a collateral ring set entry table to identify a node in a sending node's colkileral ring set entry table that is in an ancestor ring of the target prox.imit\ ring; and an act ofscnding the message to the identified node in the ancestor ring. 23. The method as recited in claim 22. I'uriher comprising: an aci of the node in ihc ancestor ring referring to local knowledge to identify any nodes in the target proximity ring. 24. The method as recited in claim 22, further comprising: an act of the node in the ancestor ring referring to a collateral ring set entry table to idcntily a further node in the identiHed node's collateral ring set that is in the closest ancestor ring of the target proximity ring: and an act ofscnding the message to the further node. 25. The melliod as recited in claim 8, wherein the act of identifying one or more entry nodes known to be member nodes of at least one of the target proximity ring and an ancestor ring of the target proximity ring comprises an act of the node utilizing an entry node directoiy mechanism to identify an entry node known to be a member node of the target proximity ring, 26. The ineihod as recited in claim 25. wherein the act of the sending node utilizing an entry node director} mechanism to identify an enir\ node known to be a member node of the target proximit\ ring comprises: an act of routing an entry node Jookup request message to a rendezvous point; and an act of receiving an entry node lookup response corresponding to the lookup request, the entry node lookup response inekiding a plurality of entry nodes, 27. The method as recited in claim 26. wherein the act of receiving an entry node lookup response corresponding to the lookup request comprises an act of receiving an entry node lookup response froni tlic rendezvous point. 28. fhe method as recited in claim 26. wherein the act of receiving an entry node lookup response corresponding lo the lookup request comprises an act of receiving an entry node lookup response thai includes one or more entr\ nodes lliat are registered with an entry node director) mechanism, 29. The method as recited in claim 28. wherein the act of receiving an entry node lookup response that includes one or more entry nodes that arc registered with an entry node dtrectorv mechanism comprises an act of receiving an entry node lookup response that includes one or more enlr> nodes that are registered with the rendezvous point. 30. The method as recited in claim 2S. wherein the act ol" receiving an entry node lookup response that includes one or more entry nodes that are registered with an entry node director)' mechanism comprises an act of receiving an entry node lookup response that includes an enlry node that registered itself with the rendezvous point. 31. The method as recited in claim 28. wherein the act of receiving an entry node lookup response that includes one or more nodes that are registered with an entry node directory mechanism compvii^cs an act of receiving an entry node lookup response that includes an entry node that was registered with the entry node directory mechanism by another party. 32. The method as recited in claim 3!. wherein the act oi" receiving an entry node lookup response that includes an entry node that was registered with the entry node directory mechanism b\' another party comprises an act of receiving an entry node lookup response that includes an entry node that was registered with the entry node directory mechanism by another rendezvous point, 33. The method as recited in claim 26. further comprising: an act of receiving an enlry node registration request tor an entry node; and an act of registering the entry node with the rendezvous point. 34. A computer program product for use at a computer system, the computer program product for implemenling a method for sending inter-proximity communication in a tree of rings {1400). the computer program product comprising one or more computer- readable storage media having stored therein computer-executable instruction that, when executed by a processor, causes a node to perform the following: delcrminc that a node (1311) is to send a message (1903) to a specified collateral ring (21 juf the node (1311): access a collateral ring set entrj table (1904) configured to store collateral ring set entries for the node, each collateral ring set entry configured to indicate a collateral ring (21) of the node (1311) and a corresponding at least one entry node (6521) into the colialeral ring of ihc node (2 I); identif\ al least one collateral ring set entry for the spceilled collateral ring (21) from the node's collateral ring set entry tabic (1904). each ofthe at least one collateral ring sei entries indicating at least one an entr> node (6521) of the specified collateral ring (21): and send the message (1903) to at least one indicated entry node (6521), 35. The compuikir program product as recited in claim 34, wherein the computer-readable storage media comprise system memory. 36. The computer program product as recited in claim 34, wherein the eomputer-readabic storage media comprise a magnetic disk. 37. A computer program product for use at a computer system, the computer program product for implementing a method for sending inter-pro.\imity communication in a tree of rings (I 900). the computer program product comprising one or more computer-readable storage media having stored therein compuier-execulable instruction that, when executed by a processor, causes a node to perform the following: determine thai an originating node intends to route a message (1998) to a destination node that is closest to a given node \D in a target proximity ring (1221) within the tree of rings (1900): identif\ one or more entry nodes (41221) known to be a member node of at least one of'ihe target proximity ring (1221) and an ancestor ring (221) of the target proximity ring (1222 I); and sending the message (1998) to an identified entry node (41221), the message (1998) indicating that the identified entry node (41221) is to resolve the message (1998) to the node which has a node \D closest to an indicated destination node in the target proximity ring (1221). 38. The computer program product as rccilcd in claim 37, wherein the computer-readable slorage media comprise system memory. 39. The computer program product as recited in claim 37, wherein the computer-readable storage media comprise a magnetic disk.