WO2023025387A1 - Service demand redirection in ingress-based service routing - Google Patents

Service demand redirection in ingress-based service routing Download PDF

Info

Publication number
WO2023025387A1
WO2023025387A1 PCT/EP2021/073612 EP2021073612W WO2023025387A1 WO 2023025387 A1 WO2023025387 A1 WO 2023025387A1 EP 2021073612 W EP2021073612 W EP 2021073612W WO 2023025387 A1 WO2023025387 A1 WO 2023025387A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
packets
service function
instance
instances
Prior art date
Application number
PCT/EP2021/073612
Other languages
French (fr)
Inventor
Dirk Trossen
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to PCT/EP2021/073612 priority Critical patent/WO2023025387A1/en
Publication of WO2023025387A1 publication Critical patent/WO2023025387A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/09—Mapping addresses
    • H04L61/10—Mapping addresses of different types
    • H04L61/106—Mapping addresses of different types across networks, e.g. mapping telephone numbers to data network addresses
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1001—Protocols in which an application is distributed across nodes in the network for accessing one among a plurality of replicated servers
    • H04L67/1004—Server selection for load balancing
    • H04L67/1012—Server selection for load balancing based on compliance of requirements or conditions with available server resources

Definitions

  • the present disclosure relates to instance-affine, i.e., stateful service routing in view of mu instances of a service function.
  • the present disclosure specifically relates to a roi device, a server device, and associated methods of operating such devices.
  • a service client C may demand a service SF, which demand may be serve any one of multiple service instances SFi, SFi that are deployed at various network locat and which demand requires a mapping to a particular one of the multiple service instances.
  • Instance affinity as used herein may relate to the concept that one or more packets MUST be se the same service instance. In other words, once a particular service instance has been selected flow of packets relating to the requested service may need to be routed to this service instance to state being built up.
  • a stateless service such as file retrieval for over-the-top (( video may be provided by ever-changing service instances in response to each request.
  • a specific service instance SFi selected for providing the service SF may not be ab fulfil a demand although the demand may be fulfilled by another service instance SFj of the se SF deployed at another network location. For example, this may be the case when demar specific videos (or video chunks) from a CDN with non-identical CDN servers deployed different content at each site).
  • Another easy answer relates to flooding of service demands, i.e., sending the demand to all se instances and receiving replies from those who can fulfill the demand.
  • the incurred load make; approach prohibitive for many scenarios.
  • HTTP service demands (i.e., requests) could be redirected through a redirect parameter in a H response.
  • This assumes knowledge at the responding service instance that the service demand c successfully or positively be responded to (i.e., fulfilled) at said redirected service instance (e main or central server).
  • the redirection server may reply again with redirection to yet an ⁇ server.
  • the HTTP redirect approach requires alternative instances to be exposed to a i resolution service, such as the DNS, to be resolvable by the client for the redirected request o the canonical address, i.e., IP address, in redirected HTTP request.
  • the client req modification at application level (i.e., issuing new requests).
  • HTTP service demands could also be redirected to the ‘right instance’ that can fulfil the den This only works within single data center (DC) sites, i.e., purely DC-internally, not across i where the site-local decision logic has suitable knowledge to select the ‘right instance’
  • CDN load balancers apply an internal metric to dispatch to a ‘capable’ service instance. ] balancing uses knowledge (e.g., a catalogue) of content distribution to dispatch to ‘right’ se: instance. However, the decision is only made at a start of a session, so that load changes di session will lead to performance degradation, while catalogue knowledge requires centra realization.
  • knowledge e.g., a catalogue
  • Dynamic-Anycast embraces the edge computing paradigm in that it aims at prov: services by sharing computing resources from multiple edges, by computationally balar services using service- specific metrics. More specifically, service demands directed to a ‘se: identifier’ are mapped to a corresponding ‘service request’ at an ingress node. The maj decision is based on a service- specific metric, such as compute load, latency etc. Evidently, metrics could include fulfilment criteria, such as load information, but would require free updates to the routing system. Despite the high load for metric signaling there is still a possil of instantaneous rejection of demands due to a mismatch between the signaled metric anc situation at request arrival. In addition, it is not clear how to include aspects such as lacking availability into the decision metric.
  • An objective of the present disclosure is to utilize the capabilities of other service instanci positively responding to service demands with the goal to positively reply to the original se: demand despite the initially selected service instance being unable to.
  • a first aspect of the present disclosure relates to a routing device for routing of one or more pa ⁇ to a service function.
  • the routing device comprises a processor.
  • the processor is configure establish a first forwarding state for an initial packet of the one or more packets to a numb instances of the service function; receive a service demand comprising the one or more pac match the received service demand and a second forwarding state for subsequent packets of the or more packets to a particular one of the number of instances of the service function; i: received service demand fails to match the second forwarding state, establish the se forwarding state for the subsequent packets of the one or more packets, and send a service rec comprising the one or more packets to a next hop towards the particular one of the numb instances of the service function in accordance with the first forwarding state; and if the rccc service demand matches the second forwarding state, send the service request to a next hop tov the particular one of the number of instances of the service function in accordance with the se forwarding state.
  • the one or more received packets may respectively comprise a source address being indicative source of the service demand, and a destination address comprising a semantic identifier o service function; and/or the one or more sent packets may respectively comprise the source ad ⁇ being indicative of the source of the service demand; and the destination address comprisin identifier of the particular one of the number of instances of the service function; and/or the 01 more sent packets may further comprise a body of the service demand, and an exclusion list o service demand, if available.
  • the exclusion list may comprise a number of identifiers of the nui of instances of the service function.
  • the processor may further be configured, so as to establish the first forwarding state for the ii packet of the one or more packets, to receive, from an adjacent device, the identifier and a meti the particular one of the number of instances of the service function, and the semantic identifi the service function; and populate a routing table of the routing device with an entry comprisin semantic identifier of the service function, the identifier, the metric and a next hop being indie of the adjacent device.
  • the processor may further be configured, so as to establish the first forwarding state for the ii packet of the one or more packets, to re-advertise the semantic identifier of the service functionor identifier and the metric.
  • the processor may further be configured, so as to establish the second forwarding state fo subsequent packets of the one or more packets, to extract, from the received service demand exclusion list of identifiers, if available; retrieve, from the routing table and in dependence o received semantic identifier of the service function, one or more entries respectively comprisir identifier, a metric and a next hop; select, in dependence of the metric and the exclusion list, 01 the one or more entries comprising an identifier of an instance of the service function that i: included in the exclusion list and being indicative of the particular one of the number of insta of the service function; and populate an instance table of the routing device with an ⁇ comprising the semantic identifier of the service function, and the identifier and the next hop o particular one of the number of instances of the service function.
  • the processor may further be configured, so as to match the received service demand am second forwarding state, to retrieve, from the instance table and in dependence of the rece semantic identifier of the service function, an entry, if available, comprising the identifier am next hop of the particular one of the number of instances of the service function.
  • the exclusion list may be included in an IPv6 extension header.
  • a second aspect of the present disclosure relates to a method of operating a routing device, method comprises establishing a first forwarding state for an initial packet of one or more pat to be routed to a service function to a number of instances of the service function; receivi service demand comprising the one or more packets; matching the received service demand z second forwarding state for subsequent packets of the one or more packets to a particular one o number of instances of the service function; if the received service demand fails to matcl second forwarding state, establishing the second forwarding state for the subsequent packets o one or more packets; and sending a service request comprising the one or more packets to a hop towards the particular one of the number of instances of the service function in accord with the first forwarding state; and if the received service demand matches the second forwar state, sending the service request to a next hop towards the particular one of the numbc instances of the service function in accordance with the second forwarding state.
  • the method may be performed by the routing device of the first aspect or any o implementations .
  • a third aspect of the present disclosure relates to a server device.
  • the server device compri processor and an instance of a service function having an identifier.
  • the processor is configun establish a first forwarding state for an initial packet of one or more packets to the instance o service function; receive a service request comprising the one or more packets; and veri capability of the instance of the service function of positively responding to the service reque the instance of the service function is capable of positively responding to the service request, c the instance of the service function to send a service response comprising one or more resp packets; and if the instance of the service function is incapable of positively responding t ⁇ service request, establish a third forwarding state for the one or more response packets o service response; and send a service demand comprising one or more packets to a next hop tov a number of instances of the service function in accordance with the first forwarding state.
  • the one or more sent packets of the service response may respectively comprise a destin: address comprising a source address of the received service request; and/or the one or more packets of the service demand may respectively comprise a source address comprising the iden of the instance of the service function, and a destination address comprising a semantic identifi the service function; and/or the one or more sent packets of the service demand may fu comprise a body of the service request, and the exclusion list of identifiers.
  • the service response may comprise response data.
  • the service response may comprise a reference to the response data.
  • the processor may further be configured, so as to establish the first forwarding state for the ii packet of the one or more packets to the one or more instances of the service function, to advt the semantic identifier of the service function, and the identifier and a metric of the instance o service function.
  • the processor may further be configured to receive the service response comprising the or more packets; and query the pending request table of the instance of the service function ft entry based on the received service response; if the entry is unavailable, drop the received sei response; and if the entry is available, forward the service response comprising the one or i packets.
  • the one or more packets of the service response may respectively comprise the destination ad ⁇ comprising the source address of the entry; and the one or more packets of the service resp may further comprise the body of the received service response.
  • the processor may further be configured, so as to establish the third forwarding state for the oi more response packets of the service response, to extract, from the service request, an exclusio of identifiers, if available; insert the identifier of the instance of the service function ink exclusion list; and populate a pending request table of the instance of the service function wil entry comprising the source address, the destination address and a body of the service request.
  • a fourth aspect of the present disclosure relates to a method of operating a server device, method comprises establishing a first forwarding state for an initial packet of one or more pa* to an instance of a service function; receiving a service request comprising the one or more pac and verifying a capability of the instance of the service function of positively responding t* service request; if the instance of the service function is capable of positively responding t ⁇ service request, causing the instance of the service function to send a service response compr one or more packets, and if the instance of the service function is uncapable of posit responding to the service request, establishing a third forwarding state for the one or more resp packets of the service response; and sending a service demand comprising one or more packets next hop towards a number of instances of the service function in accordance with the forwarding state.
  • the method may be performed by the server device of the third aspect or any o implementations .
  • a fifth aspect of the present disclosure relates to a computer program.
  • the computer pro comprises executable instructions which, when executed by a processor, cause the process* perform the method of the second aspect or any of its implementations, or the method of the f ⁇ aspect or any of its implementations.
  • the present disclosure provides a service redirection mechanism by a purely distributed realiz of ‘finding the right service instance’, i.e., a ‘crawl search’ through service instances, which not require a global synchronization of possible fulfilment.
  • the mechanism ensures a positive service reply if any of the available service instances is ab reply positively.
  • Service instances who replied negatively are excluded from subsequent repli the service demand by deploying an exclusion filter that grows per each negative reply.
  • The: the capabilities of other service instances are utilized in responding to service demands wit! goal to positively reply to the original client demand despite the initial service instance(s) 1 unable to.
  • the mechanism can accommodate cases for not being able to respond positively are otherwise hard to capture through a pure metric -based decision, e.g., not requiring co: information being part of metric or responding to short-term fluctuations in instance load.
  • the mechanism is limited to ingress routers, not intermediary ones, which eases deployment avoids exposing service redirection to clients, which in turn eases deployment.
  • the mechanism can directly be built on ingress architectures at routing level, such as exp I; herein, or at application level, such as in an application-level load balancer, e.g., ALTO server.
  • the mechanism can use referencing in responses. This avoids unnecessary data transfers A replying from more than one service instance, and improves latency and bandwidth usage.
  • FIG. 1 illustrates an exemplary scenario in accordance with the present disclosure
  • FIGs. 2 and 3 illustrate, at different levels of detail, a routing device and a method of opcr the same in accordance with the present disclosure
  • FIGs. 4 and 5 illustrate, at different levels of detail, a server device and a method of operatin same in accordance with the present disclosure.
  • FIG. 1 illustrates an exemplary scenario in accordance with the present disclosure.
  • the scenario comprises a communication network indicated by a cloud shape and compr routing devices 3, 3’ interconnected by layer-3 network links.
  • the communication network further comprise an IP gateway 6 in layer-3 communication with a peering IP network 7.
  • Routing devices as used herein may generally relate to network nodes suitable for layer-3 rout flow of packets to a service function, and as such capable of semantic routing.
  • the communication network is a routed network, such as an IP network.
  • the routing devices 3, 3’ may collectively implement the semantic routing.
  • routing devices 3, 3’ may be distinguished into ingress routing devices 3 and interme ⁇ routing devices 3’. The latter will be ignored in the following since they are not required fo service redirection mechanism outlined herein. As such, any mention of routing devices 3 relates to ingress routing devices unless specifically stated otherwise.
  • the routing devices at the data centers do not need to be of type 3 in the above scei assuming that the service instances SFi are purely receiving packets (not initiating own requests act as clients to other functions). In other words, ingress routing devices 3 only exist when c devices 5 are attached.
  • Attached to the communication network are server devices 4 deployed at various network loca such as data centers, which are indicated by cloud shapes as well.
  • the server devices 4 collect host multiple instances SFi, SFi, SFi of a service function SF indicated by cloud si having input/output arrows.
  • Attached to the communication network are client devices 5, too.
  • the client devices 5 implement a semantic routing as well.
  • the client devices 5 may demand the service provided b service function SF. For example, if one of the client devices 5 indicated on the left side of F] demands the service of service function SF, the demand may be served / fulfilled by any one o multiple service instances SFi hosted by the server devices 4. Accordingly, the client’s der requires a mapping to a particular one of the multiple service instances SFi. This mapping may collectively be implemented by the ingress routing devices 3, the intermei routing devices 3’ and the server devices 4.
  • routing of service requests can be realized as extensions within solu such as (i) constraint-based service routing, (ii) suitable IPv6 header extensions or (iii) IP an; (with service identifier mapping to IP anycast address).
  • a client 5 sends a semantically addressed packet, i.e., including a semantic identifier (such hashed URL) as destination address - this is called service demand in the following. Ex one service demand is being sent by the client. As such, no modification of the client needed to utilize this mechanism.
  • a semantically addressed packet i.e., including a semantic identifier (such hashed URL) as destination address - this is called service demand in the following. Ex one service demand is being sent by the client. As such, no modification of the client needed to utilize this mechanism.
  • a receiving routing device 3 chooses a suitable service instance z based on a metric as del for this specific semantic identifier, transforming the service demand into a service reque. replacing the destination address with a binding identifier (i.e., IP address of the instance). ' no modification of the routing device 3 is needed for receiving client requests.
  • the service request is being routed to the chosen service instance z and processed at this se: instance z once received. If the request can be fulfilled, a corresponding response will be back to the source. If the request cannot be served / fulfilled, the service request is redirects the chosen service instance z by submitting a new service demand including the sem identifier of the service function and an exclusion filter with the binding IP address o instance.
  • a receiving ingress routing device 3 chooses a suitable service instance j based on the meh defined for this specific semantic identifier, taking into account the exclusion filter fo choice. Accordingly, the service instance z chosen previously will be excluded from the cl and not be chosen again. 5. Service instances will receive responses to their redirected requests and backtrack the resp from where the initial request came from. Service instances maintain a pending request (PRT) for that purpose.
  • PRT pending request
  • FIGs. 2 and 3 illustrate, at different levels of detail, a routing device 3 and a method 1 of open the same in accordance with the present disclosure.
  • the routing device 3 is suitable for routing of one or more packets to a service function.
  • the routing device 3 comprises a processor 31.
  • the routing device 3, and in particular its processor 31, may be configured to perform the metf of operating the routing device 3 of the second aspect or any of its implementations.
  • the method 1 comprises, in accordance with FIG. 2, establishing 11, receiving matching 13, establishing 14 and sending 15 steps.
  • the method 1 comprises: establishing Il a first forwarding state for an ii packet of one or more packets to be routed to a service function to a number of instances z o service function; receiving 72 a service demand comprising the one or more packets; matchin the received service demand and a second forwarding state for subsequent packets of the oi more packets to a particular one z of the number of instances of the service function; if the rccc service demand fails to match the second forwarding state, establishing 14 the second forwai state for the subsequent packets of the one or more packets; and sending 75 a service re ⁇ comprising the one or more packets to a next hop NH towards the particular one z of the numb instances of the service function in accordance with the first forwarding state; and if the rccc service demand matches the second forwarding state, sending 75 the service request to a next NH towards the particular one z of the number of instances of the service function in accord with the second forwarding state.
  • the one or more packets relate to a flow of packets, a.k.a. packet flow.
  • the processor 31 may further be configured, so as to establish 1 first forwarding state for the initial packet of the one or more packets, to receive 111, froi adjacent device, the identifier SF, and a metric rm of the particular one z of the number of insta of the service function, and the semantic identifier SF of the service function, as is indicate FIGs. 2, 3 by incoming signals / messages (A) from server devices 4 and (B) from other roi devices 3, 3 and populate 112 a routing table RT of the routing device 3 with an entry SF; SF NH comprising the semantic identifier SF of the service function, the identifier SFi, the metr and a next hop NH being indicative of the adjacent device.
  • the first forwarding state is maintained in the routing table RT of the respective roi device 3, and comprises entries / tuples of the form SF; SFi; rm; NH.
  • the insta of the service function SF identified by SFi may be reached via next hop NH and is associated a metric rm as defined for the specific semantic identifier for choosing a suitable service instanc
  • the processor 31 may further be configured, so as to esta the first forwarding state for the initial packet of the one or more packets, to re-advertise 11.
  • the processor 31 is fu configured to receive 72 a service demand comprising the one or more packets.
  • the sc demand may have been submitted by a client 5, or by a server device 4 (see step 26 of method FIGs. 4, 5) as will be explained in more detail below.
  • the processor 31 is further configured to match 13 the received service demand and a se forwarding state.
  • the second forwarding state is for subsequent packets of the one or more pa ⁇ to a particular one z of the number of instances of the service function.
  • the processor 31 may further be configured, so as to match /. received service demand and the second forwarding state, to retrieve 131, from the instance tab and in dependence of the received semantic identifier SF of the service function, an entry SF; NH, if available, comprising the identifier SF, and the next hop NH of the particular one z o number of instances of the service function.
  • the second forwarding state is maintained in the instance table IT of the respective roi device 3, and comprises entries / tuples of the form SF; SFi; NH. That is to say, the instance z c service function SF identified by SFi may be reached via next hop NH.
  • the processor 31 is fu configured to send 15 the service request to the next hop NH towards the particular one z o number of instances of the service function in accordance with the second forwarding state, indicated in FIGs. 2, 3 by outgoing signal / message (D).
  • the processor further configured to establish 14 the second forwarding state for the subsequent packets of the or more packets; and then send 75 a service request comprising the one or more packets to the hop NH towards the particular one z of the number of instances of the service functiono accordance with the first forwarding state, as is indicated in FIGs. 2, 3 by outgoing signal / mes (D).
  • routing devices 3 turn service demands that are directed towards a service function service requests specifically directed to the particular one z of the number of instances of the se: function. Relaying the service request towards the particular one z of the number of instances of the se: function may involve known network-layer (or application-layer) protocol interaction intermediary routing devices 3’.
  • the processor 31 may further be configured, so as to establish L second forwarding state for the subsequent packets of the one or more packets, to extract 141, the received service demand, an exclusion list EXCL of identifiers SFi, if available; retrieve from the routing table RT and in dependence of the received semantic identifier SF of the se function, one or more entries SF; SFi; rm; NH respectively comprising an identifier SFi, a metr and a next hop NH-, select 143, in dependence of the metric r and the exclusion list EXCL, oi the one or more entries SF; SFi; rm; NH comprising an identifier SFi of an instance z of the se function that is not included in the exclusion list EXCL and being indicative of the particular ⁇ of the number of instances of the service function; and populate 144 an instance table IT o routing device 3 with an entry SF; SFi; NH comprising the semantic identifier SF of the se function
  • forwarding an initial packet of the one or more packets replicates first forwai state (maintained in the routing table RT) for use as second forwarding state (maintained ii instance table IT) according to which the subsequent packets of the one or more packets forwarded.
  • This replication takes into account only those instances z of the service function tha not included in the exclusion list EXCL.
  • the exclusion list EXCL may be included in an IPv6 extension header.
  • the one or more received packets may respectively comprise a source address SA being indie of a source (e.g., client 5, or server device 4) of the service demand, and a destination address comprising a semantic identifier SF of the service function.
  • the one or more sent packets may respectively comprise the source address SA being indicatr the source of the service demand; and the destination address DA comprising an identifier S the particular one z of the number of instances of the service function.
  • the one or more sent packets may further comprise a body of the service demand, anc exclusion list EXCL of the service demand, if available.
  • the exclusion list EXCL may compr number of identifiers SFi of the number of instances z of the service function.
  • FIGs. 4 and 5 illustrate, at different levels of detail, a server device 4 and a method 2 of oper the same in accordance with the present disclosure.
  • the server device 4 comprises a processor 41 and an instance 42 of a service function havir identifier SFi.
  • the server device 4, and in particular its processor 41, is configured to perform the method operating the server device 4 of the third aspect or any of its implementations.
  • the method 2 comprises, in accordance with FIG. 4, establishing 21, receiving verifying 23, causing 24, establishing 25 and sending 26 steps.
  • the method 2 comprises: establishing 21 a first forwarding state for an ii packet of one or more packets to the instance 42 of the service function; receiving 22 a se request comprising the one or more packets; and verifying 23 a capability of the instance z o service function of positively responding to the service request; if the instance z of the se function is capable of positively responding to the service request, causing 24 the instance z o service function to send a service response comprising one or more packets, and if the instance the service function is uncapable of positively responding to the service request, establishing third forwarding state for the one or more response packets of the service response; and sendin a service demand comprising one or more packets to a next hop NH towards a number of instr z of the service function in accordance with the first forwarding state.
  • the processor 41 is configured to establish 21 a first forwarding stat an initial packet of one or more packets to the instance z of the service function.
  • the processor 41 may further be configured, so as to establish 2 first forwarding state for the initial packet of the one or more packets to the one or more instan of the service function, to advertise 211 the semantic identifier SF of the service function, an ⁇ identifier SF, and a metric rm of the instance 42 of the service function, as is indicated in FIGs. by outgoing signal / message (A).
  • the processor 41 is further configured to receive 22 a service request comprising the one or i packets, as is indicated in FIGs. 4, 5 by incoming signal / message (D).
  • the processor 41 is further configured to verify 23 a capability of the instance z of the sc function of positively responding to the service request.
  • the processor 41 is further configured to cause 24 the instance 42 of the service function to se service response comprising one or more response packets, which is indicated in FIGs. 4, outgoing signal / message (E).
  • the third forwarding state is maintained in the pending request table PRT of the insta of the service function hosted by the respective server device 4, and comprises entries / tup! the form SA, DA, BODY. That is to say, a pending service demand has been submitted from sc address SA (i.e., the submitting server device 4) to destination address DA (i.e., the sem identifier initially submitted by the client 5), and the body may enable a distinction of mu] pending demands submitted to a same DA. For example, the respective pending demand ma associated with a unique requestID included in the body.
  • the notion of ‘successful response’ can be, e.g., a 200OK in an HTTP request.
  • the one or more sent packets of the service response may respectively comprise a destin: address DA comprising a source address SA of the received service request.
  • the one or more sent packets of the service demand may respectively comprise a source addres comprising the identifier SE of the instance z of the service function, and a destination addres: comprising a semantic identifier SF of the service function.
  • the one or more sent packets of the service demand may further comprise a body of the se: request, and the exclusion list EXCL of identifiers SFi.
  • the service response may comprise response data, or a reference to the response data, which save bandwidth.
  • One form of referencing the response data may involve canonical addressing, IPAddress_of_successful_instance ⁇ video ⁇ chunk3.mp4, placed into the redirect field of an H response.
  • the client 5 will then need to implement the redirect when receiving the response the initial service instance to retrieve the actual data.
  • the processor 41 may further be configured to receive 27 the service response comprising the or more packets, as is indicated in FIGs. 4, 5 by incoming signal / message (E). This may b previously mentioned service response provided by the instance 42 of the service function (see 24 above), or a service response provided by another instance of the service function that capable of positively responding to a pending service demand submitted by the receiving st device 4.
  • the processor 41 may further be configured to query 28 the pending request table PRT o instance z of the service function for an entry SA, DA, BODY based on the received se: response.
  • the processor 41 may further be configured to drop (not shown received service response. If the entry SA, DA, BODY is available, the processor 41 may further be configured to forwai the service response comprising the one or more packets, towards the client 5 or server dev: that submitted the service demand, as is indicated in FIGs. 4, 5 by outgoing signal / message (F
  • Relaying the service response towards the client 5 or server device 4 which submitted the se: demand may involve known network-layer (or application-layer) protocol interaction intermediary routing devices 3’.
  • the one or more packets of the service response may respectively comprise the destination ad ⁇ DA comprising the source address SA of the entry SA, DA, BODY.
  • the one or more packets of the service response may further comprise the body of the rccc service response.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Disclosed is a routing device (3) for routing of one or more packets to a service function. The routing device (3) comprises a processor (31). The processor (31) is configured to establish (11) a first forwarding state for an initial packet of the one or more packets to a number of instances (i) of the service function; receive (12) a service demand comprising the one or more packets; match (13) the received service demand and a second forwarding state for subsequent packets of the one or more packets to a particular one (i) of the number of instances of the service function; if the received service demand fails to match the second forwarding state, establish (14) the second forwarding state for the subsequent packets of the one or more packets, and send (15) a service request comprising the one or more packets to a next hop (NH) towards the particular one (i) of the number of instances of the service function in accordance with the first forwarding state; and if the received service demand matches the second forwarding state, send (15) the service request to a next hop (NH) towards the particular one (i) of the number of instances of the service function in accordance with the second forwarding state. This enables positively replying to a service demand despite the initially selected service instance being unable to.

Description

SERVICE DEMAND REDIRECTION IN INGRESS-BASED SERVICE ROUTING
Technical Field
The present disclosure relates to instance-affine, i.e., stateful service routing in view of mu instances of a service function. In particular, the present disclosure specifically relates to a roi device, a server device, and associated methods of operating such devices.
Background Art
In a typical scenario, a service client C may demand a service SF, which demand may be serve any one of multiple service instances SFi, SFi that are deployed at various network locat and which demand requires a mapping to a particular one of the multiple service instances.
Instance affinity as used herein may relate to the concept that one or more packets MUST be se the same service instance. In other words, once a particular service instance has been selected flow of packets relating to the requested service may need to be routed to this service instance to state being built up. By contrast, a stateless service such as file retrieval for over-the-top (( video may be provided by ever-changing service instances in response to each request.
At times, a specific service instance SFi selected for providing the service SF may not be ab fulfil a demand although the demand may be fulfilled by another service instance SFj of the se SF deployed at another network location. For example, this may be the case when demar specific videos (or video chunks) from a CDN with non-identical CDN servers deployed different content at each site).
As such, the question arises where to obtain the right response to the service request.
An easy answer would require exact service instances so that any instance can reply successl This may not be possible since content is usually not exactly replicated but according to, regionalized demand patterns, so a local CDN server may well not be able to provide the cor while other instances may do so. Furthermore, non-fulfilment of service demands may not ju an issue of local data availability (e.g., video content) but also of a capability of a local se: instance to execute, e.g., when the service instance is overloaded with other requests.
Another easy answer relates to flooding of service demands, i.e., sending the demand to all se instances and receiving replies from those who can fulfill the demand. The incurred load make; approach prohibitive for many scenarios.
HTTP service demands (i.e., requests) could be redirected through a redirect parameter in a H response. This assumes knowledge at the responding service instance that the service demand c successfully or positively be responded to (i.e., fulfilled) at said redirected service instance (e main or central server). The redirection server may reply again with redirection to yet an< server. The HTTP redirect approach requires alternative instances to be exposed to a i resolution service, such as the DNS, to be resolvable by the client for the redirected request o the canonical address, i.e., IP address, in redirected HTTP request. In addition, the client req modification at application level (i.e., issuing new requests).
HTTP service demands could also be redirected to the ‘right instance’ that can fulfil the den This only works within single data center (DC) sites, i.e., purely DC-internally, not across i where the site-local decision logic has suitable knowledge to select the ‘right instance’
CDN load balancers apply an internal metric to dispatch to a ‘capable’ service instance. ] balancing uses knowledge (e.g., a catalogue) of content distribution to dispatch to ‘right’ se: instance. However, the decision is only made at a start of a session, so that load changes di session will lead to performance degradation, while catalogue knowledge requires centra realization.
Dynamic-Anycast (Dyncast) embraces the edge computing paradigm in that it aims at prov: services by sharing computing resources from multiple edges, by computationally balar services using service- specific metrics. More specifically, service demands directed to a ‘se: identifier’ are mapped to a corresponding ‘service request’ at an ingress node. The maj decision is based on a service- specific metric, such as compute load, latency etc. Evidently, metrics could include fulfilment criteria, such as load information, but would require free updates to the routing system. Despite the high load for metric signaling there is still a possil of instantaneous rejection of demands due to a mismatch between the signaled metric anc situation at request arrival. In addition, it is not clear how to include aspects such as lacking availability into the decision metric.
Summary
An objective of the present disclosure is to utilize the capabilities of other service instanci positively responding to service demands with the goal to positively reply to the original se: demand despite the initially selected service instance being unable to.
Embodiments of this disclosure are defined by the appended independent claims. Fu embodiments are set forth in the dependent claims and in the following description and drawing
A first aspect of the present disclosure relates to a routing device for routing of one or more pa< to a service function. The routing device comprises a processor. The processor is configure establish a first forwarding state for an initial packet of the one or more packets to a numb instances of the service function; receive a service demand comprising the one or more pac match the received service demand and a second forwarding state for subsequent packets of the or more packets to a particular one of the number of instances of the service function; i: received service demand fails to match the second forwarding state, establish the se forwarding state for the subsequent packets of the one or more packets, and send a service rec comprising the one or more packets to a next hop towards the particular one of the numb instances of the service function in accordance with the first forwarding state; and if the rccc service demand matches the second forwarding state, send the service request to a next hop tov the particular one of the number of instances of the service function in accordance with the se forwarding state. The one or more received packets may respectively comprise a source address being indicative source of the service demand, and a destination address comprising a semantic identifier o service function; and/or the one or more sent packets may respectively comprise the source ad< being indicative of the source of the service demand; and the destination address comprisin identifier of the particular one of the number of instances of the service function; and/or the 01 more sent packets may further comprise a body of the service demand, and an exclusion list o service demand, if available. The exclusion list may comprise a number of identifiers of the nui of instances of the service function.
The processor may further be configured, so as to establish the first forwarding state for the ii packet of the one or more packets, to receive, from an adjacent device, the identifier and a meti the particular one of the number of instances of the service function, and the semantic identifi the service function; and populate a routing table of the routing device with an entry comprisin semantic identifier of the service function, the identifier, the metric and a next hop being indie of the adjacent device.
The processor may further be configured, so as to establish the first forwarding state for the ii packet of the one or more packets, to re-advertise the semantic identifier of the service functior identifier and the metric.
The processor may further be configured, so as to establish the second forwarding state fo subsequent packets of the one or more packets, to extract, from the received service demand exclusion list of identifiers, if available; retrieve, from the routing table and in dependence o received semantic identifier of the service function, one or more entries respectively comprisir identifier, a metric and a next hop; select, in dependence of the metric and the exclusion list, 01 the one or more entries comprising an identifier of an instance of the service function that i: included in the exclusion list and being indicative of the particular one of the number of insta of the service function; and populate an instance table of the routing device with an < comprising the semantic identifier of the service function, and the identifier and the next hop o particular one of the number of instances of the service function. The processor may further be configured, so as to match the received service demand am second forwarding state, to retrieve, from the instance table and in dependence of the rece semantic identifier of the service function, an entry, if available, comprising the identifier am next hop of the particular one of the number of instances of the service function.
The exclusion list may be included in an IPv6 extension header.
A second aspect of the present disclosure relates to a method of operating a routing device, method comprises establishing a first forwarding state for an initial packet of one or more pat to be routed to a service function to a number of instances of the service function; receivi service demand comprising the one or more packets; matching the received service demand z second forwarding state for subsequent packets of the one or more packets to a particular one o number of instances of the service function; if the received service demand fails to matcl second forwarding state, establishing the second forwarding state for the subsequent packets o one or more packets; and sending a service request comprising the one or more packets to a hop towards the particular one of the number of instances of the service function in accord with the first forwarding state; and if the received service demand matches the second forwar state, sending the service request to a next hop towards the particular one of the numbc instances of the service function in accordance with the second forwarding state.
The method may be performed by the routing device of the first aspect or any o implementations .
A third aspect of the present disclosure relates to a server device. The server device compri processor and an instance of a service function having an identifier. The processor is configun establish a first forwarding state for an initial packet of one or more packets to the instance o service function; receive a service request comprising the one or more packets; and veri capability of the instance of the service function of positively responding to the service reque the instance of the service function is capable of positively responding to the service request, c the instance of the service function to send a service response comprising one or more resp packets; and if the instance of the service function is incapable of positively responding t< service request, establish a third forwarding state for the one or more response packets o service response; and send a service demand comprising one or more packets to a next hop tov a number of instances of the service function in accordance with the first forwarding state.
The one or more sent packets of the service response may respectively comprise a destin: address comprising a source address of the received service request; and/or the one or more packets of the service demand may respectively comprise a source address comprising the iden of the instance of the service function, and a destination address comprising a semantic identifi the service function; and/or the one or more sent packets of the service demand may fu comprise a body of the service request, and the exclusion list of identifiers.
The service response may comprise response data.
The service response may comprise a reference to the response data.
The processor may further be configured, so as to establish the first forwarding state for the ii packet of the one or more packets to the one or more instances of the service function, to advt the semantic identifier of the service function, and the identifier and a metric of the instance o service function.
The processor may further be configured to receive the service response comprising the or more packets; and query the pending request table of the instance of the service function ft entry based on the received service response; if the entry is unavailable, drop the received sei response; and if the entry is available, forward the service response comprising the one or i packets.
The one or more packets of the service response may respectively comprise the destination ad< comprising the source address of the entry; and the one or more packets of the service resp may further comprise the body of the received service response. The processor may further be configured, so as to establish the third forwarding state for the oi more response packets of the service response, to extract, from the service request, an exclusio of identifiers, if available; insert the identifier of the instance of the service function ink exclusion list; and populate a pending request table of the instance of the service function wil entry comprising the source address, the destination address and a body of the service request.
A fourth aspect of the present disclosure relates to a method of operating a server device, method comprises establishing a first forwarding state for an initial packet of one or more pa* to an instance of a service function; receiving a service request comprising the one or more pac and verifying a capability of the instance of the service function of positively responding t* service request; if the instance of the service function is capable of positively responding t< service request, causing the instance of the service function to send a service response compr one or more packets, and if the instance of the service function is uncapable of posit responding to the service request, establishing a third forwarding state for the one or more resp packets of the service response; and sending a service demand comprising one or more packets next hop towards a number of instances of the service function in accordance with the forwarding state.
The method may be performed by the server device of the third aspect or any o implementations .
A fifth aspect of the present disclosure relates to a computer program. The computer pro: comprises executable instructions which, when executed by a processor, cause the process* perform the method of the second aspect or any of its implementations, or the method of the f< aspect or any of its implementations.
Of note, all devices, elements, units and means described in the present application coul implemented in the software or hardware elements or any kind of combination thereof. All which are performed by the various entities described in the present application as well a: functionalities described to be performed by the various entities are intended to mean tha respective entity is adapted to or configured to perform the respective steps and functional Even if, in the following description of specific embodiments, a specific functionality or step i performed by external entities is not reflected in the description of a specific detailed eleme that entity which performs that specific step or functionality, it should be clear for a skilled pc that these methods and functionalities can be implemented in respective software or hard elements, or any kind of combination thereof.
Advantageous Effects
The present disclosure provides a service redirection mechanism by a purely distributed realiz of ‘finding the right service instance’, i.e., a ‘crawl search’ through service instances, which not require a global synchronization of possible fulfilment.
The mechanism ensures a positive service reply if any of the available service instances is ab reply positively. Service instances who replied negatively are excluded from subsequent repli the service demand by deploying an exclusion filter that grows per each negative reply. The: the capabilities of other service instances are utilized in responding to service demands wit! goal to positively reply to the original client demand despite the initial service instance(s) 1 unable to.
Conversely, a negative response only occurs if the service instances overall are unable to fulfil particular, the mechanism can accommodate cases for not being able to respond positively are otherwise hard to capture through a pure metric -based decision, e.g., not requiring co: information being part of metric or responding to short-term fluctuations in instance load.
The mechanism is limited to ingress routers, not intermediary ones, which eases deployment avoids exposing service redirection to clients, which in turn eases deployment.
The mechanism can directly be built on ingress architectures at routing level, such as exp I; herein, or at application level, such as in an application-level load balancer, e.g., ALTO server. The mechanism can use referencing in responses. This avoids unnecessary data transfers A replying from more than one service instance, and improves latency and bandwidth usage.
The technical effects and advantages described above equally apply to the routing device server device and the associated methods of operating the same having corresponding features.
Brief Description of Drawings
The above-described aspects and implementations will now be explained with reference tc accompanying drawings, in which the same or similar reference numerals designate the san similar elements.
The features of these aspects and implementations may be combined with each other ui specifically stated otherwise.
The drawings are to be regarded as being schematic representations, and elements illustrated ii drawings are not necessarily shown to scale. Rather, the various elements are represented such their function and general purpose become apparent to those skilled in the art.
FIG. 1 illustrates an exemplary scenario in accordance with the present disclosure;
FIGs. 2 and 3 illustrate, at different levels of detail, a routing device and a method of opcr the same in accordance with the present disclosure; and
FIGs. 4 and 5 illustrate, at different levels of detail, a server device and a method of operatin same in accordance with the present disclosure.
Detailed Descriptions of Drawings
FIG. 1 illustrates an exemplary scenario in accordance with the present disclosure. The scenario comprises a communication network indicated by a cloud shape and compr routing devices 3, 3’ interconnected by layer-3 network links. The communication network further comprise an IP gateway 6 in layer-3 communication with a peering IP network 7.
Routing devices as used herein may generally relate to network nodes suitable for layer-3 rout flow of packets to a service function, and as such capable of semantic routing.
In other words, the communication network is a routed network, such as an IP network. As f the routing devices 3, 3’ may collectively implement the semantic routing.
The routing devices 3, 3’ may be distinguished into ingress routing devices 3 and interme< routing devices 3’. The latter will be ignored in the following since they are not required fo service redirection mechanism outlined herein. As such, any mention of routing devices 3 relates to ingress routing devices unless specifically stated otherwise.
Technically, the routing devices at the data centers do not need to be of type 3 in the above scei assuming that the service instances SFi are purely receiving packets (not initiating own requests act as clients to other functions). In other words, ingress routing devices 3 only exist when c devices 5 are attached.
Attached to the communication network are server devices 4 deployed at various network loca such as data centers, which are indicated by cloud shapes as well. The server devices 4 collect host multiple instances SFi, SFi, SFi of a service function SF indicated by cloud si having input/output arrows.
Attached to the communication network are client devices 5, too. The client devices 5 implement a semantic routing as well. The client devices 5 may demand the service provided b service function SF. For example, if one of the client devices 5 indicated on the left side of F] demands the service of service function SF, the demand may be served / fulfilled by any one o multiple service instances SFi hosted by the server devices 4. Accordingly, the client’s der requires a mapping to a particular one of the multiple service instances SFi. This mapping may collectively be implemented by the ingress routing devices 3, the intermei routing devices 3’ and the server devices 4.
It may be appreciated that routing of service requests can be realized as extensions within solu such as (i) constraint-based service routing, (ii) suitable IPv6 header extensions or (iii) IP an; (with service identifier mapping to IP anycast address).
Before explaining the devices 3, 4 and their interaction in more detail with reference to FIGs. below, the service redirection mechanism is briefly outlined as follows:
1. A client 5 sends a semantically addressed packet, i.e., including a semantic identifier (such hashed URL) as destination address - this is called service demand in the following. Ex one service demand is being sent by the client. As such, no modification of the client needed to utilize this mechanism.
2. A receiving routing device 3 chooses a suitable service instance z based on a metric as del for this specific semantic identifier, transforming the service demand into a service reque. replacing the destination address with a binding identifier (i.e., IP address of the instance). ' no modification of the routing device 3 is needed for receiving client requests.
3. The service request is being routed to the chosen service instance z and processed at this se: instance z once received. If the request can be fulfilled, a corresponding response will be back to the source. If the request cannot be served / fulfilled, the service request is redirects the chosen service instance z by submitting a new service demand including the sem identifier of the service function and an exclusion filter with the binding IP address o instance.
4. A receiving ingress routing device 3 chooses a suitable service instance j based on the meh defined for this specific semantic identifier, taking into account the exclusion filter fo choice. Accordingly, the service instance z chosen previously will be excluded from the cl and not be chosen again. 5. Service instances will receive responses to their redirected requests and backtrack the resp from where the initial request came from. Service instances maintain a pending request (PRT) for that purpose.
FIGs. 2 and 3 illustrate, at different levels of detail, a routing device 3 and a method 1 of open the same in accordance with the present disclosure.
The routing device 3 is suitable for routing of one or more packets to a service function.
As shown in FIG. 2, the routing device 3 comprises a processor 31.
The routing device 3, and in particular its processor 31, may be configured to perform the metf of operating the routing device 3 of the second aspect or any of its implementations.
In summary, the method 1 comprises, in accordance with FIG. 2, establishing 11, receiving matching 13, establishing 14 and sending 15 steps.
More specifically, the method 1 comprises: establishing Il a first forwarding state for an ii packet of one or more packets to be routed to a service function to a number of instances z o service function; receiving 72 a service demand comprising the one or more packets; matchin the received service demand and a second forwarding state for subsequent packets of the oi more packets to a particular one z of the number of instances of the service function; if the rccc service demand fails to match the second forwarding state, establishing 14 the second forwai state for the subsequent packets of the one or more packets; and sending 75 a service re< comprising the one or more packets to a next hop NH towards the particular one z of the numb instances of the service function in accordance with the first forwarding state; and if the rccc service demand matches the second forwarding state, sending 75 the service request to a next NH towards the particular one z of the number of instances of the service function in accord with the second forwarding state. In terms of device features, the processor 31 is configured to establish 11 a first forwarding f The first forwarding state is for an initial packet of the one or more packets to a numbs instances z of the service function.
As used herein, the one or more packets relate to a flow of packets, a.k.a. packet flow.
In accordance with FIG. 3, the processor 31 may further be configured, so as to establish 1 first forwarding state for the initial packet of the one or more packets, to receive 111, froi adjacent device, the identifier SF, and a metric rm of the particular one z of the number of insta of the service function, and the semantic identifier SF of the service function, as is indicate FIGs. 2, 3 by incoming signals / messages (A) from server devices 4 and (B) from other roi devices 3, 3 and populate 112 a routing table RT of the routing device 3 with an entry SF; SF NH comprising the semantic identifier SF of the service function, the identifier SFi, the metr and a next hop NH being indicative of the adjacent device.
Of note, the first forwarding state is maintained in the routing table RT of the respective roi device 3, and comprises entries / tuples of the form SF; SFi; rm; NH. In other words, the insta of the service function SF identified by SFi may be reached via next hop NH and is associated a metric rm as defined for the specific semantic identifier for choosing a suitable service instanc
With continued reference to FIG. 3, the processor 31 may further be configured, so as to esta the first forwarding state for the initial packet of the one or more packets, to re-advertise 11. semantic identifier SF of the service function, the identifier SFi and the metric rm, as is indicat FIGs. 2, 3 by outgoing signal / message (B), to other routing devices 3, 3
As is indicated in FIGs. 2, 3 by incoming signal / message (C), the processor 31 is fu configured to receive 72 a service demand comprising the one or more packets. The sc demand may have been submitted by a client 5, or by a server device 4 (see step 26 of method FIGs. 4, 5) as will be explained in more detail below. The processor 31 is further configured to match 13 the received service demand and a se forwarding state. The second forwarding state is for subsequent packets of the one or more pa< to a particular one z of the number of instances of the service function.
In accordance with FIG. 3, the processor 31 may further be configured, so as to match /. received service demand and the second forwarding state, to retrieve 131, from the instance tab and in dependence of the received semantic identifier SF of the service function, an entry SF; NH, if available, comprising the identifier SF, and the next hop NH of the particular one z o number of instances of the service function.
Of note, the second forwarding state is maintained in the instance table IT of the respective roi device 3, and comprises entries / tuples of the form SF; SFi; NH. That is to say, the instance z c service function SF identified by SFi may be reached via next hop NH.
If the received service demand matches the second forwarding state, the processor 31 is fu configured to send 15 the service request to the next hop NH towards the particular one z o number of instances of the service function in accordance with the second forwarding state, indicated in FIGs. 2, 3 by outgoing signal / message (D).
If the received service demand fails to match the second forwarding state, the processor . further configured to establish 14 the second forwarding state for the subsequent packets of the or more packets; and then send 75 a service request comprising the one or more packets to the hop NH towards the particular one z of the number of instances of the service functio accordance with the first forwarding state, as is indicated in FIGs. 2, 3 by outgoing signal / mes (D).
As such, routing devices 3 turn service demands that are directed towards a service function service requests specifically directed to the particular one z of the number of instances of the se: function. Relaying the service request towards the particular one z of the number of instances of the se: function may involve known network-layer (or application-layer) protocol interaction intermediary routing devices 3’.
In accordance with FIG. 3, the processor 31 may further be configured, so as to establish L second forwarding state for the subsequent packets of the one or more packets, to extract 141, the received service demand, an exclusion list EXCL of identifiers SFi, if available; retrieve from the routing table RT and in dependence of the received semantic identifier SF of the se function, one or more entries SF; SFi; rm; NH respectively comprising an identifier SFi, a metr and a next hop NH-, select 143, in dependence of the metric r and the exclusion list EXCL, oi the one or more entries SF; SFi; rm; NH comprising an identifier SFi of an instance z of the se function that is not included in the exclusion list EXCL and being indicative of the particular < of the number of instances of the service function; and populate 144 an instance table IT o routing device 3 with an entry SF; SFi; NH comprising the semantic identifier SF of the se function, and the identifier SFi and the next hop NH of the particular one z of the num instances of the service function.
In other words, forwarding an initial packet of the one or more packets replicates first forwai state (maintained in the routing table RT) for use as second forwarding state (maintained ii instance table IT) according to which the subsequent packets of the one or more packets forwarded. This replication takes into account only those instances z of the service function tha not included in the exclusion list EXCL.
The exclusion list EXCL may be included in an IPv6 extension header.
The one or more received packets may respectively comprise a source address SA being indie of a source (e.g., client 5, or server device 4) of the service demand, and a destination address comprising a semantic identifier SF of the service function. The one or more sent packets may respectively comprise the source address SA being indicatr the source of the service demand; and the destination address DA comprising an identifier S the particular one z of the number of instances of the service function.
The one or more sent packets may further comprise a body of the service demand, anc exclusion list EXCL of the service demand, if available. The exclusion list EXCL may compr number of identifiers SFi of the number of instances z of the service function.
FIGs. 4 and 5 illustrate, at different levels of detail, a server device 4 and a method 2 of oper the same in accordance with the present disclosure.
The server device 4 comprises a processor 41 and an instance 42 of a service function havir identifier SFi.
The server device 4, and in particular its processor 41, is configured to perform the method operating the server device 4 of the third aspect or any of its implementations.
In summary, the method 2 comprises, in accordance with FIG. 4, establishing 21, receiving verifying 23, causing 24, establishing 25 and sending 26 steps.
More specifically, the method 2 comprises: establishing 21 a first forwarding state for an ii packet of one or more packets to the instance 42 of the service function; receiving 22 a se request comprising the one or more packets; and verifying 23 a capability of the instance z o service function of positively responding to the service request; if the instance z of the se function is capable of positively responding to the service request, causing 24 the instance z o service function to send a service response comprising one or more packets, and if the instance the service function is uncapable of positively responding to the service request, establishing third forwarding state for the one or more response packets of the service response; and sendin a service demand comprising one or more packets to a next hop NH towards a number of instr z of the service function in accordance with the first forwarding state. In terms of device features, the processor 41 is configured to establish 21 a first forwarding stat an initial packet of one or more packets to the instance z of the service function.
In accordance with FIG. 5, the processor 41 may further be configured, so as to establish 2 first forwarding state for the initial packet of the one or more packets to the one or more instan of the service function, to advertise 211 the semantic identifier SF of the service function, an< identifier SF, and a metric rm of the instance 42 of the service function, as is indicated in FIGs. by outgoing signal / message (A).
The processor 41 is further configured to receive 22 a service request comprising the one or i packets, as is indicated in FIGs. 4, 5 by incoming signal / message (D).
The processor 41 is further configured to verify 23 a capability of the instance z of the sc function of positively responding to the service request.
If the instance z of the service function is capable of positively responding to the service req the processor 41 is further configured to cause 24 the instance 42 of the service function to se service response comprising one or more response packets, which is indicated in FIGs. 4, outgoing signal / message (E).
Of note, the third forwarding state is maintained in the pending request table PRT of the insta of the service function hosted by the respective server device 4, and comprises entries / tup! the form SA, DA, BODY. That is to say, a pending service demand has been submitted from sc address SA (i.e., the submitting server device 4) to destination address DA (i.e., the sem identifier initially submitted by the client 5), and the body may enable a distinction of mu] pending demands submitted to a same DA. For example, the respective pending demand ma associated with a unique requestID included in the body.
The notion of ‘successful response’ can be, e.g., a 200OK in an HTTP request. The one or more sent packets of the service response may respectively comprise a destin: address DA comprising a source address SA of the received service request.
The one or more sent packets of the service demand may respectively comprise a source addres comprising the identifier SE of the instance z of the service function, and a destination addres: comprising a semantic identifier SF of the service function.
The one or more sent packets of the service demand may further comprise a body of the se: request, and the exclusion list EXCL of identifiers SFi.
The service response may comprise response data, or a reference to the response data, which save bandwidth.
One form of referencing the response data may involve canonical addressing, IPAddress_of_successful_instance\video\chunk3.mp4, placed into the redirect field of an H response. The client 5 will then need to implement the redirect when receiving the response the initial service instance to retrieve the actual data.
The processor 41 may further be configured to receive 27 the service response comprising the or more packets, as is indicated in FIGs. 4, 5 by incoming signal / message (E). This may b previously mentioned service response provided by the instance 42 of the service function (see 24 above), or a service response provided by another instance of the service function that capable of positively responding to a pending service demand submitted by the receiving st device 4.
The processor 41 may further be configured to query 28 the pending request table PRT o instance z of the service function for an entry SA, DA, BODY based on the received se: response.
If such an entry is unavailable, the processor 41 may further be configured to drop (not shown received service response. If the entry SA, DA, BODY is available, the processor 41 may further be configured to forwai the service response comprising the one or more packets, towards the client 5 or server dev: that submitted the service demand, as is indicated in FIGs. 4, 5 by outgoing signal / message (F
Relaying the service response towards the client 5 or server device 4 which submitted the se: demand may involve known network-layer (or application-layer) protocol interaction intermediary routing devices 3’.
The one or more packets of the service response may respectively comprise the destination ad< DA comprising the source address SA of the entry SA, DA, BODY.
The one or more packets of the service response may further comprise the body of the rccc service response.
The present disclosure has been described in conjunction with various embodiments as exampl well as implementations. However, other variations can be understood and effected by t persons skilled in the art and practicing the claimed matter, from the studies of the drawings, disclosure and the independent claims. In the claims as well as in the description the 1 “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” not exclude a plurality. A single element or other unit may fulfill the functions of several entiti items recited in the claims. The mere fact that certain measures are recited in the mutual diffi dependent claims does not indicate that a combination of these measures cannot be used i advantageous implementation.

Claims

Claims
1. A routing device (3) for routing of one or more packets to a service function, the routing dev (3) comprising a processor (31) configured to establish (11) a first forwarding state for an initial packet of the one or more packets number of instances (i) of the service function; receive (12) a service demand comprising the one or more packets, matching (13) the received service demand and a second forwarding state for subsequent packets of the one or more packets to a particular one (i) of the number < instances of the service function, if the received service demand fails to match the second forwarding state, establish (14) the second forwarding state for the subsequent packets of the one or n packets; send (15) a service request comprising the one or more packets to a next hop (NH) towards the particular one (i) of the number of instances of the service function in accordance with the first forwarding state, and if the received service demand matches the second forwarding state, send (15) the service request to a next hop (NH) towards the particular one (i) of the number of instances of the service function in accordance with the second forwardir state.
2. The routing device (3) of claim 1, the one or more received packets respectively comprising a source address (SA) being indicative of a source of the service demand, and a destination address (DA) comprising a semantic identifier (SF) of the service fund and/or the one or more sent packets respectively comprising the source address (SA) being indicative of the source of the service demand; and the destination address (DA) comprising an identifier (SFi) of the particular one (i) c the number of instances of the service function; and/or the one or more sent packets further comprising a body (BODY) of the service demand, and an exclusion list (EXCL) of the service demand, if available, the exclusion list (EXC comprising a number of identifiers (SFi) of the number of instances (i) of the service function.
3. The routing device (3) of claim 2, wherein the processor (31) is further configured, so as to establish (11) the first forward state for the initial packet of the one or more packets, to: receive (111), from an adjacent device, the identifier (SFi) and a metric (rm) of the particular one (i) of the number of instances of the service function, and the semanti identifier (SF) of the service function; and populate (112) a routing table (RT) of the routing device (3) with an entry (SF; SFi; NH) comprising the semantic identifier (SF) of the service function, the identifier (S the metric (rm) and a next hop (NH) being indicative of the adjacent device.
4. The routing device (3) of claim 3, wherein the processor (31) is further configured, so as to establish the first forwarding s for the initial packet of the one or more packets, to: re-adv ertise (113) the semantic identifier (SF) of the service function, the identifier i and the metric (rm).
5. The routing device (3) of any one of the claims 2 to 4, wherein the processor (31) is further configured, so as to establish (14) the second forwarding state for the subsequent packets of the one or more packets, to: extract (141 ), from the received service demand, the exclusion list (EXCL) of identil (SFi), if available; retrieve (142), from the routing table (RT) and in dependence of the received seman identifier (SF) of the service function, one or more entries (SF; SFi; rm; NH) respectively comprising an identifier (SFi), a metric (rm) and a next hop (NH)-, select (143), in dependence of the metric (rm) and the exclusion list (EXCL), one of i one or more entries (SF; SFi; rm; NH) comprising an identifier (SFi) of an instance ( the service function that is not included in the exclusion list (EXCL) and being indicative of the particular one (i) of the number of instances of the service function populate (144) an instance table (IT) of the routing device (3) with an entry (SF; SF, NH) comprising the semantic identifier (SF) of the service function, and the identifii (SFi) and the next hop (NH) of the particular one (i) of the number of instances of th service function.
6. The routing device (3) of claim 5, wherein the processor (31) is further configured, so as to match (13) the received servic demand and the second forwarding state, to: retrieve (131), from the instance table (IT) and in dependence of the received seman identifier (SF) of the service function, an entry (SF; SFi; NH), if available, comprisi the identifier (SFi) and the next hop (NH) of the particular one (i) of the number of instances of the service function.
7. The routing device (3) of any one of the claims 2 to 6, wherein the exclusion list (EXCL) is included in an IPv6 extension header. thod (1) of operating a routing device (3). comprising establishing (11) a first forwarding state for an initial packet of one or more packets be routed to a service function to a number of instances (i) of the service function; receive (12) a service demand comprising the one or more packets, matching (13) the received service demand and a second forwarding state for subsequent packets of the one or more packets to a particular one (i) of the number < instances of the service function, if the received service demand fails to match the second forwarding state, establishing (14) the second forwarding state for the subsequent packets of the one c more packets; sending (15) a service request comprising the one or more packets to a next hop (Nt towards the particular one (i) of the number of instances of the service function in accordance with the first forwarding state, and if the received service demand matches the second forwarding state, sending (15) the service request to a next hop (NH) towards the particular one (i) of number of instances of the service function in accordance with the second forwardir state. ethod (1) of claim 8, being performed by the routing device (3) of any one of the claims 1 to 7. erver device (4), comprising a processor (41); and an instance (42) of a service function having an identifier (SFi) the processor (41) configured to establish (21) a first forwarding state for an initial packet of one or more packets to instance (i) of the service function; receive (22) a service request comprising the one or more packets; verify (23) a capability of the instance (i) of the service function of positively responding to the service request; if the instance (i) of the service function is capable of positively responding to the servic request, cause (24) the instance (42) of the service function to send a service response comprising one or more response packets, and if the instance (i) of the service function is incapable of positively responding to the ser request, establish (25) a third forwarding state for the one or more response packets of the service response; and send (26) a service demand comprising one or more packets to a next hop (NH) tow a number of instances (i) of the service function in accordance with the first forwarc state.
11. The server device (4) of claim 10, the one or more sent packets of the service response respectively comprising a destination address (DA) comprising a source address (SA of the received sen request; and/or the one or more sent packets of the service demand respectively comprising a source address (SA) comprising the identifier (SFi) of the instance (i) of the sei function, and a destination address (DA) comprising a semantic identifier (SF) of the service function, and/or the one or more sent packets of the service demand further comprising a body (BODY) of the service request, and the exclusion list (EXCL) of identifiers (SFi).
12. The server device (4) of claim 9 or claim 10, wherein the service response comprises response data.
13. The server device (4) of claim 9 or claim 10, wherein the service response comprises a reference to the response data.
14. The server device (4) of any one of the claims 9 to 13, wherein the processor (41) is further configured, so as to establish (21) the first forward state for the initial packet of the one or more packets to the one or more instances (i) of the serv function, to: advertise (211) the semantic identifier (SF) of the service function, and the idcntific (SFi) and a metric (rm) of the instance (42) of the service function.
15. The server device (4) of any one of the claims 10 to 14, wherein the processor (41 ) is further configured to: receive (27) the service response comprising the one or more packets; query (28) the pending request table (PRT) of the instance (i) of the service function an entry (SA, DA, BODY) based on the received service response; if the entry (SA, DA, BODY) is unavailable, drop the received service response; and if the entry (SA, DA, BODY) is available, forward (29) the service response comprising the one or more packets.
16. The server device (4) of claim 15, the one or more packets of the service response respectively comprising the destination address (DA) comprising the source address (SA) of the entry (S4 DA, BODY)-, the one or more packets of the service response further comprising the body (BODY) of the received service response.
17. The server device (4) of any one of the claims 10 to 16, wherein the processor (41) is further configured, so as to establish (25) the third forwarding sta for the one or more response packets of the service response, to: extract (257 ), from the service request, an exclusion list (EXCL) of identifiers (SFi), available; insert (252) the identifier (SFi) of the instance (i) of the service function into the exclusion list (EXCL)-, and populate (253) a pending request table (PRE) of the instance (i) of the service functi with an entry (SA, DA, BODY) comprising the source address (SA), the destination address (DA) and a body (BODY) of the service request.
18. A method (2) of operating a server device (4), comprising establishing (21) a first forwarding state for an initial packet of one or more packets an instance (42) of a service function; receiving (22) a service request comprising the one or more packets; verifying (23) a capability of the instance (i) of the service function of positively responding to the service request; if the instance (i) of the service function is capable of positively responding to the servic request, causing (24) the instance (i) of the service function to send a service response comprising one or more packets, and if the instance (i) of the service function is uncapable of positively responding to the ser request, establishing (25) a third forwarding state for the one or more response packets of the service response; and sending (26) a service demand comprising one or more packets to a next hop (NH) towards a number of instances (i) of the service function in accordance with the firsl forwarding state.
19. The method (2) of claim 18, being performed by the server device (4) of any one of the claims 10 to 17. 20. A computer program, comprising executable instructions which, when executed by a processor (31, 41 ), cause the process (31, 41 ) to perform the method (1) of claim 8 or claim 9 or the method (2) of claim 18 or claim
PCT/EP2021/073612 2021-08-26 2021-08-26 Service demand redirection in ingress-based service routing WO2023025387A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2021/073612 WO2023025387A1 (en) 2021-08-26 2021-08-26 Service demand redirection in ingress-based service routing

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2021/073612 WO2023025387A1 (en) 2021-08-26 2021-08-26 Service demand redirection in ingress-based service routing

Publications (1)

Publication Number Publication Date
WO2023025387A1 true WO2023025387A1 (en) 2023-03-02

Family

ID=77693511

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/073612 WO2023025387A1 (en) 2021-08-26 2021-08-26 Service demand redirection in ingress-based service routing

Country Status (1)

Country Link
WO (1) WO2023025387A1 (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170099194A1 (en) * 2014-06-17 2017-04-06 Huawei Technologies Co., Ltd. Service flow processing method, apparatus, and device
US20170264677A1 (en) * 2014-11-28 2017-09-14 Huawei Technologies Co., Ltd. Service Processing Apparatus and Method

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170099194A1 (en) * 2014-06-17 2017-04-06 Huawei Technologies Co., Ltd. Service flow processing method, apparatus, and device
US20170264677A1 (en) * 2014-11-28 2017-09-14 Huawei Technologies Co., Ltd. Service Processing Apparatus and Method

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KING LANCASTER UNIVERSITY A FARREL OLD DOG CONSULTING D: "A Survey of Semantic Internet Routing Techniques draft-king-irtf-semantic-routing-survey-02; draft-king-irtf-semantic-routing-survey-02.txt", no. 2, 28 June 2021 (2021-06-28), pages 1 - 32, XP015146518, Retrieved from the Internet <URL:https://tools.ietf.org/html/draft-king-irtf-semantic-routing-survey-02> [retrieved on 20210628] *
LI L IANNONE D TROSSEN HUAWEI TECHNOLOGIES P LIU CHINA MOBILE Y: "Dynamic-Anycast Architecture; draft-li-dyncast-architecture-00.txt", 15 February 2021 (2021-02-15), pages 1 - 15, XP015144195, Retrieved from the Internet <URL:https://tools.ietf.org/html/draft-li-dyncast-architecture-00> [retrieved on 20210215] *

Similar Documents

Publication Publication Date Title
US10038779B2 (en) Intercepting voice over IP communications and other data communications
US8918469B2 (en) Methods, systems, and computer readable media for sharing diameter binding data
US8601073B2 (en) Methods, systems, and computer readable media for source peer capacity-based diameter load sharing
EP2583415B1 (en) Method, diameter node, and computer readable medium for providing dynamic origination-based routing key registration in a diameter network
US8958282B2 (en) 1-for-N redundancy in private IP session border control networks
US20090119386A1 (en) Method and arrangement for data transmission between peer-to-peer networks
KR20130098403A (en) Method and router for service named routing
US20130232278A1 (en) IPv4 Data Center Support for IPv4 and IPv6 Visitors
JP6106334B2 (en) Method, system and computer readable medium for performing advanced service routing
EP2928118B1 (en) System and method for dynamic name configuration in content-centric networks
US8085759B2 (en) Method for establishing a VoIP communication using a peer-to-peer databank
EP1528745B1 (en) Communication method and apparatus
EP2594049B1 (en) Sip-based call session server and message-routing method
EP2706737B1 (en) Method, device, and system for obtaining address of sip registration server
WO2008052474A1 (en) Business message transmission method, system and apparatus
CN106970843B (en) Remote calling method and device
JP3666654B2 (en) Internet communication method {MethodforanInternetCommunication}
CN110601989A (en) Network traffic balancing method and device
CN106790502B (en) Load balancing system of IPv4 terminal and IPv6 service intercommunication service based on NAT64 prefix
WO2023025387A1 (en) Service demand redirection in ingress-based service routing
US20150244871A1 (en) Workload balancing technique for a telephone communication system
Li et al. Artemis: A practical low-latency naming and routing system
US20240113959A1 (en) Instance-affine service scheduling
Jia et al. Deploying lightweight anycast services based-on explicit multicast routing for evolved Internet
Li et al. Reliable and scalable DHT-based SIP server farm

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21766648

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21766648

Country of ref document: EP

Kind code of ref document: A1