PUBLISH/SUBSCRIBE NETWORKS

Technical Field

The present invention relates to publish/subscribe networks and in particular to a method and apparatus for interconnecting discrete publish/subscribe networks.

Background

The Internet was created primarily as a means for establishing point-to-point connections between hosts: It utilised host-to-host applications such as ftp and telnet. The historical origins of the Internet have resulted in it having a focus on hosts and end points as primary named entities, i.e. hosts are identified by URLs and endpoints are identified by IP addresses (although in many cases a host is also an endpoint). This focus creates a number of well known problems. For example, the current internetworking paradigm provides an open network which is not well suited when some users are selfish and others malicious. There is nothing inherent in the Internet architecture to prevent an attacker flooding an IP address with traffic resulting in the party "owning" that IP address potentially being denied access to the Internet. A further problem is that the Internet does not provide an inherent mechanism for the authentication of data. For example, a user retrieving a web page using an http GET and a published URL has no way of knowing if the retrieved data is authentic.

The Internet has now evolved into a system which is used primarily for data retrieval and service access. Indeed, much of the data accessed over the Internet is static, i.e. it does not change, at least in the short term. Even a dynamic web page is likely to consist of a number of static components that are glued together with a small amount of client- specific (i.e. variable) HTML code. Generalising, it can be argued that, with the possible exception of real-time interactive traffic such as voice calls, the majority of current network traffic is data oriented. The (user) applications making use of the Internet are not interested in creating connections, but rather in transferring well defined pieces of data. Whilst mechanisms such as multicasting and peer-to-peer networks

address some of the specific issues, these do not address the fundamental deficiencies present in the Internet.

A network paradigm known as "publish/subscribe" or "pubsub" is being developed and addresses many of these fundamental deficiencies. The paradigm is based upon identifying data within the pubsub network using a publication identifier which is cryptographically bound to the data. The publication identifier may be for example a hash of a private key owned by the publisher of the data. The publisher then attaches to the data a signature taken over the data using the associated private key and publishes the data on the network. The data may be held at a number of different locations. In order to retrieve data, a user sends a Subscribe message containing the publication identifier and his own location, to a local router. The router uses some rendezvous system to locate a copy of the data (typically the closest copy) and routes the Subscribe message to that location. Within an autonomous system, e.g. a network owned by a single operator, the rendezvous system may comprise a single rendezvous server that maintains a mapping between publication identities and data locations. A copy of the data with signature and public key is delivered to the requesting user via some optimised route. The user does not necessarily know or care from which location the data is retrieved. Moreover, the pubsub network does not require a separate DNS lookup to be performed in order to resolve a URL into an IP address. Rather, the Subscribe message acts both as source locator and data request.

Within a pubsub network, routers will only deliver data in the event that a Subscribe message has been received from a destination. Flooding attacks which result in a denial of service are thereby effectively prevented.

It is likely that in the short to medium term pubsub networks will be established as standalone networks, i.e. "islands", which use gateways to connect to the Internet. It can be envisaged that a user attached to one pubsub island will want to retrieve data from another pubsub island via the Internet (or possibly another IP network). In this case, the user might send a Subscribe message to a local router and which contains a publication identity for the data. Assuming that the router is appropriately configured, it

may recognise that the publication identity is not a local identity, and will forward it to the Internet gateway. The present DNS system does not however provide any means to perform a reverse mapping between a publication identity and an IP address of a remote node, in this case a location at which the requested data is held.

Summary

It is an object of the present invention to address the above noted problem. This is achieved by connecting the local rendezvous systems of the pubsub networks together using a rendezvous system based within an IP network, e.g. the Internet.

According to a first aspect of the present invention there is provided apparatus for use within a communication network, where the network comprises a local rendezvous system in which data is published using a publication identifier and which is used by local hosts to retrieve published data. The apparatus is configured to be coupled in use to an IP network and is further configured to receive from a local host a Subscribe request relating to the publication identifier, send a further Subscribe request relating to said publication identifier, to a Dissemination Handler of a rendezvous system residing within the IP network, receive over said IP network data published with said publication identifier, and route the received data to said local host.

In a preferred embodiment of the invention, the apparatus is configured to establish a TCP session with a peer node following sending of said further Subscribe request, said data being received within said session. The peer node may be a peer gateway node or an IP network host. In either case, the apparatus treats said Subscribe request as a TCP SYN message.

The invention may be employed to allow a pubsub network to subscribe to an IP multicast. In this case, the apparatus is configured to receive from the rendezvous system residing within the IP network a response to said Subscribe request, the response containing an IP multicast group address, and to send a multicast Join request to said group address.

According to a second aspect of the present invention there is provided apparatus for use within a communication network, where the network comprises a local network having a local rendezvous system in which data is published using a publication identifier and which is used by local hosts to retrieve published data. The apparatus is configured to be coupled in use to an IP network and being further configured to receive from a local host within the local network a Publish request relating to a publication identifier, send a further Publish request relating to said publication identifier, to a Dissemination Handler of a rendezvous system residing within the IP network, receive from said rendezvous system a Subscribe request relating to said publication identifier, and deliver over said IP network to a subscribing host, data published with said publication identifier.

According to a third aspect of the present invention there is provided a method of making data, published on a first publication/subscribe network, available to hosts within a second publication/subscribe network where the networks are interconnected via an IP network. The method comprises registering a publication identity of said data within a rendezvous system located within said IP network, forwarding Subscribe requests associated with said publication identity from said second network to said rendezvous system, at the rendezvous system, identifying a location of said data within said first network and forwarding the Subscribe request to said first network, and delivering said data from said first network to said second network via the IP network.

According to a fourth aspect of the present invention there is provided a method of making data, published on a first publication/subscribe network, available to hosts within a second publication/subscribe network where the networks are interconnected via an IP network. The method comprises registering a publication identity of said data and a corresponding multicast group address within a rendezvous system located within said IP network, forwarding Subscribe requests associated with said publication identity from said second network to said rendezvous system, at the rendezvous system, identifying the multicast group address and returning this to the second network, and sending a multicast Join request from said second network to said group address.

Brief Description of the Drawings

Figure 1 illustrates schematically a DONA architecture; Figure 2 illustrates schematically the use of a DONA architecture to interconnect a pair of pubsub networks;

Figure 3 shows a signalling flow associated with the publication of data from a pubsub network on a DONA system, and a subsequent subscription to that data;

Figure 4 shows a signalling flow associated with the publication of data from an Internet host on a DONA system, and a subsequent subscription to that data;

Figure 5 illustrates schematically a gateway node of a pubsub network and embodying the present invention;

Figure 6 is a flow diagram illustrating a process for publishing data in the system of

Figure 2; Figure 7 is a flow diagram illustrating a process for subscribing to published data in the system of Figure 2; and

Figure 8 shows a signalling flow associated with the publication of data by way of a multicast from a pubsub network on a DONA system, and a subsequent subscription to that multicast data.

Detailed Description

As described above, a pubsub network will use publication identities in order to identify and locate data published on the network. A rendezvous system within the network will route Subscribe messages from a subscriber to the published data. In order to allow isolated pubsub networks to be linked together in an efficient manner via the Internet, a further rendezvous system should be provided within the Internet.

It is proposed here to make use of a rendezvous system overlaid on the existing Internet and which identifies data using "flat name" identities, that is identities which do not have a hierarchical structure, e.g. "username.company.com". Flat names are desirable as they do not have a strict coupling with network topology and thus an attacker cannot

use them to deduce details of topology (or to send unwanted traffic to a chosen point in a topology). This decoupling between topology and naming also simplifies multi- homing and mobility. Flat names also make it possible to cache data in multiple locations and to retrieve it from an optimal location (i.e. the closest). Furthermore, it is proposed here to make use of a rendezvous system which implements location identification and data retrieval initiation essentially in a single step.

In order to address many of the shortcomings of the conventional Internet, a clean-slate redesign known as Data Oriented Network Architecture (DONA) has been proposed: "A Data-Oriented (and Beyond) Network Architecture", Koponen, T. et al, I. Proceedings of the Sigcomm 2007, pages 181-192, ACM Press New York, NY, USA. DONA aim to provide persistence, availability, and authenticity to data allowing the data to be cached and moved without affecting its reachability. The naming system proposed by DONA provides names that are self- certifying and of the form P:L, where P is a cryptographic hash of the principal's (publisher's) public key, and L is a string chosen by the principal.

The DONA architecture is illustrated schematically in Figure 1 and consists of Dissemination Handlers (DH), sometimes referred to as Resolution Handlers. Typically one, although possibly more, DH will be located within each autonomous system (AS). It is envisaged that the layers of the DH hierarchy will be mapped to tiers of the Internet service provision business model. Tier 1 DHs will be located within the networks of those global service providers that do not buy transit from other networks. Tier 2 DHs will be located within the networks of service providers that both peer with other networks and buy transit from tier 1 ASs. Tier 3 DHs will be located within the networks of service providers that do not peer with other networks, and only buy transit from tier 1 or tier 2 ASs. The mapping of the DH architecture to the business model ensures that higher tier networks have a supplier/customer relationship with the networks below them and whose DHs require the services of the higher tier DHs.

The DHs support two primitives: FIND(P:L) and REGISTER (P:L). When a DH receives a REGISTER(P:L) from a client, i.e. the publisher, it puts the publication

identity and the location information (e.g. an IP address) in its cache and forwards the request to a higher layer DH and peer DHs. Thus, the DH of a tier 1 AS will have location information for all registered publications. When a client, that is the subscriber, sends a FIND(P :L) request to a local DH, that DH either determines the location of the nearest copy of the publication in its registration table and forwards the request to that location, or forwards the request to a higher tier DH which repeats the process.

DHs may act as local caches for published data in addition to handling routing of Subscribe requests. Thus, a DH receiving a Subscribe request may first check its local cache to determine whether or not the requested data is held in the cache. If so, the data is provided directly from the cache and there is no need to forward the request further.

As has already been discussed, when a publisher publishes data in a pubsub network, availability information concerning that data is created within a local rendezvous system. In order to cope efficiently with a transition phase during which both pubsub networks and the Internet coexist, it is proposed here to use DONA as a rendezvous mechanism for interconnecting pubsub network islands using the Internet as the routing and forwarding mechanism. A gateway node (GW) in the pubsub network is responsible for translating the pubsub publication identity into a form used in the DONA system, i.e. P:L. The gateway node effectively operates as a DONA DH, publishing data in the DONA system and providing its own IP address as the actual location of the data. The composite architecture is illustrated schematically in Figure 2.

Consider the case where a user (of the pubsub network) Host A 1 subscribes to a data item and it is not found from the rendezvous system of the local pubsub network 2. The request is therefore routed via the gateway node 3 of that pubsub network into the DONA system 4 which is located within the Internet 5. The DONA system in turn identifies the publication and the IP address of the gateway node 6 of the pubsub network 7 within which the published data is located. The DONA system forwards the Subscribe message to that gateway node 6, including in the message the IP address of the gateway node 3 associated with the requesting user 1. The publishing side gateway

node 6 can then deliver the requested data over the Internet 5 to the subscribing side gateway node 3 using the existing IP routing system.

Transmission over the Internet between gateway nodes may be protected and the gateway nodes may authenticate each other using some appropriate mechanism. For example, the gateway nodes may use the Host Identity Protocol (HIP) in order to establish security associations between themselves.

Figure 3 illustrates an exemplary signalling flow within the composite architecture of Figure 2. The following steps can be identified:

1. Host B publishes data with a publication identifier SubID. A route to the data is stored into the local Rendezvous system from where it is available directly to other local pubsub hosts. This route could be Ethernet or MAC address, plus Ethernet routing. 2. Gateway B then maps the publication identifier SubID to a DONA name P:L, where P is a cryptographic hash of a public key of the gateway and L is a unique identifier allocated to the published data by Gateway B. Gateway B publishes the data information in the DONA system as if it were itself a DH, giving its IP address as the location for the data, i.e. it publishes the mapping P:L to IP address.

3. The DONA system stores the published mapping. This involves disseminating the mapping amongst the DHs.

4. Host A subscribes to data with identity SubID

5. Gateway A determines that this data is not available at the local network (this determination may require a query to the local rendezvous system) and therefore sends a query to the DONA system.

6. While it awaits a response from the publisher, Gateway A contacts the routing function within the local pubsub network in order to build a forwarding path from itself to the subscriber Host A. 7. The local routing function creates the path and configures the forwarding tables within routers in the path. NOTE: Steps 6 and 7 may occur later in the process, for example if Gateway A

wants to be sure that the data will be delivered, prior to establishing the local routing path.

8. The DONA system performs a lookup in its rendezvous system (see for example Figure 1) and determines that the publication is not available in the DONA system (i.e. it has not been cached previously at one of the DHs) but that it can be ordered from Gateway B.

9. The DONA system sends a Subscription to Gateway B ("ProxyB"), identifying the subscribing host Gateway A by including Gateway A's IP address ("Proxy A") in the packet header. The Subscribe request may be considered by Gateway B to be a TCP SYN.

10. Assuming that the data is not cached at Gateway B, the data needs to be subscribed from the local pubsub network. This step involves requesting the data from Host B (or other node, e.g. a network server) and building the forwarding path between Host B and Gateway B. 11. The data is forwarded between Gateway B and Gateway A using standard IP forwarding mechanisms. In the case of TCP, Gateway B replies (to the TCP SYN) by sending a TCP SYN+ ACK to the IP address of Gateway A. 12. The data received at Gateway A is forwarded using the forwarding path configured at step 7.

The approach described above can be adapted in order to allow data to be retrieved by a pubsub network host from an Internet host (for example the host 9 in Figure 2) that uses DONA to publish its data. When the Internet host 9 publishes its data, a DONA identifier (P:L) for the data is inserted in the DONA system as described earlier, i.e. steps 2 and 3 above. When a pubsub gateway requests the published data (steps 5 to 6 above), the request is routed to the closest location of the data (which may be a DH if the data has been cached there, or the publishing host). This request packet is considered by the destination to be a TCP SYN packet. The rest of the TCP communication setup (server SYN-ACK and client ACK) is carried out directly between the data location and the gateway node. Finally, the data is transmitted over the TCP connection to the gateway node. After the gateway node has received the data, it converts it into the publication format (e.g. by replacing the IP headers with pubsub

headers) that is used in the pubsub network and publishes it locally so that is available for the subscribing host (in practice this may means sending the data to the host over the pubsub network).

Figure 4 illustrates a signalling flow for the case where the data publisher is an Internet host. The flow is similar to that illustrated in Figure 3, except that the publish and subscribe requests are exchanged directly between the DONA system and the Internet host and no gateway (i.e. Gateway B) is involved.

Figure 5 illustrates schematically a gateway node 10 for use in the system described above. The node comprises a first interface 11 for connecting the gateway to the pubsub network and a second interface 12 for connecting the gateway node to the Internet. A processor 13 is responsible for forwarding Subscribe request received from the pubsub network to the DONA system and for establishing TCP connections with peer gateways. The processor also handles incoming Subscribe requests from peer gateways.

The flow diagram of Figure 6 illustrates the processes of publishing data on the DONA system. At step 100, Gateway B receives a Publish (SubID) request from local Host B and at step 101 sends the request to a DH of the DONA system. At step 102 the DONA system distributes the publication location across the DH hierarchy.

The flow diagram of Figure 7 illustrates the processes of retrieving data via the DONA system. At step 200, Gateway A receives a Subscribe (SubID) message from Host A and at step 201 forwards the message to a DH of the DONA system. Gateway A then builds the local forwarding path. At step 202, the DONA system locates the data using SubID and forwards the Subscribe request to Gateway B. At step 203, Gateway B retrieves the published data from Host B and forwards the data to Gateway A over the Internet.

The DONA system may be used by pubsub networks to publish data by way of an IP multicast, and to subscribe to such multicasts. A signalling flow associated with this

scenario is shown in Figure 8. The flow is generally in line with that illustrated in Figure 3, except that at step 2 Gateway A publishes the data location by way of the source address S (i.e. IP address at which the data is located) and a group address G conforming to the multicast standard. When the DONA system subsequently receives a Subscribe request addressed to SubID and which maps to the multicast address (S, G), the DONA system responds to Gateway A with the group address. At step 10 Gateway A sends a standard multicast JOIN request to the group address. This request is routed to Gateway A, allowing the multicast path to be built.

It will be appreciated by the person of skill in the art that various modifications may be made to the above described embodiments without departing from the scope of the present invention.