WO2022106027A1

WO2022106027A1 - Interconnecting semantic routing islands using non-semantic routing based services

Info

Publication number: WO2022106027A1
Application number: PCT/EP2020/082906
Authority: WO
Inventors: Dirk Trossen
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2020-11-20
Filing date: 2020-11-20
Publication date: 2022-05-27
Also published as: EP4229847A1

Abstract

A routing device (3, 3') for a network (1, 1', 1") with semantic routing is provided. The routing device (3, 3') comprises a control unit (301) configured to: receive (102) a semantic announcement comprising a service name; associate (103) the service name with a locator; receive (110) a semantic service request comprising the service name; and forward (111) the received semantic service request according to the locator associated with the service name. The semantic service request originates from a first network (1') with semantic routing and the service is hosted in a second network (1") with semantic routing. A gateway device (4), a server device (7), a client device (2) and a name resolution server (6) are also provided. These devices (2, 3, 3', 4, 6, 7) realize edge-based semantic routing that allows for communicating with any Internet services, including those in other semantic routing islands, without particular client awareness.

Description

INTERCONNECTING SEMANTIC ROUTING ISLANDS USING NON- SEMANTIC ROUTING BASED SERVICES

TECHNICAL FIELD

The present disclosure relates to semantic routing across semantic routing islands formed in the Internet. The present disclosure provides, to this end, a routing device, gateway device, server device, client device, and name resolution server device. The present disclosure also provides a corresponding network with semantic routing.

BACKGROUND

Service routing in the Internet is being coupled to discovery systems such as the Domain Name Service (DNS) to resolve service names, e.g., Uniform Resource Locators (URLs), into Internet Protocol (IP) addresses. This causes latencies by DNS resolution and flushing of local DNS cache, which happens frequently in, e.g., Android systems. DNS latency can be avoided in a number of ways:

Information-Centric Networking (ICN) denotes a paradigm shift to route in accordance with names of the requested data/content instead of addresses of hosts. Service routing over ICN allows for utilizing internal as well as Internet services by using path-based (non-IP) forwarding. As such, ICN attempts to replace the IP-based routing system.

Semantic routing uses, e.g., IPv6 extension headers for carrying service information in IP packets. However, semantic routing suffers from insufficient scalability of service announcement to semantic routers in large networks. Edge-based semantic routing limits this scalability issue but restricts utilizing services in the larger Internet. Therefore, client awareness is needed to utilize semantic routing for services hosted within a semantic routing island, and DNS and IP for services hosted outside the semantic routing island. Making semantically routed service names publically available, e.g., through DNS, allows for exposure beyond single semantic routing island, but the service is then tied to the IP locator, losing the intrinsic advantages of semantic routing. Accordingly, a solution is needed to remove the need for client awareness at a semantic routing edge while allowing for full Internet services being used as well as exposing services hosted within the semantic routing island to the Internet as well as other semantic routing edges.

SUMMARY

In view of the above-mentioned problems and disadvantages, it is an object to improve a scalability of semantic routing without particular client awareness of services.

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 routing device for a network with semantic routing, comprising: a control unit configured to receive a semantic announcement comprising a service name; associate the service name with a locator; receive a semantic service request comprising the service name; and forward the received semantic service request according to the locator associated with the service name. The semantic service request originates from a first network with semantic routing and the service is hosted in a second network with semantic routing.

Advantageously, associating the service name, throughout a local semantic routing island, with locators - the locators, for example, denoting semantic next-hops in the same or in a different semantic routing island - may enable taking advantage of a service hosted in the different semantic routing island, and may improve scalability of semantic routing without particular client awareness of services. In other words, a service requestor may merely need to know the service name, but not the locator of the server.

The control unit may further be configured to forward the semantic announcement to another routing device in the network with semantic routing.

Advantageously, forwarding the semantic announcement within the local semantic routing island may improve a reachability of the underlying service. The locator associated with the service name may relate to another routing device or to a gateway device in the network with semantic routing from which the semantic announcement has been received by the routing device.

Advantageously, associating the service name with locators, which for instance denote semantic next-hops, may provide a daisy-chained connectivity to the underlying service.

The received semantic service request may comprise a locator of the routing device as a destination address; and the control unit may further be configured to extract the service name from an extension header of the received semantic service request.

Advantageously, extracting the service name from an extension header may enable bridging a semantic routing gap between semantic routing islands, based on existing protocol standards.

A second aspect of the present disclosure provides a gateway device for a network with semantic routing, comprising a control unit configured to send a semantic announcement comprising a service name to a routing device in the network with semantic routing; receive a semantic service request comprising the service name; associate the service name with a locator identified by a name resolution of the service name, or with an associated locator; and forward the received semantic service request according to the locator associated with the service name. The semantic service request originates from a first network with semantic routing and the service is hosted in a second network with semantic routing.

Advantageously, sending semantic (peering) announcements comprising a service name may advertise services hosted in different semantic routing islands within the local semantic routing island. This also allows for designating specific gateway devices for specific service names, such as a dedicated “foo.com” gateway compared to a standard gateway device.

The semantic announcement may comprise a wildcard for any not explicitly announced service name. Advantageously, sending semantic (peering) announcements comprising a wildcard may advertise a connectivity to any unannounced services hosted in different semantic routing islands within the local semantic routing island. The peering announcement may piggyback on service announcements of baseline semantic routing. Using the wildcard matching entry, routing devices will have an action for ‘no matching announced service’ in any case rather than dropping the request, which requires only a minimal extension to baseline semantic routers.

A third aspect of the present disclosure provides a name resolution server, comprising a control unit configured to receive a semantic announcement comprising a service name; associate the service name with a locator; receive a name resolution request comprising the service name; and send a name resolution response comprising the locator associated with the service name. The name resolution request originates from a first network with semantic routing and the service is hosted in a second network with semantic routing.

Advantageously, providing an association of the service name with a locator - for instance, a locator of a next-hop in a globally reachable name resolution server - may expose a service outside a hosting semantic routing island, while preserving the semantic routing capabilities.

The locator associated with the service name may relate to a routing device of the second network with semantic routing hosting the service.

Advantageously, providing an association of the service name with a locator of, for example, a semantic next-hop in a globally reachable name resolution server may enable bridging a semantic routing gap between semantic routing islands, based on existing protocol standards.

A fourth aspect of the present disclosure provides a server device for a network with semantic routing, comprising a control unit configured to send a semantic announcement comprising a service name; receive a semantic service request comprising the service name; and send a service response in respect of the received semantic service request. The semantic service request originates from a first network with semantic routing and the service is hosted in a second network with semantic routing. The semantic announcement may be sent to a routing device of the network with semantic routing.

Advantageously, sending a semantic announcement comprising the service name triggers associating the service name, throughout the local semantic routing island, with locators denoting semantic next-hops within the same semantic routing island, and may enable taking advantage of a service hosted in the local semantic routing island.

The semantic service announcement may be sent to a name resolution server reachable by the server device; and the semantic service announcement may further comprise a locator relating to a routing device of the second network with semantic routing.

Advantageously, sending a semantic announcement comprising the service name to a globally reachable name resolution server may enable taking advantage of a service hosted in a different semantic routing island.

A fifth aspect of the present disclosure provides a client device for a network with semantic routing, comprising a control unit configured to send a semantic service request comprising a service name; and receive a service response in response to the semantic service request. The semantic service request originates from a first network with semantic routing and the service is hosted in a second network with semantic routing.

Advantageously, sending a semantic service request comprising a service name may enable taking advantage of a service hosted in a different semantic routing island with no need to know the particular locator of the server, and thus may improve a scalability of semantic routing without particular client awareness of services.

A sixth aspect of the present disclosure provides a network with semantic routing, comprising a routing device of the first aspect or any of its embodiments; and a gateway device of the second aspect or any of its embodiments.

The network may further comprise a server device of the fourth aspect or any of its embodiments. The network may further comprise a client device of the fifth aspect or any of its embodiments.

A network with semantic routing may comprise a first network of the sixth aspect or any of its embodiments; a second network of the sixth aspect or any of its embodiments; and a name resolution server of the third aspect or any of its embodiments.

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 a network with semantic routing according to an embodiment;

FIG. 2 illustrates a routing device for a network with semantic routing according to an embodiment, and a corresponding mode of operation;

FIG. 3 illustrates a gateway device for a network with semantic routing according to an embodiment, and a corresponding mode of operation; FIG. 4 illustrates a name resolution server according to an embodiment, and a corresponding mode of operation;

FIG. 5 illustrates a server device for a network with semantic routing according to an embodiment, and a corresponding mode of operation;

FIG. 6 illustrates a client device for a network with semantic routing according to an embodiment, and a corresponding mode of operation;

FIG. 7 illustrates an interplay of the respective modes of operation of the devices of FIGs. 2 - 6.

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 a network 1, 1’, 1” with semantic routing according to an embodiment.

The exemplary network 1 with semantic routing comprises first and second networks 1’, 1” with semantic routing, or in other terms, semantic routing islands 1’, 1”.

As used herein, semantic routing may refer to routing in accordance with service information that is embedded in a header of a packet. The service information may comprise, or may be indicative of, a name of a service (rather than a locator of the corresponding server).

As used herein, a service may refer to a work split between a service requester (client) and a service provider (server) in accordance with a client-server model.

An exemplary IP routing device 5 (or a network of such IP routing devices 5) may provide IP connectivity between the first and second networks 1’, 1” as indicated by the dashed line that directly interconnects the two semantic routing islands 1’, 1”.

The exemplary network 1 may further comprise a name resolution server 6, which will be explained in more detail in connection with FIG. 4.

With reference to FIG. 1, the first network 1’ with semantic routing may comprise a client device 2, a routing device 3, and a gateway device 4, which will respectively be explained in more detail in connection with FIGs. 6, 2, and 3. As FIG. 1 suggests, the client device 2 may form part of a mobile device, such as a smartphone, for example, or of a stationary device operable by a user. Of course the first network 1 ’ with semantic routing may further comprise a server device 7 and a routing device 3 ’ as will be mentioned next in connection with the second network 1”, but for simplicity no such devices have been indicated in the first network 1’ illustrated in FIG. 1.

With continued reference to FIG. 1, the second network 1” may comprise routing devices 3, 3’ and a server device 7, which will be explained in more detail in connection with FIG. 5. According to FIG. 1, the server device 7 may form part of a data center, for example, operable by a Service Provider (SP). Exemplary services may comprise providing content, or computational power, on demand. Needless to say, the second network 1” with semantic routing may further include a client device 2 and a gateway device 4 as has just been mentioned in connection with the first network 1’, but FIG. 1 illustrates only the essential functions for requesting, from within in the first network 1’, a service hosted within the second network 1”.

In connection with FIGs. 2 - 6 below, the various devices 3, 3’, 4, 6, 7, 2 and their respective modes of operation will be explained in more detail, in line with a graphical representation borrowing from the Specification and Description Language (SDL), see ITU-T Recommendations Z.100 to Z.106.

For example, a block having a pointy concavity represents receiving of a message stimulus (signal) coming from another device, a block having a pointy convexity denotes sending a signal to another device, and a rectangular block stands for device-internal processing. Horizontal and vertical lines represent signals and process flow, respectively.

An interplay of these devices and their respective modes of operation will be given in connection with FIG. 7.

FIG. 2 illustrates a routing device 3, 3’ for a network 1, 1’, 1” with semantic routing according to an embodiment, and a corresponding mode of operation.

The routing device 3, 3’ comprises a control unit 301, whose mode of operation is outlined as follows:

According to FIG. 2, the control unit 301 is configured to receive 102 a semantic announcement comprising a service name. The semantic announcement may relate to a specific service hosted locally within the semantic routing island 1’, 1”, or a peering to a specific service hosted outside the semantic routing island 1’, 1”. In both cases, the service name thus relates to a specific service. Alternatively, the semantic announcement may announce a peering to services not being announced within the semantic routing island 1’, 1” and potentially hosted outside the semantic routing island 1’, 1”. In such case, the semantic announcement may comprise a wildcard for any not explicitly announced service name, as will be explained in more detail below.

The semantic announcement may comprise a service name such as “foo.com”, or a hash value thereof.

According to FIG. 2, the control unit 301 is configured to associate 103 the service name with a locator. This may populate a device-internal table with a tuple comprising the service name and the locator. In case of an announcement of a local service (cf. above), the locator associated with the service name may relate to another routing device 3, 3’ in the network 1’, 1” with semantic routing from which the semantic announcement has been received by the routing device 3, 3’. In other words, the locator may be a next-hop IP address of an adjacent routing device 3, 3’.

In case of an announcement of a peering to a specific service (cf. above), the locator associated with the service name may - initially - relate to a gateway device 4 in the network 1’ with semantic routing from which the semantic announcement has been received by the routing device 3, 3’, because peering announcements are issued by gateway devices 4. As the peering announcement is forwarded within the semantic routing island 1’, 1” the locator may become a next-hop IP address of an adjacent routing device 3, 3’. Furthermore, the peering announcement may comprise a wildcard, such as for any not explicitly announced service name. This may populate the above-mentioned deviceinternal table with a tuple comprising the wildcard and the locator.

According to FIG. 2, the control unit 301 may further be configured to forward 104 the semantic announcement to another routing device 3, 3’ in the network 1 ’, 1” with semantic routing. This may disseminate a semantic announcement within the concerned semantic routing island 1’, 1”, so that throughout the semantic island 1’, 1” it is clear where to route service requests for the announced service or peering based on the respective service name (or wildcard, if applicable).

The semantic announcement procedure set out above paves the way for a subsequent service request.

According to FIG. 2, the control unit 301 is further configured to receive 110 a semantic service request comprising the service name. In other words, the concerned service may be addressed by its name included in the prior service announcement, such as “foo.com”, or a hash value thereof.

In case of a semantic service request being received from outside the concerned semantic island 1’, 1”, i.e., via IP routing, the received semantic service request may comprise a locator of the receiving routing device 3’ as a destination address. In other words, the received semantic service request is intended for the receiving routing device 3’. If so, then the control unit 301 may further be configured to extract 119 the service name, according to which a semantic routing is to be commenced within the receiving semantic island 1’, 1”, from an extension header of the received semantic service request. In particular, the extension header may be an IPv6 extension header.

By contrast, if a semantic service request is received from outside the concerned semantic island 1’, 1” which fails to comprise the locator of the receiving routing device 3’ as a destination address, the receiving routing device 3’ may drop the request.

Given the previously mentioned semantic announcement procedure, the routing devices 3, 3’ of the concerned semantic island 1’, 1” may have respective device-internal tables at their disposal which are populated with tuples of service names and corresponding locators.

The control unit 301 is thus configured to forward 111 the received semantic service request according to the locator associated with the service name, in accordance with FIG.

2.

This mode of operation applies for services being requested and hosted within a semantic island 1’, 1”, but also endorses network scenarios such as illustrated in FIG. 7 below wherein the semantic service request originates from a first network 1’ with semantic routing and the service is hosted in a second network 1” with semantic routing. In such a scenario, the routing device 3’ capable of extraction 119 of the service name may be arranged at an ingress of the second network 1” with semantic routing hosting the service.

FIG. 3 illustrates a gateway device 4 for a network 1, 1’, 1” with semantic routing according to an embodiment, and a corresponding mode of operation.

The gateway device 4 comprises a control unit 401, whose mode of operation is outlined as follows:

According to FIG. 3, the control unit 401 is configured to send 108 a semantic announcement comprising a service name to a routing device 3, 3’ in the network 1’, 1” with semantic routing. This relates to the previously mentioned peering announcements. More specifically, the semantic announcement may announce a peering to a specific service hosted outside the semantic routing island 1’, 1”, or a peering to services not being announced within the semantic routing island 1’, 1” and potentially hosted outside the semantic routing island 1’, 1”. 6. In the latter case, the semantic announcement may comprise a wildcard for any not explicitly announced service name, as already mentioned.

This initiates a dissemination of the semantic announcement within the concerned semantic routing island 1’, 1” in accordance with the semantic announcement procedure set out above.

According to FIG. 3, the control unit 401 is further configured to receive 112 a semantic service request comprising the service name. Especially if the gateway device 4 has issued a peering announcement comprising a wildcard for any not explicitly announced service name, it may well be that the above-mentioned device-internal table fails to provide a tuple comprising the service name and a corresponding locator, because the service name has not been announced explicitly.

In such a case, a name resolution 113, 116 may be used to associate 117 the service name with an appropriate locator. In other words, the control unit 401 is further configured to send 113 a name resolution request comprising the service name to a name resolution server 6 reachable by the server device 7; and receive 116 a corresponding name resolution response comprising the locator associated with the service name. If such a name resolution 113, 116 has already taken place, an associated locator may be retrieved from an internal DNS cache.

When receiving a service name as hashed information, the hash is applied for retrieving the service name, before name resolution 113, 116 applies.

If the received 112 semantic service request comprises a service name based on P:L information, the P information is verified to retrieve the domain name information, before name resolution 113, 116 applies. If P cannot be verified, e.g., when no public key information or P information can be retrieved (from the name resolution server 6 or similar registries), the request is dropped. As used herein, P:L information may refer to the Principals and Labels (P:L) naming convention wherein names are of the form P:L, where P is a cryptographic hash of the principal’s public key, and where L is a service unique label chosen by the principal. Only hosts authorized by the principal P can provide access to entities with names of the form P:L.

The control unit 401 is thus further configured to forward 118 the received semantic service request according to the locator associated with the service name.

This mode of operation endorses network scenarios such as illustrated in FIG. 7 below wherein the semantic service request originates from a first network 1’ with semantic routing and the service is hosted in a second network 1” with semantic routing. In such a scenario, the gateway device 4 may be arranged at an egress of the first network 1 ’ with semantic routing originating the service request.

FIG. 4 illustrates a name resolution server 6 according to an embodiment, and a corresponding mode of operation.

The name resolution server 6 comprises a control unit 601, whose mode of operation is outlined as follows:

According to FIG. 4, the control unit 601 is configured to receive 106 a semantic announcement comprising a service name. The semantic announcement may relate to a service which should be discoverable outside the semantic network island 1” hosting the service.

According to FIG. 4, the control unit 601 is further configured to associate 107 the service name with a locator. This may populate a device-internal table with a tuple comprising the service name and the locator. In particular, the locator associated with the service name relates to a routing device 3’ of the second network 1” with semantic routing hosting the service. The service announcement may include additional information or utilize a distinct ‘semantic routing’ record entry for avoiding a situation in which a non-semantic routing network utilizes the returned IP locator.

With continued reference to FIG. 4, the control unit 601 is further configured to receive 114 a name resolution request comprising the service name. In other words, the sought- after service may be identified by its name included in the prior service announcement, such as “foo.com”, or a hash value thereof.

Still referring to FIG. 4, the control unit 601 is further configured to send 115 a name resolution response comprising the locator associated with the service name.

This mode of operation endorses network scenarios such as illustrated in FIG. 7 below wherein the semantic service request originates from a first network 1’ with semantic routing and the service is hosted in a second network 1” with semantic routing. In such a scenario, the name resolution server 6 may be arranged in an IP network reachable by the involved semantic routing islands 1’, 1”.

FIG. 5 illustrates a server device 7 for a network 1, 1’, 1” with semantic routing according to an embodiment, and a corresponding mode of operation.

The server device 7 comprises a control unit 701, whose mode of operation is outlined as follows:

According to FIG. 5, the control unit 701 is configured to send 101 a semantic announcement comprising a service name. The semantic announcement may be sent 101 to a routing device 3 , 3 ’ of the network 1’ , 1” with semantic routing, may relate to a specific service hosted locally within the semantic routing island 1” hosting the service, and may comprise a service name such as “foo.com”, or a hash value thereof.

With continued reference to FIG. 5, the control unit 701 is further configured to send 105 a semantic announcement comprising the service name. The semantic announcement may relate to the same service which should be discoverable outside the semantic network island 1” hosting the service, as already mentioned in connection with FIG. 4 above. In particular, the semantic service announcement may be sent 105 to a name resolution server 6 reachable by the server device 7; and may further comprise a locator relating to a routing device 3’ of the second network 1” with semantic routing. In other words, this semantic announcement may direct a corresponding semantic service request to a locator of the routing device 3’, which may be arranged at an ingress of the second network 1”.

In addition, the server device 7 may register its own locator in addition to the locator of the routing device 3’ of the second network 1”, providing a second name resolution record. A semantic routing client device 2 may then utilize the ‘semantic routing’ record entry while a standard IP routing client will utilize the common record entry, directing any service requests to the specific locator.

Still referring to FIG. 5, the control unit 701 is further configured to receive 120 a semantic service request comprising the service name; and send 121 a service response in respect of the received semantic service request.

This mode of operation endorses network scenarios such as illustrated in FIG. 7 below wherein the semantic service request originates from a first network 1’ with semantic routing and the service is hosted in a second network 1” with semantic routing. In such a scenario, the server device 7 may evidently be arranged within the second network 1” with semantic routing hosting the service.

FIG. 6 illustrates a client device 2 for a network 1, 1’, 1” with semantic routing according to an embodiment, and a corresponding mode of operation.

The client device 2 comprises a control unit 201, whose mode of operation is outlined as follows:

According to FIG. 6, the control unit 201 is configured to send 109 a semantic service request comprising a service name, such as “foo.com”; and receive 122 a service response in response to the semantic service request.

This mode of operation applies for services being requested and hosted within a semantic island 1’, 1”, but also endorses network scenarios such as illustrated in FIG. 7 below wherein the semantic service request originates from a first network 1’ with semantic routing and the service is hosted in a second network 1” with semantic routing. In such a scenario, the client device 2 may evidently be arranged within the first network 1’ with semantic routing originating the service request.

The control units of the above-mentioned devices may respectively comprise processing circuitry and/or may be controlled by software. The processing circuitry 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.

Furthermore, the control units of the above-mentioned devices may respectively comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium (not shown) storing executable program code which, when executed by the processing circuitry, causes the control unit of the respective device to operate, i.e., to execute the appropriate blocks 101 - 122 mentioned in connection with the respective mode of operation.

FIG. 7 illustrates an interplay of the respective modes of operation of the devices 3, 3’, 4, 6, 7, 2 of FIGs. 2 - 6.

In an upper section of FIG. 7, the exemplary network 1 of FIG. 1 is repeated for a better overview.

In a lower section of FIG, the respective modes of operation of FIGs. 2 - 6 are repeated and brought in alignment with each other, so that corresponding signals and blocks are arranged in a same vertical position.

First, a service may be announced locally within the second network 1” with semantic routing. To this end, a semantic announcement is sent 101 by the server device 7. The semantic announcement comprises a service name, such as “foo.com”, or a hash value thereof.

The semantic announcement is received 102 by a routing device 3 of the second network 1”. The service name is associated 103 with a locator, in this case a next-hop IP address of the preceding server device 7, and a device-internal table is populated with a tuple comprising the service name and the locator.

The semantic announcement is forwarded 104 by the routing device 3 and received 102 by another routing device 3’ within the second network 1”.

Again, the service name is associated 103 with a locator, in this case a next-hop IP address of the preceding routing device 3, and a device-internal table is populated with a tuple comprising the service name and the locator.

Second, the service may also be announced globally. This can be accomplished by a further semantic announcement being sent 105 by the server device 7.

The further semantic announcement comprises the service name or a hash value thereof, too.

However, the further semantic announcement is sent 105 to, and received by, a name resolution server 6 reachable by the server device 7.

The service name is associated 107 with a locator. Different from the previous local service announcement, the locator relates to the routing device 3’ of the second network 1”. This may populate a device-internal table with a tuple comprising the service name and the - different - locator.

Third, a peering to one or more services may be announced locally within the first network 1’ with semantic routing. To this end, a semantic announcement is sent 108 by a gateway device 4 to a routing device 3 within the first network 1’ with semantic routing. The semantic announcement may announce a peering to a specific service hosted outside the semantic routing island 1’, or a peering to services not being announced specifically within the semantic routing island 1’ and potentially hosted outside the semantic routing island 1’. In the latter case, the semantic announcement may comprise a wildcard for any not explicitly announced service name.

This initiates a dissemination of the peering announcement within the semantic routing island 1’. In accordance with FIG. 7, it shall be assumed in the following that the semantic announcement comprises the afore-mentioned wildcard.

The semantic announcement is received 102 by the routing device 3 of the first network 1’. The service name is associated 103 with a locator, in this case a next-hop IP address of the preceding gateway device 4, and a device-internal table is populated with a tuple comprising the afore-mentioned wildcard and the locator.

According to FIG. 7, the semantic announcement is not forwarded 104 any further by the routing device 3 within the first network 1 ’ .

Subsequent to the preceding semantic announcements, announced services may be requested. To this end, a semantic service request may be sent 109 by a client device 2.

The semantic request comprises a service name of the announced service, such as “foo.com”, or a hash value thereof. In other words, the concerned service may be addressed by its name included in the prior service announcement. Requesting client devices 2 do not require any further knowledge of Internet services beyond the information provided by the above-mentioned announcements.

The semantic service request may be received 110 by the routing device 3.

In accordance with the preceding announcements, the routing device 3 of the semantic island 1 ’ has a device-internal table at its disposal which is populated with tuples of service names and corresponding locators. The routing device 3 is thus configured to forward 111 the received semantic service request according to the locator associated with the aforementioned wildcard, which relates to the gateway device 4 shown in FIG. 7. In other words, since in the device-internal table there is no locator associated with the service name, the routing device 3 may retrieve the locator associated with the wildcard entry (extended service name matching action).

The gateway device 4 is configured to receive 112 a semantic service request comprising the service name. As the gateway device 4 has issued a peering announcement comprising a wildcard for any not explicitly announced service name, the device-internal table of the gateway device 4 may fail to provide a tuple comprising the service name and a corresponding locator, because the service name has not been announced explicitly.

Therefore, a name resolution 113, 116 may be used to associate 117 the service name “foo.com” with an appropriate locator. In other words, the gateway device 4 may send 113 a name resolution request comprising the service name to a name resolution server 6 reachable by the gateway device 4. If such a name resolution 113, 116 has already taken place, an associated locator may be retrieved from a local cache of the gateway device 4.

The name resolution server 6 may receive 114 the name resolution request comprising the service name, and send 115 a corresponding name resolution response comprising the locator associated with the service name. As already mentioned, a device-internal table of the name resolution server 6 has previously been populated with a tuple comprising the service name and the locator, which relates to the routing device 3’ of the second network 1”.

The gateway device 4 may receive 116 the name resolution response comprising the locator associated with the service name, associate 117 the service name with the received locator, and forward 118 the received semantic service request to the routing device 3 ’ of the second network 1”.

The forwarded semantic service request may be received 110 by the routing device 3’ of the second network 1” with semantic routing.

As the semantic service request is received from outside the second network 1” with semantic routing, i.e., via an exemplary IP routing device 5 (or a network of such IP routing devices 5), it may comprise a locator of the receiving routing device 3’ as a destination address. In other words, the received semantic service request is intended for the receiving routing device 3’. If so, then the receiving routing device 3’ may extract 119 the service name, according to which a semantic routing is to be commenced within the semantic island 1”, from an extension header of the received semantic service request. In particular, the extension header may be an IPv6 extension header.

In accordance with the preceding announcements, the routing device 3’ of the semantic island 1 ’ has a device-internal table at its disposal which is populated with tuples of service names and corresponding locators. The routing device 3’ may thus forward 111 the received semantic service request according to the locator associated with the aforementioned wildcard, which according to FIG. 7 relates to the routing device 3 of the second network 1” with semantic routing.

The forwarded semantic service request may be received 110 by the routing device 3 of the second network 1” with semantic routing, which also has a device-internal table at its disposal which is populated with tuples of service names and corresponding locators. The routing device 3 may thus forward 111 the received semantic service request according to the locator associated with the afore-mentioned wildcard, which according to FIG. 7 relates to the server device 7 of the second network 1” with semantic routing.

The server device 7 may receive 120 the semantic service request comprising the service name. Alternatively, an IP locator of the server device 7 may be given as the destination address. In respect of the received semantic service request, the server device 7 may send 121 a service response.

The response is sent 121 to the client device 2 as one or more IP packets, assuming full backward compatibility of the semantic routing stack. The intermediate IP hops in FIG. 7 are thus omitted for the sake of conciseness. As an example, when receiving a response from a different semantic routing island 1”, the gateway device 4 may forward the response, in accordance with IP routing, to the client IP address when provided as the destination address.

The client device 2 may receive 122 the service response in reply to its semantic service request. The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. 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

1. A routing device (3, 3’) for a network (1, 1’, 1”) with semantic routing, comprising a control unit (301) configured to receive (102) a semantic announcement comprising a service name; associate (103) the service name with a locator; receive (110) a semantic service request comprising the service name; and forward (111) the received semantic service request according to the locator associated with the service name; characterized in that the semantic service request originates from a first network (T) with semantic routing and the service is hosted in a second network (1”) with semantic routing.

2. The routing device (3, 3’) of claim 1, wherein the control unit (301) is further configured to forward (104) the semantic announcement to another routing device (3, 3’) in the network (1’, 1”) with semantic routing.

3. The routing device (3, 3’) of claim 1 or claim 2, wherein the locator associated with the service name relates to another routing device (3, 3’) or to a gateway device (4) in the network (1 1”) with semantic routing from which the semantic announcement has been received by the routing device (3, 3’).

4. The routing device (3’) of claim 3, wherein the received semantic service request comprises a locator of the routing device (3’) as a destination address; and the control unit (301) is configured to

22 extract (119) the service name from an extension header of the received semantic service request.

5. A gateway device (4) for a network (1, 1’, 1”) with semantic routing, comprising a control unit (401) configured to send (108) a semantic announcement comprising a service name to a routing device (3, 3’) in the network (T, 1”) with semantic routing; receive (112) a semantic service request comprising the service name; associate (117) the service name with a locator identified by a name resolution (113, 116) of the service name, or with an associated locator; and forward (118) the received semantic service request according to the locator associated with the service name; characterized in that the semantic service request originates from a first network (T, 1”) with semantic routing and the service is hosted in a second network (1’, 1”) with semantic routing.

6. The gateway device (4) of claim 5, wherein the semantic announcement comprises a wildcard for any not explicitly announced service name.

7. A name resolution server (6), comprising a control unit (601) configured to receive (106) a semantic announcement comprising a service name; associate (107) the service name with a locator; receive (114) a name resolution request comprising the service name; and send (115) a name resolution response comprising the locator associated with the service name; characterized in that the name resolution request originates from a first network (1’, 1”) with semantic routing and the service is hosted in a second network (1’, 1”) with semantic routing.

8. The name resolution server (6) of claim 7, wherein the locator associated with the service name relates to a routing device (3’) of the second network (1’, 1”) with semantic routing hosting the service.

9. A server device (7) for a network (1, 1’, 1”) with semantic routing, comprising a control unit (701) configured to send (101, 105) a semantic announcement comprising a service name; receive (120) a semantic service request comprising the service name; and send (121) a service response in respect of the received semantic service request; characterized in that the semantic service request originates from a first network (T, 1”) with semantic routing and the service is hosted in a second network (1’, 1”) with semantic routing.

10. The server device (7) of claim 9, wherein the semantic announcement is sent (101) to a routing device (3, 3’) of the network (1’, 1”) with semantic routing.

11. The server device (7) of claim 9 or claim 10, wherein the semantic service announcement is sent (105) to a semantic name resolution server (6) reachable by the server device (7); and wherein the semantic service announcement further comprises a locator relating to a routing device (3’) of the second network (T, 1”) with semantic routing.

12. A client device (2) for a network (1, 1’, 1”) with semantic routing, comprising a control unit (201) configured to send (109) a semantic service request comprising a service name; and receive (122) a service response in response to the semantic service request; characterized in that the semantic service request originates from a first network (1’, 1”) with semantic routing and the service is hosted in a second network (1’, 1”) with semantic routing.

13. A network (1’, 1”) with semantic routing, comprising a routing device (3, 3’) of any of the claims 1 to 4; and a gateway device (4) of claim 5 or claim 6.

14. The network (T, 1”) of claim 13, further comprising a server device (7) of any of the claims 9 to 11.

15. The network (T, 1”) of claim 13, further comprising a client device (2) of claim 12.

16. A network (1) with semantic routing, comprising a first network (1) of claim 15; a second network (1”) of claim 14; and a semantic name resolution server (6) of claim 7 or claim 8.

25