WO2023078570A1

WO2023078570A1 - Multicast service invocation for dynamic group sizes in constraint-based service routing

Info

Publication number: WO2023078570A1
Application number: PCT/EP2021/080928
Authority: WO
Inventors: Dirk Trossen
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2021-11-08
Filing date: 2021-11-08
Publication date: 2023-05-11

Abstract

Disclosed is a routing device (1) for routing a service request (R) to a service function (SF). The routing device (1) comprises a processor (11). The processor (11) is configured to establish (21) a number of constraints (ci) for the routing of the service request (R) to a number of instances (SFm) of the service function (SF), wherein each one of the number of constraints (ci) indicates how many of the instances (SFm) of the service function (SF) are reachable by a forwarding action in accordance with the routing. The processor (11) is further configured to selectively forward (22) the service request (R) towards the number of instances (SFm) of the service function (SF) in accordance with the number of constraints (ci). This allows for dynamic group size as well as group changes in multicast communication to multiple service instances.

Description

MULTICAST SERVICE INVOCATION FOR DYNAMIC GROUP SIZES IN CONSTRAINT-BASED SERVICE ROUTING TECHNICAL FIELD The present disclosure relates generally to the field of network routing, for instance, to constraint-based service routing. More specifically, the present disclosure relates to a routing device for routing a service request to a service function, a method of operating said routing device, and a corresponding computer program. BACKGROUND A distributed ledger (or distributed ledger technology, DLT) may refer to a digital system for recording of transactions of assets, such as cryptocurrencies or smart contracts, by a distributed plurality of parties. Typically, a non-hierarchical network of nodes, such as a peer-to-peer network, maintains identical local copies of the ledger per node. The blockchain, a particular DLT concept, serves as a public transaction ledger of the cryptocurrency ‘Bitcoin’, whereas ‘Ethereum’ is a blockchain design with smart contract functionality. DLT for cryptocurrency may be mineable (i.e., one can claim ownership of new coins when contributing with a node) or not. In DLT transaction mining, a client may issue a new transaction, such as a transfer of cryptocurrency. The nodes bearing the digital ledger may validate the new transaction as part of a block of similar transactions (this being referred to as the “mining”), add the block of validated transactions to the ledger and reach a consensus on which of the local copies of the ledger is correct, using algorithms such as ‘proof of work’, ‘proof of stake’, voting systems, etc. Eventually, the nodes update their local copy of the ledger with the correct one, and the client may then read the validated transaction from the added block of validated transactions. In this connection, a transaction may be sent to multiple capable miners in a specific network diameter (one-to-many or point-to-multipoint communication), which typically involves a random number of the available miners. That is to say, the group size of the multipoint communication is dynamically determined by the difficulty of the DLT “riddle”, i.e., the intensity of the computational operations for validating transactions. Other use cases of multipoint communication where group sizes may not be fixed over a long period of time may include distributed storage (i.e., replication to multiple replicas) and distributed/redundant computing. Using unicast replication requires specifying, via a suitable client API, that N service instances are needed, and subsequent replication to N out of M (>N) possible service instances. For example, the Message Passing Interface (MPI) designed for parallel computing architectures offers such a replication interface. However, a cost of communication as well as latency increases linearly with N. Using IP multicast requires building multicast trees, either on-demand or a-priori to N instances, and has issues with respect to latency of forming dynamic groups on-demand. In addition, a network state grows linearly with the number of groups, i.e., number of different N. Using source-rooted multicast involves building a tree to N destinations at a source node only, with configured possible multicast configuration as network state. Building source trees requires recursive tree computation, which can be done once (for given N) and then cached. Disadvantageously, adding possible multicast destinations requires adaption of in-network state and possible change of source tree information. Additionally, source-rooted multicast may still require multiple (partial) multicast operations when keeping in-packet routing information fixed. As can be seen, it remains difficult in connection with these implementations to adapt the multicast group size dynamically when requesting the service. SUMMARY The present disclosure aims to improve the above-described solutions. Thereby, it is an objective to allow for dynamic group size as well as group changes in multicast communication to multiple service instances, while keeping needed additional routing state at minimum. This and other objectives are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures. According to a first aspect, a routing device for routing a service request to a service function is provided. The routing device comprises a processor. The processor is configured to establish a number of constraints for the routing of the service request to a number of instances of the service function, wherein each one of the number of constraints indicates how many of the instances of the service function are reachable by a forwarding action in accordance with the routing. The processor is further configured to selectively forward the service request towards the number of instances of the service function in accordance with the number of constraints. As each one of the number of constraints indicates how many of the instances of the service function are reachable by a respective forwarding action, a selective forwarding of the service request in accordance with the number of constraints effectively forwards the service request towards the required number of instances of the service function which is dynamically signaled in the service request. As such, a multicast communication to a dynamic group size is achieved, while keeping needed additional routing state (i.e., the number of constraints) at a minimum. In a possible implementation form, the processor may be configured to, so as to establish the number of constraints for the routing of the service request to the number of instances of the service function: receive, from an adjacent routing device, a service announcement including one or more of: an identifier of the service function, a particular constraint of the number of constraints, wherein the constraint is initially defined by a particular instance of the service function, and a type of the particular constraint. Each particular instance of the service function may thus advertise a quantitative constraint for the routing of a service request to itself, thereby re-using established routing protocols. In a possible implementation form, the service announcement may be included in an IPv6 packet; and the one or more of the received identifier of the service function, the received constraint and the received type of the received constraint may be encoded in an extension header of the IPv6 packet. The routing of a service request to a service function is thus compatible with established Internet protocols, and does not require implementation in the global Internet, since interconnection to existing Internet services and other constraint-based service routing (CBSR) domains is possible using locator-based forwarding. In a possible implementation form, the processor may further be configured to, so as to establish the number of constraints for the routing of the service request to the number of instances of the service function: populate a routing table of the routing device with an entry including the received identifier of the service function, the received type of the received constraint, the received constraint, and an identifier of the adjacent routing device from which the received constraint has been received as a next hop. Each particular routing device may thus turn the advertised constraints of the number of instances of the service function which it received in accordance with the routing into routing entries, thereby re-using established routing protocols. In a possible implementation form, the entry of the routing table may be associated with an expiry time, after which the entry is dismissed. The established number of constraints for the routing to the number of instances of the service function may be made “self-cleansing”. In a possible implementation form, the processor may further be configured to, so as to populate the routing table of the routing device with an entry: populate the routing table of the routing device with a new entry including the received identifier of the service function, the received type of the received constraint, the identifier of the adjacent routing device as the next hop, and the received constraint, if no existing entry of the routing table of the routing device is associated with the received identifier of the service function, the received type of the received constraint, and the identifier of the adjacent routing device as the next hop. Each particular routing device may thus turn the advertised constraints of the number of instances of the service function which it received in accordance with the routing into new routing entries, thereby re-using established routing protocols. In a possible implementation form, the processor may further be configured to, so as to populate the routing table of the routing device with an entry: modify the constraint of the existing entry by adding the received constraint, if an existing entry of the routing table of the routing device is associated with the received identifier of the service function, the received type of the received constraint, and the identifier of the adjacent routing device as the next hop. Each particular routing device may thus turn the advertised constraints of the number of instances of the service function which it received in accordance with the routing into aggregated routing entries, thereby re-using established routing protocols. In a possible implementation form, the processor may further be configured to, so as to establish the number of constraints for the routing of the service request to the number of instances of the service function: advertise, to another adjacent routing device, one or more of the received identifier of the service function, the received type of the received constraint, the identifier of the routing device as the next hop, and the constraint of the entry of the routing table. Each particular routing device may thus further distribute the advertised and possibly aggregated constraints of the number of instances of the service function which it received in accordance with the routing, thereby re-using established routing protocols. In a possible implementation form, the processor may further be configured to, so as to selectively forward the service request towards the number of instances of the service function in accordance with the number of constraints: receive the service request including an identifier of the service function, a type of a constraint, and a matching value from an originator of the service request; retrieve, from the routing table of the routing device, the number of constraints, and respective identifiers of adjacent routing devices associated with the respective constraint of the number of constraints in accordance with the received identifier of the service function, and the received type of the constraint; and drop the service request if the number of retrieved constraints comprises zero constraints. Each particular routing device may thus retrieve those constraints specified in the constraint- based service request and take any service request with no matching constraints out of circulation. In a possible implementation form, the service request may be included in an IPv6 packet; and the received identifier of the service function, the received type of the constraint, and the received matching value may be encoded in an extension header of the IPv6 packet. The routing of a service request to a service function is thus compatible with established Internet protocols, and does not require implementation in the global Internet, since interconnection to existing Internet services and other CBSR domains is possible using locator-based forwarding. In a possible implementation form, the processor may further be configured to, so as to selectively forward the service request towards the number of instances of the service function in accordance with the number of constraints: select a particular identifier of the retrieved identifiers of the routing table, if a lesser one of the received matching value and the constraint associated with the particular identifier amounts to a positive value; set the matching value of the received service request to the positive value; forward the received service request to the adjacent routing device associated with the selected identifier; and decrease the received matching value by subtracting the positive value. As the received matching value indicates the number of instances (initially N) of the service function to which the service request is (still) to be forwarded, and the respective constraint indicates how many of the instances of the service function are reachable down the respective next hop, a positive value therefore indicates that the service request should be forwarded in accordance with the respective constraint. Thereby, the service request is distributed to multiple instances of the service function in accordance with the demand for service instances (as specified in the service request), in accordance with the supply of service instances (as specified in the service announcements), and in accordance with stateless operations. In a possible implementation form, the service request may further include an identifier of the service request; and the processor may further be configured to, so as to selectively forward the service request towards the number of instances of the service function in accordance with the number of constraints: retrieve, from a pending request table of the routing device and in accordance with the received identifier of the service function and the received identifier of the service request, a number of positive values, and respective identifiers of adjacent routing devices associated with the respective positive value of the number of positive values; if the number of retrieved positive values comprises zero positive values, select a particular identifier of the retrieved identifiers of the routing table if a lesser one) of the received matching value and the constraint associated with the particular identifier amounts to a positive value; set the matching value of the received service request to the positive value; forward the received service request to the adjacent routing device associated with the selected identifier; decrease the received matching value by subtracting the positive value; populate the pending request table of the routing device with an entry including the received identifier of the service function, the received identifier of the service request, the identifier of the adjacent routing device as the next hop, and the positive value; if the number of retrieved positive values comprises one or more positive values, select a respective identifier of the retrieved identifiers of the pending request table associated with a respective positive value of the number of retrieved positive values of the pending request table; set the matching value of the received service request to the respective positive value; and forward the received service request to the adjacent routing device associated with the selected identifier. As set out above, the service request is distributed to multiple instances of the service function in accordance with the demand for service instances (as specified in the service request), in accordance with the supply of service instances (as specified in the service announcements), and in accordance with stateless operations. However, the pending request table may be used to realize an affinity to a previous selection of instances of the service function, thereby distributing subsequent service requests to the same set of instances of the service function in accordance with stateful operations. In a possible implementation form, the entry of the pending request table may be associated with an expiry time, after which the entry is dismissed. The affinity to specific service instances of the service function may thus support an ephemeral state maintained at the specific service instances. In a possible implementation form, the selection may include a linear iteration or a randomized iteration through the retrieved next hops depending on the received type of the constraint. Thus even in stable announcement scenarios, random instances could be selected for subsequent service requests, which may be desirable for certain use cases. In a possible implementation form, the service function may provide a mining service associated with a digital ledger; and the identifier of the service function may address all the instances of the service function. DLT transaction mining may thus generally benefit from constraint-based service routing taking into account the specific constraints of DLT transaction mining. In a possible implementation form, the digital ledger may comprise a blockchain-type digital ledger. The specific blockchain-type DLT transaction mining may thus benefit from constraint-based service routing taking into account the specific constraints of blockchain-type DLT transaction mining. According to a second aspect, a method of operating a routing device is provided. The method comprises establishing a number of constraints for the routing of the service request to a number of instances of the service function, wherein each one of the number of constraints indicates how many of the instances of the service function are reachable by a forwarding action in accordance with the routing. The method further comprises selectively forwarding the service request towards the number of instances of the service function in accordance with the number of constraints. In a possible implementation form, the method may be performed by the routing device of the first aspect or any of its implementations. According to a third aspect, a computer program is provided, comprising executable instructions which, when executed by a processor, cause the processor to perform the method of the second aspect or any of its implementations. The technical effects and advantages described above in relation with the routing device equally apply to methods having corresponding features as well as the corresponding computer programs. BRIEF DESCRIPTION OF DRAWINGS The above-described aspects and implementations will now be explained with reference to the accompanying drawings, in which the same or similar reference numerals designate the same or similar elements. 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 those skilled in the art. FIG.1 illustrates an exemplary network scenario in accordance with the present disclosure; FIG.2 schematically illustrates a routing device 1 and a method 2 of operating the same, both in accordance with the present disclosure; and FIG.3 schematically illustrates an interoperation of adjacent routing devices 1 in accordance with the present disclosure. DETAILED DESCRIPTION OF EMBODIMENTS In the following description, reference is made to the accompanying drawings, which form part of the disclosure, and which show, by way of illustration, specific aspects of embodiments of this disclosure or specific aspects in which embodiments may be used. It is understood that embodiments of this disclosure may be used in other aspects and comprise structural or logical changes not depicted in the figures. The following detailed description, therefore, is not to be taken in a limiting sense, and the scope of the present disclosure is defined by the appended claims. For instance, it is understood that a disclosure in connection with a described method may also hold true for a corresponding apparatus or system configured to perform the method and vice versa. For example, if one or a plurality of specific method steps are described, a corresponding device may include one or a plurality of units, e.g. functional units, to perform the described one or plurality of method steps (e.g. one unit performing the one or plurality of steps, or a plurality of units each performing one or more of the plurality of steps), even if such one or more units are not explicitly described or illustrated in the figures. On the other hand, for example, if a specific apparatus is described based on one or a plurality of units, e.g. functional units, a corresponding method may include one step to perform the functionality of the one or plurality of units (e.g. one step performing the functionality of the one or plurality of units, or a plurality of steps each performing the functionality of one or more of the plurality of units), even if such one or plurality of steps are not explicitly described or illustrated in the figures. Further, it is understood that the features of the various exemplary embodiments and/or aspects described herein may be combined with each other, unless specifically noted otherwise. FIG.1 illustrates an exemplary network scenario in accordance with the present disclosure. The scenario comprises a communication network N indicated by a cloud shape and comprising routing devices 1 in accordance with the present disclosure as well as further routing / forwarding devices F interconnected by network layer (i.e., layer-3) links. A “routing device” as used herein may generally relate to a network node suitable for layer-3 routing. In other words, the communication network N may be a routed network, such as an IP network. The routing devices 1 are suited for CBSR in accordance with the method 2 of operating a routing device 1 which will be explained in more detail in connection with FIGs.2 – 3 below. As used herein, service routing may refer to a routing in accordance with addressing of services rather than network interfaces. For example, service routing may use address foo.com/bar (in binary form, such as a hash of foo.com/bar) instead of the IP address of foo.com/bar. A number of instances of the service can be registered in the network, all of which can receive service requests for, e.g., foo.com/bar, possibly as forward multicast (i.e., be selected for service provisioning). There may be arrangements that allow service clients to maintain affinity with one or more particular instances of the service function after having been directed there for a first time. As used herein, CBSR may refer to a service routing wherein service instances can constrain their selection for service provisioning, by advertising constraint and matching operations together with service identifiers. Such information may be piggy-backed on packets of routing protocols and thus be distributed with a possibility for aggregation and/or suppression of advertisements. Service clients may match their demand against advertised supply (constraint) of the number of instances, by providing a matching value against which advertised constraint information is matched. Forwarding operation may be a two-stage process of longest prefix match (against service identifier) and demand/supply matching. This can be implemented in P4 (a programming language for network devices in software-defined networks, specifying how data plane devices process packets), for example, at line-speed. Attached to the communication network N is a number of service clients C deployed at various network locations, and a number of instances SF_m of a service function SF deployed at servers S at various network locations as well. Service routing may be deployed in limited domains of the global internet, but interconnection to existing Internet services and other CBSR domains may be realized using locator-based forwarding in peer network P (see bottom-right of FIG.1). In this exemplary scenario, a respective server S may issue a service advertisement A (see arrows) for the service function SF, and the respective service client C may issue a service request R (see arrows) for the service function SF, to be served by one or more instances of the number of service instances SF_m. As will be explained in more detail below, the present disclosure provides multicast communication in support of dynamic group size for service requests R (or other traffic), while keeping needed additional routing state at minimum. FIG.2 schematically illustrates a routing device 1 and a method 2 of operating the same, both in accordance with the present disclosure. As will become clear from the following disclosure, the routing device 1 is suitable for routing a service request R to a service function SF. The idea is as follows: Possible service instances SF_m of a service function SF (e.g., identified as foo.com) are advertised throughout the communication network N. A suitable routing protocol will disseminate the announcement to the routing devices 1 in the communication network N. The advertisement / announcement of possible service instances SF_m may include an additional constraint, which results in routing information in each routing device 1 as to the possible number of service instances SF_m along the next hop from which announcement was received. Service clients C send service requests R and constrain their requests with a number of needed destinations. Constraint-based service routing is used to transfer a respective service request R to a subset of the advertised service instances SF_m. More specifically, routing devices 1 perform multicast replication through forwarding to one or more of the reachable service instances along a respective next hop interface. This replication will be repeated along further next hop interfaces of the routing device 1 until all or the client-specified number of service instances has been covered. For example, given two next-hop interfaces NH1, NH2 having respective constraints of 25 and 35 means that 25 service instances are reachable along next- hop interface NH1 and 35 service instances along NH2. For example, a service request R for 50 service instances may then be replicated to the 25 service instances reachable along next-hop interface NH1, and further replicated to 25 of the 35 service instances reachable along next-hop interface NH2. Importantly, multicast communication here relates to the initial service request R, i.e., for invocation, to bootstrap relationships with service instances SF_m, not to stream data from the client C to the multiple service instances SF_m. Any responses from the multiple service instances SF_m to the single client C, identified by its IP locator, may be delivered via unicast routing. The routing device 1 comprises a processor 11 (see top-left of FIG.2). The processor 11 may be configured to execute instructions of a computer program and to thereby perform the method 2 of the second aspect (or any of its implementations) of operating the routing device 1. A most generic representation of the method 2 (see left of FIG.2) comprises steps 21 and 22. More specifically, the method 2 comprises a step of establishing 21 a number of constraints c_i for the routing of the service request R to a number of instances SF_m of the service function SF, wherein each one of the number of constraints c_i indicates how many of the instances SF_m of the service function SF are reachable by a forwarding action in accordance with the routing. Furthermore, the method 2 comprises a step of selectively forwarding 22 the service request R towards the number of instances SF_m of the service function SF in accordance with the number of constraints c_i. As the routing device 1 and the method 2 of operating the same correspond to one another in terms of their features, further details of FIG.2 will merely be provided in relation to the routing device 1 and its processor 11, respectively. Corresponding to method step 21, the processor 11 of the routing device 1 is configured to establish 21 a number of constraints c_i for the routing of the service request R to a number of instances SF_m of the service function SF, wherein each one of the number of constraints c_i indicates how many of the instances SF_m of the service function SF are reachable by a forwarding action in accordance with the routing. This may involve that the processor 11 is further configured to: - receive 211 (see block), from an adjacent device (such as an adjacent routing device 1), a service announcement A (see arrow incoming from the right), the service announcement A including one or more of: an identifier ID_SF of the service function SF, a particular constraint c_i of the number of constraints c_i, wherein the constraint c_i is initially defined by a particular instance SF_m of the service function SF, and a type T_Ci of the particular constraint c_i; - populate 212 (see block) a routing table RT (see cylindric shape) of the routing device 1 with an entry including the content of the service announcement A, i.e., the received identifier ID_SF of the service function SF, the received type T_Ci of the received constraint c_i, the received constraint c_i, and additionally an identifier NH of the adjacent routing device 1 from which the received constraint c_i has been received as a next hop; and/or - advertise 213 (see block), to another adjacent routing device 1, one or more of the received identifier ID_SF of the service function SF, the received type T_Ci of the received constraint c_i, the identifier NH of the routing device 1 as the next hop, and the constraint of the entry of the routing table RT. Generally, constraint operations can be encoded in the service announcement A using constraint type IDs where each ID uniquely identifies a specific constraint operation supported by the routing device 1. Checking for a particular constraint operation then becomes a check for an assigned type ID for said operation. The service announcement A may be included in an IPv6 packet. The content of the service announcement A, i.e., the one or more of the received identifier ID_SF of the service function SF, the received constraint c_i and the received type T_Ci of the received constraint c_i may thus be encoded in an extension header of the IPv6 packet. In particular, the entry of the routing table RT may be associated with an expiry time, after which the entry is dismissed. So as to populate 212 the routing table RT of the routing device 1 with an entry, this may involve that the processor 11 is further configured to: - populate 2121 (see nested block) the routing table RT of the routing device 1 with a new entry including the received identifier ID_SF of the service function SF, the received type T_Ci of the received constraint c_i, the identifier NH of the adjacent routing device 1 as the next hop, and the received constraint c_i, if no existing entry of the routing table RT of the routing device 1 is associated with the content of the service announcement A; or alternatively - modify 2122 (see nested block) the constraint of the existing entry by adding the received constraint c_i, if an existing entry of the routing table RT of the routing device 1 is associated with the content of the service announcement A. As can be seen, announcing a service identifier ID_SF of the service function SF over a specific next hop interface leads to a single routing table entry for said identifier. Thus, a size of a routing table is the same as for IP locator routing, albeit growing with the number of service identifiers ID_SF instead. Associating the constraint value is done per service identifier ID_SF and updated for every service announcement A. That is to say, a size of a routing table does not change, but the entry of the routing table will additionally include the type T_Ci of the constraint c_i as well as the constraint c_i. Corresponding to method step 22 of the method 2, the processor 11 of the routing device 1 is further configured to selectively forward 22 the service request R towards the number of instances SF_m of the service function SF in accordance with the number of constraints c_i. This may involve that the processor 11 is further configured to: - receive 221 (see block) the service request R including an identifier ID_SF of the service function SF, a type T_Ci of a constraint c_i, and a matching value m from an originator of the service request R; - retrieve 222 (see block), from the routing table RT of the routing device 1, the number of constraints c_i, and respective identifiers NH_i of adjacent routing devices 1 associated with the respective constraint c_i of the number of constraints c_i in accordance with the received identifier ID_SF of the service function SF, and the received type T_Ci of the constraint c_i; and - drop 223 (see block) the service request R if the number of retrieved constraints c_i comprises zero constraints. In particular, the service request R may be included in an IPv6 packet; and the received identifier ID_SF of the service function SF, the received type T_Ci of the constraint c_i, and the received matching value m may be encoded in an extension header of the IPv6 packet. So as to selectively forward 22 the service request R towards the number of instances SF_m of the service function SF in accordance with the number of constraints c_i, this may involve that the processor 11 is further configured to: - select 225 a particular identifier NH_i of the retrieved identifiers NH of the routing table RT, if a lesser one of the received matching value m and the constraint c_i associated with the particular identifier NH_i amounts to a positive value m_i = min(m; C_i); - set 226 the matching value m of the received service request R to the positive value mi; - forward 227 the received service request R to the adjacent routing device 1 associated with the selected identifier NH_i; and - decrease 228 the received matching value m by subtracting the positive value mi. As mentioned before, the multicast communication as used herein relates to stateless operations involving individual service requests R. Affinity to specific service instances SF_m, e.g., for follow-up stateful operations, can be supported by - using the service instance IP locator that is provided in the response to the service request R, therefore falling back to IP unicast routing to the specific service instance SF_m; - issuing another service request R with the same group size, which will implicitly result in the service request R being forwarded to the same set of service instances SF_m in announcement situations wherein the set of possible service instances SF_m is stable over a given time period T; or - providing explicit support of stateful operations as follows: So as to selectively forward 22 the service request R towards the number of instances SF_m of the service function SF in accordance with the number of constraints c_i, the service request R may further include an identifier ID_R of the service request R; and the processor 11 may further be configured to: - retrieve 224, from a pending request table PRT of the routing device 1 and in accordance with the received identifier ID_SF of the service function SF and the received identifier IDR of the service request R, a number of positive values mi, and respective identifiers NH_i of adjacent routing devices 1 associated with the respective positive value m_i of the number of positive values m_i; and - if the number of retrieved positive values mi comprises zero positive values: - select 225 a particular identifier NH_i of the retrieved identifiers NH of the routing table RT if a lesser one min(m; C_i) of the received matching value m and the constraint c_i associated with the particular identifier NH_i amounts to a positive value mi; - set 226 the matching value m of the received service request R to the positive value mi; - forward 227 the received service request R to the adjacent routing device 1 associated with the selected identifier NH_i; - decrease 228 the received matching value m by subtracting the positive value mi; and - populate 229 the pending request table PRT of the routing device 1 with an entry including the received identifier ID_SF of the service function SF, the received identifier IDR of the service request R, the identifier NH_i of the adjacent routing device 1 as the next hop, and the positive value mi; and - if the number of retrieved positive values mi comprises one or more positive values: - select 225’ a respective identifier NH_i of the retrieved identifiers NH of the pending request table PRT associated with a respective positive value m_i of the number of retrieved positive values m_i of the pending request table PRT; - set 226’ the matching value m of the received service request R to the respective positive value m_i; and - forward 227 the received service request R to the adjacent routing device 1 associated with the selected identifier NH_i. In particular, the entry of the pending request table PRT may be associated with an expiry time, after which the entry is dismissed. This may enforce a keep-alive signaling by service clients C to refresh the PRT network state. In particular, the selection may include a linear iteration or a randomized iteration through the retrieved next hops depending on the received type T_Ci of the constraint c_i. This may enable selecting random service instances SF_m for subsequent requests by the service client C, even in stable announcement scenarios, which may be desirable for certain use cases. This may involve explicit signaling in the service request R (e.g., as a further constraint type) or could be left for implementation at the routing device 1. No matter if a program flow executed by the processor 11 includes blocks 225 – 228 (stateless operations), blocks 224 – 229 (stateful operations including new PRT entry) or blocks 224 – 227 (stateful operations based on existing PRT entry), a forwarding complexity includes a longest prefix match (on the service identifier, see block 222) and an additional check over all matched interfaces on the reachable instances (see blocks 225 – 227 and 225’ – 227, respectively). This may be implemented in a programmable switch, e.g., based on P4 or similar technologies, a field-programmable gate array (FPGA) or as an extended Berkeley Packet Filter (eBPF) module in a software router, for example. The signalling of service announcements A and service requests R could also be simplified without supporting general (i.e., different kinds of) constraints. In this case, the announcement A will implicitly increase the reachable service instance count and the service request R may only signal the group size, always assuming the constraint on the number of service instants. In particular, the service function SF may provide a mining service associated with a digital ledger; and the identifier ID_SF of the service function SF may address all the instances SF_m of the service function SF. The digital ledger may comprise a blockchain-type digital ledger. FIG. 3 schematically illustrates an interoperation of adjacent routing devices 1 in accordance with the present disclosure. More specifically, FIG.3 shows service announcements A and service requests R being passed between the adjacent routing devices 1. Otherwise, the reference signs of FIG. 3 correspond to those of FIG. 2, which is why the explanation of FIG.2 is not repeated. In summary, the routing device 1 and the method 2 of operating the same suggested herein - allow for arbitrary multicast group sizes at service request level, supporting high dynamicity (down to individual requests), - do not impact routing table size compared to existing CBSR (no additional routing table complexity), and - integrate well with CBSR but can also be realized stand-alone, i.e., without support for general constraints but merely using service-oriented routing. 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 matter, 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. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

Claims

CLAIMS 1. A routing device (1) for routing a service request (R) to a service function (SF), the routing device (1) comprising a processor (11) configured to: - establish (21) a number of constraints (c_i) for the routing of the service request (R) to a number of instances (SF_m) of the service function (SF), each one of the number of constraints (c_i) indicating how many of the instances (SF_m) of the service function (SF) are reachable by a forwarding action in accordance with the routing; and - selectively forward (22) the service request (R) towards the number of instances (SF_m) of the service function (SF) in accordance with the number of constraints (c_i).

2. The routing device (1) of claim 1, the processor (11) being configured to, so as to establish (21) the number of constraints (c_i) for the routing of the service request (R) to the number of instances (SF_m) of the service function (SF): - receive (211), from an adjacent routing device (1), a service announcement (A) including one or more of - an identifier ( ID_SF) of the service function (SF), - a particular constraint (c_i) of the number of constraints (c_i), the constraint (c_i) being initially defined by a particular instance (SF_m) of the service function (SF), and - a type (T_Ci) of the particular constraint (c_i).

3. The routing device (1) of claim 2, the service announcement (A) being included in an IPv6 packet; and the one or more of the received identifier (ID_SF) of the service function (SF), the received constraint (c_i) and the received type (T_Ci) of the received constraint (c_i) being encoded in an extension header of the IPv6 packet.

4. The routing device (1) of claim 2 or claim 3, the processor (11) further being configured to, so as to establish (21) the number of constraints (c_i) for the routing of the service request (R) to the number of instances (SF_m) of the service function (SF): - populate (212) a routing table (RT) of the routing device (1) with an entry including - the received identifier (ID_SF) of the service function (SF), - the received type (T_Ci) of the received constraint (c_i), - the received constraint (c_i), and - an identifier (NH) of the adjacent routing device (1) from which the received constraint (c_i) has been received as a next hop.

5. The routing device (1) of claim 4, the entry of the routing table (RT) being associated with an expiry time, after which the entry is dismissed.

6. The routing device (1) of claim 4 or claim 5, the processor (11) further being configured to, so as to populate (212) the routing table (RT) of the routing device (1) with an entry: - if no existing entry of the routing table (RT) of the routing device (1) is associated with - the received identifier (ID_SF) of the service function (SF), - the received type (T_Ci) of the received constraint (c_i), and - the identifier (NH) of the adjacent routing device (1) as the next hop, populate (2121) the routing table (RT) of the routing device (1) with a new entry including - the received identifier (ID_SF) of the service function (SF), - the received type (T_Ci) of the received constraint (c_i), - the identifier (NH) of the adjacent routing device (1) as the next hop, and - the received constraint (c_i).

7. The routing device (1) of claim 4 or claim 5, the processor (11) further being configured to, so as to populate (212) the routing table (RT) of the routing device (1) with an entry: - if an existing entry of the routing table (RT) of the routing device (1) is associated with - the received identifier (ID_SF) of the service function (SF), - the received type (T_Ci) of the received constraint (c_i), and - the identifier (NH) of the adjacent routing device (1) as the next hop, modify (2122) the constraint of the existing entry by adding the received constraint (c_i).

8. The routing device (1) of claim 6 or claim 7, the processor (11) further being configured to, so as to establish (21) the number of constraints (c_i) for the routing of the service request (R) to the number of instances (SF_m) of the service function (SF): - advertise (213), to another adjacent routing device (1), one or more of - the received identifier (ID_SF) of the service function (SF), - the received type (T_Ci) of the received constraint (c_i), and - the identifier (NH) of the routing device (1) as the next hop, and - the constraint of the entry of the routing table (RT).

9. The routing device (1) of any one of the preceding claims, the processor (11) further being configured to, so as to selectively forward (22) the service request (R) towards the number of instances (SF_m) of the service function (SF) in accordance with the number of constraints (c_i): - receive (221) the service request (R) including - an identifier (ID_SF) of the service function (SF), - a type (T_Ci) of a constraint (c_i), and - a matching value (m) from an originator of the service request (R); - retrieve (222), from the routing table (RT) of the routing device (1), - the number of constraints (c_i), and - respective identifiers (NH_i) of adjacent routing devices (1) associated with the respective constraint (c_i) of the number of constraints (c_i) in accordance with - the received identifier (ID_SF) of the service function (SF), and - the received type (T_Ci) of the constraint (c_i); - if the number of retrieved constraints (c_i) comprises zero constraints, drop (223) the service request (R).

10. The routing device (1) of claim 9, the service request (R) being included in an IPv6 packet; and the received identifier (ID_SF) of the service function (SF), the received type (T_Ci) of the constraint (c_i), and the received matching value (m) being encoded in an extension header of the IPv6 packet.

11. The routing device (1) of claim 9 or claim 10, the processor (11) further being configured to, so as to selectively forward (22) the service request (R) towards the number of instances (SF_m) of the service function (SF) in accordance with the number of constraints (c_i): - select (225) a particular identifier (NH_i) of the retrieved identifiers (NH) of the routing table (RT) if a lesser one of the received matching value (m) and the constraint (c_i) associated with the particular identifier (NH_i) amounts to a positive value (mi = min(m; C_i)); - set (226) the matching value (m) of the received service request (R) to the positive value (mi); - forward (227) the received service request (R) to the adjacent routing device (1) associated with the selected identifier (NH_i); and - decrease (228) the received matching value (m) by subtracting the positive value (mi).

12. The routing device (1) of claim 9 or claim 10, the service request (R) further including - an identifier (IDR) of the service request (R); and the processor (11) further being configured to, so as to selectively forward (22) the service request (R) towards the number of instances (SF_m) of the service function (SF) in accordance with the number of constraints (c_i): - retrieve (224), from a pending request table (PRT) of the routing device (1), - a number of positive values (mi), and - respective identifiers (NH_i) of adjacent routing devices (1) associated with the respective positive value (m_i) of the number of positive values (m_i) in accordance with - the received identifier (ID_SF) of the service function (SF), and - the received identifier (ID_R) of the service request (R); - if the number of retrieved positive values (m_i) comprises zero positive values, - select (225) a particular identifier (NH_i) of the retrieved identifiers (NH) of the routing table (RT) if a lesser one (min(m; C_i)) of the received matching value (m) and the constraint (c_i) associated with the particular identifier (NH_i) amounts to a positive value (m_i); - set (226) the matching value (m) of the received service request (R) to the positive value (mi); - forward (227) the received service request (R) to the adjacent routing device (1) associated with the selected identifier (NH_i); - decrease (228) the received matching value (m) by subtracting the positive value (mi); - populate (229) the pending request table (PRT) of the routing device (1) with an entry including - the received identifier (ID_SF) of the service function (SF), - the received identifier (IDR) of the service request (R), - the identifier (NH_i) of the adjacent routing device (1) as the next hop, and - the positive value (m_i); - if the number of retrieved positive values (m_i) comprises one or more positive values, - select (225’) a respective identifier (NH_i) of the retrieved identifiers (NH) of the pending request table (PRT) associated with a respective positive value (m_i) of the number of retrieved positive values (m_i) of the pending request table (PRT); - set (226’) the matching value (m) of the received service request (R) to the respective positive value (mi); and - forward (227) the received service request (R) to the adjacent routing device (1) associated with the selected identifier (NH_i).

13. The routing device (1) of claim 12, the entry of the pending request table (PRT) being associated with an expiry time, after which the entry is dismissed.

14. The routing device (1) of any one of the claims 11 to 13, the selection including a linear iteration or randomized iteration through the retrieved next hops depending on the received type (T_Ci) of the constraint (c_i).

15. The routing device (1) of any one of the preceding claims, the service function (SF) providing a mining service associated with a digital ledger; and the identifier (ID_SF) of the service function (SF) addressing all the instances (SF_m) of the service function (SF).

16. The routing device (1) of claim 15, the digital ledger comprising a blockchain-type digital ledger.

17. A method (2) of operating a routing device (1), the method (2) comprising: - establishing (21) a number of constraints (c_i) for the routing of the service request (R) to a number of instances (SF_m) of the service function (SF), each one of the number of constraints (c_i) indicating how many of the instances (SF_m) of the service function (SF) are reachable by a forwarding action in accordance with the routing; and - selectively forwarding (22) the service request (R) towards the number of instances (SF_m) of the service function (SF) in accordance with the number of constraints (c_i).

18. The method (2) of claim 17, being performed by the routing device (1) of any one of the claims 1 to 16.

19. A computer program, comprising executable instructions which, when executed by a processor (11), cause the processor (11) to perform the method (2) of claim 17 or claim 18.