Name-based service function chaining over routing on service addresses
Name-based service chaining addresses the latency and affinity issues in current technologies by using name-based addresses and temporary routing data to facilitate efficient chaining within a single transaction, maintaining affinity and reducing latency through the use of Network Service Headers and segment routing information.
Patent Information
- Application Number
- PCT/EP2023/067900
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-06-29
- Publication Date
- 2025-01-02
AI Technical Summary
Current service function chaining technologies require explicit discovery and path computation at each chain segment, leading to latency and potential breakage of transactions due to instance selection not considering affinity, especially when state information is built up, and are limited to Layer 2 or Layer 3 information.
Implementing name-based service chaining that uses name-based addresses and temporary routing data to generate a list of network layer addresses for service chains, allowing for efficient chaining without explicit discovery and adhering to affinity within a single transaction, using a Network Service Header and segment routing information to define relationships between nodes in the service chain.
Enables efficient name-based service chaining without the need for explicit discovery at each chain segment, maintaining affinity and reducing latency by using name-based interactions and ephemeral routing tables to trace responses back to initial clients, while being backward compatible with current SFC architectures.
Smart Images

Figure EP2023067900_02012025_PF_FP_ABST
Abstract
Description
[0001]92035986EP01 NAME-BASED SERVICE FUNCTION CHAINING OVER ROUTING ON SERVICE ADDRESSES Technical Field The present disclosure relates, in general, to service chaining in networks. Aspects relate to service chaining at a named level of the service address / name. Background Virtualization of compute and storage resources enables the provision of services to end users. The Service Function Chaining (SFC) framework allows network operators as well as service providers to compose new services by chaining individual service functions (SFs) together. Such chains are expressed through explicit relationships of functional components (the SFs) realized through their direct Layer 2 (e.g., Media Access Control (MAC) address) or Layer 3 (e.g., IP address) relationship as defined through next-hop information that is being defined by the network operator. As such, new services can be dynamically composed from existing services. For example, service functions SF1, …, SFn can be executed as a service chain towards a more complex composite service S, and each service may be deployed as a service instance SFi1, … SFimi at various network locations, where the number of instances mi per service may be entirely independent from each other and vary widely. Accordingly, virtualized service instances can be instantiated in topologically different network locations with a typical geographically remote data centre being transformed into a network of distributed ones. A client C can issue a request to SF1 as the initial service in the chain, with all subsequent chained services being executed, and where the execution may be served at any of the mi service instances per service in the chain. Services composed of chained service functions may be sticky in that once an instance is selected, future communication may need to go to this instance (for example, due to state being built up). 92035986EP01 Summary An objective of the present disclosure is to enable efficient chaining for services at the named level, i.e., at the level of the service address / name, while adhering to any affinity of a transaction. The foregoing and other objectives are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the Figures. A first aspect of the present disclosure provides a method for service function chaining in a network, the method comprising providing a name-based address for a functional component representing a service function of the network, translating a service request to generate a name- based service request using the name-based address for the functional component, wherein the service request comprises a request to use at least the functional component, generating temporary routing data comprising data representing a set of name-based addresses for a service chain, wherein the temporary routing data includes the name-based address for the functional component, and wherein the service chain comprises the functional component and a set of nodes for the service chain, generating a list of network layer addresses, wherein each network- layer address of the list of network layer addresses corresponds to a name-based address from the set of name-based addresses for the service chain, such that each node of the service chain is associated with a network-layer address from the list of network layer addresses, and providing a response to an apparatus in respect of the service request, the response comprising the list of network layer addresses. Accordingly, the method enables name-based service chaining without the need for explicit discovery, where every chain request may be sent to a different combination of service instances per chain service, all whilst adhering to affinity within a single transaction along the chain in question. In an implementation of the first aspect, the method further comprises generating data representing segment routing information using the list of network layer addresses, wherein the segment routing information defines a relationship between each node of the service chain. The set of nodes can comprise one or more service functions and / or one or more network elements. 92035986EP01 In an example, the method can further comprise using a network service header associated with the service request to store the set of name-based addresses for a service chain. The method can further comprise associating each name-based address of the set of name-based addresses with a service path identifier, wherein a service path identifier identifies a service function path that defines a logical pathway between the set of nodes for the service chain. Service routing removes the need for explicit discovery at each chain segment. A second aspect of the present disclosure provides a network apparatus configured to form part of a network suitable for implementing a composite service formed from one or more service functions, the network apparatus configured to translate a service request to generate a name- based service request using a name-based address for a functional component representing a service function of the network, wherein the service request comprises a request to use at least the functional component, generate temporary routing data comprising data representing a set of name-based addresses for a service chain, wherein the temporary routing data includes the name-based address for the functional component, and wherein the service chain comprises the functional component and a set of nodes for the service chain, generate a list of network layer addresses, wherein each network-layer address of the list of network layer addresses corresponds to a name-based address from the set of name-based addresses for the service chain, such that each node of the service chain is associated with a network-layer address from the list of network layer addresses, and provide a response to an apparatus in respect of the service request, the response comprising the list of network layer addresses. Temporary routing data, forming an ephemeral routing table, can therefore be used to trace backwards from the last chained service instance to an initial client for delivery of service responses to individual chained service instances. In an implementation of the second aspect, the network apparatus can generate data representing segment routing information using the list of network layer addresses, wherein the segment routing information defines a relationship between each node of the service chain. The network apparatus can use a network service header associated with the service request to store the set of name-based addresses for a service chain. The network apparatus can associate each name- based address of the set of name-based addresses with a service path identifier, wherein a service path identifier identifies a service function path that defines a logical pathway between 92035986EP01 the set of nodes for the service chain. The network apparatus can provide, as part of the segment routing information, data representing the identity of the network apparatus. A third aspect of the present disclosure provides a machine-readable storage medium comprising instructions for service function chaining in a network, the instructions executable by a processor, whereby to cause the processor to translate a service request to generate a name- based service request using a name-based address for a functional component representing a service function of the network, wherein the service request comprises a request to use at least the functional component, generate temporary routing data comprising data representing a set of name-based addresses for a service chain, wherein the temporary routing data includes the name-based address for the functional component, and wherein the service chain comprises the functional component and a set of nodes for the service chain, generate a list of network layer addresses, wherein each network-layer address of the list of network layer addresses corresponds to a name-based address from the set of name-based addresses for the service chain, such that each node of the service chain is associated with a network-layer address from the list of network layer addresses, and provide a response to an apparatus in respect of the service request, the response comprising the list of network layer addresses. In an implementation of the third aspect, the machine-readable storage medium can further comprise instructions executable by the processor, whereby to cause the processor to generate data representing segment routing information using the list of network layer addresses, wherein the segment routing information defines a relationship between each node of the service chain. The machine-readable storage medium can further comprise instructions executable by the processor, whereby to cause the processor to use a network service header associated with the service request to store the set of name-based addresses for a service chain. The machine-readable storage medium can further comprise instructions executable by the processor, whereby to cause the processor to associate each name-based address of the set of name-based addresses with a service path identifier, wherein a service path identifier identifies a service function path that defines a logical pathway between the set of nodes for the service chain. The machine-readable storage medium can further comprise instructions executable by the processor, whereby to cause the processor to provide, as part of the segment routing information, data representing the identity of the network apparatus. These and other aspects of the present disclosure will be apparent from the embodiment(s) described below. 92035986EP01 Brief Description of the Drawings In order that the present disclosure may be more readily understood, embodiments will now be described, by way of example, with reference to the accompanying drawings, in which: Fig.1 is a schematic representation of a machine according to an example; Fig.2 is as schematic representation of a method for service function chaining in a network, according to an example; and Fig.3 is a schematic representation of a Routing on Service Addresses system, according to an example. Detailed Description Example embodiments are described below in sufficient detail to enable those of ordinary skill in the art to embody and implement the systems and processes herein described. It is important to understand that embodiments can be provided in many alternate forms and should not be construed as limited to the examples set forth herein. Accordingly, while embodiments can be modified in various ways and take on various alternative forms, specific embodiments thereof are shown in the drawings and described in detail below as examples. There is no intent to limit to the particular forms disclosed. On the contrary, all modifications, equivalents, and alternatives falling within the scope of the appended claims should be included. Elements of the example embodiments are consistently denoted by the same reference numerals throughout the drawings and detailed description where appropriate. The terminology used herein to describe embodiments is not intended to limit the scope. The articles “a,” “an,” and “the” are singular in that they have a single referent, however the use of the singular form in the present document should not preclude the presence of more than one referent. In other words, elements referred to in the singular can number one or more, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and / or “including,” when used herein, specify the presence of stated features, items, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, items, steps, operations, elements, 92035986EP01 components, and / or groups thereof. The term “and / or” is only an association relationship for describing associated objects and represents that three relationships may exist such that A and / or B may indicate that A exists alone, A and B exist at the same time, or B exists alone. The character “ / ” generally represents that the associated objects are in an “or” relationship. Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealized or overly formal sense unless expressly so defined herein. The following contains specific information related to implementations of the present disclosure. The drawings and their accompanying detailed disclosure are merely directed to implementations. However, the present disclosure is not limited to these implementations. Other variations and implementations of the present disclosure will be obvious to those skilled in the art. The phrases “in one implementation,” or “in some implementations,” may each refer to one or more of the same or different implementations. The term “coupled” is defined as connected whether directly or indirectly through intervening components and is not necessarily limited to physical connections. The expression “at least one of A, B and C” or “at least one of the following: A, B and C” means “only A, or only B, or only C, or any combination of A, B and C.” The terms “system” and “network” may be used interchangeably. For the purposes of explanation and non-limitation, specific details such as functional entities, techniques, protocols, and standards are set forth for providing an understanding of the present disclosure. In other examples, detailed disclosure of well-known methods, technologies, systems, and architectures are omitted so as not to obscure the present disclosure with unnecessary details. Persons skilled in the art will immediately recognize that any network function(s) or algorithm(s) disclosed may be implemented by hardware, software or a combination of software and hardware. Disclosed functions may correspond to modules which may be software, hardware, firmware, or any combination thereof. 92035986EP01 A software implementation may include machine- and / or computer- readable and / or executable instructions stored on a machine- and / or computer-readable medium such as memory or other types of storage devices. One or more microprocessors or general-purpose computers with communication processing capability may be programmed with corresponding executable instructions and perform the disclosed network function(s) or algorithm(s). The microprocessors or general-purpose computers may include Applications Specific Integrated Circuitry (ASIC), programmable logic arrays, and / or using one or more Digital Signal Processor (DSPs). Although some of the disclosed implementations are oriented to software installed and executing on computer hardware, alternative implementations implemented as firmware or as hardware or as a combination of hardware and software are well within the scope of the present disclosure. The computer readable medium includes but is not limited to Random Access Memory (RAM), Read Only Memory (ROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), flash memory, Compact Disc Read-Only Memory (CD-ROM), magnetic cassettes, magnetic tape, magnetic disk storage, or any other equivalent medium capable of storing computer-readable instructions. The following terminology may be used herein. Service: A monolithic functionality that is provided according to the specification for said service. A composite service can be built by orchestrating a combination of monolithic services. Service Instance: A running environment (e.g., a node, a virtual instance) that provides the expected service. One service can involve several instances running within the same network at different network locations. Service Address: An identifier for a specific service. Service Transaction: A sequence of higher-layer requests for a specific service, consisting of at least one service request, addressed to the service address, and zero or more affinity requests. Service Request: A request for a specific service, addressed to a specific service address, which is directed to at least one of possibly many service instances. Affinity Request: A request to a specific service, following an initial service request, requiring steering to the same service instance chosen for the initial service request. 92035986EP01 Service Function Chain (SFC): A service function chain defines an ordered set of abstract service functions and ordering constraints that must be applied to packets and / or frames and / or flows selected as a result of classification. An example of an abstract service function is "a firewall". The implied order may not be a linear progression as the architecture allows for SFCs that copy to more than one branch, and also allows for cases where there is flexibility in the order in which service functions need to be applied. The term "service chain" is often used as shorthand for service function chain. Service Function (SF): A function that is responsible for specific treatment of received packets. A Service Function can act at various layers of a protocol stack (e.g., at the network layer or other OSI layers). As a logical component, a service function can be realized as a virtual element or be embedded in a physical network element. One or more Service Functions can be embedded in the same network element. Multiple occurrences of the service function can exist in the same administrative domain. One or more service functions can be involved in the delivery of added-value services. Service Function Forwarder (SFF): A service function forwarder is responsible for forwarding traffic to one or more connected service functions according to information carried in the SFC encapsulation, as well as handling traffic coming back from the SF. Additionally, an SFF is responsible for delivering traffic to a classifier when needed and supported, transporting traffic to another SFF (in the same or different type of overlay), and terminating the Service Function Path (SFP). Service Function Path (SFP): The service function path is a constrained specification of where packets assigned to a certain service function path must go. While it may be so constrained as to identify the exact locations, it can also be less specific. The SFP provides a level of indirection between the fully abstract notion of service chain as a sequence of abstract service functions to be delivered, and the fully specified notion of exactly which SFF / SFs the packet will visit when it actually traverses the network. By allowing the control components to specify this level of indirection, the operator may control the degree of SFF / SF selection authority that is delegated to the network. ROSA (Routing on Service Addresses) Provider: Realizing the ROSA-based traffic steering capabilities over at least one infrastructure provider. ROSA Domain: Domain of reachability for services supported by a single ROSA provider. 92035986EP01 ROSA Endpoint: A node accessing or providing one or more services through one or more ROSA providers. ROSA Client: A ROSA endpoint accessing one or more services through one or more ROSA providers, thus issuing services requests directed to one of possible many service instances that have previously announced the service address provided by the ROSA client in the service request. Service Address Router (SAR): A node supporting the operations for steering service requests to one of possibly many service instances. Service Address Gateway (SAG): A node supporting the operations for steering service requests to service addresses not previously announced to SARs of the same ROSA domain to suitable endpoints in the Internet. Typically, service function chaining is performed at Layer 2 (data link layer) or Layer 3 (network layer) of the seven-layer Open Systems Interconnection (OSI) model of computer networking, which means that the chain of network locations must already be known when constructing the chain itself. In this regard, chaining is static in terms of the instance selection per service, and re-chaining endpoints requires adjustment of the overall chain with (re- )distribution of the service function path (SFP) info. In a name-based Service Function Chaining architecture, chaining is performed at the name- level using a service function forwarder (SFF). Service instance selection at each chained service level requires explicit discovery and path computation per chained service request, which incurs latency. Furthermore, instance selection does not consider possible affinity, such as when a service instance has built up state information, and may therefore break transactions by sending requests to different instances during a transaction. In a ROSA system, service addresses are addresses of a single service, not a chained service. Accordingly, services are addressed, not network interfaces, so for example an address would be provided in binary form rather than as an IP address. Many instances of one service can be registered in a network, and all can receive requests. However, a client maintains affinity with a particular instance after a first (service) request. Any affinity request (of a longer transaction) will go directly to service endpoint via IPv6. Any new scheduling decision requires another service request with the affinity followed. 92035986EP01 According to an example, a method is provided to enable name-based service chaining without any need for explicit discovery, in which every chain request may be sent to a different combination of service instances per chain service, whilst still adhering to affinity within a single transaction along the chain. According to an example, a Network Service Header (NSH) can be extended to comprise name- based addresses, thereby enabling chaining of service names, not just IP addresses. For example, information representing one or more name-based addresses can be added to an NSH. Accordingly, in an example, the definition of an SFP is elevated onto the level of name-based interactions rather than limiting SFPs to Layer 2 or Layer 3 information only. Furthermore, the operations of the SFF can be extended to enable forwarding of decisions that take into account such name-based interaction while remaining backward compatible with current SFC architectures. A chained service request can be translated into a ROSA-based service routing of individual chain requests from one client / instance to another. Service routing removes the need for explicit discovery at each chain segment, and a service instance from one chain segment can be treated as the client to the next chain segment. In an example, a temporary or ephemeral routing table (ERT) can be used to keep track of ephemeral chain information, such as temporary routing data. The ERT can be used to trace backwards from the last chained service instance to an initial client for delivery of service responses to individual chained service instances. The trace back can also be used to build a list of IPv6 addresses of the chained service instances. When the ultimate response is delivered to the client, the list of IPv6 addresses of all chained service instances is also delivered to the client. The list of IPv6 addresses of all chained service instances can be transformed into a segment routing over IPv6 (SRv6) chain to be used for any affinity request within the service chain. Any future affinity requests can then be sent directly over SRv6, utilizing the address list noted above. According to an example, a name-based NSH chain request can be translated into a ROSA- based service request. An NSH mapping table (or network locator map – NLM), an example of which is shown below, is provided that comprises name relations based on URIs as well as high-level transport protocols such as HTTP for means of SFC packet forwarding. The NSH mapping table shown below is an example for ‘www.example.com’ being part of an extended 92035986EP01 SFP (nSFP). Such an NSH mapping table can be stored at each SFF throughout an SFC domain with suitable information populated to the table during a configuration phase for example. For example, given a name based request in the form: IPv6(client, SFF) + NSH + payload received at an SFF for example, where client is the source address, SFF is the destination address, and NSH is the name based header information, an extended mapping table can be used to determine the next service name from the NSH. A ROSA (IPv6) extension header (EH) is constructed with a service address, Sn, determined from the service name Ingress SAR I (being the SFF’s own IPv6 address), and a client address, Cm, being the IPv6 source address of the received packet. The constructed ROSA EH is added to the packet to be forwarded. A service instance SFF SI is determined for the service address utilizing the service-specific routing defined for the service address S as per the ROSA mechanism. Then S, C, and SI are stored in or as part of an ephemeral routing table (ERT) for later retrieval. An example of an ephemeral routing table according to an example is: 92035986EP01 Service Client Service Address instance S1 C1 SI1 S2 C2 SI2 S1 C2 SI3 Note that the same service address may have been chosen in separate chains (indicated by the different clients C1 and C2 where the requests were received from). Different service instances for the same service address may be used in separate chains (indicated by the different clients C1 and C2 where the requests were received from, being directed to different service instances SI1 and SI3, respectively). In an example, service instances are used for obtaining a return path. The packet can then be forwarded according to ROSA forwarding rules to the next service instance SI, in which case the packet takes the form: IPv6(SFF, SI) + EH(S, I, C) + NSH + payload When tracking back from the last chain service instance towards the client, the ERT can be used. For example, the last chain service instance can add an initial SRv6 header with its own instance IP address to start the process of backward path building (see below). Such a packet may thus take the form: IPv6(SFF, SIn) + NSH + SRv6(SIn) + payload The extended mapping table can be used to determine the next service name from the NSH for the response path. A table entry for service address Sn and service instance address SIn is determined from the ERT, as obtained from the NSH and IPv6 SA information. The client address SI(n-1) is then retrieved for the next (return) hop in the chain’s return path. According to an example, the ERT table entry can be removed (since the ephemeral request has now been responded to), and the packet can be forwarded with destination address (DA)=C1, as retrieved from the ERT, and SA = I = SFF IP address. The ERT associated with this could thus be of the form: 92035986EP01 Service Client Service Address instance Sn SI(n-1) Sin Sm SIk SI3 Sn SI(n-2) SI1 An SFF can then forward a packet to the (n-1)th chain client in the form: IPv6(SFF, SI(n-1)) + SRv6(SIn) + NSH + payload According to an example, in order to keep track of affinity at each backtracking service instance, upon receiving the incoming response packet, the SFF can generate a suitable response for the n-1 service request (payload*). It retrieves the SRv6 header of the incoming packet and appends its own IP address in the SRv6 header. It can then forward the packet with the newly generated response and the extended SRv6 header as: IPv6(C1, SFF) + SRv6(SIn, SI(n-1)) + NSH + payload* These actions in relation to backtracking can be executed until the entire chain of services has backtracked to the original client of the overall service chain. According to an example, an affinity path can be constructed at the chain client through the SR path. For example, upon receiving an incoming response packet of the form: IPv6(SFF, C1) + SRv6(SIn, …, SI1) + NSH + payload at the last response path element, the original client of the service chain can obtain the SRv6 header and reverse the SRv6 header entries. It can then store the SRv6 header for use in any future chain affinity request in the affinity chain table (ACT). An example of an ACT could be as follows: NSH Affinity Chain 92035986EP01 17 SRv6(SI1, …, SIn) 23 SRv6(SI1, …, SIm) … … According to an example, an affinity chain service request can be sent directly using the SRv6 header. For example, when needing to construct a new chain service request within the same service transaction for a given NSH, the client can retrieve the SRv6 header as provided above. The client can then send the packet without an NSH but with the SRv6 chaining instead. If the client sends a service request within a new service transaction, it can remove the previously stored SRv6 header and proceed with the entire process as described above again. Examples in the present disclosure can be provided as methods, systems or machine-readable instructions, such as any combination of software, hardware, firmware or the like. Such machine-readable instructions may be included on a computer readable storage medium (including but not limited to disc storage, CD-ROM, optical storage, etc.) having computer readable program codes therein or thereon. The present disclosure is described with reference to flow charts and / or block diagrams of the method, devices and systems according to examples of the present disclosure. Although the flow diagrams described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. In some examples, some blocks of the flow diagrams may not be necessary and / or additional blocks may be added. It shall be understood that each flow and / or block in the flow charts and / or block diagrams, as well as combinations of the flows and / or diagrams in the flow charts and / or block diagrams can be realized by machine readable instructions. The machine-readable instructions may, for example, be executed by a machine such as a general-purpose computer, a platform comprising user equipment such as a smart device, e.g., a smart phone, a special purpose computer, an embedded processor or processors of other programmable data processing devices to realize the functions described in the description and 92035986EP01 diagrams. In particular, a processor or processing apparatus may execute the machine-readable instructions. Thus, modules of apparatus (for example, a module implementing a network function) may be implemented by a processor executing machine readable instructions stored in a memory, or a processor operating in accordance with instructions embedded in logic circuitry. The term 'processor' is to be interpreted broadly to include a CPU, processing unit, ASIC, logic unit, or programmable gate set etc. The methods and modules may all be performed by a single processor or divided amongst several processors. Such machine-readable instructions may also be stored in a computer readable storage that can guide the computer or other programmable data processing devices to operate in a specific mode. For example, the instructions may be provided on a non-transitory computer readable storage medium encoded with instructions, executable by a processor. Figure 1 is a schematic representation of a machine according to an example. The machine 100 can be, e.g., a system or apparatus, user equipment, a network apparatus or part thereof. The machine 100 comprises a processor 103, and a memory 105 to store instructions 102, executable by the processor 103. The machine comprises a storage 109 that can be used to store data 101 representing tables, headers, payloads and so on as described herein. The instructions 107, executable by the processor 103, can cause the machine 100 to translate a service request to generate a name-based service request using a name-based address for a functional component representing a service function of the network, wherein the service request comprises a request to use at least the functional component, generate temporary routing data comprising data representing a set of name-based addresses for a service chain, wherein the temporary routing data includes the name-based address for the functional component, and wherein the service chain comprises the functional component and a set of nodes for the service chain, generate a list of network layer addresses, wherein each network-layer address of the list of network layer addresses corresponds to a name-based address from the set of name-based addresses for the service chain, such that each node of the service chain is associated with a network-layer address from the list of network layer addresses, and provide a response to an apparatus in respect of the service request, the response comprising the list of network layer addresses. Accordingly, the machine 100 can implement a method for service function chaining in a network. 92035986EP01 Such machine-readable instructions may also be loaded onto a computer or other programmable data processing devices, so that the computer or other programmable data processing devices perform a series of operations to produce computer-implemented processing, thus the instructions executed on the computer or other programmable devices provide an operation for realizing functions specified by flow(s) in the flow charts and / or block(s) in the block diagrams. Further, the teachings herein may be implemented in the form of a computer or software product, such as a non-transitory machine-readable storage medium, the computer software or product being stored in a storage medium and comprising a plurality of instructions, e.g., machine readable instructions, for making a computer device implement the methods recited in the examples of the present disclosure. In some examples, some methods can be performed in a cloud-computing or network-based environment. Cloud-computing environments may provide various services and applications via the Internet. These cloud-based services (e.g., software as a service, platform as a service, infrastructure as a service, etc.) may be accessible through a web browser or other remote interface of the user equipment for example. Various functions described herein may be provided through a remote desktop environment or any other cloud-based computing environment. Figure 2 is as schematic representation of a method for service function chaining in a network, according to an example. In block 201 a name-based address is provided for a functional component representing a service function of the network. In block 203, a service request is translated in order to generate a name-based service request using the name-based address for the functional component. In an example, the service request can comprise a request to use at least the functional component. In block 205, temporary routing data comprising data representing a set of name-based addresses for a service chain is generated. The temporary routing data can include the name-based address for the functional component, and the service chain can comprise the functional component and a set of nodes for the service chain. In block 207, a list of network layer addresses is generated. Each network-layer address of the list of network layer addresses can correspond to a name-based address from the set of name-based addresses for the service chain, such that each node of the service chain is associated with a network-layer address from the list of network layer addresses. In block 209, a response can be 92035986EP01 provided to an apparatus in respect of the service request, the response comprising the list of network layer addresses. Figure 3 is a schematic representation of a Routing on Service Addresses system, according to an example. In the example of figure 3, semantic routing is provided on top of IPv6. That is, service names are used instead of locators for service requests, as described above. For example, a request from a client 301 for a service 303, comprising a service request, can be used to generate a name-based service request using a name-based address for a functional component representing a service function (in this case 303) of the network 300. In an example, one or more of the nodes in the network 300, such as the SARs, 305 can implement an SFF. As described above, name-based SFC can be provided using names, not just IP / L2 addresses, thereby enabling service chaining, e.g., in microservices or CAN / MCN like virtualized environments. Routing on service concepts can be used in SFF to instantaneously select one of multiple service function instances in order to discover an overall service chain path. Thus, there is a move away from, e.g., path-based approaches, which require explicit discovery steps and thus incur latencies, to an in-band routing approach. Accordingly, an SFF / SAR can perform NSH-based chaining but with service routing-based selection of the next chain hop. This can be complemented with SRv6 concepts to build an affinity request path when backtracking the SFC chain. This enables limiting of SFC / ROSA techniques to the initial chain building while using efficient SRv6 techniques for any future requests within a service transaction. As such, as described above, instead of ROSA-based operations in the SFFs, dynamic anycast (dyncast) may be used for initial chaining. Furthermore, other source routing approaches beyond SRv6 may be used (e.g., path-based forwarding through pathlets). Instead of returning an SRv6 header on a backtracking path, the list of IPv6 addresses may form part of another suitable packet header, including the payload. In an example, operations are defined to work in a proxyless and proxy mode, i.e., with an SFF integrated into the SI or not. For example, in proxy mode, an SFF can perform operations as described herein. In a proxyless mode, a service instance can perform the SFF operations (and thus the SFF address information equals the SI address, while the SFF equals a ROSA SAR). While various embodiments have been described and / or illustrated herein in the context of fully functional computing systems, one or more of these exemplary embodiments may be distributed as a program product in a variety of forms, regardless of the particular type of computer- readable-storage media used to actually carry out the distribution. The embodiments disclosed 92035986EP01 herein may also be implemented using software modules that perform certain tasks. These software modules may include script, batch, or other executable files that may be stored on a computer-readable storage medium or in a computing system. In some embodiments, these software modules may configure a computing system to perform one or more of the exemplary embodiments disclosed herein. In addition, one or more of the modules described herein may transform data, physical devices, and / or representations of physical devices from one form to another. The preceding description has been provided to enable others skilled in the art to best utilize various aspects of the exemplary embodiments disclosed herein. This exemplary description is not intended to be exhaustive or to be limited to any precise form disclosed. Many modifications and variations are possible without departing from the spirit and scope of the instant disclosure. The embodiments disclosed herein should be considered in all respects illustrative and not restrictive. Reference should be made to the appended claims and their equivalents in determining the scope of the instant disclosure.
Claims
CLAIMS 1. A method for service function chaining in a network, the method comprising: providing a name-based address for a functional component representing a service function of the network; translating a service request to generate a name-based service request using the name- based address for the functional component, wherein the service request comprises a request to use at least the functional component; generating temporary routing data comprising data representing a set of name-based addresses for a service chain, wherein the temporary routing data includes the name-based address for the functional component, and wherein the service chain comprises the functional component and a set of nodes for the service chain; generating a list of network layer addresses, wherein each network-layer address of the list of network layer addresses corresponds to a name-based address from the set of name-based addresses for the service chain, such that each node of the service chain is associated with a network-layer address from the list of network layer addresses; and providing a response to an apparatus in respect of the service request, the response comprising the list of network layer addresses.
2. The method as claimed in claim 1, further comprising: generating data representing segment routing information using the list of network layer addresses, wherein the segment routing information defines a relationship between each node of the service chain.
3. The method as claimed in claim 1 or 2, wherein the set of nodes comprise one or more service functions and / or one or more network elements.
4. The method as claimed in any preceding claim, further comprising: using a network service header associated with the service request to store the set of name-based addresses for a service chain.
5. The method as claimed in claim 4, further comprising:associating each name-based address of the set of name-based addresses with a service path identifier, wherein a service path identifier identifies a service function path that defines a logical pathway between the set of nodes for the service chain.
6. A network apparatus configured to form part of a network suitable for implementing a composite service formed from one or more service functions, the network apparatus configured to: translate a service request to generate a name-based service request using a name-based address for a functional component representing a service function of the network, wherein the service request comprises a request to use at least the functional component; generate temporary routing data comprising data representing a set of name-based addresses for a service chain, wherein the temporary routing data includes the name-based address for the functional component, and wherein the service chain comprises the functional component and a set of nodes for the service chain; generate a list of network layer addresses, wherein each network-layer address of the list of network layer addresses corresponds to a name-based address from the set of name-based addresses for the service chain, such that each node of the service chain is associated with a network-layer address from the list of network layer addresses; and provide a response to an apparatus in respect of the service request, the response comprising the list of network layer addresses.
7. The network apparatus as claimed in claim 6, wherein the network apparatus is further configured to: generate data representing segment routing information using the list of network layer addresses, wherein the segment routing information defines a relationship between each node of the service chain.
8. The network apparatus as claimed in claim 6 or 7, wherein the network apparatus is further configured to: use a network service header associated with the service request to store the set of name- based addresses for a service chain.
9. The network apparatus as claimed in any of claims 6 to 8, wherein the network apparatus is further configured to:associate each name-based address of the set of name-based addresses with a service path identifier, wherein a service path identifier identifies a service function path that defines a logical pathway between the set of nodes for the service chain.
10. The network apparatus as claimed in claim 7, wherein the network apparatus is further configured to: provide, as part of the segment routing information, data representing the identity of the network apparatus.
11. A machine-readable storage medium comprising instructions for service function chaining in a network, the instructions executable by a processor, whereby to cause the processor to: translate a service request to generate a name-based service request using a name-based address for a functional component representing a service function of the network, wherein the service request comprises a request to use at least the functional component; generate temporary routing data comprising data representing a set of name-based addresses for a service chain, wherein the temporary routing data includes the name-based address for the functional component, and wherein the service chain comprises the functional component and a set of nodes for the service chain; generate a list of network layer addresses, wherein each network-layer address of the list of network layer addresses corresponds to a name-based address from the set of name-based addresses for the service chain, such that each node of the service chain is associated with a network-layer address from the list of network layer addresses; and provide a response to an apparatus in respect of the service request, the response comprising the list of network layer addresses.
12. The machine-readable storage medium as claimed in claim 11, further comprising instructions executable by the processor, whereby to cause the processor to: generate data representing segment routing information using the list of network layer addresses, wherein the segment routing information defines a relationship between each node of the service chain.
13. The machine-readable storage medium as claimed in claim 11 or 12, further comprising instructions executable by the processor, whereby to cause the processor to:use a network service header associated with the service request to store the set of name- based addresses for a service chain.
14. The machine-readable storage medium as claimed in claim 13, further comprising instructions executable by the processor, whereby to cause the processor to: associate each name-based address of the set of name-based addresses with a service path identifier, wherein a service path identifier identifies a service function path that defines a logical pathway between the set of nodes for the service chain.
15. The machine-readable storage medium as claimed in claim 12, further comprising instructions executable by the processor, whereby to cause the processor to: provide, as part of the segment routing information, data representing the identity of the network apparatus.
