WO2022178762A1

WO2022178762A1 - Ad-hoc multicast delivery of unicast services

Info

Publication number: WO2022178762A1
Application number: PCT/CN2021/077897
Authority: WO
Inventors: Dirk Trossen; Rui Meng
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-02-25
Filing date: 2021-02-25
Publication date: 2022-09-01

Abstract

A device (10) for ad-hoc multicast delivery of a unicast service is provided. The device (10) comprises a processor (101) configured to forward respective requests (7, 7', 7" ) of a plurality of clients (3) for the unicast service to a server (4) of the service, and return a response associated with the requested unicast service to the plurality of requesting clients (3) by: receiving the response provided by the server (4) in accordance with a first ad-hoc multicast delivery scheme, and providing the received response to the plurality of clients (3) in accordance with a second multicast delivery scheme. This enables multicast responses for statistically concurrent, yet asynchronous requests from a plurality of clients for a unicast service provided by a server.

Description

AD-HOC MULTICAST DELIVERY OF UNICAST SERVICES

TECHNICAL FIELD

The present disclosure relates to network communications, and in particular to enabling multicast responses for statistically concurrent, yet asynchronous, requests from a plurality of clients to a server. The present disclosure provides, to this end, a device, a method and a computer program for ad-hoc multicast delivery of a unicast service.

BACKGROUND

Multicast is an important communication mode for many computational tasks. It comes in the form of 1: N, N: 1, or M: N relations, which can be stable (e.g., for video conferences) or instantaneous (e.g., for computational scenarios) at the level of each request.

IP multicast routing accommodates scenarios with a relatively stable relationship, due to reliance on spanning trees. Overlay solutions can be used, but lead to network inefficiencies, e.g., due to reliance on unicast packet forwarding.

Recognition of the importance of multicast has led to new network/routing level solutions that enable different forms of multicast delivery in the network.

Semantic routing uses, e.g., IPv6 extension headers for carrying service information in IP packets, and enables the routing of packets to servers identified by computational information rather than locators only, e.g., foo. com. Such requests can lead to a response to one or more clients, i.e., service invocation in semantic routing can be seen as a computational invocation, therefore requiring a multicast routing solution. However, semantic routing per se lacks multicast delivery of a response to more than one client.

Layer 2 path-based forwarding is realized by describing a path from a server to a client in the network, which is identified through a bit field, wherein a bit position indicates the forwarding over a specific link in the network. Bit positions may be assigned during network configuration. Forwarding in a specific switch is realized by said switch checking all bit positions of those links it is connected to in outward direction, which merely requires binary AND/CMP operations. This solution works on top of a Software-Defined Network (SDN) or Bit Indexed Explicit Replication (BIER) network, but requires centralized path computation or alternatively distributed path knowledge, and entails security issues with respect to the path identification bit field.

Information-centric networking (ICN) provides multicast as mode of communication for retrieving content/information from one source to more than one sink. The approach suffers from scalability issues due to extensive forwarding state and latency issues owing to centralized path computation.

Source-based spanning tree approaches include spanning tree information into packet for network traversal. The approaches are associated with processing overhead due to parsing and modification of the spanning tree information within the packet, and high complexity as rooting the spanning tree at the source requires recursive sub-tree determination.

SUMMARY

In view of the above-mentioned problems and disadvantages, it is an objective to enable multicast responses for statistically concurrent, yet asynchronous, requests from a plurality of clients for a unicast service provided by a server.

This and other objectives are achieved by the embodiments as defined by the appended independent claims. Further embodiments are set forth in the dependent claims and in the following description and drawings.

A first aspect of the present disclosure provides a device for ad-hoc multicast delivery of a unicast service. The device comprises a processor configured to forward respective requests of a plurality of clients for the unicast service to a server of the service, and return a response associated with the requested unicast service to the plurality of requesting clients by: receiving the response provided by the server in accordance with a first ad-hoc multicast delivery scheme, and providing the received response to the plurality of clients in accordance with a second multicast delivery scheme.

The device of the first aspect enables a delivery of service responses to more than one client/requestee, wherein the requests incoming at the server providing the service are of asynchronous, yet statistically concurrent, nature. That means, the requests arrive within a certain time window, but are not coordinated beyond the statistical possibility of being sent at the same time as one or more other request for the same service.

An idea of this disclosure is to split the network between the server and the clients into consecutive subnetworks associated with respective ad-hoc multicast delivery schemes. This allows for a mixture of forwarding operations used for the return path, including path-based forwarding using bit fields, tree-based forwarding using bit fields, and pending request forwarding using ephemeral (i.e., short-lived) table entries. As an example, if a complexity of a multicast delivery scheme increases more than linearly (e>1) as N ^e, where N represents the number of network nodes, a complexity effectively reduces to 2 × (N/2) ^e when splitting the network into halves. Further, splitting reverse path forwarding removes a need for centralized path computation, which in turn reduces complexity and removes any latency for sending an initial request packet to a semantic address.

In an implementation form of the first aspect, the processor may be further configured to forward the respective requests based on semantic unicast routing.

In an implementation form of the first aspect, each of the respective requests may comprise a same semantic identifier indicative of the server, and a same request identifier indicative of the requested unicast service. The received response may further comprise the same semantic identifier, and the same request identifier.

In an implementation form of the first aspect, the first ad-hoc multicast delivery scheme may comprise path-based forwarding. The processor may further be configured to set a bit position in a path identifier of the respective request in dependence of a network link traversed by the respective request towards the server, and insert the path identifier into the respective request. The received response may further comprise a path identifier comprising a binary OR-combination of the path identifiers of the plurality of requests. In an implementation form of the first aspect, the processor may further be configured to remove the path identifier from the received response.

In an implementation form of the first aspect, the first ad-hoc multicast delivery scheme may comprise tree-based forwarding. The processor may further be configured to insert a first multicast request identifier indicative of the device as a leaf of the first ad-hoc multicast delivery scheme into the respective request. The received response may further comprise a multicast sub-tree comprising the device as a leaf. The processor may further be configured to remove the multicast sub-tree from the received response.

In an implementation form of the first aspect, the second ad-hoc multicast delivery scheme may comprise tree-based forwarding. Each of the respective requests may further comprise a second multicast request identifier indicative of a leaf of the second ad-hoc multicast delivery scheme. The processor may further be configured to maintain a multicast sub-tree associated with the semantic identifier and the request identifier and comprising the leaf.

In an implementation form of the first aspect, the processor may further be configured to compute the multicast sub-tree in response to the forwarding the respective request or in response to the receiving the response provided by the server.

In an implementation form of the first aspect, the processor may further be configured to insert the maintained multicast sub-tree associated with the semantic identifier and the request identifier of the received response, into the response; submit the response to a network link in accordance with the inserted multicast sub-tree; and delete the maintained multicast sub-tree.

In an implementation form of the first aspect, the second multicast delivery scheme may comprise pending request forwarding. The processor may further be configured to associate a network link traversed by the respective request towards the device with the semantic identifier and the request identifier of the respective request; submit the response to a network link associated with the semantic identifier and the request identifier of the received response; and delete the association of the network link with the semantic identifier and the request identifier of the received response.

A second aspect of the present disclosure provides a method of ad-hoc multicast delivery of a unicast service. The method comprises forwarding respective requests of a plurality of clients for the unicast service to a server of the service, and returning a response associated with the requested unicast service to the plurality of requesting clients by: receiving the response provided by the server in accordance with a first ad-hoc multicast delivery scheme, and providing the received response to the plurality of clients in accordance with a second multicast delivery scheme.

The method may be performed by a device of the first aspect or any of the above-described implementation forms of the first aspect.

In an implementation form of the second aspect, the method may further comprise forwarding the respective requests based on semantic unicast routing.

In an implementation form of the second aspect, each of the respective requests may comprise a same semantic identifier indicative of the server, and a same request identifier indicative of the requested unicast service. The received response may further comprise the same semantic identifier, and the same request identifier.

In an implementation form of the second aspect, the first ad-hoc multicast delivery scheme may comprise path-based forwarding. The method may further comprise setting a bit position in a path identifier of the respective request in dependence of a network link traversed by the respective request towards the server, and insert the path identifier into the respective request. The received response may further comprise a path identifier comprising a binary OR-combination of the path identifiers of the plurality of requests. In

In an implementation form of the second aspect, the method may further comprise removing the path identifier from the received response.

In an implementation form of the second aspect, the first ad-hoc multicast delivery scheme may comprise tree-based forwarding. The method may further comprise inserting a first multicast request identifier indicative of the device as a leaf of the first ad-hoc multicast delivery scheme into the respective request. The received response may further comprise a multicast sub-tree comprising the device as a leaf. The method may further comprise removing the multicast sub-tree from the received response.

In an implementation form of the second aspect, the second ad-hoc multicast delivery scheme may comprise tree-based forwarding. Each of the respective requests may further comprise a second multicast request identifier indicative of a leaf of the second ad-hoc multicast delivery scheme. The method may further comprise maintaining a multicast sub-tree associated with the semantic identifier and the request identifier and comprising the leaf.

In an implementation form of the second aspect, the method may further comprise computing the multicast sub-tree in response to the forwarding the respective request or in response to the receiving the response provided by the server.

In an implementation form of the second aspect, the method may further comprise inserting the maintained multicast sub-tree associated with the semantic identifier and the request identifier of the received response, into the response; submit the response to a network link in accordance with the inserted multicast sub-tree; and delete the maintained multicast sub-tree.

In an implementation form of the second aspect, the second multicast delivery scheme may comprise pending request forwarding. The method may further comprise associating a network link traversed by the respective request towards the device with the semantic identifier and the request identifier of the respective request; submit the response to a network link associated with the semantic identifier and the request identifier of the received response; and delete the association of the network link with the semantic identifier and the request identifier of the received response.

A third aspect of the present disclosure provides a computer program comprising executable instructions which, when executed by a processor –for instance of a device of the first aspect or any of its implementation forms –cause the processor to perform a method of the second aspect or any of its implementation forms.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above described aspects will be explained in the following description of various embodiments in relation to the enclosed drawings, in which

FIG. 1 illustrates an exemplary network involving devices for ad-hoc multicast delivery of a unicast service;

FIG. 2 illustrates exemplary requests in accordance with various multicast delivery schemes;

FIG. 3 illustrates a flowchart associated with an example of an embodiment of the present disclosure;

FIG. 4 illustrates a flowchart associated with another example of an embodiment of the present disclosure; and

FIG. 5 illustrates a flowchart associated with a further example of an embodiment of the present disclosure.

DETAILED DESCRIPTION OF EMBODIMENTS

The above described aspects will now be described with respect to various embodiments illustrated in the enclosed drawings.

The features of these embodiments may be combined with each other unless specified otherwise.

The drawings are to be regarded as being schematic representations and elements illustrated in the drawings are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose become apparent to a person skilled in the art.

FIG. 1 illustrates an exemplary network 1 involving devices 10 for ad-hoc multicast delivery of a unicast service.

The exemplary network 1 comprises a first network 1” to the right of FIG. 1 and a second network 1’ to the left of FIG. 1. The networks 1’, 1” may form an overlap, in which the aforementioned devices 10 may be arranged.

Ad-hoc multicast delivery as used herein may relate to a multicast delivery scheme, wherein a multicast transmission may be formed on an opportunistic basis, if circumstances warrant.

The first network 1” may include a plurality of routing devices 5 interconnected by a plurality of network links 6”. Likewise, the second network 1’ may include further routing devices 5 interconnected by further network links 6’.

Accordingly, the first network 1” may be configured to provide network connectivity between a server 4 of the service and the devices 10, and the second network 1’ may be arranged to provide network connectivity between the devices 10 and a plurality of clients 3 of the service.

Each of the devices 10 comprises a processor 101. The processor 101 is configured to forward

respective requests

7, 7’, 7” of a plurality of clients 3 for the unicast service to the server 4.

In particular, the processor 101 of the respective device 10 may be configured to forward the

respective requests

7, 7’, 7” based on semantic unicast routing.

Assuming that the routing devices 5 are also configured to perform semantic unicast routing, this means that semantic unicast routing may be used for end-to-end forwarding each

request

7, 7’, 7” of the plurality of clients 3 for the unicast service to the server 4.

As will be explained in more detail in connection with the various embodiments illustrated in FIG. 3 –5, the processor 101 is further configured to return a response associated with the requested unicast service to the plurality of requesting clients 3. The returning includes receiving the response provided by the server 4 in accordance with a first ad-hoc multicast delivery scheme, and providing the received response to the plurality of clients 3 in accordance with a second multicast delivery scheme.

That is to say, the first network 1” may be associated with the first ad-hoc multicast delivery scheme, the second network 1’ may be associated with the second multicast delivery scheme, and the devices 10 may be communication peers of both networks 1’, 1”, so that they are capable of relaying

requests

7, 7’, 7” and corresponding responses between the first and second ad-hoc multicast delivery schemes.

FIG. 2 illustrates

exemplary requests

7, 7’, 7” in accordance with various multicast delivery schemes.

Each of the exemplary

respective requests

7, 7’, 7” shown in the FIGs. 2 (a) –2 (c) comprises a same semantic identifier 70, SID indicative of the server 4, and a same request identifier 71, RID indicative of the requested unicast service. The response (s) received in response to the

respective request

7, 7’, 7” comprises the same semantic identifier 70, SID, and the same request identifier 71, RID.

The semantic identifier 70, SID may identify a computational process (e.g., of the server 4) , to which the request is routed, and the request identifier 71, RID may identify the requested computational request/service. The request identifier 71, RID may indicate possible multipoint communication and is thus included only if the requested unicast service may benefit from multicast. Thus, if a client does not specify a request identifier 71, RID (or sets RID=0) , normal unicast return routing applies.

The exemplary request 7’s hown in FIG. 2 (b) further includes a path identifier 72, pathID, which has a significance in conjunction with an ad-hoc multicast delivery scheme known as path-based forwarding, which is going to be addressed in connection with FIG. 3 below.

The exemplary request 7” shown in FIG. 2 (c) includes a multicast request identifier 73, mcrID, which has a significance in conjunction with an ad-hoc multicast delivery scheme known as tree-based forwarding, which is going to be discussed in connection with FIGs. 4 and 5 below.

The suggested header fields, namely the semantic identifier 70, SID, the request identifier 71, RID, the path identifier 72, pathID as well as the multicast request identifier 73, mcrID, may be embedded into a network-level packet header, such as an IPv6 header or an IPv6 extension header, for example.

FIG. 3 –5 illustrate flowcharts associated with examples of an embodiment of the present disclosure.

In particular, FIG. 3 –5 visualize methods 2 of ad-hoc multicast delivery of a unicast service, which the devices 10 illustrated in FIG. 1 are configured to execute, according to an embodiment of the present disclosure.

FIG. 3 –5 have in common that to their left, the method 2 comprises steps 201-203 of forwarding

respective requests

7, 7’, 7” of a plurality of clients 3 for the unicast service to a server 4 of the service, and to their right, the method 2 comprises steps 204-206 of returning a response associated with the requested unicast service to the plurality of requesting clients 3.

The forwarding steps 201-203 comprise a step 201 of receiving the

respective request

7, 7’, 7” of the plurality of clients 3 for the desired service on an incoming network link 6’, the

respective request

7, 7’, 7” comprising a semantic identifier 70, SID used to identify the server 4, i.e., a computational process which provides the service, and a request identifier 71, RID indicative of the requested unicast service. Then, the forwarding steps 201-203 comprise a step 202 of processing the

respective request

7, 7’, 7”, and a subsequent step 203 of forwarding the

respective request

7, 7’, 7” for the unicast service to the server 4 in accordance with the applicable unicast scheme, such as semantic unicast routing.

In other words, semantic routing may be used for forward routing, i.e., sending a request to the semantic identifier 70, SID, in a unicast manner. Using the semantic identifier 70, SID to identify the server 4, i.e., computational process, may keep routing tables smaller by focusing on, e.g., SID=foo. com rather than a full request identifier, e.g., foo. com/service1/? query=name. Forward routing may further be utilized to ‘collect’ information on return forwarding, as will be explained in connection with the processing step 202.

The returning steps 204-206 comprise a step 204 of receiving the response provided by the server 4 in response to the

previous request

7, 7’, 7” in accordance with a first ad-hoc multicast delivery scheme, the response comprising the same semantic identifier 70, SID, and the same request identifier 71, RID as the underlying request (s) 7, 7’, 7”. Then, the returning steps 204-206 comprise a step 205 of processing the response, and thereafter a step 206 of providing the received response to the plurality of clients 3 in accordance with the second multicast delivery scheme.

FIG. 3 –5 differ from one another in terms of how the

respective processing steps

202, 205 are implemented in the various embodiments. This will be explained in more detail in connection with the respective figures below.

FIG. 3 illustrates a flowchart associated with an example of an embodiment of the present disclosure.

According to this example, the first ad-hoc multicast delivery scheme employed in the first network 1” may comprise path-based forwarding, and the second ad-hoc multicast delivery scheme employed in the second network 1’ may comprise pending request forwarding (hop-by-hop forwarding) .

Path-based forwarding as used herein may relate to describing a path from a server to a client in the network through a bit field where a bit position indicates the forwarding over a specific network link. Alternatively, or for each routing device not having all network links associated with a bit position in the bit field, network links may be assigned sub-tree masks for multicast delivery.

Path-based forwarding has no multicast-related and flow-related state. Path-based forwarding enables multicasting by allowing for combining unicast forwarding paths of requests to a same service into a single binary multicast tree. This keeps a complexity of return forwarding simple (merely requires AND/CMP over all outgoing links in each device 10, no packet modification) and harnesses multicast gain.

In addition, pending request forwarding may serve as a fallback for incoming network links 6’ not being associated with path-based forwarding. Thus, hop-by-hop forwarding may be used for those network areas without path-based forwarding. This keeps a complexity of return forwarding simple since a number of aggregated pending requests is likely much lower than in a core of the network 1 (i.e., in the first network 1” ) .

Initially, the illustrated method 2 comprises a step 201 of receiving the respective incoming request 7 for the unicast service on an incoming network link 6’ (or corresponding network interface) .

With reference to FIG. 3, the processing step 202 may comprise a step 202a of querying a SID routing table 102 of the device 10 for a number of outgoing network links 6” in dependence of the semantic identifier 70, SID comprised in the incoming request 7. Further, the processing step 202 may comprise a step 202b of establishing if the incoming request 7 comprises a non-zero request identifier 71, RID, and if not, proceeding to step 203. Further, the processing step 202 may comprise a step 202c of establishing if the queried outgoing network links 6” are associated with path-based forwarding, and if not, proceeding to 202e.

The processing step 202 may then comprise a step 202d of setting bit position (s) in a path identifier 72, pathID of an outgoing request 7’ in dependence of the queried outgoing network link (s) 6” traversed by the outgoing request 7’ towards the server 4, and inserting the path identifier 72, pathID into the outgoing request 7’. Further, the processing step 202 may comprise a step 202e of establishing if the incoming network link 6’ is associated with path-based forwarding, and if so, proceeding to 203. Finally, the processing step 202 may comprise a step 202f of associating the incoming network link 6’ (or corresponding network interface) traversed by the incoming request 7 towards the device 10 with the semantic identifier 70, SID and the request identifier 71, RID of the incoming request 7, and storing the

triplet

6’, 70, 71 in a pending request table 103 of the device 10.

In other words, when sending the outgoing request 7’ over a network link 6” with an assigned bit position, the bit position may be binary OR-ed into the path identifier 72, pathID. When receiving an incoming request 7 over a network link 6’ with no assigned bit position, a pending request entry may be maintained, pointing to the incoming interface. It should be verified that pathID=0 to prevent malicious packets.

Subsequently, the outgoing request 7’ for the unicast service may be forwarded 203 to the server 4 in accordance with the applicable unicast scheme, such as semantic unicast routing.

Responsive to receiving the requests 7’ of the plurality of clients 3 for the unicast service, the server 4 may submit a response comprising the same semantic identifier 70, SID, and the same request identifier 71, RID as the requests 7’. The combination of multiple requests 7’ into a single response may be driven by service-specific semantics, with the server 4 deciding on the criteria, e.g., timing, for combining one or more requests 7’ into the single response.

In other words, if the server 4 receives statistically concurrent, yet asynchronous, requests 7’ from a plurality of clients 3 including the same semantic identifier 70, SID and the same request identifier 71, RID, the server 4 may answer by providing a single response to the plurality of requests 7’.

In connection with path-based forwarding, the response further comprises a return path identifier 72, pathID comprising a binary OR-combination of the path identifiers 72, pathID of the plurality of requests 7’ forwarded to the server 4.

Ultimately, the response provided by the server 4 in accordance with a first ad-hoc multicast delivery scheme and responsive to the requests 7’ is received 204 as an incoming response.

With continuing reference to FIG. 3, the processing step 205 may comprise a step 205a of establishing if any set bit position (s) of the return path identifier 72, pathID of the incoming response match with outgoing network link (s) 6’ (or corresponding network interface (s) ) of the device 10, and if not, proceeding to 205c. Further, the processing step 205 may comprise a step 205b of forwarding the incoming response as an outgoing response on all matching interfaces. Then, the processing step 205 may comprise a step 205c of querying the pending request table 103 of the device 10 for outgoing network link (s) 6’ (or corresponding network interface (s) ) in dependence of the semantic identifier 70, SID and the request identifier 71, RID comprised in the incoming response; and removing the return path identifier 72, pathID from the outgoing response.

Accordingly, the outgoing response can be provided 206 to the plurality of clients 3 in accordance with the second multicast delivery scheme, i.e., to the network link (s) 6’ associated with the semantic identifier 70, SID and the request identifier 71, RID of the incoming response. Further, the triplet (s) 6’, 70, 71 may be deleted from the pending request table 103 of the device 10.

The mix of path-based and hop-by-hop forwarding keeps reverse forwarding simple, while still achieving multicast in all parts of the network 1.

FIG. 4 illustrates a flowchart associated with another example of an embodiment of the disclosure.

According to this example, the first ad-hoc multicast delivery scheme employed in the first network 1” comprises path-based forwarding, and the second ad-hoc multicast delivery scheme employed in the second network 1’ comprises tree-based forwarding.

Initially, the illustrated method 2 may comprise a step 201 of receiving the respective incoming request 7” for the unicast service on an incoming network link 6’ (or corresponding network interface) .

Tree-based forwarding as used herein may relate to describing a tree from a server to a number of clients in the network through a bit field where a bit position indicates the forwarding over a specific network link.

Tree-based forwarding has no flow-related state and requires only processing of in-packet tree information and forwarding according to a bit field. Maintaining tree information according to incoming requests occurs much less frequent than packet forwarding.

Tree-based forwarding as the second ad-hoc multicast delivery scheme may involve that each of the respective incoming requests 7” (see Fig. 2 (c) ) further comprises a (second) multicast request identifier 73, mcrID indicative of a leaf of the second ad-hoc multicast delivery scheme.

With reference to FIG. 4, the processing step 202 may comprise a step 202a of querying the SID routing table 102 of the device 10 for a number of outgoing network links 6” in dependence of the semantic identifier 70, SID comprised in the incoming request 7”. Further, the processing step 202 may comprise a step 202b of establishing if the incoming request 7” comprises a non-zero request identifier 71, RID, and if not, proceeding to 203. The processing step 202 may also comprise a step 202c of establishing if the queried outgoing network link (s) 6” is or are associated with path-based forwarding, and if not, proceeding to 202e’.

The processing step 202 may then comprise a step 202d of setting bit position (s) in a path identifier 72, pathID of an outgoing request 7’ in dependence of the queried outgoing network link (s) 6” traversed by the outgoing request 7’ towards the server 4, and inserting the path identifier 72, pathID into the outgoing request 7’. Further, the processing step 202 may comprise a step 202e’ of establishing if the device 10 is a communication peer of both networks 1’, 1” (i.e., if at least one but not all the incoming network link (s) 6’ is/are associated with path-based forwarding) ; if not, proceeding to 203. Finally, the processing step 202 may comprise a step 202f’ of maintaining a multicast sub-tree associated with the semantic identifier 70, SID and the request identifier 71, RID of the incoming request 7” and comprising the leaf as identified by the above-mentioned second multicast request identifier 73, mcrID; the multicast subtree maintained in a subtree table 104 of the device 10.

In particular, the multicast sub-tree may be computed responsive to the forwarding of the respective request or responsive to the receiving of the response.

Again, the server 4 may submit a single response to statistically concurrent yet asynchronous requests 7’ from a plurality of clients 3 including the same semantic identifier 70, SID and the same request identifier 71, RID.

In connection with path-based forwarding, the received response further comprises a return path identifier 72, pathID comprising a binary OR-combination of the path identifiers 72, pathID of the plurality of requests 7’s ent to the server 4.

With continuing reference to FIG. 4, the processing step 205 may comprise a step 205a of establishing if any set bit position (s) of the return path identifier 72, pathID of the incoming response match with outgoing network link (s) 6’ (or corresponding network interface (s) ) of the device 10, and if not, proceeding to 205c’. The processing step 205 may further comprise a step 205b of forwarding the response on all matching network interface (s) . Then, the processing step 205 may comprise a step 205c’ of establishing if any multicast subtree (s) is/are available in the subtree table 104 of the device 10 for the semantic identifier 70, SID and the request identifier 71, RID of the incoming response, and if not, proceeding to 205e’. Further, the processing step 205 may comprise a step 205d’ of querying the subtree table 104 for maintained multicast subtree (s) associated with the semantic identifier 70, SID and the request identifier 71, RID of the incoming response, and inserting the maintained multicast subtree (s) into an outgoing response, thereby removing the return path identifier 72, pathID of the response; then proceeding to 206. Finally, the processing step 205 may comprise a step 205e’ of modifying any multicast subtree (s) in the outgoing response.

Accordingly, the outgoing response may be provided 206 to the plurality of clients 3 in accordance with the second multicast delivery scheme, i.e. to outgoing network link (s) 6’ in accordance with the inserted multicast subtree (s) associated with the semantic identifier 70, SID and the request identifier 71, RID of the incoming response, and the maintained multicast sub-tree is deleted from the subtree table 104 of the device 10.

The mix of path-based and tree-based forwarding keeps reverse forwarding simple, while still achieving multicast in all parts of the network 1.

FIG. 5 illustrates a flowchart associated with a further example of the first aspect.

According to this example, both the first ad-hoc multicast delivery scheme employed in the first network 1” and the second ad-hoc multicast delivery scheme employed in the second network 1’ comprise tree-based forwarding.

Initially, the illustrated method 2 comprises a step 201 of receiving the respective incoming request 7” for the unicast service on an incoming network link 6’ (or corresponding network interface) .

With reference to FIG. 5, the processing step 202 may comprise a step 202e” of establishing if the device 10 is a communication peer of both networks 1’, 1”, and if not, proceeding to 203. Further, the processing step 202 may comprise a step 202f’ of maintaining a multicast sub-tree associated with the semantic identifier 70, SID and the request identifier 71, RID of the incoming request 7” and comprising the leaf as identified by the above-mentioned second multicast request identifier 73, mcrID. The multicast subtree is maintained in a subtree table 104 of the device 10.

Tree-based forwarding as the first ad-hoc multicast delivery scheme may involve that each of the respective outgoing requests 7” (see Fig. 2 (c) ) further comprises a (first) multicast request identifier 73, mcrID indicative of a leaf of the first ad-hoc multicast delivery scheme (i.e., the device 10 processing the request 7” ) . As such, a first multicast request identifier 73, mcrID indicative of the device 10 as a leaf of the first ad-hoc multicast delivery scheme may be inserted into the respective outgoing request 7”.

Subsequently, the outgoing request 7” for the unicast service may be forwarded 203 to the server 4 in accordance with the applicable unicast scheme, such as semantic unicast routing.

Again, the server 4 may submit a single response to statistically concurrent yet asynchronous requests 7” from a plurality of clients 3 including the same semantic identifier 70, SID and the same request identifier 71, RID.

When combining more than one request 7” into a single response, all the first multicast request identifiers 73, mcrID received in the requests 7” are used to compute a multicast tree from the server 4 to all devices 10 as identified by the first multicast request identifiers 73, mcrID.

Thus, in connection with tree-based forwarding, the response further comprises a multicast tree including all the leaves (i.e., devices 10) of the first ad-hoc multicast delivery scheme as identified by the above-mentioned first multicast request identifiers 73, mcrID of the plurality of requests 7” sent to the server 4.

Ultimately, the response provided by the server 4 in accordance with the first ad-hoc multicast delivery scheme and responsive to the requests 7” is received 204 by the device 10 as an incoming response. As such, the incoming response comprises a multicast tree including the device 10 as a leaf.

With continuing reference to FIG. 5, the processing step 205 may comprise a step 205c’ of establishing if any multicast subtree (s) is/are available in the subtree table 104 of the device 10 for the semantic identifier 70, SID and the request identifier 71, RID of the incoming response, and if not, proceeding to 205e’. The processing step 205 may further comprise a step 205d’ of querying the subtree table 104 for maintained multicast subtree (s) associated with the semantic identifier 70, SID and the request identifier 71, RID of the incoming response; inserting the maintained multicast subtree (s) into an outgoing response, thereby removing the multicast sub-tree associated with the first ad-hoc multicast delivery scheme from the response; then proceeding to 206. Finally, the processing step 205 may comprise a step 205e’ of modifying 205e’ any multicast subtree (s) in the outgoing response.

Accordingly, the outgoing response may be provided 206 to the plurality of clients 3 in accordance with the second multicast delivery scheme, i.e., to outgoing network link (s) 6’ in accordance with the inserted multicast subtree (s) associated with the semantic identifier 70, SID and the request identifier 71, RID of the incoming response, and the maintained multicast sub-tree is deleted from the subtree table 104 of the device 10. As such, the outgoing response may comprise a multicast tree rooted at the device 10.

The sequence of tree-based forwarding keeps reverse forwarding simple, while still achieving multicast in all parts of the network 1.

The processor 101 of the device 10 may comprise hardware and/or may be controlled by software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs) , field-programmable gate arrays (FPGAs) , digital signal processors (DSPs) , or multi-purpose processors.

The present disclosure has been described in connection with various example devices 10. Those skilled in the art will appreciate that the flowcharts of FIG. 3 –5 relate to corresponding methods and computer programs.

A corresponding computer program comprises executable instructions, which when executed by a processor 101 of the device 10 according to the first aspect or any of its embodiments, cause the processor 101 to perform the method 2 according to the second aspect or any of its embodiments.

However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed invention, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.

Claims

A device (10) for ad-hoc multicast delivery of a unicast service, the device (10) comprising:

a processor (101) configured to:

forward respective requests (7, 7’, 7”) of a plurality of clients (3) for the unicast service to a server (4) of the service; and

return a response associated with the requested service to the plurality of requesting clients (3) by:

receiving the response provided by the server (4) in accordance with a first ad-hoc multicast delivery scheme, and

providing the received response to the plurality of clients (3) in accordance with a second multicast delivery scheme.
The device (10) of claim 1, wherein the processor (101) is further configured to forward the respective requests (7, 7’, 7”) based on semantic unicast routing.
The device (10) of claim 1 or claim 2, wherein each of the respective requests (7, 7’, 7”) comprises:

a same semantic identifier (70) indicative of the server (4) ; and

a same request identifier (71) indicative of the requested service, and

wherein the received response further comprises:

the same semantic identifier (70) ; and

the same request identifier (71) .
The device (10) of claim 3, wherein the first ad-hoc multicast delivery scheme comprises path-based forwarding, and

wherein the processor (101) is further configured to:

set a bit position in a path identifier (72) of the respective request (7, 7’, 7”) in dependence of a network link (6”) traversed by the respective request (7, 7’, 7”) towards the server (4) ; and

insert the path identifier (72) into the respective request,

wherein the received response further comprises a return path identifier (72) comprising a binary OR-combination of the path identifiers (72) of the plurality of requests (7, 7’, 7”) , and

wherein the processor (101) is further configured to remove the return path identifier (72) from the received response.
The device (10) of claim 3, wherein the first ad-hoc multicast delivery scheme comprises tree-based forwarding, and

wherein the processor (101) is further configured to insert a first multicast request identifier (73) indicative of the device (10) as a leaf of the first ad-hoc multicast delivery scheme into the respective request,

wherein the received response further comprises a multicast sub-tree comprising the device (10) as a leaf, and

wherein the processor (101) is further configured to remove the multicast sub-tree from the received response.
The device (10) of claim 4 or claim 5, wherein the second ad-hoc multicast delivery scheme comprises tree-based forwarding,

wherein each of the respective requests (7, 7’, 7”) further comprises a second multicast request identifier (73) indicative of a leaf of the second ad-hoc multicast delivery scheme, and

wherein the processor (101) is further configured to maintain a multicast sub-tree associated with the semantic identifier (70) and the request identifier (71) an