Method and apparatus for protecting a stateful traffic function path

Abstract

A method, apparatus, and system are provided that provide a stateful service function path with redundancy. Multiple instances of a service function path are included, each instance having at least one instance of a stateful service function. The redundant stateful service functions send messages to each other in order to synchronize current state. When a service function in a first instance of the service function path fails, a packet is redirected to a backup associated with the failed service function located in another instance of the service function path. Once processed by the backup service function, the redirected packet can be routed back to the first instance of the service function path.

Description

[0001] Cross-citation of related applications

[0002] This application claims priority to U.S. Patent Application No. 16 / 998,625, filed August 20, 2020, entitled “METHOD AN APPARATUS FOR PROTECTING STATEFUL SERVICE FUNCTION PATHS”, the contents of which are incorporated herein by reference. Technical Field

[0003] This invention relates to the field of message-based data communication, and more specifically to a method and apparatus for protecting service function paths through service domains. Background Technology

[0004] In communication networks, service function chains (SFCs) and service function forwarding can be used to forward packets along predetermined service function paths through the communication network. Internet Engineering Task Force (IETF) Request for Comment (RFC) document 7665, titled "Service Function Chain (SFC) Architecture," issued in October 2015 (here referred to as RFC 7665), describes various aspects of service function chains, service functions, service function paths, service function forwarders, and service nodes. According to RFC 7665, a service function chain (SFC) defines an ordered set of logical service functions and sequencing constraints that must be applied to packets or packet flows traversing the SFC. The concept of a "chain" indicates that a packet must be processed by one service function in the SFC, and then by the next service function in the SFC in sequence. An SFC may also include classification criteria indicating which packets (or packet flows) will be processed by the SFC. Service function chains can be used to implement critical packet network operations such as traffic management, intra-network content management, and network security. In addition, the business function chain can also customize message network operations for specific customers or applications through network slicing.

[0005] According to RFC 7665, a service function (SF) is responsible for specific processing applied to received messages. Service functions can operate at various layers of the protocol stack (e.g., one or more of the network (IP) layer, transport (TCP / UDP) layer, link layer, and application layer). Service functions can modify received messages and / or observe and record characteristics of received messages. A specific service function can be incorporated into multiple service function chains. A service function node (SFN) is a physical network element that carries one or more service functions. Different service functions can coexist on a specific service function node. Different instances of a specific service function can exist on different service function nodes within the same service domain.

[0006] A service function path (SFP) can be defined as the physical representation of an Service Function Path (SFC). It indicates the sequence of network nodes, network functions, and links that are actually traversed to implement the message processing defined by the SFC. Multiple SFPs can exist in a single service domain, and multiple specific SFP instances can exist within the same service domain. Different service functions can be applied to messages at each network node or network function along the SFP path.

[0007] In many cases, service functions must use information associated with previous messages in a message flow to process messages within that flow. This information, which the service function must retain for a period of time, is called the message flow-related SF state or SF status, and processing messages using the SF state is called stateful processing. Therefore, a service function that performs stateful processing on a message flow is called a stateful SF. If the network cannot forward messages to the SFN hosting the stateful SF, it may be unable to process or forward other messages in the message flow, leading to premature and unexpected loss of communication between network endpoints exchanging information using that message flow.

[0008] For critical communications, it is typically necessary to identify alternative paths and / or instantiate redundant copies of the Service Provider (SF) or Service Provider Network (SFN) through the network to ensure that if the path to the primary SF instance is lost, packets can be redirected to the backup SF instance. However, current solutions do not provide a sufficiently effective way to achieve service function redundancy and stateful processing. Therefore, there is a need for a method and apparatus for service function path protection through the service domain, which also supports stateful processing and eliminates or mitigates one or more limitations of existing technologies. Summary of the Invention

[0009] The purpose of embodiments of the present invention is to provide a method, apparatus, and system for providing stateful service function paths, which provide fault protection along service function paths. When a service domain must process a large number of packets, traffic associated with a service function chain (SFC) is typically distributed across multiple instances of a replicated service function path (SFP), where each instance of the replicated SFP may have dedicated network resources associated with its associated service function (SF) and service function node (SFN). Therefore, each instance of the replicated SFP will be responsible for processing a subset of the packet flow allocated to the corresponding SFC in the service domain. Multiple SFP instances are used to provide multiple redundant service function paths, each redundant service function path having at least one stateful service function. The replicated stateful service functions send messages to each other so that the current state of the packet flow associated with that service function is synchronized across all instances of the replicated service function. When a service function in the first instance of a service function path fails, packets in the affected packet flow are redirected to a copy of the failed service function located in another instance of the service function path. Once processed by a copy of the business function, the redirected message can be routed back to the subsequent business function on the first instance of the business function path.

[0010] According to one aspect of the present invention, a method and apparatus for protecting a service function path are provided. According to an embodiment of the present invention, a method for processing a message flow in a service function path is provided. The method includes a network function receiving a first message in a message flow, the first message including an indication identifying a primary SFP instance assigned to the message flow, wherein the network function is associated with the primary SFP. The method further includes: the network function sending the first message to a primary second network function associated with the primary SFP instance; and in response to a communication failure with the primary second network function, the network function sending a second message in the message flow to a backup second network function associated with a second SFP instance, the second message being received by the network function after the first message in the message flow and including an indication identifying the primary SFP instance of the message flow.

[0011] According to other aspects, the primary second network function updates the state of the message flow-related service function (SF) associated with the message flow based on the first message. The primary second network function and the backup second network function are communicatively coupled to synchronize the message flow-related SF states. According to other aspects of the invention, after processing the second message, the backup second network function can send the second message to the primary third network function associated with the primary SFP instance, based on the indication in the second message that identifies the primary SFP instance of the message flow.

[0012] Furthermore, synchronizing the packet flow-related SF status associated with the packet flow includes the primary second network function determining the second SFP instance associated with the backup second network function based on the indication identifying the primary SFP instance of the packet flow. The synchronization also includes the primary second network function sending a status update message to the backup second network function, including the packet flow-related SF status associated with the packet flow.

[0013] According to another aspect of the method, the status update message is sent in a status update packet. The destination address of the status update packet is a unicast address associated with the backup second network function, and the source address of the status update packet is a unicast address associated with the primary second network function. The destination address includes an indication identifying the second SFP instance associated with the backup second network function, and the source address includes an indication identifying the primary SFP instance associated with the primary second network function. Another aspect of the method includes: the primary second network function starting a timer for monitoring the reception of the status update message. The other aspect includes the primary second network function receiving a copy of the status update packet before the timer expires, wherein the destination address associated with the copy of the status update packet is a unicast address including the SFP instance associated with the primary second network function. In another aspect, the copy of the state update message is received by the primary second network function due to the forwarding of the state update message among members of the SF instance set, the SF instance set including at least the primary second network function and the backup second network function, and each member of the SF instance set is used to forward a copy of the state update message to a designated next member of the SF instance set, each member of the SF instance set being associated with a different SFP instance.

[0014] The method further includes the indication identifying the primary SFP instance included in a segment routing extension (SRE) associated with each of the first and second packets. The segment routing extension also includes a segment list, wherein the segment list includes a list of segment identifiers (SIDs). Each SID is associated with a distinct corresponding service among the plurality of service functions forming the SFP. According to another aspect of the invention, each SID is an Internet Protocol (IP) address, and the IP address includes the indication identifying the primary SFP instance. According to another aspect of the invention, the segment routing extension also includes an indication of the number of members in the SF instance set.

[0015] According to another aspect of the present invention, a network node is provided, the network node comprising: a network interface; a processor; a first memory; and a non-transitory memory storing instructions. The network node is configured, for example, to execute instructions via the processor. The network node is configured to receive a first message in a message stream using the network interface, the first message including an indication identifying a primary service function path (SFP) instance assigned to the message stream, the network node being associated with the primary SFP instance. The network node is configured to send the first message to a primary second network node using the network interface, the primary second network node being associated with the primary SFP instance. The network node is configured to, in response to a communication failure with the primary second network node, send a second message in the message stream to a backup second network node associated with a second instance of the SFP using the network interface. The second message is received by the network node after the first message in the message stream and includes an indication identifying the primary SFP instance of the message stream. The network node is further configured to update the message stream-related service function (SF) status associated with the message stream in the first memory based on the first message. The network node is also configured to use the network interface to send a status update message including the updated SF status related to the packet flow, the status update message including the indication identifying the primary SFP instance of the packet flow. The instruction further causes the network node to insert a unicast network address associated with a backup network node configured as a backup of the network node into the destination address of the status update message, the unicast network address including the indication identifying the backup SFP instance of the packet flow; and to send the status update message to the backup network node using the network interface.

[0016] According to another aspect of the present invention, a network node is provided, the network node comprising: a network interface; a processor; a first memory; and a non-transitory memory storing instructions, which, when executed by the processor, cause the network node to: receive a state update message using the network interface, the state update message including a service function (SF) state associated with a packet flow, the state update message including an indication identifying a primary service function path (SFP) instance associated with the packet flow, the network node forming part of an SFP instance other than the primary SFP instance of the packet flow; store the packet flow-related SF state associated with the packet flow in the first memory according to the primary SFP instance indicated in the state update message; and transmit a copy of the state update message using the network interface, the copy of the state update message including an indication identifying another SFP instance associated with the packet flow.

[0017] The instructions further instruct the network node to receive, using the network interface, a message associated with the message flow, the message including an indication identifying the primary service function path (SFP) instance associated with the message flow; retrieve, based on the primary SFP instance indicated in the message, the message flow state associated with the message flow from the first memory; and send the message to another network node using the network interface. According to other aspects of the invention, the other network node may be associated with the primary SFP instance indicated in the message. The instructions further instruct the network node to update, based on the message, the message flow-related SF state associated with the message flow in the first memory; and send, using the network interface, a second state update message including the updated message flow-related SF state associated with the message flow.

[0018] Potential advantages of this invention include providing redundancy without incurring additional costs associated with dedicated backup links and network elements by enabling all components of the SFP to actively handle traffic associated with their assigned packet flows while simultaneously acting as backups for SFP components handling other packet flows.

[0019] Other advantages of the invention include the elimination of the need for pre-configuration and provision of dedicated backup components by enabling information to be transmitted in the segment routing extension (SRE) of each message in the accompanying message flow to guide messages toward (i.e., forward messages to) primary or backup service functions.

[0020] Furthermore, in the event of a failure, rerouting decisions are made locally (i.e., by the network elements associated with the service function) using information transmitted in the SRE of each packet in the accompanying packet flow. Local rerouting decisions minimize the time required to recover from a failure and minimize the interruption of affected packet flows.

[0021] Embodiments have been described above in conjunction with various aspects of the present invention, and these embodiments can be implemented based on these aspects. Those skilled in the art will understand that embodiments can be implemented in conjunction with the aspects described therein, but may also be implemented together with other embodiments of that aspect. It will be apparent to those skilled in the art that embodiments are mutually exclusive or incompatible with each other. Some embodiments may be described in conjunction with one aspect, but may also be applicable to other aspects, as will be apparent to those skilled in the art. Attached Figure Description

[0022] Further features and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, in which:

[0023] Figure 1 Existing technologies associated with business function paths in a business domain are illustrated.

[0024] Figure 2 The illustration shows the distribution and balancing of message flows across multiple instances of a service function path corresponding to a service function chain, as provided by an embodiment of the present invention.

[0025] Figure 3 This illustration shows message and status forwarding on multiple service function paths provided by embodiments of the present invention.

[0026] Figure 4 This illustration shows a message rerouting via a backup SF of the service function path provided by an embodiment of the present invention.

[0027] Figure 5 The operation of the entry classifier provided by an embodiment of the present invention is illustrated.

[0028] Figure 6A An encapsulated message including an exemplary segment routing extension is shown as provided by an embodiment of the present invention.

[0029] Figure 6B A segment list with segment routing extensions having structured IPv6 SIDs, provided by an embodiment of the present invention, is illustrated.

[0030] Figure 6C A segment list with compact SID segment routing extension provided by an embodiment of the present invention is shown.

[0031] Figure 7The operation performed by the load balancer provided in an embodiment of the present invention is illustrated.

[0032] Figure 8 The embodiments of the present invention illustrate operations performed on a service function, service function node, or service function forwarder.

[0033] Figure 9 An embodiment of the present invention provides a method for propagating cyclic SF states.

[0034] Figure 10 The SF state operation provided by an embodiment of the present invention is illustrated.

[0035] Figure 11 The present invention illustrates the redirection of messages after a communication failure, as provided in an embodiment of the invention.

[0036] Figure 12 The present invention illustrates the processing of redirection messages at a backup of an SF instance, as provided by an embodiment of the present invention.

[0037] Figure 13 A network device provided by an embodiment of the present invention is shown.

[0038] It should be noted that the same features are identified by the same reference numerals throughout the accompanying drawings. Detailed Implementation

[0039] Embodiments of the present invention generally provide apparatus, systems, and methods for protecting stateful service function paths. Specifically, embodiments of the present invention use multiple instances of replicated service function paths to redirect traffic to the replicated service function instances when a communication failure occurs along the path to the service function. For example, each copy of the service function path can be instantiated to provide load balancing across available network resources. A communication failure may correspond to a faulty or unavailable communication link, or a faulty network node or component thereof.

[0040] Figure 1 This illustrates an existing technology business domain with a business function path that implements the corresponding business function chain. For example... Figure 1As shown, user packets from a first network node (Node A) enter service domain 110 through ingress node (classifier) ​​115 and exit service domain through egress node 120, subsequently being received at another network node (Node B). User packets can be part of a packet stream comprising a sequence of user packets sent from Node A to Node B. Traditionally, packet streams are identified by a five-tuple in the Internet Protocol (IP) header, including IP protocol type, source IP address, destination IP address, source TCP / UDP port, and destination TCP / UDP port. In one embodiment, multiple packet streams can be processed within service domain 110. In this embodiment, ingress node 115 forwards packets associated with a specific packet stream along specific SFPs, such as SFP1 122, SFP2 124, or SFP3 126, according to a classification of the service function set defined to be applied to the user packets. Therefore, ingress node 115 acts as a classifier node. Although in Figure 1 In this simplified example, there is a single ingress (classifier) ​​node 115 and a single egress node 120. However, in other embodiments, there may be multiple ingress nodes 115 and multiple egress nodes 120 within the service domain. Furthermore, the service domain 110 may contain more than... Figure 1 The three business function paths shown (SFP1 122 (solid line), SFP2 124 (dashed line), and SFP3 126 (dashed line)) have more or fewer business function paths.

[0041] As a service function forwarder (SFF) 130, the network node or network function is responsible for forwarding traffic to the connected service function (SF) 135. The SFF 130 can be responsible for selecting routes and forwarding packets from the service function node (SFN) hosting an SF or to the SFN of the next SF hosting an SFF. For example... Figure 1 As shown, an SFF 130 can be associated with zero or one SFN 140 and can provide forwarding services to multiple SFPs within service domain 110. In some embodiments, network nodes or network functions used as SFF 130 can be merged into SFN 140. Each SFF 130 can use information transmitted in the network header associated with the packet to determine which connected SFs (if any) to send the packet to. When an SF 135 finishes processing a packet, the processed packet is returned to the SFF 130, which is also responsible for forwarding the packet to the next SFF or SFN. An SFN 140 can host one or more SFs 135 and can have one or more SFFs 130 associated with them.

[0042] Packet forwarding between SFs (or between SFNs hosting SFs) can be performed by SFFs that can serve one or more instances of an SFP. Packet forwarding between SFFs and SFNs, as well as between SFFs themselves, can be performed by traditional packet forwarding network nodes or network functions within the routing network infrastructure.

[0043] An SF can be a virtual network function (VNF) instantiated by network function virtualization performed on the resources of a computing server, a standalone physical network device, or a physical network element.

[0044] Further details regarding the above definition can be found in RFC 7665.

[0045] Embodiments of the present invention provide a scheme for protected service function paths based on a distributed local mechanism, which can restore the connectivity of service function paths after a failure of a network node or network function or the link to said network node or network function. In one embodiment, the packet flow associated with a service function chain (SFC) can be distributed across multiple instances of a replicated service function path (SFP). Each instance of an SFP can have dedicated network resources associated with its associated service function (SF) and service function node (SFN). Therefore, each instance of an SFP will be responsible for processing a subset of the packet flow associated with the SFC in the service domain. Figure 2 This embodiment illustrates the distribution and balancing of packet flows across multiple instances of the SFP corresponding to the SFC. For simplicity, the SFN and SFF associated with the SF are not shown here; the remaining figures are included herein. Figure 2 As shown, ingress node 115 acts as a classifier and determines which SFC should be used to process incoming user packets belonging to the packet flow. In the following description, the primary SF instance refers to the SF instance in the primary SFP instance, and the backup SF instance refers to the SF instance in the SFP instance that is not the primary SFP instance. The primary SF instance and the backup SF instance constitute the SF instance set.

[0046] After processing the incoming user packet and identifying the SFC to be associated with it, the ingress node 115 forwards the user packet to the load balancer (LB) associated with the SFP corresponding to the selected SFC. In this example, SFP-1LB 210 corresponds to the load balancer associated with SFP 215 corresponding to the first SFC, and SFP-2LB 220 corresponds to the load balancer associated with SFP 225 corresponding to the second SFC. The following will combine... Figure 5 This describes the operation of the ingress (classifier) ​​node 115 for processing incoming user packets. The load balancer receiving user packets from the ingress (classifier) ​​node 115 (i.e., SFP-1LB 210 or SFP-2LB 220) selects an instance of the associated SFP through which the user packet is routed (i.e., forwarded). For example, if a user packet is received at SFP-1 LB 210, and if the user packet is the first received user packet in the packet flow, SFP-1 LB 210 can select an instance of SFP 215 (e.g., SFP instance 230, SFP instance 250, or SFP instance 270) to process the packet flow. The SFP 215 instance (e.g., SFP instance 230, SFP instance 250, or SFP instance 270) selected by SFP-1 LB 210 to process the packet flow is called the primary SFP instance for that packet flow, and the SF within the primary SFP instance is called the primary SF instance for that packet flow. SFP instances 230, 250, and 270 are all instances of SFP215, while SFP instances 240 and 260 are instances of SFP225.

[0047] Figure 2 The ingress (classifier) ​​node 115 and the load balancer nodes SFP-1 LB 210 and SFP-2 LB 220 are presented as distinct entities. Those skilled in the art will recognize that this separation is for reference only, and the ingress (classifier) ​​node can integrate the functionality of the load balancer. Embodiments of the present invention provide an ingress (classifier) ​​node that performs load balancing functions.

[0048] Within each SFP (e.g., SFP 215 and SFP 225), there are multiple copies of the SF (i.e., multiple SF instances), which can be configured as backup SF instances of each other, and the multiple SF instances in each SFP 215, 225 can be referred to as an SF instance set. As an example, SF-A in SFP 215 has “n” SF instances (SF-A1.1 231, SF-A1.2 251 to SF-A1.n 271) forming an SF instance set associated with SF-A, SF-B has “n” SF instances (SF-B1.1 233, SF-B1.2 253 to SF-B1.n 273) forming another SF instance set associated with SF-B, and similarly, SF-C has “n” SF instances (SF-C1.1 235, SF-C1.2 255 to SF-C1.n 275) forming another SF instance set associated with SF-C. although Figure 2 Only three SFs (e.g., SF-A, SF-B, and SF-C) for each SFP are shown, but it is understood that the number of SFs for each SFP depends only on the SFC associated with the message flow, and this number is provided for illustrative purposes only and without any limitation.

[0049] Stateful SFs appearing in different SFPs can generate different packet flow state information. Therefore, an SF instance in another SFP (e.g., SF-B 2.1 242 and SF-B 2.m 262 in SFP 225) cannot be included in the SF instance set associated with SFP 215. For a specific packet flow, an SF instance in the SF instance set associated with the primary SFP instance can be designated as the primary SF instance for that packet flow, and other SFs in the SF instance set can be used as backup SF instances for that packet flow. The network node or network function associated with an SF instance in the primary SFP instance is called the primary network node or network function. Similarly, the network node or network function associated with a backup SF instance is called the backup network node or network function.

[0050] It should be noted that SF instance sets can also be configured in other ways. One or more SF instances can be used as primary SF instances, and one or more other SF instances can be used as backup SF instances. An SF instance can be used as a primary SF instance alone, a backup SF instance alone, or both simultaneously. A backup SF instance can be used as a backup of at least one specified or unspecified other SF instance; this backup SF instance can itself be a primary SF instance or another backup SF instance. An SF instance can be specified as a backup SF instance relative to another SF instance, and (possibly) as a primary SF instance relative to one or more backup SF instances. Primary SF instances and backup SF instances can be organized relative to each other in one or more loops, trees, or combinations thereof.

[0051] A load balancer can be used to forward all user packets in a specific packet flow to the same instance of an SFP (i.e., an SPF instance). In one embodiment, an indication of the SFP instance assigned to a packet flow is provided by transmitting the identifier of the selected SFP instance along with the user packet within the service domain. The selection of an SFP instance from the available SFP instances can be based on load balancing criteria such as round-robin, least recently used, or other methods best suited to the specific situation. If SFP-1 LB 210 selects SFP instance 230 to handle the packet flow, SFP-1 LB 210 forwards the encapsulated packets to SF-A1.1 231, which is the first SF along the selected primary SFP instance 230. In the absence of SF instance failure as described elsewhere herein, SF-A1.1 231 can be used to forward received encapsulated packets along the selected SFP instance 230 to subsequent SFs (e.g., SF-B1.1 233, and ultimately to SF-C1.1 235). The following describes the operation of the load balancer and service function nodes provided in the embodiments of the present invention, as well as the description of the encapsulated messages.

[0052] Embodiments of the present invention route user plane traffic around a communication failure along a path to the next SF via a backup instance of the next SF. According to some such embodiments, for a particular SF in an associated SFC, each instance of the SF in the replicated SFP serves as a backup for other instances of the SF in the same SFP. For example, if there are n SFP instances in a service domain, for a particular SF in an associated SFC, a message flow may have one (1) primary SF, and that message flow may have (n–1) backup SFs. In other embodiments, different arrangements of primary and backup SFs may be used. To serve as backup SF instances and replace primary SF instances in the event of a failure, each instance of an SF stores its own SF state and (n–1) SF states associated with other instances of the SF in the SFP. Back Figure 2Each SF instance in the SF instance set associated with SF A (e.g., SF-A1.1 231, SF-A1.2 251 to SF-A 1.n 271) serves as a backup SF instance for the remaining (n–1) SFs forming the SF instance set of SF-A in SFP 215. Furthermore, to allow stateful processing of user messages, even after an SF failure, each backup SF instance stores a synchronized copy of the message stream-related SF state locally in the primary SF instance. Local storage can refer to storing the SF state in locally accessible electronic storage (e.g., located in the same device, rack, or data center, depending on the context). Figure 3 This illustration demonstrates packet and state forwarding across multiple instances of a service function path, as provided by an embodiment of the present invention. A synchronized copy of the SF state is maintained on each backup SF instance.

[0053] In some embodiments, when a fault is detected, the encapsulated message can be redirected to a backup instance of the next SF. In other embodiments, the encapsulated message can be redirected to multiple backup instances of the next SF, such as a primary backup instance and a secondary backup instance of the next SF, or multiple backup instances of the next SF. This may be the case, for example, when processing time-critical user messages and a low failure rate is desired.

[0054] Now for reference Figure 3 When the processing of a user message causes a change in the SF state associated with a message stream allocated to the primary SF instance, the primary SF instance forwards the updated SF state (or at least the SF state associated with that message stream) to the other (backup) instances of the SF. For example, in SFP 215, when the primary SF-A 1.1 231 updates its SF state during the processing of a user message in an allocated message stream, a copy of the updated SF state for that message stream is propagated to all corresponding backup SFs in the set of SF instances associated with SF-A, i.e., to SF-A1.2 251 to SF-A1.n 271, as indicated by state synchronization path 310. At each subsequent SF (SF-B1.1 233 and SF-C 1.1 235) of SFP instance 230, the SF state change (i.e., the indication of the SF state change) can be similarly propagated to the backup SF instances in the SF instance sets associated with SF-B and SF-C, respectively, as indicated by state synchronization paths 320 and 330. However, it should be noted that in various other embodiments, not all SFs must be stateful SFs. If an SF is not a stateful SF, there is no need to propagate the SF state.

[0055] According to these embodiments, each backup SF instance in SFP instances 250 and 270 stores the packet flow-related SF state provided by the primary SF instance in primary SFP 230, without needing to repeat the processing of user packets performed by the primary SF instance. Therefore, the SF can use deterministic or nondeterministic procedures, as the results of nondeterministic procedures are captured in the packet flow-related SF state and a synchronized copy is maintained on each backup SF instance.

[0056] In some embodiments, the primary SF instance (e.g., SF-A 1.1 231) may send a unicast message containing the updated SF state to each backup SF instance (e.g., SF-A 1.2 251 and SF-A 1.n 271). In other embodiments, multicast messages may be used to distribute the updated SF state to all backup SF instances (e.g., SF-A1.1 231) associated with the multicast tree rooted in the primary SF instance. Alternatively, the SF state update process may be used to propagate the SF state along a path (e.g., a loop) such as state synchronization path 310. (Refer to...) Figure 9 and Figure 10 Describe such an SF state update process. The SF state update process can be considered "cyclic" because the SF state propagates along a closed path that starts and ends at the same node.

[0057] Figure 4 This illustrates an embodiment of the invention providing an operation for rerouting encapsulated packets when a communication failure occurs on the path to the primary SF instance. For simplicity, Figure 4 Only SFP 215 is shown. According to an embodiment of the invention, after receiving and processing user messages, the primary SF instance (e.g., SF-A1.1 231) generates encapsulated messages for transmission to the next SF (e.g., SF-B1.1 233) in the primary SFP instance 230 for the message stream; [The reference will be...] Figure 5The generation of encapsulated packets is discussed. In the event of a state change caused by user packet processing, the primary SF instance (SF-A1.1 231) also updates the packet flow-related SF state and then propagates the packet flow-related SF state change to (n–1) backup SF instances (e.g., SF-A1.2 251 to SF-A1.n 271) in the set of SF instances associated with SF-A, as disclosed above. When a communication failure is detected on the path from the primary SFP instance 230 to the next primary SF instance, or when the next primary SF instance itself fails (e.g., the failed SF-B1.1 433), the rerouting function is used to redirect the encapsulated packets to a backup SF instance of the next primary SF instance (e.g., SF-B1.1 433), such as SF-B1.2 253. The rerouting function can be attached to SF 135 or to network elements associated with SF, such as SFN 140 or SFF 130; the rerouting function can also be attached to a load balancer, such as SFP-1LB 210. Other implementations of the rerouting function are possible without departing from the scope of the invention. Communication failures can be detected by adjacent network elements (e.g., SFN 140 or SFF 130 associated with SF135 (e.g., SF-A1.1 231)) based on an activity check, such as bidirectional forwarding detection. Failures can be detected before forwarding encapsulated packets or when an attempt to forward an encapsulated packet to an SF instance (e.g., to SF-B 1.1433) fails. Other methods for detecting path failures are well known to those skilled in the art and can be used to detect path failures of SFs within SFP instances.

[0058] In this embodiment, the rerouting function can also modify the header of the encapsulated packet to include the address of the backup SF instance (e.g., SF-B 1.2 253) of the next primary SF instance (e.g., SF-B 1.1 433) in the destination address field of the encapsulated packet. The rerouting function can then forward the encapsulated packet to the backup SF instance (SF-B 1.2 253), as indicated by backup forwarding path 420.

[0059] According to an embodiment of the present invention, the rerouting function can be used to provide the destination address of the backup SF instance (SF-B1.2 253) to SFF 130 or SFN 140 for insertion into the header of the encapsulated message.

[0060] When the backup SF instance (SF-B1.2 253) receives an encapsulated packet via backup forwarding path 420, it uses the packet previously received from the primary SF instance (SF-B1.2 253). Figure 3The SF-B 1.1 233 receives user packets and processes the SF state associated with the packet stream. If the processed user packet causes a change in the SF state associated with the packet stream (i.e., a change in the SF state associated with the packet stream that includes the user packet), the backup SF instance (SF B 1.2 253) forwards the updated SF state associated with that packet stream to the remaining backup SF instances in the set of SF instances associated with SF-B within SFP215, as indicated by state synchronization path 410. As shown, state synchronization path 410 does not include the failed SF (SF-B 1.1 433) due to a failure of the path to the node or the path itself. However, if the primary SF instance (SF-B 1.1 433) is able to communicate for the purpose of SF state updates, state synchronization path 410 may alternatively include or attempt to include the primary SF instance (SF-B 1.1 433).

[0061] Embodiments of the present invention provide that user packets on a backup SF instance (SF-B1.2 253) are forwarded to the next SF (e.g., SF-C1.1 235) in the primary SFP instance, as indicated by backup forwarding link 430. Route recovery functionality of SFN 140 or SFF 130 attached to or associated with the backup SF instance (SF-B1.2 253) restores the path through the primary SFP instance 230 by directing encapsulated packets toward (i.e., forwarding encapsulated packets to) the next SF (i.e., SFC1.1 235) in the primary SFP instance. For this purpose, the encapsulated packets may include an indication of their associated primary SFP instance. If necessary, the next SF (SF-C1.1 235) in the primary SFP instance can synchronize its SF state via state synchronization path 330.

[0062] Figure 5 This illustration shows a method for performing user packet processing 500 at an ingress (classifier) ​​node, such as ingress (classifier) ​​node 115, according to an embodiment of the present invention. After receiving an incoming user packet in step 510, the ingress (classifier) ​​node classifies the user packet in step 520 by determining the SFC to be associated with the incoming user packet. In step 530, the ingress (classifier) ​​node determines the SFP associated with the SFC, wherein the SFP includes an SF sequence for processing the incoming user packet, which is a user packet in an identified packet stream. In this embodiment, all user packets from the identified packet stream are associated with the same SFP. Figure 2 For example, an SFP can be represented as [SF-A, SF-B, SF-C]. Figure 2This represents the SF sequence to be applied to all user packets in the identified message stream. In step 540, the ingress (classifier) ​​node inserts the incoming user packet, including the header and payload of the user packet, into the encapsulated packet. In step 550, the ingress (classifier) ​​node sends the encapsulated packet to the load balancer associated with the SFP, such as LB 210 associated with SFP 215.

[0063] Reference Figure 6A , Figure 6B and Figure 6C This describes the encapsulated message. According to embodiments of the invention, encapsulated message 600 may use an enhanced version of the segment routing header defined for segment routing over IPv6, referred to herein as SRv6; other embodiments may also be used without departing from the scope of the invention, such as those using multi-protocol labelswitching (MPLS). The conventional SRv6 segment routing header is described in IETF RFC 8754, entitled "IPv6 Segment Routing Header (SRH)". In exemplary embodiments utilizing IPv6 and segment routing, encapsulated message 600 includes an IPv6 header 610 and a segment routing extension (SRE) 620 inserted between the IPv6 header 610 and the payload 630 of encapsulated message 600. In some embodiments, user packets processed by the SF in the SFP are included in the payload 630 of encapsulated message 600. The IPv6 header 610 encapsulating message 600 includes a destination network address field 616, a source network address field 614, and a "next header" field 612, and Figure 6A Other fields shown. The presence of segment routing extension (SRE) 620 is indicated by the "Next Header" field 612 in the IPv6 header 610.

[0064] The fields of SRE 620 include a "routing type" field 622 indicating the format of the segment route extension 620, a segment list field 625 containing a list of path segments to be traversed by the encapsulated packet 600, a "last entry" field 624 indicating the number of entries in the segment list 625, and a "remaining segments" field 621 indicating the number of segments in the segment list 625 that have not yet been traversed in the forwarding path. According to an embodiment of the invention, the ingress (classifier) ​​node 115 sets the "remaining segments" field 621 (and the "last entry" field 624) to (n-1), where n is the number of segments in the segment list 625.

[0065] The fields of SRE 620 may also include a “flag” field 626 indicating optional aspects of SRE 620 and a “metadata” field (not shown) containing information that can be used in the processing of SRE 620 and a segment list field 625.

[0066] The segment list field 625 contains a list of path segments that will be traversed by the encapsulated packet 600. Each entry in the segment list field 625 contains a segment identifier (SID), which can be used by the SFF 130 to identify a path to SF 135 or to SFN 140. Embodiments of the invention provide a path segment list as a reverse-ordered list, i.e., the first entry in the path segment list contains the SID identifying the last path segment, and the last entry in the path segment list contains the SID identifying the first path segment. In these embodiments, the path segment list will represent SFC[SF-A, SF-B, SF-C] as (SF-C, SF-B, SF-A). Other sorting methods for the entries in the path segment list may be used without departing from the scope of the invention. In some embodiments, the user packet includes an IPv6 header 610, and an SRE 620 is inserted after the IPv6 header 610 of the user packet. In these embodiments, encapsulated message 600 is a user message with SRE 620 following the IPv6 header 610 of the user message. The destination address field 616 in the IPv6 header 610 of the user message received by ingress node 115 is inserted as the last entry in the SID segment list field 625, i.e., (DA, SF-C, SF-B, SF-A), and is restored to the destination address field 616 of the user message by egress node 120.

[0067] Embodiments of the present invention provide an SRE 620 including a hashed message authentication code (HMAC) field 628, a segment list field 625 for protection, and other fields in some embodiments of the SRE 620. This protection is provided using cryptographic key material that the load balancer may not know but that is known to the ingress (classifier) ​​node 115 and network elements of the SFP (e.g., SF 135, SFN 140, or SFF 130). The HMAC 628 can be computed by the ingress (classifier) ​​node 115 and can be verified by the network elements of the SFP (e.g., SF 135, SFN 140, or SFF 130) using a pre-shared cryptographic key and a predetermined cryptographic hash algorithm.

[0068] According to an embodiment of the invention, SRE 620 may include a field for identifying the SFP instance selected to process the identified packet flow. The “SFP instance identifier” field 623 in SRE 620 may be provided as an indication of the primary SFP instance assigned to the identified packet flow by a load balancer (e.g., LB 210). The current number of instances of this SFP in the service domain may also be indicated by a field in SRE 620 represented as the “SFP instance count” field 627. The presence of the SFP instance identifier field 623 and the SFP instance count field 627 may be indicated by entries in the “routing type” field 622 or the “flag” field 626 of SRE 620.

[0069] According to certain embodiments of the invention, the SID in the path segment list included in segment list 625 may be encoded as a 128-bit IPv6 address associated with the SF within the SFP assigned to the identified message flow. Figure 6B The structured IPv6 address 640 is shown as the SID used within the segment list field 625B. Using the structured IPv6 address 640 as the SID within the segment list field 625B enables service function forwarding along the SFP using traditional IP routers within the service domain. For example... Figure 6B As shown, the structured IPv6 address 640 may include: a service group field 642, for example, indicating that the address is being used for service function linking to distinguish it from IPv6 addresses used for other purposes (e.g., as endpoint addresses); an SFP identifier field 644, for example, indicating an SFC or SFP associated with the SID; an instance field 646, indicating the primary instance of a protected SFP (i.e., an SFP instance) associated with the SID; and an SF identifier field 648, indicating an SF associated with the SID. In some embodiments, the SF identifier 648 is unique only or at least unique in the context of the SFP identifier; in other embodiments, the SF identifier may be unique in the context of the service domain.

[0070] In an alternative embodiment of the invention, the SID in the path segment list included in the segment list field 625 can be encoded as a compact SID in the compressed segment routing extension. Figure 6C The compact SID 650 is shown in the path segment list contained in the segment list field 625C. For example, the compact SID 650 can be an 8-bit to 64-bit token associated with the corresponding SF within the SFP. The SF token can, for example, be assigned by a management plane entity. The SF token can be unique at least in the context of the SFP, or it can be unique in the context of the business domain. For example, the SFF 130 or SFN 140 can use the token to access a lookup table, where information is stored to indicate how the encapsulated message 600 will be forwarded to the associated SF.

[0071] Back Figure 5 In step 540, the ingress (classifier) ​​node 115 inserts the incoming user message into the payload 630 of the encapsulated message 600, which has an IPv6 header 610 and an SRE 620, as shown below. Figure 6A As shown in the diagram, the source address field 614 is set to the address associated with the ingress (classifier) ​​node 115, and the destination address field 616 is set to the address of the load balancer (e.g., SFP-1LB 210) associated with the SFP corresponding to the selected SFC.

[0072] Embodiments of the present invention provide an ingress (classifier) ​​node (e.g., ingress classifier 115) to provide SRE 620 without identifying the SFP instance to be used in the corresponding SFP. In these embodiments, after selecting or identifying the SFP instance associated with the identified packet flow, the load balancer inserts the SFP instance into SRE 620. In embodiments that include the SFP instance identifier field 623 in SRE 620, ingress (classifier) ​​node 115 initializes SFP instance 623 (e.g., set I = 0). In embodiments that do not include the SFP instance identifier field 623 and include each SID in the path segment list in segment list field 625B as a structured IPv6 address 640, ingress (classifier) ​​node 115 initializes the SFP instance field 646 in each SID (e.g., set I = 0). The entry (classifier) ​​node 115 then sets the list of path segments contained in the segment list field 625 to indicate the sequence of SFs in the SFP (e.g., (SF-C, SF-B, SF-A)), and sets the last entry field 624 and the remaining segment field 621 to indicate the number of SIDs in the list of path segments contained in the segment list field 625 (e.g., in...). Figure 2 In the example, SL = (3–1) = 2). These values ​​for source address field 614, destination address field 616, and the information elements of SRE 620 are represented in Table 1 to indicate the direction of the user message from... Figure 2 The entry (classifier) ​​node 115 in the process transmits the IPv6 header 610 and SRE 620 in the encapsulated message to the SFP-1LB 210.

[0073] Table 1

[0074] Entry (Classifier) ​​Node SFP-1LB I=0; (SF-C, SF-B, SF-A); SL=2

[0075] Figure 7Operation 700, performed by a load balancer such as an SFP-1LB 210, according to an embodiment of the present invention, is illustrated. For illustrative purposes, the steps of operation 700 are provided in this order, but the order may be changed or some steps may be performed simultaneously without departing from the scope of the invention. In step 710, an encapsulated packet 600 having an IPv6 header 610 and an SRE 620 is received at the load balancer. In step 715, the load balancer determines, based on information in, for example, the header of a user packet, whether the user packet in the payload 630 of the encapsulated packet 600 indicates the start of a new packet flow. If the user packet indicates the start of a new packet flow, an instance of an SFP is selected in step 720 to serve the packet flow. Otherwise, if the user packet does not indicate the start of a new packet flow, the load balancer determines the instance of the SFP currently assigned to the packet flow in step 725. The SFP instance identified in step 720 or step 725 is considered the primary SFP instance for the identified packet flow.

[0076] According to certain embodiments of the present invention, in step 730, the identifier of the primary SFP instance (I) may be inserted into the optional field 623 of the SRE 620 encapsulating the message 600; Figure 3 In the example, I = 1. According to other embodiments of the invention, in step 730, the identifier of the primary SFP instance (I) may be inserted into the SFP instance field 646 of each SID 640 used as a structured IPv6 address in the path segment list contained in the segment list field 625B.

[0077] According to certain embodiments of the invention, in step 740, if the SFP instances can be dynamically provisioned in the business domain, for example, to reflect the expected load of the SFP, the load balancer can insert the current number of the SFP instances into optional field 627 in SRE 620.

[0078] In step 750, the SID associated with the first SF in the SFP is determined by the current value of the “Remaining Segment” field 621 of the SRE 620; in the example of Table 1, the list of path segments in the segment list field 625 indexed by SL=2 refers to the SID associated with SF-A.

[0079] In step 760, the network address associated with the first SF in the primary SFP instance is determined. In an embodiment where the SID is a structured IPv6 address 640, the SID associated with the first SF is directly used as the IP address attached to the first SF in the primary SFP instance. In an embodiment where the SID is a compact SID 650, a lookup table can be used to map the compact SID 650 associated with the first SF to a network (e.g., IP) address attached to the first SF in the primary SFP instance. If necessary, the identifier of the primary SFP instance (I) can be inserted into the instance identifier field 646 of the IP address 640.

[0080] In step 770, the network address determined in step 760 is inserted into the destination address field 616 of the encapsulated message 600. In step 780, the encapsulated message is forwarded to the first SF in the primary instance of the SFP. Figure 3 In the example, the values ​​of the source address field 614 and the destination address field 616 in the IPv6 header 610, and the information element example 230 of the SRE 620 of the encapsulated message 600 that transmits the user message from the load balancer SFP-1LB 210 to the first SF (SF-A 1.1 231) of the SFP are shown in Table 2.

[0081] Table 2

[0082] SFP-1 LB SF-A 1.1 I=1; (SF-C1.1, SF-B1.1, SF-A1.1); SL=2

[0083] Figure 8 This illustration shows an operation 800 performed at the SF within an SFP instance in a service domain and at the SF node or SFF associated with the SF, as provided by an embodiment of the present invention. For illustrative purposes, the steps of operation 800 are provided in this order, but the order may be changed or some steps may be performed simultaneously without departing from the scope of the invention. After receiving the encapsulated message 600 in step 810, the user message in the payload 630 of the encapsulated message 600 is processed by the SF instance in step 820. In step 830, if the processing in step 820 causes any SF state change, the SF state related to the message flow is updated. In step 840, if the SF state related to the message flow is updated in step 830, the updated SF state is propagated to the backup SF instance of the SF instance, as described below. Figure 3 Following the example, when a received user message at SF-A1.1 231 causes a change in the SF state, the SF state will be updated and propagated to the backup SF instances, namely SF-A1.2 251 and SF-A1.3 271.

[0084] In step 850, a test is performed to determine whether the current SF is the last SF in the SFP. This determination may be based on the value of the SRE “Remaining Segment” field 621 in SRE 620. Embodiments of the invention provide that after processing user packets at each SF along the SFP, the value of the SRE “Remaining Segment” field 621 is decremented. When the received value of the SRE “Remaining Segment” field 621 is equal to zero (0), this indicates that the current SF is the last SF in the SFP, as described in the “Yes” branch of step 850.

[0085] If the current SF is the last SF in the SFP, then in step 853, the SFN or SFF associated with the last SF extracts the user packet from the payload 630 of the encapsulated message 600, and in step 855, forwards the user packet to the destination node indicated by the destination address field in the header of the user packet.

[0086] If the current SF is not the last SF in the SFP (i.e., the received value of the SRE "Remaining Segment" field 621 is not equal to zero), then in step 860, after the "No" branch of step 850, the SFN or SFF associated with the SF instance determines the SID associated with the next SF in the SFP based on the value of the "Remaining Segment" field 621 in the SRE 620. According to some embodiments of the invention, the updated value of the SRE "Remaining Segment" field 621 is obtained by subtracting 1 from the value of the SRE "Remaining Segment" field 621 received in the encapsulated message 600 in step 810. According to the example in Table 2, the value of the SRE "Remaining Segment" field received by SF-A1.1 231 is SL=2, and the updated value is SL=1. The next SF from SF-A 1.1 231 is determined by indexing the SRE "Segment List" field 625 with SL=1, which refers to the SID of SF-B 1.1 233.

[0087] In step 870, the network address associated with the next SF instance (i.e., SF-B 1.1 233) is determined. As previously described, in the embodiment where the SID is a structured IPv6 address 640, the SID associated with the next SF is directly used as the network address associated with the next SF instance. In the embodiment where the SID is a compact SID 650, a lookup table can be used to map the compact SID 650 associated with the next SF to the network address associated with the next SF instance. In step 880, the determined network address is inserted into the destination address field 616 of the encapsulated message 600. In step 890, the SRE "Remaining Segment" field 621 of the encapsulated message 600 is updated with a new value (SL = 1). In step 895, the updated encapsulated message 600 is forwarded to the next SF instance (i.e., SF-B 1.1 233). Figure 3In the example, the values ​​of the source address field 614 and the destination address field 616 in the IPv6 header 610, as well as the information elements in the SRE 620 of the encapsulated message 600 that transmits the user message from SF-A 1.1 231 to SF-B 1.1 233, are shown in Table 3.

[0088] Table 3

[0089] SF-A1.1 SF-B 1.1 I=1; (SF-C1.1, SF-B1.1, SF-A1.1); SL=1

[0090] When executed in SF-B 1.1 233, operation 800 will cause the modified encapsulated message 600 to be forwarded to SF-C 1.1 235. Figure 3 In the example, the values ​​in the source address field 614 and destination address field 616 of the IPv6 header 610, as well as the information elements of the SRE 620 encapsulating the message, are shown in Table 4.

[0091] Table 4

[0092] SF-B 1.1 SF-C 1.1 I=1, (SF-C1.1, SF-B1.1, SF-A1.1); SL=0)

[0093] Operation 800 is performed at the last SF (i.e., SF-C 1.1 235) instance in the SFP, where a received SRE “Remaining Segment” field 621 value equal to zero (SL = 0) will result in the “Yes” branch of step 850 as described above. The steps of operation 800 do not establish any particular order of operations, but are merely illustrative. Those skilled in the art will recognize that the order of the illustrated steps can be changed, and some steps or actions can be performed simultaneously without affecting the work of the invention.

[0094] In operation 800 described above, before forwarding the user or encapsulating message 600, the SF state update (also known as a state update message, which may be transmitted in the state update message) is propagated to other SF instances in the SF instance set in step 840. However, some embodiments of the present invention provide that the SF state update is propagated after forwarding the encapsulating message 600 (i.e., after step 895) or after forwarding the user message (i.e., after step 855). Those skilled in the art will recognize that the propagation of the SF state update can be performed before or after the forwarding step without departing from the principles or scope of the present invention.

[0095] Embodiments of the present invention provide SF instances to propagate SF state changes (i.e., indications of SF state changes) or updated SF states to their backup SF instances. According to embodiments of the present invention, backup SF instances of an SF instance set are used to cooperatively synchronize message flow-related SF states whenever the processing of user messages by an SF instance causes a message flow-related state change.

[0096] According to an embodiment of the present invention, the maintenance of the SF state can be handled by a backup SF instance of the SF instance set, without actually processing the user packets that constitute the message stream of the identifier.

[0097] According to some embodiments, an SF state change (i.e., an indication of an SF state change) can be sent as a unicast message to each SF instance in a set of backup SF instances configured as the primary SF instance. The unicast message may have a destination network address associated with the backup SF instance and an indication identifying the SFP instance associated with the backup SF instance. The source address of the unicast message may be associated with the primary SF instance and has an indication of the primary SFP instance associated with the primary SF instance. For example, the destination network address and source network address of the unicast message may each be a structured IPv6 address 640 with an SF instance identifier field 646. Alternatively, a multicast (or broadcast) message can be used to send the SF state change to all backup SF instances. In other embodiments, the state message may be a unicast message with an SRE 620, wherein the list of backup SF instances is included in the SRE segment list field 625.

[0098] According to other embodiments, an SF state propagation method can be used, wherein a message containing an SF state change (i.e., an indication of an SF state change) is sequentially sent from one SF instance in a set of SF instances to another SF instance. According to embodiments of the invention, each SF instance may be configured (e.g., by a management function) with an identifier for another SF instance to which the SF state is to be sent. According to other embodiments of the invention, the SF state may be propagated from one SF instance to another in a cyclical manner. Figure 9 A cyclic SF state propagation method is illustrated, denoted as Operation 900. For illustrative purposes, the steps of Operation 900 are provided in this order, but the order may be changed or some steps may be performed simultaneously without departing from the scope of the invention. In step 910, the initial SF instance that needs to propagate its SF state generates a status message, which is a unicast message containing an SF state indication, and in step 920, its network address is inserted into the source address field of the status message. According to some embodiments of the invention, the network address of the initial SF instance is a structured IPv6 address 640 with an SFP instance identifier field 646, and the initial SF instance in SFP instance k inserts the value k into the SFP instance identifier field 646 of the status message source address 614. In step 925, the initial SF instance starts a synchronization timer T.

[0099] In step 930, the SF generates a network address associated with the SF instance in a neighboring SFP instance. According to some embodiments of the invention, the network address associated with the SF instance in a neighboring SFP instance is a structured IPv6 address 640 with an SFP instance identifier field 646, and the SF instance is based on instance modulo operation I. OUT =(I IN +1)mod(n) sets the SFP instance identifier field 646 of the destination address 614 of the status message to the value I. OUT Where n is the number of SFP instances in the business domain, I IN It is the value of the SFP instance identifier field 646 in the destination address 614 of the status message received by the SF instance; in the initial SF instance, I IN =k. In some embodiments, the value of n can be pre-configured in the SF instance (e.g., through management functions). In other embodiments, the value of n can be determined from the "Number of SFP Instances" field 627 in the SRE 620 encapsulating message 600. In step 940, the generated network address is inserted into the destination address field 616 of the status message, and the status message is forwarded to the adjacent SF instance.

[0100] In step 950, the SF instance receiving the status message determines whether the destination address 616 in the status message is the same as the source address 614 in the status message. If they are the same, it indicates that the status message has been returned to the SF instance that initiated the status message in step 920, and the "Yes" branch in step 950 is followed. In step 980, the initiating SF instance stops the synchronization timer T, and in step 985, it is considered that the SF state needs to be synchronized with other SF instances in the SF instance set.

[0101] If the destination address 616 in the status message is different from the source address 614 in the status message, then the "No" branch in step 950 is followed. In step 960, the backup instance of the SF stores the SF status associated with the SF instance indicated by the SFP instance identifier field 646 of the source address 614 in the status message. In step 930, the backup instance of the SF instance continues operation 900.

[0102] In step 990, the initiating SF instance determines whether the synchronization timer T has expired. If the synchronization timer T expires before the initiating SF instance receives a copy of its SF status message, the "Yes" branch of step 990 is followed, indicating that SF status synchronization across the SF instance set was unsuccessful, and a fault recovery procedure can be initiated in step 995. Such a fault recovery procedure may include the initiating SF instance retransmitting the SF status message according to operation 900, or other recovery procedures known to those skilled in the art may be used.

[0103] Figure 10 An SF state propagation operation 1000 using a structured IPv6 address 640 with an SF instance identifier field 646 is illustrated. For illustrative purposes, the steps of the SF state propagation operation 1000 are provided in this order, but the order may be changed or some steps may be performed simultaneously without departing from the scope of the invention. The initial SF instance 1010 associated with SFP instance k generates a state message 1012 for forwarding to a backup SF instance 1020 associated with SFP instance k+1; the SF instance identifier of the source address of state message 1012 is set to k, and the SF instance identifier of the destination address of state message 1012 is set to k+1. The state message is propagated through subsequent backup instances of the SF, wherein each backup instance of the SF adds the SF instance identifier field 646 to the destination address of the state message, while keeping the source address of state message 1012 unchanged. Finally, SF 1030, associated with the last SFP instance n, receives a copy of status message 1022, where the SF instance identifier at the source address of status message 1022 is set to k, and the SF instance identifier at the destination address of status message 1022 is set to n. Backup SF instance n 1030 modifies status message 1032 such that, according to the modulo addition operation described in step 930 of operation 900, the SF instance identifier at the destination address of the status message is set to 1. Status message 1032 is received by backup SF instance 1040, associated with SFP instance 1. Status message 1042 is forwarded by backup SF instance 1040, and the SF instance identifier at the destination address of status message 1042 is incremented to 2. Status message 1042 is propagated through subsequent backup instances of the SF, with each backup instance of the SF incrementing the SF instance identifier field 646 in the destination address of the status message, until it is received by SF 1050, associated with SFP instance k–1. Backup SF instance k-1 forwards the modified status message 1052, in which the SF instance identifier of the destination address of status message 1052 is increased to k, and the SF instance identifier of the unmodified source address of status message 1052 is also set to k. When status message 1052 is received by the starting SF instance 1010, the starting SF instance 1010 identifies the matching source and destination addresses to indicate that the status message has been successfully propagated through the SF instance set.

[0104] Figure 11 This illustrates operation 1100, which reroutes messages along the path around a communication failure to the next SF instance. The steps of operation 1100 can be performed by a single entity or by a combination of entities such as SF, SFF, or SFN and a rerouting function (RRF). For illustrative purposes, the steps of operation 1100 are provided in this order, but the order can be changed or some steps can be performed simultaneously without departing from the scope of the invention. (The following will be followed...) Figure 4 The example describes operation 1100, where a network entity affiliated with SF-A 1.1 231 detects a communication failure along the path to SF-B 1.1 433, and redirects the packet to the backup instance SF-B 1.2 253.

[0105] In step 1110, an encapsulated packet 600 with SRE 620 is received at an SF instance (e.g., SF-A 1.1 231). In step 1120, the user packet in the payload 630 of the encapsulated packet 600 is processed according to an embodiment of the present invention, for example, to process the user packet according to the service function (SF-A 1.1 231), and if necessary, propagate the updated SF state to the backup SF instances in the SF instance set. In step 1130, the SRE 620 in the encapsulated packet 600 is used to identify the SID associated with the next SF in the SFP. In step 1140, the network address associated with the SID is determined, and a check is performed to ensure that an operational path to the network address associated with the next SF in the SFP instance exists. If an operational path to the next SF in the SFP instance exists, the "Yes" branch of step 1150 is followed, and in step 1190, the encapsulated packet is forwarded to the network address associated with the next SF in the SFP instance.

[0106] If no operational path to the next SF in the SFP instance exists, the "No" branch of step 1150 is followed, and in step 1160, a rerouting function (RRF) determines a backup SF instance in another instance of the SFP. According to an embodiment of the present invention, and following Figure 4 the example, the RRF may be affiliated with the SFN 140 or SFF 130 associated with SF 135, such as SF-A 1.1 231; the RRF may also be affiliated with a load balancer, such as SFP-1 LB 210. According to an embodiment of the present invention, the RRF may select a backup SF instance of the failed SF instance, so as to distribute the processing load of the failed SF instance to the remaining SF instances. The RRF may, for example, select the backup SF instance randomly, select the backup SF instance in a polling manner, or select the backup SF instance according to the current load in each backup SF instance.

[0107] For example, the RRF may select a number m (1≤m<n) and derive the backup SF instance (b) as a modulo operation, for example, b=(k+m)mod(n), where n is the number of SFP instances in the service domain (e.g., as indicated by the "Number of SFP Instances" field 627 in SRE 620). In Figure 4In the example, if m = 1, then b = 2, and the backup SF instance is SF-B 1.2 253. According to other embodiments of the invention, for example, the management function can be pre-configured with the RRF to use the backup SF instance (b) in the event of a communication failure.

[0108] In step 1170, when using the structured IPv6 address 640 as the SID to obtain the network address associated with the backup SF instance b, the RRF determines the network address associated with the backup SF instance b by inserting b into the SFP instance identifier field 646, or by accessing the lookup table entry associated with the backup SF instance b when using the compact SID 650 as described above. In step 1180, the RRF inserts the resolved IP address of the backup SF instance b (i.e., SF-B 1.2 253) into the destination address field of the encapsulated message 600, and then sends the encapsulated message 600 to the network address associated with the selected backup SF instance (SF-B 1.2 253).

[0109] According to an embodiment of the present invention, even if the encapsulated message 600 is forwarded to a backup SF instance associated with a different SFP instance (I=2), the SFP instance identifier 623 within the SRE 620 of the received encapsulated message 600 remains unchanged (i.e., it remains set to the primary SFP instance (i.e., I=1)). Figure 4 In the example, the values ​​of the source address field 614 and the destination address field 616 in the IPv6 header 610, as well as the information element SRE 620 of the encapsulated message 600 that transmits the user message from SF-A1.1 231 to SF-B1.2 253, are shown in Table 5.

[0110] Table 5

[0111] SF-A1.1 SF-B 1.2 I=1; (SF-C1.1, SF-B1.1, SF-A1.1); SL=1

[0112] Embodiments of the present invention provide a backup SF instance that, after processing user packets, redirects the encapsulated packet 600 back to the primary SFP instance originally assigned by the load balancer to the identified packet stream. Figure 4 Following the example, the route restoration function (RSF) associated with the backup SF instance (i.e., SF-B 1.2 253 in SFP instance 250 (I=2)) can forward the encapsulated packet 600 to the next SF of the primary SFP instance (i.e., SF-C 1.1 235 in SFP instance 230 (I=1)). Figure 12This illustrates an operation 1200 of backing up an SF instance (e.g., SF-B 1.2 253) after receiving encapsulated message 600 due to a communication failure in the path of the primary SFP. For illustrative purposes, the steps of operation 1200 are provided in this order, but some steps may be performed in a different order or simultaneously without departing from the scope of the invention.

[0113] In step 1210, an encapsulated message 600 with SRE 620 is received at the backup SF instance (e.g., SF-B1.2 253 in SFP instance 250 (b=2)). In step 1220, the backup SF instance retrieves the SFP instance identifier 623(I) from the SRE 620 of the encapsulated message 600. In step 1230, the backup SF instance determines that the SFP instance identifier (I) does not match the SFP instance (b) of the backup SF instance (i.e., I ≠ b).

[0114] In step 1240, the backup SF instance (SF-B 1.2 253) retrieves the storage SF state associated with the primary SFP instance (I) of the identified message flow, and then performs further processing of the user message in the payload 630 of the encapsulated message 600 according to an embodiment of the present invention.

[0115] In step 1250, if a user message processed by the backup SF instance causes a change in the SF state related to the message stream, then as described above, the backup SF instance propagates the updated SF state or SF state change of the message stream identified (i.e., an indication of an SF state change).

[0116] In step 1260, the route restoration function (RSF) may be attached to the SFN 140 or SFF 130 associated with the backup SF instance, update the "remaining segment" field 621 of the SRE 620, and determine the SID of the next SF to receive the encapsulated message 600 based on the segment list 625 as described above.

[0117] In step 1270, based on whether the SID is the structured IPv6 address 640 as described above or the compact SID 650, the network address associated with the SID of the next SF instance is determined.

[0118] Since the backup SF instance is associated with an SFP instance (b) of the primary SFP instance (I) with a different identifier for the packet flow, the network address of the next SF instance determined in step 1270 can refer to the SF in SFP instance b. Therefore, in step 1280, the network address of the next SF instance is modified to insert the identifier of the primary SFP instance (I) into the SFP instance identifier field 646 of network address 640.

[0119] In step 1290, the network address of the next SF instance determined in step 1270 is inserted into the destination address field 616 of the encapsulated message 600, and the encapsulated message 600 is forwarded to the next SF (SF-C 1.1235) in the primary SFP instance, thereby restoring the encapsulated message 600 to the primary SFP instance associated with the identified message flow for subsequent processing. Figure 4 In the example, the values ​​of the source address field 614 and the destination address field 616 in the IPv6 header 610, as well as the information elements in the SRE 620 encapsulating the message, are shown in Table 6.

[0120] Table 6

[0121] SF-B 1.2 SF-C 1.1 I=1, (SF-C1.1, SF-B1.1, SF-A1.1); SL=0)

[0122] refer to Figure 13 Embodiments of the present invention provide a network device 1300, for example, a network device for functioning as a classifier, ingress node 115, load balancer, service function node, service function forwarder, or service function. Network device 1300 includes a processor 1305, a network interface 1310, and a memory 1315 capable of storing at least program instructions executable by the processor 1305. Network device 1300 may optionally be provided using network function virtualization or similar technologies. Network device 1300 may be provided as a single integrated physical device or a single integrated virtual device using different physical resources, such as resources in a data network, resources in a data center, resources provided by a network service provider, or a combination thereof. Network device 1300 is used to send and receive user packets through the network interface. Network device 1300 is used to operate on user packets using the processor and / or memory, such as encapsulating user packets in encapsulated packets, operating on data in the encapsulated packet header, modifying or replacing data in the encapsulated packet header, and / or operating on the payload of the encapsulated packets.

[0123] The above-mentioned operations of the network device can be performed by one or more functional modules, which include at least a processor, a network interface, and a memory that operate in a specific manner.

[0124] The various methods disclosed herein can be implemented on one or more real or virtual computing devices, such as devices operating in the control plane of a communication network, devices operating in the data plane of a communication network, or combinations thereof. A computing device for implementing the operations described herein may include a processor operatively coupled to a memory that provides instructions executed by the processor to perform the methods described herein.

[0125] Various embodiments of the present invention utilize real and / or virtual computer resources. Such computer resources utilize at the hardware level a set of one or more processors operatively coupled to a corresponding set of memory components, the memory components including stored program instructions executed by the processors. Computational resources can be used to provide virtual computing resources at one or more virtualization levels. For example, one or more given general-purpose computer hardware platforms can be used to provide one or more virtual computers. Computer hardware (e.g., processor resources and memory) can also be virtualized to provide resources from which other virtual computers are built. A set of computing resources allocable to provide various computing resources, which in turn are used to implement various computing components of the system, can be considered as providing a distributed computing system whose internal architecture can be configured in various ways.

[0126] Based on the description of the above embodiments, the present invention can be implemented solely in hardware, or it can be implemented using software and a necessary general-purpose hardware platform. Based on this understanding, the technical solution of the present invention can be embodied in the form of a software product. The software product can be stored in a non-volatile or non-transitory storage medium, such as a compact disk read-only memory (CD-ROM), a USB flash drive, or a removable hard drive. The software product includes a number of instructions that enable a computer device (personal computer, server, or network device) to perform the methods provided in the embodiments of the present invention. For example, such performance may correspond to the simulation of the logical operations described herein. According to exemplary embodiments, the software product may additionally or alternatively include multiple instructions that enable a computer device to perform operations configuring or programming digital logic devices.

[0127] Although specific embodiments of the invention have been described in detail, it should be understood that the described embodiments are intended to be illustrative and not restrictive. Various changes and modifications to the embodiments shown in the drawings and described in the specification can be made within the scope of the following claims without departing from the broader scope of the invention.

Claims

1. A method for processing message flows in a service function path (SFP), characterized in that, The method includes: The network function receives a first message from the message stream, the first message including an indication identifying the primary SFP instance assigned to the message stream, wherein the network function is associated with the primary SFP instance; The network function sends the first message to the primary second network function, which is associated with the primary SFP instance. In response to a communication failure with the primary second network function, the network function sends a second message in the message stream to a backup second network function associated with the second SFP instance. The second message is received by the network function after the first message in the message stream and includes an indication identifying the primary SFP instance of the message stream. The primary second network function updates the status of the packet flow-related service function (SF) associated with the packet flow based on the first message, wherein the primary second network function and the backup second network function are communicatively coupled to synchronize the packet flow-related SF status; The synchronization of the message stream-related SF status includes: The primary second network function determines the second SFP instance associated with the backup second network function based on the indication of the primary SFP instance that identifies the packet flow; The primary second network function sends a status update message to the backup second network function, including the SF status of the packet flow associated with the packet flow; The status update message is sent in a status update packet, wherein the destination address of the status update packet is a unicast address associated with the backup second network function, the source address of the status update packet is a unicast address associated with the primary second network function, the destination address includes an indication identifying the second SFP instance associated with the backup second network function, and the source address includes an indication identifying the primary SFP instance associated with the primary second network function.

2. The method according to claim 1, characterized in that, Also includes: The primary and secondary network functions start timer; The primary second network function receives a copy of the state update message before the timer expires, wherein the destination address associated with the copy of the state update message is a unicast address including the SFP instance associated with the primary second network function.

3. The method according to claim 2, characterized in that, The copy of the state update message is received by the primary second network function because the state update message is forwarded among members of the SF instance set. The SF instance set includes at least the primary second network function and the backup second network function, wherein each member of the SF instance set is used to forward a copy of the state update message to a designated next member of the SF instance set, and each member of the SF instance set is associated with a different SFP instance.

4. The method according to claim 3, characterized in that, The indication of the number of members in the SF instance set is included in the segment routing extension (SRE) associated with each of the first and second messages.

5. The method according to claim 1, characterized in that, The status update message is sent in a status update packet, wherein the destination address of the status update packet is a multicast address associated with one or more backup network functions, each of the one or more backup network functions being associated with a different SFP instance.

6. The method according to any one of claims 1 to 5, characterized in that, After processing the second message, the backup second network function sends the second message to the primary third network function associated with the primary SFP instance, based on the instruction in the second message that identifies the primary SFP instance of the message flow.

7. The method according to any one of claims 1 to 6, characterized in that, The indication identifying the primary SFP instance is included in the segment routing extension (SRE) associated with each of the first and second packets.

8. The method according to claim 7, characterized in that, The segment routing extension also includes a segment list, wherein the segment list includes a list of segment identifiers (SIDs), each SID being associated with a different corresponding service function among the multiple service functions that form the SFP.

9. The method according to claim 8, characterized in that, Each SID is an Internet Protocol (IP) address, and the IP address includes the indication that identifies the primary SFP instance.

10. The method according to any one of claims 1 to 9, characterized in that, It also includes the network function updating the SF status of the auxiliary message flow related service functions associated with the message flow based on the first data packet, wherein the network function and the backup network function are communicatively coupled to synchronize the SF status of the auxiliary message flow.

11. A network node, characterized in that, include: Network interface; processor; First memory; A non-transient memory that stores instructions that, when executed by the processor, cause the network node to perform the method according to any one of claims 1 to 10.

12. A computer-readable medium, characterized in that, Includes instructions that, when executed by the processor of a network node, cause the network node to perform the method according to any one of claims 1 to 10.

13. A method for processing message flows in a service function path (SFP), characterized in that, include: At the network node, a status update message is received, the status update message including the status of the service function (SF) associated with the packet flow, the status update message including an indication identifying the primary service function path (SFP) instance associated with the packet flow, wherein the network node forms part of an SFP instance other than the primary SFP instance of the packet flow; Based on the primary SFP instance indicated in the status update message, the network node stores the packet flow-related SF status associated with the packet flow; The network node sends a copy of the state update message, the copy of which includes an indication identifying another SFP instance associated with the message flow; At the network node, a message associated with the message flow is received, the message including an indication identifying the primary service function path (SFP) instance associated with the message flow; Based on the primary SFP instance indicated in the message, at the network node, the message flow state associated with the message flow is retrieved; The network node sends the message to another network node; Based on the message, at the network node, update the SF state associated with the message flow. The network node sends a second state update message, which includes the updated SF state associated with the packet flow.

14. The method according to claim 13, characterized in that, The other network node is associated with the primary SFP instance indicated in the message.

15. A network node, characterized in that, include: Network interface; processor; Memory; Non-transient memory stores instructions that, when executed by the processor, cause the network node to: The network interface is used to receive a status update message, the status update message including the status of the service function (SF) associated with the packet flow, the status update message including an indication identifying the main service function path (SFP) instance associated with the packet flow, wherein the network node forms part of an SFP instance other than the main SFP instance of the packet flow; Based on the primary SFP instance indicated in the status update message, the packet flow-related SF status associated with the packet flow is stored in the memory; A copy of the state update message is sent using the network interface, the copy of the state update message including an indication identifying another SFP instance associated with the message flow; When the instruction is executed by the processor, it also causes the network node to: The network interface is used to receive a message associated with the message flow, the message including an indication identifying the primary service function path (SFP) instance associated with the message flow; Based on the primary SFP instance indicated in the message, retrieve the message flow state associated with the message flow from the memory; Use the network interface to send the message to another network node; When the instruction is executed by the processor, it also causes the network node to: Based on the message, update the message stream-related SF state associated with the message stream in the memory; The network interface is used to send a second state update message, which includes the updated SF state associated with the message flow.

16. The network node according to claim 15, characterized in that, The other network node is associated with the primary SFP instance indicated in the message.

17. A computer-readable medium, characterized in that, Includes instructions that, when executed by the processor of a network node, cause the network node to perform the method according to any one of claims 13 to 14.

Images