CN113079089A

CN113079089A - Service chain fault protection method, device, equipment, system and storage medium

Info

Publication number: CN113079089A
Application number: CN202010004825.6A
Authority: CN
Inventors: 路君; 韦乃文; 苗青
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-01-03
Filing date: 2020-01-03
Publication date: 2021-07-06
Also published as: EP4075738A1; EP4075738A4; WO2021135420A1; US20220337514A1

Abstract

The application provides a method, a device, equipment, a system and a storage medium for fault protection of a service chain, and belongs to the technical field of communication. In the SRV6 static service chain scenario, when a link between an SF network element and an accessed SFF fails, a secondary SID (subordinate SID) is introduced to update a destination address field of a header of a message to the secondary SID, so that the message is directed to other SFFs accessed by the SF network element through the secondary SID, thereby implementing link failure protection between the SFF and the SF network element, avoiding interruption of traffic due to a single-point link failure, and improving reliability of a service chain.

Description

Service chain fault protection method, device, equipment, system and storage medium

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method, an apparatus, a device, a system, and a storage medium for service chain fault protection.

Background

A Service Function Chain (SFC) is a technology for providing an ordered service to an application layer. The SFC will carry the service link path information in the message, and indicate the path to be passed by the message through the service link path information, so that the message sequentially passes through each device according to the specified path. In this way, services provided by the devices can be logically linked to form an ordered combination of services.

The framework of the SFC includes nodes such as a flow Classifier (CF), a Service Function (SF), an SFC Proxy (SFC Proxy), and a Service function forwarding device (SFF). The SFF is configured to forward a message received from a network to a plurality of SFs associated with the SFF according to service link path information carried in the message. The SF is used for receiving the message from the SFF, performing service function processing on the message, and returning the processed message to the same SFF. Logically, the SFC agent is located between the SFF and its associated SFs that do not sense the service link path information, and the SFC agent may receive a message from the SFF on behalf of the SFs, delete the service link path information, and forward the message to the SFs. Physically, the SFF and SFC agents are typically integrated on the same device.

In the meantime, with the continuous evolution of Segment Routing (SR), the service link path information in the SFC technology is usually implemented based on Segment ID (SID) in the SR technology. Specifically, when the SR technology is used to transmit a packet in the SFC, the packet may include a segment list (segment list), where the segment list includes ordered SIDs, a node or a link through which the packet passes may be specified by the SID, and a path sequence of a service chain may be specified by an order of the SIDs. When an internet protocol version 6 (IPv 6for short) is used as a forwarding plane of the SR, each SID in the segment list is in the form of an IPv6 address, and the segment list is carried by a segment routing header (SRH for short) in the message; when Multi-Protocol Label Switching (MPLS for short) is used as the forwarding plane of the SR, the segment list is a Label stack in MPLS.

In many scenarios, an SF in the service chain is a device that does not support SR (SR-unaware), i.e., the SF itself may not be able to identify the segment list. In view of this, if the SFF receives a message addressed to the SF, the SFF may perform a proxy operation for the SF by performing a proxy function on the SFC. Specifically, the SFF deletes the segment list from the received message, caches the short list in a cache (cache), and forwards the message not including the segment list to the SF through a link between the SFF and the SF. When the SF receives the message, even if the SF is an SR-unaware device, the message received by the SF can be identified and the service function processing can be carried out because the message does not contain the SRH.

In the current service chain technology, when an SFF receives a message to be sent to an SF, if a link between the SFF and the SF fails, the message cannot reach the SF, which causes traffic interruption.

Disclosure of Invention

The embodiment of the application provides a method, a device, equipment, a system and a storage medium for service chain fault protection, which can avoid service flow interruption caused by faults and improve the reliability of a service chain. The technical scheme is as follows:

in a first aspect, a method for protecting a service chain from a fault is provided, in which a first service function forwarding device SFF in a service chain receives a first message, a destination address field of a message header of the first message includes an agent segment identifier SID corresponding to a first service function SF network element in the service chain, and the first SFF is an SFF accessed by the first SF network element; if the link between the first SFF and the first SF network element fails, the first SFF updates the destination address field of the first message to obtain a second message, the destination address field of the second message includes a first subordinate SID, the first subordinate SID is a local SID of a second SFF in the service chain, the second SFF is another SFF in a protection group except the first SFF, the protection group includes a plurality of SFFs accessed by the first SF network element, and the second message includes a load of the first message; and the first SFF sends the second message.

By the method, under a SRV6 static service chain scene, when a link between an SF network element and an accessed SFF fails, a secondary SID (subordinate SID) is introduced, and a destination address field of a message header of a message is updated to the secondary SID, so that the message is drained to other SFFs accessed by the SF network element through the secondary SID, thereby realizing link failure protection between the SFFs and the SF network element, avoiding interruption of flow caused by single-point link failure, and improving the reliability of a service chain.

Optionally, the type of the first subordinate SID is an endpoint End type.

By selecting the SID of the End type as the first secondary SID, compared with the mode of selecting the SID of the end.x type as the first secondary SID, the operation of designating a next hop and an egress interface when configuring the end.x SID can be avoided, so that the situation that a large number of secondary SIDs are to be configured on the first SFF instead of the globally unique secondary SID due to the fact that the end.x SID has functions of both drainage and designation of an egress interface instead of the original proxy SID (proxy SID) is avoided. In addition, the first secondary SID is an End type SID, so that the subsequent planning of the backup SID is prevented from causing large constraint.

Optionally, the method further comprises: and the first SFF replaces the proxy SID in the first message with a backup SID, wherein the backup SID is used for indicating that the second SFF does not update the destination address field of the second message to be a second subordinate SID, and the second subordinate SID is a local SID of the first SFF.

Through the optional mode, even if the links between the SF network element and the two dual-homed SFFs are failed in the SRV6 static service chain scene, the proxy SID originally contained in the message is replaced by the backup SID by introducing the backup SID (backup SID), so that the message can be drained to other SFFs accessed by the SF network element through the backup SID, and can also indicate other SFFs to forward to the SF network element through the backup SID without entering the secondary SID flow, thereby avoiding the flow loop caused by the other SFFs entering the secondary SID flow. Thus, with the backup SID mechanism, the flow loop caused by double-point failure can be prevented.

Optionally, the protection group is an anycast group, and the proxy SID issued by different SFFs in the anycast group is an anycast SID.

In a second aspect, a method for protecting a service chain from a fault is provided, in which a second SFF in a service chain receives a second packet, a destination address field of a packet header of the second packet includes a first subordinate SID, and the first subordinate SID is a SID local to the second SFF; the second SFF carries out local forwarding processing on the second message according to the first subordinate SID to obtain a third message; the second SFF obtains a fourth message according to the third message, wherein the fourth message comprises the load of the third message and does not comprise a segment list; and the second SFF sends the fourth message to the first SF network element in the service chain.

Optionally, the type of the first subordinate SID is an endpoint End type.

By selecting the SID of the End type as the first secondary SID, compared with the mode of selecting the SID of the end.x type as the first secondary SID, the operation of designating a next hop and an egress interface when configuring the end.x SID can be avoided, so that the situation that a large number of secondary SIDs are to be configured on the first SFF instead of globally unique secondary SIDs due to the fact that the end.x SID has functions of both a drainage function and an egress interface designation function instead of the original proxy SID is avoided. In addition, because the first secondary SID is an End type SID, it is avoided that a subsequent planning for a backup SID (backup SID) is greatly restricted.

Optionally, the destination address field of the header of the third packet includes the proxy SID corresponding to the first SF network element, and the sending, by the second SFF, the fourth packet to the first SF network element includes: and the second SFF sends the fourth message to the first SF network element through an output interface corresponding to the proxy SID.

Optionally, a destination address field of a header of the third packet includes a backup SID, where the backup SID is used to indicate that the second SFF does not update the destination address field of the second packet to a second subordinate SID, the second subordinate SID is a local SID of the first SFF, and the second SFF sends the fourth packet to the first SF network element, where the method includes:

and the second SFF sends the fourth message to the first SF network element through an output interface corresponding to the backup SID.

Optionally, the type of the second subordinate SID is an End type.

Optionally, a destination address field of a header of the third packet includes a backup SID, and the method further includes: if the output interface corresponding to the backup SID fails, the second SFF updates the destination address field of the third message to obtain an eighth message, wherein the destination address field of the message header of the eighth message comprises a drainage SID, and the drainage SID is a local SID of the third SFF; and the second SFF sends the eighth message.

Through the optional mode, in an SRV6 static service chain scene, when an SF network element fails, a bypass SID (drainage SID) is introduced to update a destination address field of a packet header of a packet to the bypass SID, so that the packet is drained to other SF network elements, such as a backup SF network element outside an original path or a next SF network element inside the original path, through the bypass SID, thereby performing service protection through other network elements, implementing normal forwarding of service traffic, avoiding interruption of traffic due to a single node failure, and improving reliability of a service chain.

Optionally, the method further comprises: and if the outlet interface corresponding to the backup SID fails and the local SID table of the second SFF does not have the drainage SID, the second SFF discards the third message.

In the method, a fourth service function forwarding device SFF in a service chain receives a fifth message, where a destination address of a message header of the fifth message includes an agent segment identifier SID corresponding to a second SF network element in the service chain, and the fourth SFF is an SFF accessed by the second SF; if the second SF network element is in a fault state, the fourth SFF updates the destination address field of the fifth message to obtain a sixth message, the destination address of the message header of the sixth message includes a drainage SID, the drainage SID is a local SID of the fifth SFF, the fifth SFF is an SFF accessed by a third SF network element, the third SF network element is another SF network element except the second SF network element, and the sixth message includes a load of the fifth message; and the fourth SFF sends the sixth message.

In a static service chain scenario of SRV6, when an SF network element fails, a bypass SID is introduced to update a destination address field of a header of a packet to a bypass SID (drainage SID), so that the packet is drained to other SF network elements, such as a backup SF network element outside an original path or a next SF network element inside the original path, through the bypass SID, thereby performing service protection through other network elements, implementing normal forwarding of service traffic, avoiding interruption of traffic due to a single node failure, and improving reliability of a service chain.

Optionally, the drainage SID is an End type SID; or, the drainage SID is a proxy SID corresponding to the third SF network element.

Optionally, the method further comprises: if an output interface corresponding to the agent SID is in an open state and each virtual machine where the second SF network element is located is unreachable, the fourth SFF detects that the second SF network element is in a fault state, and the agent SID is used for indicating that the second SF network element executes agent operation; or, if at least one of the egress interface corresponding to the backup SID or the egress interface corresponding to the proxy SID has a link failure, the fourth SFF detects that the second SF network element is in a failure state, where the backup SID is used to indicate that the fourth SFF does not update the destination address field of the second packet to a third subordinate SID, the third subordinate SID is a local SID of a fifth SFF, the fifth SFF is another SFF except the fourth SFF in a protection group, and the protection group includes multiple SFFs accessed by the second SF network element.

Optionally, the third subordinate SID is an End-type SID;

optionally, the third SF network element is a backup SF network element of the second SF network element; or, the third SF network element is a next SF network element of the second SF network element in the service chain.

In the method, a fifth service function forwarding device SFF in a service chain receives a sixth message, a destination address field of a message header of the sixth message includes a drainage SID, the drainage SID is a SID local to the fifth SFF, and the fifth SFF is an SFF accessed by a SF network element of a third service function; the fifth SFF obtains a seventh message according to the sixth message, wherein the seventh message comprises the load of the sixth message and does not comprise a segment list; and the fifth SFF sends the seventh message to the third SF network element.

Optionally, the drainage SID is an End type SID; or, the drainage SID is the proxy SID corresponding to the third SF network element.

Optionally, the obtaining, by the fifth SFF, a seventh packet according to the sixth packet includes: the fifth SFF performs local forwarding processing on the sixth message according to the bypass SID to obtain an eighth message, where a destination address field of a message header of the eighth message includes an agent SID corresponding to the third SF network element, and the eighth message includes a load of the sixth message; and the fifth SFF obtains the seventh message according to the eighth message.

Optionally, the third SF network element is a backup SF network element of a second SF network element, and the second SF network element is an SF network element in a fault state; or, the third SF network element is a next SF network element of the second SF network element in the service chain.

In a fifth aspect, an SFF is provided, where the SFF has a function of implementing fault protection for a service chain in the first aspect or any one of the optional manners of the first aspect. The SFF includes at least one module, and the at least one module is configured to implement the method for fault protection of the service chain provided in the first aspect or any one of the optional manners of the first aspect.

Optionally, the type of the first subordinate SID is an endpoint End type.

Specific details of the SFF provided by the fifth aspect may be found in the first aspect or any alternative manner of the first aspect, and are not described herein again.

A sixth aspect provides an SFF having a function of implementing fault protection of a service chain in the second aspect or any of the alternatives of the second aspect. The SFF includes at least one module, and the at least one module is configured to implement the method for fault protection of the service chain provided in the second aspect or any optional manner of the second aspect.

Optionally, the type of the first subordinate SID is an End type.

Optionally, the SFF further comprises: and the discarding module is configured to discard the third packet if the outgoing interface corresponding to the backup SID fails and the local SID list does not have the drainage SID.

Specific details of the SFF provided by the sixth aspect may be found in the second aspect or any alternative manner of the second aspect, and are not described herein again.

In a seventh aspect, an SFF is provided, where the SFF has a function of implementing fault protection for a service chain in the third aspect or any optional manner of the third aspect. The SFF includes at least one module, and the at least one module is configured to implement the method for fault protection of the service chain provided in the third aspect or any optional manner of the third aspect.

Optionally, the drainage SID is an End type SID; alternatively, the first and second electrodes may be,

and the drainage SID is the proxy SID corresponding to the third SF network element.

Optionally, the third SF network element is a backup SF network element of the second SF network element; or the like, or, alternatively,

the third SF network element is a next SF network element of the second SF network element in the service chain.

Specific details of the SFF provided in the seventh aspect may be found in the third aspect or any optional manner of the third aspect, and are not described herein again.

In an eighth aspect, an SFF is provided, where the SFF has a function of implementing fault protection for a service chain in the fourth aspect or any of the optional manners of the fourth aspect. The SFF includes at least one module, and the at least one module is configured to implement the method for fault protection of the service chain provided in the fourth aspect or any optional manner of the fourth aspect.

Specific details of the SFF provided by the eighth aspect may be found in any of the above-mentioned fourth aspect or the fourth aspect, and are not described herein again.

In a ninth aspect, an SFF is provided, where the SFF includes a processor, and the processor is configured to execute instructions, so that the SFF performs the method for fault protection of a service chain provided in the first aspect or any one of the options of the first aspect. Specific details of the SFF provided by the ninth aspect may be found in the first aspect or any alternative manner of the first aspect, and are not described herein again.

In a tenth aspect, an SFF is provided, where the SFF includes a processor, and the processor is configured to execute instructions, so that the SFF performs the method for protecting the fault of the service chain provided in the second aspect or any optional manner of the second aspect. Specific details of the SFF provided by the tenth aspect may be found in the second aspect or any alternative manner of the second aspect, and are not described herein again.

In an eleventh aspect, an SFF is provided, where the SFF includes a processor, and the processor is configured to execute instructions so that the SFF performs the method for protecting a fault of a service chain provided in any one of the third aspect and the third aspect. Specific details of the SFF provided by the eleventh aspect may be found in the third aspect or any alternative manner of the third aspect, and are not described herein again.

In a twelfth aspect, an SFF is provided, where the SFF includes a processor, and the processor is configured to execute instructions, so that the SFF performs the method for protecting the fault of the service chain provided in any one of the above-mentioned fourth aspect or the optional manner of the fourth aspect. Specific details of the SFF provided by the twelfth aspect may be found in any of the above-mentioned fourth aspect or the fourth aspect, and are not described herein again.

In a thirteenth aspect, a computer-readable storage medium is provided, where at least one instruction is stored in the storage medium, and the instruction is read by a processor to cause an SFF to execute the method for fault protection of a service chain provided in the first aspect or any one of the alternatives of the first aspect.

In a fourteenth aspect, a computer-readable storage medium is provided, where at least one instruction is stored in the storage medium, and the instruction is read by a processor to cause an SFF to execute the method for fault protection of a service chain provided in the second aspect or any optional manner of the second aspect.

In a fifteenth aspect, a computer-readable storage medium is provided, where at least one instruction is stored in the storage medium, and the instruction is read by a processor to cause an SFF to execute the method for fault protection of a service chain provided in the third aspect or any optional manner of the third aspect.

In a sixteenth aspect, a computer-readable storage medium is provided, where at least one instruction is stored in the storage medium, and the instruction is read by a processor to cause an SFF to execute the method for fault protection of a service chain provided in any one of the above-mentioned fourth aspect or the fourth aspect.

A seventeenth aspect provides a computer program product, which when running on an SFF, causes the SFF to perform the method for fault protection of a service chain as provided in the first aspect or any of the alternatives of the first aspect.

In an eighteenth aspect, a computer program product is provided, which, when running on an SFF, causes the SFF to execute the method for fault protection of a service chain as provided in the second aspect or any of the alternatives of the second aspect.

A nineteenth aspect provides a computer program product, which when running on an SFF, causes the SFF to execute the method for fault protection of a service chain provided in the third aspect or any one of the alternatives of the third aspect.

A twentieth aspect provides a computer program product, which, when run on an SFF, causes the SFF to perform the method for fault protection of a service chain as provided in the fourth aspect or any of the alternatives of the fourth aspect.

In a twenty-first aspect, a service chain fault protection system is provided, where the service chain fault protection system includes the SFF provided in any optional manner of the above fifth aspect or fifth aspect, and the service chain fault protection system further includes the SFF provided in any optional manner of the above sixth aspect or sixth aspect.

A twenty-second aspect provides a service chain fault protection system, where the service chain fault protection system includes the SFF provided in any optional manner of the seventh aspect or the seventh aspect, and the service chain fault protection system further includes the SFF provided in any optional manner of the eighth aspect or the eighth aspect.

Drawings

FIG. 1 is a system architecture diagram of an SFC provided by an embodiment of the present application;

fig. 2 is a schematic diagram of an SRv6 message according to an embodiment of the present disclosure;

fig. 3 is a schematic diagram of an SRH provided in an embodiment of the present application;

fig. 4 is a schematic diagram of an SRv6 SID provided in an embodiment of the present application;

FIG. 5 is a schematic diagram of an End SID according to an embodiment of the present application;

fig. 6 is a schematic diagram of a forwarding process based on an End SID according to an embodiment of the present application;

fig. 7 is a schematic diagram of an end.x SID provided in an embodiment of the present application;

fig. 8 is a schematic diagram of a forwarding process based on an end.x SID provided in an embodiment of the present application;

fig. 9 is a schematic diagram of a forwarding flow of an SRv6 service chain according to an embodiment of the present application;

fig. 10 is a schematic diagram of a fault scenario of a service chain according to an embodiment of the present application;

fig. 11 is a flowchart of a method for fault protection of a service chain according to an embodiment of the present application;

fig. 12 is a schematic diagram of forwarding a packet in a service chain under a scenario of a link failure between an SFF and an SF according to an embodiment of the present application;

fig. 13 is a schematic diagram of a SID of an SFF provided in an embodiment of the present application;

fig. 14 is a schematic diagram of a loop appearing in a double-link failure scenario in a service chain according to an embodiment of the present application;

fig. 15 is a schematic diagram of a SID of an SFF provided in an embodiment of the present application;

fig. 16 is a flowchart of a method for fault protection of a service chain according to an embodiment of the present application;

fig. 17 is a schematic diagram of forwarding a packet in a scenario of a double link failure in a service chain according to an embodiment of the present application;

fig. 18 is a schematic diagram of a SID of an SFF provided in an embodiment of the present application;

fig. 19 is a flowchart of a method for fault protection of a service chain according to an embodiment of the present application;

fig. 20 is a schematic diagram of forwarding a packet in an SF network element fault scenario in a service chain according to an embodiment of the present application;

fig. 21 is a schematic diagram of a SID of an SFF provided in an embodiment of the present application;

fig. 22 is a flowchart of a method for fault protection of a service chain according to an embodiment of the present application;

fig. 23 is a flowchart of a method for fault protection of a service chain according to an embodiment of the present application;

FIG. 24 is a schematic structural diagram of an SFF provided by an embodiment of the present application;

FIG. 25 is a schematic structural diagram of an SFF provided by an embodiment of the present application;

FIG. 26 is a schematic structural diagram of an SFF provided by an embodiment of the present application;

FIG. 27 is a schematic structural diagram of an SFF provided by an embodiment of the present application;

fig. 28 is a schematic structural diagram of a network device according to an embodiment of the present application;

fig. 29 is a schematic structural diagram of an interface board according to an embodiment of the present application;

fig. 30 is a schematic structural diagram of a computing device according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.

The terms "first," "second," and the like in this application are used for distinguishing between similar items and items that have substantially the same function or similar functionality, and it should be understood that "first," "second," and "nth" do not have any logical or temporal dependency or limitation on the number or order of execution. It will be further understood that, although the following description uses the terms first, second, etc. to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first image may be referred to as a second image, and similarly, a second image may be referred to as a first image, without departing from the scope of the various examples. Both the first image and the second image may be images, and in some cases, may be separate and distinct images.

The term "at least one" in this application means one or more, and the term "plurality" in this application means two or more, for example, the plurality of second messages means two or more second messages. The terms "system" and "network" are often used interchangeably herein.

It is to be understood that the terminology used in the description of the various examples herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise.

It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. The term "and/or" is an associative relationship that describes an associated object, meaning that three relationships may exist, e.g., A and/or B, may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, the character "/" in the present application generally indicates that the former and latter related objects are in an "or" relationship.

It should also be understood that, in the embodiments of the present application, the size of the serial number of each process does not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

It should be understood that determining B from a does not mean determining B from a alone, but may also be determined from a and/or other information.

It will be further understood that the terms "comprises," "comprising," "includes," and/or "including," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

It is also understood that the term "if" may be interpreted to mean "when" ("where" or "upon") or "in response to a determination" or "in response to a detection". Similarly, the phrase "if it is determined." or "if [ a stated condition or event ] is detected" may be interpreted to mean "upon determining.. or" in response to determining. "or" upon detecting [ a stated condition or event ] or "in response to detecting [ a stated condition or event ]" depending on the context.

It should be appreciated that reference throughout this specification to "one embodiment," "an embodiment," "one possible implementation" means that a particular feature, structure, or characteristic described in connection with the embodiment or implementation is included in at least one embodiment of the present application. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" or "one possible implementation" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

First, some technical terms related to the present application will be described.

Service chaining of traditional telecommunication networks: when the data message is transmitted in the network, the data message often needs to pass through various service nodes, so that the network can be ensured to provide safe, rapid and stable service for users according to the preset plan. These service nodes include but are not limited to Firewalls (FWs), Load Balancers (LBs), Intrusion Prevention Systems (IPS), etc., and network traffic needs to pass through these service nodes in a predetermined order required by the service logic to implement the required services. In a service chain of a traditional telecommunication network, the strategy drainage is realized by inputting a complex command line on hardware equipment, the operation, the maintenance and the change are difficult, and the deployment and the physical position of the VAS server are greatly restricted. The occurrence of service function chain (SFC, also called service chain for short) effectively solves the problem of service chain in traditional telecommunication network.

SFC is a technology that provides ordered services to the application layer. SFCs are used to logically join services on network devices to form an ordered set of services. The SFC adds the service chain path information in the original message to realize that the message passes through the service equipment in sequence according to the specified path. Under the traditional network architecture, the SFC technology utilizes the virtual network to better integrate service services, thereby well solving the problems: aiming at the problem that service deployment is not flexible due to large coupling among network devices, the SFC is independent of network planning based on an Overlay technology, deployment and activation of service nodes are not influenced when the topology of a bottom-layer physical network is changed, and virtual service chains can be mapped to the physical service nodes as long as the carrying network routing can be reached. Aiming at the problem of low forwarding efficiency, the SFC packages a Network Service Header (NSH) of a packet, so that each node on a Service chain path can mutually transmit information, and the whole Service chain with the information can perform dynamic and flexible policy processing on data. Aiming at the problem that service equipment cannot be shared, a forwarding layer and a service layer in the SFC are separated from each other, a user can divide the service equipment into resource pools, and all data traffic is classified and then is guided to a plurality of service equipment through a service chain, so that the performance requirement on the peak traffic processing capacity of the service equipment is reduced by the distributed data traffic, and the resource sharing of the service equipment is realized.

The network elements in the SFC are described below with reference to fig. 1:

stream Classifier (English: Service Classifier, abbreviated SC): and the message is positioned at the boundary inlet of the SFC domain, the flow classification is firstly carried out after the message enters the SFC domain, the classification granularity is determined by the classifier capability and the SFC strategy, and the classification rule can be rough or detailed. For example, in a rough case, all messages on one port satisfy a certain SFC rule, and a service chain path 1 is taken; in detail, only the packet satisfying the quintuple requirement can satisfy a certain SFC rule, and the service chain path 2 is taken.

Service function (English: service function, abbreviated as SF) network element: the method is used for carrying out service processing on the message. For example, the SF Network element may be, but is not limited to, a firewall, load balancing, an application accelerator, Legal Interception (LI), Network Address Translation (NAT), bandwidth control, virus detection, cloud storage, Deep Packet Inspection (DPI), intrusion detection, intrusion prevention, and the like. The physical entity of the SF network element may be a computing device which may be, without limitation, a server, a host, a personal computer, a network device, or a terminal device. In some possible embodiments, the SF network element may be implemented in such a way that: the general server of the X86 architecture runs a virtual machine or container, and an application program runs in the virtual machine or container, and the application program can be used for performing business function processing. The SFs are classified into an SF (NSH-aware SF) that senses NSH encapsulation and an SF (NSH-unbeware SF) that does not sense NSH encapsulation according to whether NSH encapsulation can be sensed. The NSH-aware SF can identify and process the received NSH message, and the NSH-unaware SF does not identify the NSH message and discards the NSH message after receiving the NSH message.

The Service function forwarding device (SFF) is configured to forward a message received from a network to a plurality of SFs associated with the SFF, where the forwarding is based on NSH encapsulated information. After SF processing, the message is returned to the same SFF, and the SFF finally determines whether to send the message back to the network. The physical entity of the SFF may be a network device, which may be, for example, a router, a switch, etc.

SFC Proxy (SFC Proxy): and the representing SF is positioned between the SFF and the associated NSH-unaware SFs, receives the message from the SFF, deletes NSH encapsulation information, sends the message to the NSH-unaware SF through a local logic component, also receives the message sent back from the NSH-unaware SF, adds NSH encapsulation information for the message again, and sends the message to the SFF for processing. From the SFF perspective, the SFC proxy behaves as an NSH-aware SF. Typically, the SFC Proxy and the SFF will be integrated on the same hardware device.

With the development of Segment Routing (SR) technology, an internet protocol version 6 (internet protocol version 6for Segment Routing, SRv 6for short) service chaining scheme becomes an excellent scheme for implementing service chaining. For ease of understanding, before introducing SRV6 service chain techniques, SRv6 techniques are first introduced:

segment Routing (SR) is a technology designed based on the concept of source Routing to forward packets in a network. Segment Routing divides the network path into segments and assigns Segment Identifications (SID) to the segments and forwarding nodes in the network. By arranging the SIDs in order, a Segment List (Segment List) can be obtained, and the Segment List can indicate the forwarding path of the packet. Through the SR technology, the nodes and paths through which the messages carrying the Segment List pass can be specified, so that the requirement of flow optimization is met. By way of an analogy, the message may be compared to luggage, the SR may be compared to labels attached to luggage, and if luggage is to be sent from area a to area D, on the way to area B and area C, the luggage may be attached with a label "first to area B, then to area C, and finally to area D" at originating area a, so that each area only needs to identify the label on the luggage and forward the luggage from one area to another according to the label of the luggage. In the SR technique, a source node adds a label to a packet, and an intermediate node can forward the packet to a next node according to the label until the packet reaches a destination node. For example, if < SID1, SID2, SID3> is inserted into the packet header of the packet, the packet is first forwarded to the node corresponding to SID1, then forwarded to the node corresponding to SID2, and then forwarded to the node corresponding to SID 3.

SR Domain (Segment Routing Domain): a set of SR nodes. The SR domain may be nodes connected to the same physical fabric (e.g., a service provider network) or remotely interconnected nodes (e.g., an enterprise virtual private network or overlay).

The SR Tunnel (SR Tunnel) is a Tunnel that encapsulates the Segment List in the header on the head node, and may be created manually by an administrator, or may be created automatically by an interface Protocol such as network configuration (NETCONF) or Path computing Element Communication Protocol (PCEP) that the controller passes through. One SR tunnel may be used for Traffic Engineering (TE) application, Operation and Maintenance (OAM) and Fast Reroute (FRR).

Segment List (Segment List): an ordered Segment list representing the packet forwarding path. In SR MPLS, the segment list is a label stack. In SRv6, the segment list is an IPv6 address list and is carried in a Segment Routing Header (SRH) of the IPv6 message.

A Segment (also called a Segment) may be any instruction that directs a device to process a packet, such as: forwarding the message to the destination according to the shortest path, forwarding the message through a specified interface, forwarding the message to a specified application/service instance, and the like. The segments may include Global segments (Global segments) and Local segments (Local segments).

Global segment: all SR nodes within an SR domain are able to identify global segment-related instructions. In SR MPLS, a global segment is a globally unique index (index), and the label on each device is [ SRGB + index ]; at SRv6, the global segment is a globally unique IPv6 address.

In this section: only the relevant instructions identified by the node that generated it. In SR MPLS, the local segment is a local label outside an SRGB block; at SRv6, the local segment is any IPv6 address for which reachability has not been advertised by any routing protocol.

Segment Identification (SID) is the identification of Segment, which is used to identify a unique Segment. In the forwarding plane of SR MPLS, the SID may be mapped to an MPLS label. At the forwarding plane of SRv6, SIDs may be mapped to IPv6 addresses. The SID can essentially represent a topology, an instruction, or a service.

SID of current job: the segment to be currently processed in the segment list may also be referred to as active SID (active SID), active segment (active segment), currently pending SID, and currently working SID. When the SR node receives the message, the active segment is processed. In SR MPLS, the active segment is the outermost label of the label stack. At SRv6, the active segment is the destination address of the IPv6 packet carrying the SRH. In addition, the active segment may be indicated by the value of the SL field. For example, if the segment list includes 5 SIDs, i.e., SID0, SID1, SID2, SID3 and SID4, and SL takes a value of 2, it indicates that there are 2 unprocessed SIDs in the segment list, i.e., SID0 and SID1, the SID to be currently processed in the segment list is SID2, and the SID to be processed in the segment list is 2 SID3 and SID 4.

The SID may include multiple types. In SR MPLS, the SID may include a node SID (node SID), a prefix SID (prefix SID), and an adjacent SID (adjacency SID). The Prefix SID may be an offset value in the SRGB range issued by the source end, and the receiving end may calculate an actual label value according to its own SRGB to generate an MPLS forwarding entry. In SRv6, the SIDs include End SID, end.X SID, end.DT4 SID, end.OTP SID, and so on types.

Segment operations (Segment Actions): may include insert (PUSH), NEXT (NEXT), CONTINUE (CONTINUE), etc. PUSH refers to the insertion of a Segment at the top of a Segment List. The top of Segment List in SR MPLS refers to the outermost label of the label stack. The top of the Segment List in SRv6 refers to the first IPv6 address in the SRH header. NEXT means that when the current active segment (active segment) is processed, the NEXT segment (the NEXT segment) is changed to the active segment. CONTINUE: the active segment is not processed yet, and the active state is kept. In SR MPLS, the CONTINUE operation is equivalent to a SWAP (SWAP) operation. At SRv6, the CONTINUE operation is an operation of forwarding the IPv6 message according to the IPv6 destination address.

SR technologies include Multi-Protocol Label Switching Segment Routing (SR MPLS) technology and SRv6 technology. The SRv6 technique will be specifically described below.

The SRv6 technology refers to the application of SR technology in IPv6 networks. SRv6 is encoded using IPv6 addresses (128bits) and encapsulated in SRv6 extended headers (SRH). When a message is forwarded, a node supporting SRv6 queries a local SID table (local SID table) according to a Destination Address (DA) of a message header in the message, and when the Destination Address of the message header of the message is matched with any SID in the local SID table, determines that the Destination Address hits the local SID table, and executes corresponding operations based on a topology, an instruction or service corresponding to the SID; and if the destination address of the message is not matched with each SID in the local SID table, inquiring a routing forwarding table of the IPv6 according to the destination address, and forwarding the message according to the routing forwarding table hit by the destination address in the routing forwarding table.

A local SID table (also called local SID table) is a table maintained by SRv 6-enabled nodes. The local SID table contains SRv6 SIDs generated by this node. A forwarding table FIB may be generated SRv6 from the local SID table. The function of the local SID list is mainly three. First, a locally generated SID, such as an end.x SID, is defined. Second, instructions bound to these SIDs are specified. Third, forwarding information associated with the instructions, such as outgoing interfaces and next hops, is stored. In some embodiments, after entering the command display segment-routing ipv6 local-SID, the local SID table of SRv6 configured on the device can be viewed. Wherein the command may carry a parameter End to specify viewing SRv6 End's local SID table. The command may carry a parameter end.x to specify viewing SRv6 the local SID table for end.x. The command may carry the parameter end-dt4 to specify viewing the local SID table SRv6 end-dt 4.

SRv6 adds an SRH to IPv6 message, uses the SRH to record Segment related information, and smoothly fuses with the original IPv6 forwarding plane by adding the extension header. Referring to fig. 2, fig. 2 is a schematic diagram of an SRv6 message according to an embodiment of the present disclosure. SRv6 messages may include an IPv6 header, SRH, and payload. Each part of the SRv6 message is described below by (1) to (3):

(1) SRv6 message IPv6 header.

The IPv6 header in the SRv6 message may include a Source Address (SA) and a Destination Address (DA). In the ordinary IPv6 message, IPv6DA is fixed and unchangeable. At SRv6, at SRv6, IPv6DA identifies the next node of the current packet, and in the SR tunnel, the SR node may continuously update the destination address to complete hop-by-hop forwarding. The SID carried by the destination address in the IPv6 header may be referred to as an active SID.

(2) SRv6 in the message SRH.

SRH is an IPv6 extension header. SRH is used for IPv 6-based forwarding plane implementation SRv 6. Referring to fig. 3, fig. 3 is a schematic diagram of an SRH provided in an embodiment of the present application. SRH may include the following:

(2.1) segment List

The segment list may include one or more SIDs, each of which may be in the form of an IPv6 address, and thus the segment list may also be understood as an explicit IPv6 address stack. The segment list may be abstracted into the following format:

SRH(SL＝n)

<Segment List[0],Segment List[1],Segment List[2],...,Segment List[n]>：

wherein < Segment List [0], Segment List [1], Segment List [2],. and Segment List [ n ] > are Segment lists of Rv6 messages, and are generated at the ingress node similarly to MPLS label stack information in SR MPLS. Segment List [0] is the first Segment List on the SRv6 path to be processed, Segment List [1] is the second, Segment List [2] is the third. Wherein n is a positive integer or 0.

It should be noted that, when the SRH in the IPv6 message is expressed, the SRH can be expressed in a reverse order form, that is, in the form of (Segment List [2], Segment List [1], Segment List [0 ]).

At SRv6, every time when passing through a SRv6 node, the value of SL field is reduced by 1, and IPv6DA information is transformed once. The SL field and the Segments List field together determine IPv6DA information.

If the SL value is n (n-0), the value of IPv6DA is the value of Segments List [0 ].

If the SL value is n-1, the value of IPv6DA is the value of Segments List [1 ].

If the SL value is n-2, the value of IPv6DA is the value of Segments List [2 ].

By analogy, if the SL value is 0(n-n ═ 0), the IPv6DA value is the value of Segments List [ n ].

(2.2)SL。

The SL may indicate the active SID in the segment list. In the SR tunnel, the SR node updates the active SID by performing an operation that offsets the address stack. A field for indicating the number of segmented end nodes (SL) that the node should access up to now, which may also be referred to as a remaining nodes field. For example, if the segment list includes 5 SIDs, i.e., SID0, SID1, SID2, SID3 and SID4, and SL takes a value of 2, it indicates that there are 2 unprocessed SIDs in the segment list, i.e., SID0 and SID1, the SID to be currently processed in the segment list is SID2, and the SID to be processed in the segment list is 2 SID3 and SID 4.

(2.3) one or more TLVs

TLV is an encoding format and includes a type (type), a length (length), and a value (value). One or more TLVs may be included in the SRH. Different TLVs in SRH may have a parallel relationship or a nested relationship.

Further, as shown in fig. 3, the SRH may further include the following fields:

(2.4) next header type (next header): SRv6 the message may also include one or more extension headers or one or more higher layer headers after the extension header, and the next header is used to indicate the type of extension header or higher layer header following the extension header in the message. The next header may be 1 byte in length.

(2.5) the Length of the extension header (English: header Extended Length, abbreviated as Hdr Ext Len): for indicating the length of the extension header. The length indicated by Hdr Ext Len may not include the first 8 bytes of the extension header.

And (2.6) a field for indicating a Routing Type (Routing Type).

(2.7) a field for indicating an index of the Last element (Last Entry).

(2.8) a field for indicating some identification (Flags) of the packet.

(2.9) a field for indicating a same group packet (Tag).

(3) SRv6 messages.

The payload in the SRv6 message may be the original message. The original message may be an IPv4 message, an IPv6 message, or an Ethernet (english: Ethernet) frame.

The structure of SRv6 message is described above, and SRv6 SID is described below.

The SRv6 SID may include 128 bits. The SRv6 SID may be in 16-ary data form. The format of SRv6 SID may be X: X: X: X: X: X: X. Referring to fig. 4, fig. 4 is a schematic diagram of an SRv6 SID according to an embodiment of the present disclosure. The SID may include location information (locator) and function information (function), and the format of the SID is locator: and (4) performing function. Optionally, the SID may also include parameter information (definitions), and the format of the SID is locator: function: definitions.

The locator occupies the high order bits of the SID. The locator field corresponds to the ipv6-prefix ipv6-address parameter, and the length is determined by the prefix-length parameter. The locator itself is an IPv6 network segment, and all IPv6 addresses under the network segment can be allocated as SRv6 SIDs. After the node is configured with the locator, the system generates a locator network segment route, the node can be positioned through the locator network segment route, and all SIDs issued by the node can also reach through the locator network segment route. SRv6 can be issued through SRv6 locator TLV, other SRv 6-capable IS-IS devices issue corresponding locators to the local forwarding table after receiving the TLV, and no SRv 6-capable IS-IS devices issue no corresponding locators to the forwarding table.

The function occupies the low bits of the SID. The function field is also called an operation Code (opcode), and may be dynamically allocated by the IGP protocol or statically configured by an opcode command. SRv6 can define the action corresponding to each Segment by function.

Argments is optional in SRv6 SIDs, depending on command configuration.

SRv6, after the SID is generated, it will be added into local SID table on one hand, and can be released outside through routing protocol on the other hand. In actual forwarding, the locator part in the SRv6 SID is used to help other nodes in the network to perform routing addressing, find the generating node of SRv6 SID, and forward the SRv6 message to the node, and the function part is used to instruct the generating node of SRv6 SID to perform corresponding functional operations.

SRv6 SIDs were introduced above. The SRv6 SID may include an End SID, an end.X SID, an end.DT4 SID, an end.OTP SID, and the like. The following describes a SRv6 SID-based forwarding procedure with specific types of SRv6 SIDs:

end in End SID represents endpoint. The End SID is an Endpoint SID, and is used to identify a certain destination address Prefix (Prefix) in the network. The End SID in SRv6 is similar to the Prefix SID in SR MPLS. The SRv6End SID may be issued via SRv6End SID sub-TLV. SRv6End SIDs may be flooded to other network elements based on IGP protocols. SRv6End SID sub-TLV is a seed TLV for issuing SRv6End SIDs with Endpoint functionality. For example, please refer to fig. 5, fig. 5 is a schematic diagram of an End SID provided in the present application. The End SID of node A may be A: : . The End SID of the node B may be B: : . The End SID of node C may be C: :

the End SID-based forwarding operation may include the steps of:

step one, an SR node receives a message.

And step two, the SR node inquires a local SID table according to a destination address in an IPv6 header of the message.

And step three, the SR node judges the type (FuncType) of the active SID to be an End type according to a local SID table.

Step four, the SR node continuously queries the IPv6FIB table.

And step five, forwarding the message according to the exit interface and the next hop inquired in the IPv6 routing forwarding table.

For example, referring to table 1 below, table 1 is an illustration of a local SID table. If the IPv6DA of the message is 10:1::1:0/128, when the SR node receives the SRv6 message, the table 1 is inquired according to the IPv6DA of the SRv6 message, the FuncType of the 10:1::1:0/128 is judged to be End, the routing forwarding table of the IPv6 is continuously inquired according to the 10:1: 0/128, and the message is forwarded according to the outgoing interface and the next hop hit by the routing forwarding table of the IPv6 of the 10:1: 0/128.

TABLE 1

Wherein, the header My Local-SID End Forwarding Table of Table 1 represents the Local SID Table of SRv6 End. FuncType denotes the function type. The flag represents a property, such as a Penultimate Segment POP (PSP) of the SRH. locator ID denotes an identifier (Identity, ID) assigned to the locator

Referring to fig. 6, fig. 6 is a schematic diagram of a forwarding process based on an End SID provided in an embodiment of the present application, where the forwarding process includes: the message is pushed into the SRH at the node A, the path information in the SRH is < Z:, F:, D:, B: >, and the destination address in the IPv6 header of the message is B:. When a message passes through an intermediate node, such as a node B and a node D, the intermediate node queries a local SID table according to the IPv6DA of the message, and if the intermediate node judges that the message is of an End type, the intermediate node continues to query an IPv6FIB table, forwards the message according to the next hop of an outgoing interface searched by the IPv6FIB table, and simultaneously subtracts 1 from SL and transforms the IPv6DA once. When the message reaches the node F, the node F inquires a local SID table according to the destination address of the IPv6 header in the message, judges the type is an End type, then continuously inquires an IPv6FIB table, and forwards the message according to the outlet interface inquired by the IPv6FIB table. And meanwhile, SL is reduced to 0, IPv6DA is changed into Z, and at the moment, the path information is < Z:, F:, D:, B: > has no practical value, so the node F removes SRH by utilizing the PSP characteristic and then forwards the message with the SRH removed to the node Z.

The End SID and the process of forwarding the packet in the SR tunnel based on the End SID are introduced above. The end.x SID and the forwarding procedure based on the end.x SID are described below.

X in end.x SID represents cross. The end.x SID represents a three-tier cross-connected Endpoint SID. Each end.X SID of the SR node is used for identifying an IP layer link directly connected with the SR node. The end.x SID in SRv6 is similar to the Adjacency SID in SR MPLS. The SRv6 end.x SID may be flooded to other network elements based on IGP protocols. For example, please refer to fig. 7, fig. 7 is a schematic diagram of an end.x SID provided in the present application. The End SID of node A may be A: : . Further, node a includes 3 end.x SIDs. The end.x SID corresponding to the link 1 directly connected to the node a is a: :1, the end.X SID corresponding to the link 2 directly connected to the node A is A: : 2, the end.x SID corresponding to the link 3 directly connected to the node a is a: : 3.

the End X SID based forwarding operation may include the steps of:

step one, an SR node receives a message.

And step three, the SR node judges the active SID to be an end.X SID according to a local SID table.

And step four, the SR node directly forwards the message according to the next hop and the output interface bound by the End X SID in the local SID table.

For example, see table 2 below, table 2 is an illustration of a local SID table. If the IPv6DA of the SRv6 message is 222: 4:101:0:1/128, when the SR node receives the SRv6 message, the Table 2 is inquired according to the IPv6DA, the judgment is made that the FuncType of 222: 4:101:0:1/128 is end.X, the fact that the output interface of 222: 4:101:0:1/128 hit in the Table 2 is GE2/0/0, the fact that the next hop of 222: 4:101:0:1/128 hit in the Table 2 is FE80: 3A00:10FF: FE03:1 is determined, and the SR node forwards the message according to GE2/0/0 and FE80: 3A00:10FF: FE03: 1.

TABLE 2

Wherein, the header My Local-SID end.X Forwarding Table of Table 2 represents SRv6 end.X Local SID Table. FuncType denotes the function type. The flag represents a property, such as a Penultimate Segment POP (PSP) of the SRH. NextHop denotes the next hop address. An Interface represents an Interface. The Exit Index indicates the interface Index.

Referring to fig. 8, fig. 8 is a schematic diagram of a forwarding process based on an end.x SID provided in an embodiment of the present application, where the forwarding process includes: the message is pressed into an SRH at a head node A, the path information in the SRH is < Z:: 1, F::1, B::1>, and the destination address in the IPv6 head of the message is B:: 1. When the message reaches the intermediate node B, the intermediate node B inquires a local SID table according to IPv6DA, judges that the message is of an end.X type, forwards the message according to a next hop and an outgoing interface corresponding to the end.X SID in the local SID table, and simultaneously reduces SL by 1 and converts IPv6DA into F:: 1. When the message reaches the node D, the node D queries a local SID table according to IPv6DA information F::1, if the matched SID cannot be queried, the node D continues to use F::1 to query a matched IPv6FIB table, and then forwards the message to F according to the forwarding information of the IPv6FIB table. When the terminal node F is reached, the terminal node F inquires a local SID table according to IPv6DA and judges that the terminal node is of an end.X type, so the terminal node F directly forwards the terminal node according to a next hop and an outgoing interface corresponding to the end.X SID in the local SID table, meanwhile SL is reduced to 0, IPv6DA is converted into Z, at the moment, SRH carrying path information (Z:, F::1, B:: 1) has no actual value, therefore, the terminal node F removes the SRH by using PSP characteristics, then forwards the SRH-removed message to the Z node, and at the moment, the message flows out of an SR tunnel.

In the SRv6 technique, two or more SR nodes may form an anycast group by issuing an anycast SID. Anycast and anycast SIDs are described below.

Anycast (Anycast), also called Anycast, flooding or Anycast, is a communication method of IPv6, and refers to identifying a group of nodes providing the same or corresponding services by the same address.

The anycast SID is used to identify a group of SR nodes. The SR nodes issue anycast SIDs, and the anycast SIDs issued by each SR node are the same. These SR nodes may be referred to as an Anycast Group (Anycast Group). The same locator may be configured on each device of the same anycast group to ensure that when one of the nodes fails, Fast Re-Route (FRR) mode can be used to quickly switch to another node. When forwarding is carried out according to the anycast SID, the shortest path can be selected from paths reaching each SR node in the anycast group, and forwarding is carried out according to the shortest path.

The SRv6 technique is introduced above, and the SRV6 service chain technique is introduced below:

the SRV6 service chain may use the tuning capability of the SRV6 and the SDN global network management capability to globally schedule SRV6 SID paths through a controller, and the following, please refer to fig. 9, to supplement the description of the functions of each network element in the SRV6 service chain:

the SC may be a head node of an SRv6 tunnel, and the SC is configured to complete packet encapsulation according to an SR label stack issued by the controller. The original message may be pushed at the SC to the SRH, where the segment list indicates the forwarding path of the message in the service chain. The controller may be a management node in Network Function Virtualization (NFV), such as a Network function Virtualization Manager (VNFM). The controller may be an SDN controller (SDN controller) in a Software Defined Network (SDN). The SR label stack may be a segment list.

For SF network elements that do not support SR, the sff (proxy) accessing the SF network element may handle SRH for its proxy.

Specifically, after receiving SRv6 the SFF may obtain an output interface and a corresponding behavior (behavior) according to the SID in the label stack, and if it is determined that the behavior pops up the label stack, strip the SRH of the message, for example, perform a pop (pop) operation in the SR, pop the SRH out of the message, and send the message not including the SRH to the SF; in addition, the SFF may store the cache information of the service chain, and when the SF message returns, complete SR message encapsulation of the service chain again. After the SF network element returns a message to the Proxy, the Proxy can query an SRH from a cache (cache) according to an input interface, and use the SRH to complete SR encapsulation of the message.

SF network element: and performing service processing based on the original message to obtain a processed message. The SF network element may query the route and forward the packet to the Proxy. Or, the SF network element may send the message to the Proxy through a default egress interface. In addition, if the SF network element is dually accessed to two proxy, load sharing can be formed based on IGP routing.

SRV6 static service chain: the method refers to a mode that the SFF obtains the cache list through static configuration.

SRV6 dynamic service chain: the method refers to a mode that the SFF dynamically learns the cache list according to the flow.

In the future, how to perform fault protection in a service chain has become a key of a service chain technology.

Referring to fig. 10, the fault scenario of the service chain may specifically include multiple types:

scenario 1, SFF failure

For example, referring to (r) in fig. 10, SFF1 may fail.

Scenario 2, failure of the link between the SFF and SF network elements

For example, referring to ② in fig. 10, a link from SFF1 to SF1 may fail.

Scenario 3, VM failure

For example, referring to (c) of fig. 10, the VM1 where SF1 is located may fail.

Scenario 4, SF network element failure

For example, SF1 may fail, see (r) in fig. 10.

In the above scenario, the present embodiment provides a fault protection scheme in an SRV6 service chain scenario, and may perform effective protection in multiple fault scenarios.

Specifically, the embodiment of the present application defines many new SIDs, including but not limited to a subordinate SID, a backup SID, a drainage SID, and the like, and the new SIDs can be used to implement normal forwarding of traffic in a service chain failure scenario. In the following method embodiments, the dependent SID is referred to as secondary SID, the backup SID is referred to as backup SID, and the drainage SID is referred to as bypass SID. In addition, the proxy SID is referred to as proxy SID.

It should be understood that the naming of these SIDs is merely an example, and that these SIDs may have other designations as well. For example, the SIDs may have different names in different scenarios, such as different names for different vendors or different names for different standards, and the name of the SID is not intended to limit the scope of the present application.

In addition, the SID provided by the embodiment of the present application may be configured on multiple nodes. The functions of the SIDs configured on different nodes may be the same, and the functions of the SIDs configured on different nodes may also be different. In some possible embodiments, the same SID may be configured at different nodes having an anycast relationship in the traffic chain, so as to perform load sharing. For the purpose of description differentiation, words such as "first", "second", etc. are used to differentiate the SIDs configured on different nodes. For example, the secondary SID configured on the first SFF is referred to as a first secondary SID, and the secondary SID configured on the second SFF is referred to as a second secondary SID. It should be understood that the words "first", "second", etc. do not have a logical or temporal dependency, nor do they define the number of SIDs and the order in which the SIDs are operated. For example, for two SIDs, called the first SID and the second SID, respectively, the first SID is not necessarily a first-active SID, and the second SID is not necessarily a second-active SID. The working order of the first SID and the second SID can be determined according to the arrangement order of the section list of the 2 SIDs in SRH.

In addition, the SID provided in the embodiment of the present application is a SID used for identifying a segment in an SR technology. For example, the SID provided in this embodiment of the present application may be, but is not limited to, SRv6 SID, and the format of the SID provided in this embodiment of the present application may be as shown in fig. 4. It is to be understood that the SID described in the following embodiments may implement the functionality provided by the SID described above.

In addition, the message carrying the SID provided in the embodiment of the present application may be an SR message transmitted in an SR network. For example, the message provided by the embodiment of the present application may be, but is not limited to, the SRv6 message. Schematically, the format of the message provided in the embodiment of the present application may be as shown in fig. 2. It should be understood that the messages described in the following embodiments may implement the functions of the SRv6 message described above.

In addition, the SID provided by the embodiment of the present application may be carried in the destination address and SRH of the IPv6 header of the packet. Illustratively, the format of the SRH in the message provided by the embodiment of the present application may be as shown in fig. 3. Details of IPv6 header, SRH, can be found in the above description.

In addition, the message carrying the SID provided in the embodiment of the present application may be an SR message transmitted in an SR network. For example, the message provided by the embodiment of the present application may be, but is not limited to, the SRv6 message. For example, the format of the message provided in the embodiment of the present application may be as shown in fig. 2, and the details of the message may be as described above with reference to SRv6 message. The message provided by the embodiment of the present application may include an IPv6 header, an SRH, and a payload, and the SID is carried by the destination address of the IPv6 header and the SRH. The format of SRH may be as shown in fig. 3. Details of IPv6 header, SRH, can be found in the above description.

In addition, the basic principle of the method for forwarding a packet through an SID may refer to fig. 6, fig. 8 and the related description above. In the following method embodiments, the differences from the above description will be focused, and the steps similar to the above description are also referred to fig. 6 and fig. 8 and the related descriptions above, and for brevity of description, no further description will be given in the following method embodiments.

In addition, each node (e.g., SFF, SF network element, SC, etc.) related to the embodiment of the present application may be a node in a service chain (SFC), and the function and physical entity of each node may refer to the above related descriptions, and for brevity of description, details will not be described in the following method embodiments.

The embodiment of the application can be applied to fault protection scenes of various service chains, including but not limited to: and protection is carried out under a link fault scene between the SFF and the SF network element, and protection is carried out under a double-link fault scene to prevent a loop and an SF network element from being in fault.

First, an embodiment of a method for protecting in a scenario of a link failure between an SFF and an SF network element is described below. In this embodiment of the method, a description is given by taking an example that a link between a first SFF and a first SF network element fails.

Referring to fig. 11, the method may include the steps of:

step 1101, a first SFF in a service chain receives a first message, and a destination address field of a message header of the first message includes a proxy SID corresponding to a first SF network element in the service chain.

The first SFF may be one of the service chains for which SRv6 is enabled. For example, please refer to fig. 12, where fig. 12 is a schematic diagram of forwarding a packet in a scenario of a link failure between an SFF and an SF in a service chain according to an embodiment of the present application, and a first SFF may be the SFF1 in fig. 12.

The first SF network element is an SF network element accessed by a first SFF in a service chain. For example, referring to fig. 12, the first SF network element may be the SF1 accessed by the SFF1 in fig. 12.

The first message may include an IPv6 header, an SRH, and a payload. The payload in the first message may be an original message to be processed by the SF network element. The IPv6 header in the first message includes a DA field, and a value of the DA field is a proxy SID corresponding to the first SF network element. The SRH in the first message includes a segment list and a SL. The segment list includes proxy SID corresponding to the first SF network element and other SIDs. The value of SL may indicate that the currently operating SID in the segment list is the proxy SID corresponding to the first SF network element.

proxy SID is a kind of SID of proxy function. And the proxy SID corresponding to the first SF network element is used for indicating proxy operation for the first SF network element. The proxy SID is SRv6 SID, and may be end.X SID.

The proxy SID included in the destination address field of the first packet may be the SID of the first SFF. The proxy SID may be configured on the first SFF in advance. The proxy SID may be pre-stored in a local SID table of the first SFF. The first SFF may pre-issue the proxy SID. Wherein, the locator of the proxy SID is the locator configured on the first SFF. The locator of proxy SID is used to locate the first SFF. The function of the proxy SID is used to instruct proxy operation for the first SF network element. In the local SID list on the first SFF, the next hop bound by the proxy SID may be the first SF network element, and the egress interface bound by the proxy SID may be used to establish a link with the first SF network element.

In addition, in some embodiments, the SF may have dual access to the first SFF and the second SFF, and the proxy SID is also included in the local SID table of the second SFF, so as to form load sharing based on the anycast relationship.

For example, referring to fig. 12 and 13, sid2 is preconfigured on SFF1, and sid2 is preconfigured on SFF 2. The SID2 on SFF1 is proxy SID corresponding to SF1, and the SID2 on SFF2 is also proxy SID corresponding to SF 1. SID2 of SFF1 and SID2 of SFF2 form an anycast SID relationship.

The first message may come from the SC. The SC may be a head node of the SR tunnel. The SC may push the SRH to the original message, obtain the first message carrying the SRH, and send the first message. The first packet may be forwarded to the first SFF through the locator of the proxy SID, and then the first SFF may receive the first packet. For example, referring to fig. 12, traffic enters from the SC, the SC sends a message, the message is directed to SFF1 according to SF1 proxy SID, and SFF1 receives the message. The destination address field of the message received by the ingress interface of SFF1 includes SF1 proxy SID.

Step 1102, if a link between the first SFF and the first SF network element fails, the first SFF updates a destination address field of the first message to obtain a second message, where the destination address field of the second message includes a first secondary SID.

The second message is obtained after the first SFF processes the first message according to the first secondary SID. The second message may include an IPv6 header, an SRH, and a payload. The IPv6 header in the second message includes a DA field whose value is the first secondary SID. The SRH in the second message includes a segment list and a SL. The segment list includes the first secondary SID and other SIDs. Optionally, the segment list may include a proxy SID corresponding to the first SF network element. The value of SL may indicate that the currently operating SID in the segment list is the first secondary SID. The payload in the second message may be an original message to be processed by the SF network element. The second message may include the payload of the first message, e.g., the payload in the second message may be the same as the payload in the first message.

The secondary SID and the proxy SID may form a protection relationship of the primary backup and the backup. Specifically, if the currently working SID is a proxy SID and an outgoing interface corresponding to the proxy SID has a link failure, the SFF may insert a secondary SID into the packet, and update the destination address of the packet from the proxy SID to the secondary SID, so as to switch the packet from the tunnel corresponding to the proxy SID to the tunnel corresponding to the secondary SID, thereby achieving the purpose of directing the packet to other SFFs in the same pair of protection groups. Furthermore, in some embodiments, it may be planned that the locator of the secondary SID and the locator of the proxy SID do not repeat.

The first secondary SID may be a secondary SID configured on the first SFF. The first secondary SID may be a SID local to the second SFF. The first secondary SID may be pre-stored in a local SID table of the second SFF. The locator of the first secondary SID is used for routing to the second SFF. The locator of the first secondary SID may be a locator previously issued by the second SFF.

For example, referring to fig. 12 and 13, SFF1 includes SFF2 secondary SID. The SFF2 secondary SID is a local SID of the SFF2, and the locator of the SFF2 secondary SID can be located to the SFF 2. By configuring SFF2 secondary SID on SFF1, when SFF1 fails to go to a link of SF1, SFF1 inserts SFF2 secondary SID into a message, refreshes a destination address field of a message header, and leads the message to SFF2 through a locator route corresponding to SFF2 secondary SID. Thus, SFF1 switches traffic to the secondary SID tunnel.

The first SFF can update the destination address field of the header from the proxy SID to the first secondary SID by executing the operation of updating the destination address field, so that the currently-operating SID in the second message is the first secondary SID, and when the second SFF receives the second message, the second SFF queries the local SID table by using the destination address, and then executes the operation corresponding to the first secondary SID. It should be appreciated that the first message may be in a form similar to an IP in IP (mobile IP data encapsulation and tunneling) message, including an outer IPv6 header and an inner original message. The update destination address field referred to herein may refer to the destination address field of the IPv6 header at the outer layer of the update, rather than the destination address field of the original message at the inner layer of the update. For example, if the original packet itself is an IPv6 packet, the outer layer of the first packet is an IPv6 header, and the inner layer is an IPv6 packet, in this step, the first SFF may update the DA field in the outer IPv6 header.

In some embodiments, the type of the first second SID may be an endpoint (End) type. For example, in the local SID table of the second SFF, the value of Func Type of the first secondary SID may be End.

By selecting the SID of the End type as the first secondary SID, compared with the mode of selecting the SID of the end.x type as the first secondary SID, the operation of designating a next hop and an egress interface when configuring the end.x SID can be avoided, so that the situation that a large number of secondary SIDs are to be configured on the first SFF instead of globally unique secondary SIDs due to the fact that the end.x SID has functions of both a drainage function and an egress interface designation function instead of the original proxy SID is avoided. In addition, the first secondary SID is an End type SID, so that the subsequent planning of the backup SID is prevented from causing large constraint.

The second SFF is other SFFs except the first SFF in the protection group. The protection group includes a plurality of SFFs accessed by the first SF network element. For example, 2 SFF nodes may be included in the protection group, and the 2 SFF nodes are two nodes of SF dual-homed access. Alternatively, the protection group may include 3 or more SFF nodes, which are nodes for SF multi-homing access. For example, referring to fig. 12, SF1 is dually accessed to SFF1 and SFF2, and if the first SFF is SFF1, the second SFF may be SFF 2.

The protection groups may be implemented based on redundant protection techniques. In some embodiments, the protected group is an anycast group, and proxy SIDs issued by different SFFs in the anycast group are anycast SIDs. On the SF side, the SFFs in the protection group may assume the role of an equivalent gateway, and on the network side, the SFFs in the protection group may issue the same proxy SID. Each SFF in a protection group may be understood as an equivalent node for load sharing. In physical topology, direct links, where IP routes are reachable, may be provided between different SFFs in the same protection group as bypass protection. The second SFF may be a bypass SFF of the first SFF. For example, referring to fig. 12, if the first SFF is SFF1, and SFF1 and SFF2 form an Anycast relationship through the Anycast SID, the second SFF is SFF2, and the first secondary SID is the End SID local to SFF 2. Direct links between SFF1 and SFF2 may be reachable by IP routing, and SFF2 is a bypass SFF of SFF 1.

In some embodiments, secondary SIDs may be configured on each SFF belonging to the same protection group. The function of the second SID configured on each SFF may be the same. For the same pair of SFFs, the secondary SID configured on one SFF is an End type SID local to the other SFF. For example, referring to fig. 12, SFF1 and SFF2 form a pair of protection groups, and SFF fault protection is implemented by anycast SID. The secondary SID configured by SFF1 is an End type SID local to SFF 2. The locator of the secondary SID configured on SFF1 is used for routing to SFF 2. Similarly, the locator of the secondary SID configured on SFF2 is used for routing to SFF1, and the secondary SID configured on SFF2 is a local End SID on SFF 1. The function of the secondary SID configured by SFF1 and the secondary SID configured by SFF2 is the same, and therefore, the action performed by SFF1 according to the local secondary SID and the action performed by SFF2 according to the local secondary SID belong to symmetric actions.

In addition, the first SFF may insert the first secondary SID into the SRH of the first packet, and update the SL in the SRH of the first packet, so that the SL points to the first secondary SID, thereby indicating that the first secondary SID is the currently-operating SID in the SRH. By performing the step of updating the SL, the SL of the second message generated by the first SFF may be larger than the SL of the received first message. In SRv6, SL in SRH of SRv6 message is usually used to identify the number of SID to be processed, so that by modifying the value of SL, it can be indicated that the SRH of the second message sent by the first SFF contains more SID to be processed than the first message received by the first SFF, and the first SFF performs the action of inserting SID into SRH.

Step 1103, the first SFF sends the second message.

Since the destination address field of the header of the second packet includes the first secondary SID, and the locator route of the first secondary SID is the locator route of the second SFF, the second packet is routed to the second SFF through the first secondary SID after being sent from the first SFF. For example, referring to the bold black line on the lower side of the SFF1 block diagram in fig. 12, after SFF1 inserts SFF2 secondary SID into traffic, the traffic is routed to SFF2 through SFF2 secondary SID.

Step 1104, a second SFF in the service chain receives a second message, and a destination address field of the second message includes the first secondary SID.

And 1105, the second SFF performs local forwarding processing on the second message according to the first secondary SID to obtain a third message, where a destination address field of a header of the third message includes a proxy SID corresponding to the first SF network element.

The third packet is a packet obtained by performing local forwarding processing on the second packet according to the first secondary SID.

The first secondary SID configured on the second SFF may be understood as a local forwarding identity. After receiving the message, the second SFF may query the local SID list according to a destination address of a header of the second message, and if the second SFF determines that the Type (Func Type) of the first secondary SID is End, the second SFF performs local forwarding processing on the second message according to the secondary SID behavior.

The second SFF may update the destination address field of the header of the second packet, so as to update the destination address field of the header of the second packet from the first secondary SID to the proxy SID, and update the currently operating SID from the first secondary SID to the proxy SID. In addition, the second SFF may pop the first secondary SID from the SRH of the second packet. In addition, the second SFF may update the SL in the SRH of the second packet, so that the SL points to the proxy SID corresponding to the first SF network element, thereby indicating that the proxy SID is the currently-operating SID in the SRH.

Step 1106, the second SFF obtains a fourth message according to the third message, where the fourth message includes the load of the third message and does not include the segment list.

After the second SFF processes the message according to the second SID behavior, it may continue to process the message according to the proxy SID behavior, and strip the SRH of the third message to obtain the fourth message.

Step 1107, the second SFF sends the fourth packet to the first SF network element in the service chain through the egress interface corresponding to the proxy SID.

The outbound interface corresponding to the proxy SID refers to an outbound interface of the going SF which has a binding relationship with the proxy SID. After the fourth message is sent through the output interface, the fourth message may reach the first SF network element.

Step 1108, the first SF network element receives the fourth message, and performs service function processing on the fourth message.

Since the message received by the first SF network element does not already contain the SRH, the first SF network element can process the message even if the first SF network element is an SR-unaware node.

At this time, SRv6 no protection scheme under link failure between SF network element and SFF has been defined in the technology related to service chain. Service traffic interruption occurs as soon as the link between the SF network element and the SFF fails.

In the method provided by this embodiment, in a static SRV6 service chain scenario, when a link between an SF network element and an accessed SFF fails, a secondary SID is introduced to update a destination address field of a packet header of a packet to the secondary SID, so that the packet is directed to other SFFs accessed by the SF network element through the secondary SID, thereby implementing link failure protection between the SFF and the SF network element, avoiding interruption of traffic due to a single-point link failure, and improving reliability of a service chain.

The method for protecting under the condition of link failure between the SFF and the SF network element is introduced above. It is extended from the above embodiments that the method for preventing the loop of the SRv6 service chain in the double-link failure scenario is introduced below.

For ease of understanding, a description will first be given of the case where a loop occurs in a double-link failure scenario.

A double-point failure of a pair of leaf nodes (leaf nodes) may occur in the traffic chain, i.e., a link failure occurs in each leaf of a pair of leaf nodes. For example, referring to fig. 14 and 15, the link between SFF1 and SF1 fails, as does the link between SFF2 and SF 1. In this scenario, SFF1 would insert SFF2 secondary SID into the traffic. Thereafter, traffic is channeled through SFF2 secondary SID to SFF 2. When the SFF2 receives the traffic, it senses the link failure and inserts SFF1secondary SID into the traffic. Thereafter, the traffic is diverted back to SFF1 through SFF1secondary SID, causing the traffic to loop between SFF1 and SFF 2. Among them, a leaf node is a term in a leaf-spine (leaf-spine) topology network, and a leaf node is used to serve as an access layer of the network. The leaf node can be connected with the host and spine node. The spine node is used to act as the convergence layer of the network. The physical entity of the leaf node may be, without limitation, a switch of a data center.

In view of this, the present embodiment provides a method for preventing a loop in a scenario where a service chain has a double-link failure, which is described below with reference to the embodiment in fig. 16. In the embodiment of fig. 16, a scenario in which a link between a first SFF and a first SF network element fails and a link between a second SFF and the first SF network element also fails is taken as an example for description. It should be understood that the embodiment of fig. 16 focuses on the differences from the embodiment of fig. 11, and please refer to the embodiment of fig. 11 for steps similar to the embodiment of fig. 11, which are not repeated in the embodiment of fig. 16.

Referring to fig. 16, the method may include the steps of:

step 1601, a first SFF in the service chain receives a first message, and a destination address field of the first message includes a proxy SID corresponding to a first service function SF network element in the service chain.

Step 1602, if a link between the first SFF and the first SF network element fails, the first SFF replaces the proxy SID in the first message with a backup SID, the first SFF updates a destination address field of a header of the first message to obtain a second message, and the destination address field of the second message includes the first secondary SID.

In this embodiment, the second packet is obtained by processing the first packet by the first SFF according to the first secondary SID and the backup SID. The SRH in the second message includes a segment list and a SL. The segment list includes a first secondary SID and a backup SID, and the segment list does not include a proxy SID corresponding to an original first SF network element of the first packet. The value of SL in the second message may indicate that the currently operating SID in the segment list is the first secondary SID.

The backup SID may be a backup of a proxy SID corresponding to a first SF network element on a first SFF. For example, referring to FIGS. 17 and 18, the backup SID may be B-SID2 contained in SFF 1. In SFF1, B-SID2 is a backup of SID2, and SID2 is proxy SID corresponding to SF 1. In SFF1, the sid2 bound outgoing interface and next hop are used to go to SF 1. In addition, the proxy SID of the first SFF and the proxy SID of the second SFF may be a relationship of anycast SIDs, and then the backup SID may also be a backup of the proxy SID corresponding to the first SF network element on the second SFF. For example, referring to FIGS. 17 and 18, the backup SID may also be B-SID2 contained in SFF 2. In SFF2, B-SID2 is a backup of SID2, and SID2 is proxy SID corresponding to SF 1. In SFF2, the sid2 bound outgoing interface and next hop are also used to go to SF 1. The backup SID may be an end.x type SID, or may also be an End type SID, which is not limited in this embodiment.

The backup SID is used for indicating the second SFF not to use the second secondary SID to forward the second message. In a possible implementation, the configuration may be performed on the second SFF in advance, and if the current working SID is a backup SID, the forwarding directed to the first SF network element is performed, without entering the procedure of the second SID. For example, referring to fig. 17, SFF2 includes "B-SID 2", and if the current working SID in the packet is B-SID2, SFF2 may not use SFF1secondary SID to enter the secondary SID flow, but perform forwarding to SF 1.

Wherein the second secondary SID may be a secondary SID configured on the second SFF. The second secondary SID may be a SID local to the first SFF. The second secondary SID may be pre-stored in the local SID table of the first SFF. The locator of the second secondary SID is used for routing to the first SFF. The locator of the second secondary SID may be the locator previously issued by the first SFF. For example, referring to fig. 17 and 18, SFF2 includes "SFF 1secondary SID". The SFF1secondary SID is a local SID of the SFF1, and the locator of the SFF1secondary SID can be located to the SFF 1.

In some embodiments, the type of the second secondary SID may be an End type. For example, in the local SID table of the first SFF, the value of Func Type of the second secondary SID may be End.

In some embodiments, a binding relationship between a backup SID and an egress interface may be established on the second SFF, where the egress interface corresponding to the backup SID is used to establish a link with the first SF network element, and the egress interface corresponding to the backup SID and the egress interface corresponding to the proxy SID may be different.

In addition, the function of the backup SID and the proxy SID may be the same. In addition, the function of the backup SID configured on the first SFF and the function of the backup SID configured on the second SFF may be the same.

It should be understood that the timing sequence of the two steps of updating the destination address and replacing the proxy SID is not limited in this embodiment. In some embodiments, updating the destination address and replacing the proxy SID may be performed sequentially. For example, updating the destination address may be performed first, followed by replacing the proxy SID; it is also possible to perform the replacement of proxy SID first and then perform the update of the destination address. In other embodiments, updating the destination address and replacing the proxy SID may also be performed in parallel, i.e., the updating the destination address and replacing the proxy SID may be performed simultaneously.

Step 1603, the first SFF sends a second message.

After the second message is sent out from the output interface of the first SFF, the second message is directed to the second SFF through the first secondary SID. For example, referring to fig. 17, when a link (link corresponding to SID 2) between SFF1 and SF2 fails and traffic enters an SFF2 secondary SID tunnel, SFF1 first replaces the original SF1 proxy SID of the traffic with a backup proxy SID, and then SFF1 pushes the SFF2 secondary SID to the traffic, so that the traffic is drained to SFF2 through SFF2 secondary SID.

Step 1604, the second SFF in the service chain receives the second packet, where a destination address of a header of the second packet includes a first secondary SID, and the first secondary SID is a local SID of the second SFF, for example, the first secondary SID is an End type SID.

And 1605, the second SFF performs local forwarding processing on the second message according to the first secondary SID to obtain a third message, and the destination address of the message header of the third message comprises a backup SID.

The third packet may be a packet obtained by performing local forwarding processing on the second packet according to the first secondary SID.

Step 1606, the second SFF obtains a fourth packet according to the third packet, where the fourth packet includes the load of the third packet and does not include the segment list.

This step may include: and the second SFF inquires a local SID table according to the destination address field of the message header of the third message, determines that the destination address of the third message is matched with the backup SID, and executes a command corresponding to the backup SID to obtain a fourth message. The process of executing the instruction corresponding to the backup SID may be referred to as a backup SID behavior. The fourth packet may be a packet obtained by processing the third packet according to the backup SID.

For example, referring to fig. 17 and 18, after the SFF2 receives the message, since the SFF1secondary SID is on the outer layer and the backup SID is on the inner layer, the SFF2 will process the message according to the secondary SID behavior first and then continue to process the message according to the backup SID behavior. For example, please refer to an arrow inside SFF2 in fig. 17, where the arrow points from SFF1secondary SID to B-SID2, and then points from B-SID2 to VM2 where SF1 is located, meaning that the message is processed according to SFF1secondary SID behavior, and then the message is processed according to B-SID2 behavior and then forwarded to VM2 where SF1 is located.

In addition, because the function of the backup SID is the same as that of the proxy SID, the second SFF will perform the function of the proxy SID according to the backup SID, and strip the SRH of the third message to obtain the fourth message.

Step 1607, the second SFF sends the fourth message to the first SF network element in the service chain through the egress interface corresponding to the backup SID.

Step 1608, the first SF network element receives the fourth packet, and performs service function processing on the fourth packet.

If the link between the second SFF and the first SF network element fails, and the message still carries the proxy SID but does not carry the backup SID, the second SFF inserts the second secondary SID into the message, refreshes the destination address field of the message header, and returns the message to the first SFF through the locator route corresponding to the second secondary SID, thereby causing a loop. And by replacing the proxy SID in the message with the backup SID, because the backup SID indicates that the second SFF does not use the second secondary SID to forward the second message, the second SFF does not enter the secondary SID flow, but only forwards the second message to the first SF network element, thereby breaking the loop.

In summary, in the method provided in this embodiment, in a SRV6 static service chain scenario, even if links between an SF network element and two SFFs in dual-homed access fail, a backup SID is introduced to replace a proxy SID originally included in a message with a backup SID, so that the message can be directed to other SFFs accessed by the SF network element through the backup SID, and can also be directed to other SFFs for forwarding to the SF network element through the backup SID without entering a backup SID flow, thereby avoiding a traffic loop caused by the entry of other SFFs into the backup SID flow. Thus, with the backup SID mechanism, the flow loop caused by double-point failure can be prevented.

The method for protecting and preventing the flow loop in the link failure scene between the SFF and the SF network element is introduced above. The failure scenario of SRV6 static service chain includes node failure scenarios, such as SF whole network element failure, in addition to the link failure scenario described in the above embodiments. In view of this, the present embodiment provides a method for protecting an SF network element in a service chain in a fault scenario, which is described below with reference to the embodiment in fig. 19. In the embodiment of fig. 19, the failure of the second SF network element is taken as an example for explanation. It should be understood that the embodiment of fig. 19 focuses on the differences from the above-mentioned embodiments, and the steps similar to the above-mentioned embodiments are also referred to the above-mentioned embodiments, which are not repeated in the embodiment of fig. 19.

Referring to fig. 19, the method may include the steps of:

step 1901, the fourth SFF in the service chain receives the fifth message, and the destination address field of the header of the fifth message includes the proxy SID corresponding to the second SF network element in the service chain.

The fourth SFF may be the first SFF in the embodiment of fig. 11. The fourth SFF may also be the second SFF in the embodiment of fig. 11. The fourth SFF may also be other SFFs in the service chain instead of the first SFF or the second SFF, which is not limited in this embodiment. The second SF network element is an SF network element accessed by a fourth SFF in the service chain. For example, if the fourth SFF is the first SFF or the second SFF in the embodiment of fig. 11, the second SF network element may be the first SF network element in the embodiment of fig. 11.

Step 1902, if the second SF network element is in a failure state, the fourth SFF updates a destination address field of a header of the fifth packet to obtain a sixth packet, where the destination address field of the sixth packet includes a bypass SID.

The sixth message is obtained after the fourth SFF processes the fifth message according to the bypass SID. The IPv6 header in the sixth message includes a DA field, and the value of the DA field is bypass SID. The SRH in the sixth message includes a segment list and a SL. The fragment list includes bypass SIDs and other SIDs. The value of SL may indicate that the currently-working SID in the segment list is a bypass SID. The load in the sixth message may be an original message to be processed by the SF network element. The sixth message may include a payload of the fifth message, for example, the payload in the sixth message may be the same as the payload in the fifth message.

The bypass SID is used for guiding other SF network elements except the SF network element in the fault state so as to realize normal forwarding of the service flow. In the present embodiment, a scenario is illustrated in which: the second SF network element fails, and the service chain has a third SF network element in addition to the second SF network element, and the third SF network element has access to a fifth SFF. In this scenario, the bypass SID may be a SID configured on the fifth SFF. The bypass SID may be a SID local to the fifth SFF. The bypass SID may be stored in advance in the local SID table of the fifth SFF. The locator of the bypass SID is used for routing to the fifth SFF. The locator of the bypass SID may be the locator previously issued by the fifth SFF. For example, referring to fig. 20 and 21, SFF2 contains "Bypass SID". The bypass SID is SID3 local to SFF3, and the locator of the bypass SID can be located to SFF 3.

In some embodiments, the type of bypass SID may be an End type. For example, in the local SID table of the fifth SFF, the value of Func Type of bypass SID may be End.

The bypass SID specifically includes multiple implementation manners, and when the bypass SID is implemented in different manners, the actions of the fourth SFF may have differences. The following is illustrated by way of example in ways one and two:

mode one, bypass SID can be defined separately.

The bypass SID may be an SID of an End type defined separately on the fifth SFF. In this way, the fourth SFF may further insert the bypass SID into the SRH of the fifth packet, and update the destination address field of the packet header of the fifth packet to obtain the sixth packet.

And in the second mode, the bypass SID is the proxy SID corresponding to the third SF network element.

The bypass SID may also multiplex a proxy SID corresponding to the SF network element to be skipped, i.e., a proxy SID corresponding to the third SF network element. In this way, since the SRH of the fifth packet already includes the proxy SID corresponding to the third SF network element, the third SF network element may not insert the bypass SID into the SRH of the fifth packet, but directly shift the currently operating SID to the proxy SID corresponding to the third SF network element by updating the value of the SL field in the SRH, and update the destination address field of the packet header of the fifth packet, and forward the packet.

The third SF network element is other SF network elements except the second SF network element. The third SF network element may be an SF network element to be jumped to after the failure of the specified second SF network element. The third SF network element specifically includes multiple cases, which are exemplified by the following cases (1) to (2):

in case (1), the third SF network element is a backup SF network element of the second SF network element.

The backup SF network element is configured to act as a backup for the third SF network element. The service function provided by the backup SF network element and the service function provided by the third SF network element can be the same. For example, in one possible implementation, the backup SF network element and the third SF network element may be in a dual-computer hot standby relationship, where the third SF network element is a master and the backup SF network element is a slave, and when the third SF network element fails, the backup SF network element may replace the third SF network element to perform service function processing.

In case (2), the third SF network element is the next SF network element of the second SF network element in the service chain.

For example, referring to fig. 12, if the second SF network element is SF1, the third SF network element may be SF 2.

If the third SF network element is the case (2), because the proxy SID corresponding to the two adjacent SF network elements may be adjacent in the segment list of the SRH, the proxy SID corresponding to the third SF network element may be the next proxy SID of the proxy SID corresponding to the second SF network element, and the third SF network element may shift the currently-operating SID in the fifth message to the next proxy SID, for example, reduce the value of the SL field by one, update the destination address field of the header of the fifth message, obtain the sixth message, and forward the sixth message.

There are various ways to determine that the SF network element is in the fault state, which are exemplified by the following first and second ways:

in the first mode, if the output interface corresponding to the proxy SID is in an UP state and each VM where the second SF network element is located is unreachable, the fourth SFF detects that the second SF network element is in a fault state.

For example, referring to fig. 20, if the iface-out interface bound to the sid2 on the SFF2 is in a physical UP state and all of the

VMs

1 and 2 running with the SF1 are not reachable, the SFF2 may determine that the SF1 fails.

And in a second mode, if at least one of the outgoing interface corresponding to the backup SID or the outgoing interface corresponding to the proxy SID has a link failure, the fourth SFF detects that the second SF network element is in a failure state.

Specifically, the second mode may be, but is not limited to, the following modes 2.1 to 2.2:

in the mode 2.1, the fourth SFF is configured with proxy SID and backup SID.

In the mode 2.1, the fourth SFF has two outgoing interfaces to the second SF network element, one of the outgoing interfaces establishes a binding relationship with the proxy SID, and the other outgoing interface establishes a binding relationship with the backup SID. If the fourth SFF detects that the outgoing interface corresponding to the backup SID is in a closed (down) state, the outgoing interface corresponding to the proxy SID is also in a down state, and the fourth SFF can determine that each link between the fourth SFF and the second SF network element is disconnected, so that the fourth SFF can determine that the second SF network element is in a fault state.

Wherein the backup SID on the fourth SFF may be used to prevent traffic between the fourth SFF and the fifth SFF from looping. The backup SID on the fourth SFF may be used to indicate that the fourth SFF does not use the third secondary SID to forward the fifth packet. The third secondary SID is a SID local to the fifth SFF. The relationship between the fifth SFF and the fourth SFF may be an anycast relationship. The fifth SFF may be another SFF in the protection group except the fourth SFF, and the protection group includes a plurality of SFFs accessed by the second SF network element.

In the mode 2.2, only proxy SID is configured on the fourth SFF, and backup SID is not configured.

In the mode 2.2, the fourth SFF has an outgoing interface to the second SF network element, and the outgoing interface establishes a binding relationship with the proxy SID. If the fourth SFF detects that the outbound interface corresponding to the proxy SID is in the down state, the fourth SFF may determine that all links with the second SF network element are disconnected, and thus the fourth SFF may determine that the second SF network element is in the fault state.

Step 1903, the fourth SFF sends a sixth message.

And after the sixth message is sent out from the output interface of the fourth SFF, the sixth message is guided to the fifth SFF through the bypass SID.

Step 1904, the fifth SFF in the service chain receives the sixth message.

Step 1905, the fifth SFF obtains a seventh message according to the sixth message, where the seventh message includes the load of the sixth message and does not include the segment list.

Since the fourth SFF updates the destination address field of the header to the bypass SID, the fifth SFF will execute the operation corresponding to the bypass SID after querying the local SID table by using the destination address field.

The action of the fifth SFF may have a difference according to the implementation of the bypass SID. The following is illustrated by way of example in ways one and two:

mode one, bypass SID can be defined separately.

The actions of the fifth SFF may include the following steps one to two:

step one, the fifth SFF carries out local forwarding processing on the sixth message according to the bypass SID to obtain the eighth message.

The destination address field of the header of the eighth packet includes a proxy SID corresponding to the third SF network element, and the eighth packet may include a load of the sixth packet.

And step two, the fifth SFF obtains a seventh message according to the eighth message.

In the mode, because the bypass SID is at the outer layer, the proxy SID is at the inner layer, and when the fifth SFF receives the sixth message, the fifth SFF may query the local SID table according to the bypass SID, determine that the type of the bypass SID is the End type, and query the IPv6 routing forwarding table for local forwarding according to the End type SID action. And then, the fifth SFF continues to process the message according to the proxy SID behavior and forwards the message.

In the second mode, the fifth SFF may directly process the packet according to the proxy SID behavior and forward the packet.

It should be understood that in both the first and second manners, the fifth SFF will strip the SRH first and then send it to the third SF network element, and after the third SF network element returns a message to the fifth SFF, the fifth SFF will repackage the SRH according to cachelist.

Step 1906, the fifth SFF sends the seventh message to the third SF network element through the egress interface corresponding to the proxy SID.

Step 1907, the third SF network element receives the seventh message, and performs service function processing on the seventh message.

In the method provided by this embodiment, in an SRV6 static service chain scenario, when an SF network element fails, a bypass SID is introduced to update a destination address field of a header of a packet to the bypass SID, so that the packet is directed to another SF network element, such as a backup SF network element outside an original path or a next SF network element inside the original path, through the bypass SID, thereby performing service protection through the other network element, implementing normal forwarding of service traffic, avoiding interruption of traffic due to a single node failure, and improving reliability of a service chain.

The method for protecting the SF network element fault scene through the bypass SID is described above. It is to be understood that the features presented in the various embodiments above may be combined with each other to create other situations. The following exemplary method embodiments in two other cases are presented.

Referring to fig. 22, the method for fault protection of a service chain may include the following steps:

step 2201, a first SFF in the service chain receives the first message, and a destination address of a message header of the first message includes a proxy SID corresponding to a first SF network element in the service chain.

Step 2202, if a link between the first SFF and the first SF network element fails, the first SFF updates a destination address of the first message, the first SFF replaces a proxy SID in the first message with a backup SID to obtain a second message, and the destination address of a header of the second message includes the first secondary SID.

Step 2203, the first SFF sends the second message.

Step 2204, the second SFF in the service chain receives the second packet, and the destination address of the packet header of the second packet includes the first secondary SID.

The first secondary SID is a local SID of the second SFF, where the first secondary SID may be an End-type SID;

step 2205, the second SFF performs local forwarding processing on the second message according to the first secondary SID to obtain a third message, where a destination address of a header of the third message includes a backup SID.

Step 2206, if the output interface corresponding to the backup SID fails, the second SFF updates the destination address of the third message to obtain an eighth message, and the destination address of the message header of the eighth message includes the bypass SID.

The backup SID is used to indicate the second SFF not to update the destination address field of the header of the second message to the second secondary SID, and the second secondary SID is a local SID of the first SFF. Wherein, the second secondary SID may be an End type SID; when the message carries the backup SID, it may indicate that the link between the first SFF and the first SF network element has a failure, and the second secondary SID may not be used to enter the secondary flow. At this time, the second SFF may determine whether the egress interface corresponding to the backup SID is in an open (up) state, and if the egress interface corresponding to the backup SID is in the up state, the second SFF may send the message to the first SF network element through the egress interface corresponding to the backup SID. If the output interface corresponding to the backup SID is also in the down state, the second SFF can enter the bypass SID flow by executing the following steps.

The bypass SID is the SID local to the third SFF. The bypass SID may be an End type SID. For example, in the local SID table of the third SFF, the FuncType value of bypass SID may be End. And the third SFF is the SFF accessed by the fourth SF network element. The fourth SF network element may include the following cases (1) to (2):

(1) the fourth SF network element is a backup SF network element of the first SF network element.

(2) The fourth SF network element is the next SF network element of the first SF network element in the service chain.

Step 2207, the second SFF sends the eighth message to the third SFF.

Step 2208, the third SFF receives the eighth message, obtains a ninth message according to the eighth message, and sends the ninth message to the fourth SF network element through the egress interface corresponding to the proxy SID, where the ninth message includes the load of the eighth message and does not include the segment list.

Step 2209, the fourth SF network element receives the ninth message, and performs service function processing on the ninth message.

In the embodiment of the method, the second SFF realizes normal forwarding of the service traffic through the bypass SID. In other embodiments, if the bypass SID is not preconfigured on the second SFF, the packet may be discarded, which is specifically referred to in the following method embodiments.

Referring to fig. 23, the method may include the steps of:

step 2301, a first SFF in the service chain receives a first message, and a destination address field of a header of the first message includes an agent SID corresponding to a first SF network element in the service chain.

Step 2302, if a link between the first SFF and the first SF network element fails, the first SFF updates a destination address field of the first message, the first SFF replaces the proxy SID in the first message with a backup SID to obtain a second message, and the destination address field of a header of the second message includes the first secondary SID.

Step 2303, the first SFF sends the second message.

Step 2304, the second service function forwarding device SFF in the service chain receives the second packet, and the destination address field of the packet header of the second packet includes the first secondary SID.

Step 2305, the second SFF performs local forwarding processing on the second packet according to the first secondary SID to obtain a third packet, and a destination address field of a packet header of the third packet includes a backup SID.

The backup SID is used for indicating the second SFF not to update the destination address field of the second message to be the second secondary SID, and the second secondary SID is the local SID of the first SFF. The second secondary SID may be an End type SID.

Step 2306, if the back interface corresponding to the backup SID fails and the local SID table of the second SFF does not have a bypass SID, the second SFF discards the third message.

The method for fault protection of a service chain according to an embodiment of the present application is described above, and the SFF according to an embodiment of the present application is described below.

Fig. 24 is a schematic structural diagram of an SFF provided in an embodiment of the present application, and as shown in fig. 24, the SFF includes:

a receiving module 2401, configured to perform step 1101, step 1601, step 2201, or step 2301;

an update module 2402 for performing step 1102, step 1602, step 2202, or step 2302;

a sending module 2403, configured to execute step 1103, step 1603, step 2203, or step 2303.

Optionally, the SFF further comprises: and the replacing module is used for replacing the proxy SID with the backup SID.

It should be understood that the SFF provided in the embodiment of fig. 24 corresponds to the first SFF in the foregoing method embodiment, and each module and the other operations and/or functions described above in the embodiment of fig. 24 are respectively for implementing various steps and methods implemented by the first SFF in the method embodiment, and specific details may be referred to the foregoing method embodiment and are not described herein again for brevity.

It should be understood that, when the SFF provided in the embodiment of fig. 24 performs fault protection on a service chain, only the division of the above functional modules is illustrated, and in practical applications, the above function distribution may be completed by different functional modules according to needs, that is, the internal structure of the SFF is divided into different functional modules, so as to complete all or part of the functions described above. In addition, the SFF provided in the foregoing embodiment and the embodiment of the method for protecting the service chain in the foregoing embodiment in fig. 11, fig. 16, fig. 22, or fig. 23 belong to the same concept, and details of the specific implementation process are referred to as method embodiments, and are not described herein again.

Fig. 25 is a schematic structural diagram of an SFF provided in an embodiment of the present application, and as shown in fig. 25, the SFF includes:

a receiving module 2501, configured to perform step 1104, step 1604, step 2204, or step 2304;

a processing module 2502 for performing steps 1105 and 1106, or for performing steps 1605 and 1606, or for performing steps 2205 and 2206, or for performing step 2305;

a sending module 2503, configured to execute step 1107, step 1607, or step 2207.

Optionally, the SFF further comprises: a discard module to perform step 2306.

It should be understood that the SFF provided in the embodiment of fig. 25 corresponds to the first SFF in the foregoing method embodiment, and each module and the other operations and/or functions described above in the embodiment of fig. 25 are respectively used to implement various steps and methods implemented by the second SFF in the method embodiment, and specific details may be referred to the foregoing method embodiment and are not described herein again for brevity.

It should be understood that, when the SFF provided in the embodiment of fig. 25 performs fault protection on a service chain, only the division of the above function modules is illustrated, and in practical applications, the above function allocation may be completed by different function modules according to needs, that is, the internal structure of the SFF is divided into different function modules, so as to complete all or part of the functions described above. In addition, the SFF provided in the foregoing embodiment and the embodiment of the method for protecting the service chain in the foregoing embodiment in fig. 11, fig. 16, fig. 22, or fig. 23 belong to the same concept, and details of the specific implementation process are referred to as method embodiments, and are not described herein again.

Fig. 26 is a schematic structural diagram of an SFF provided in an embodiment of the present application, and as shown in fig. 26, the SFF includes:

a receiving module 2601, configured to perform step 1901;

an update module 2602 for performing step 1902;

a sending module 2603 is configured to execute step 1903.

Optionally, the SFF further comprises: the detection module is used for detecting that the second SF network element is in a fault state if the output interface corresponding to the agent SID is in an open state and each virtual machine where the second SF network element is located is unreachable; or, if at least one of the outgoing interface corresponding to the backup SID or the outgoing interface corresponding to the proxy SID has a link failure, it is detected that the second SF network element is in a failure state.

It should be understood that the SFF provided in the embodiment of fig. 26 corresponds to the third SFF in the foregoing method embodiment, and each module and the other operations and/or functions described above in the embodiment of fig. 26 are respectively for implementing various steps and methods implemented by the third SFF in the method embodiment, and specific details may be referred to in the foregoing method embodiment and are not described herein again for brevity.

It should be understood that, when the SFF provided in the embodiment of fig. 26 performs fault protection on a service chain, only the division of the above functional modules is illustrated, and in practical applications, the above function distribution may be completed by different functional modules according to needs, that is, the internal structure of the SFF is divided into different functional modules, so as to complete all or part of the above described functions. In addition, the SFF provided in the foregoing embodiment and the embodiment of the method for protecting the service chain in the foregoing embodiment in fig. 19 belong to the same concept, and details of a specific implementation process thereof are referred to in the method embodiment and are not described herein again.

Fig. 27 is a schematic structural diagram of an SFF provided in an embodiment of the present application, and as shown in fig. 27, the SFF includes:

a receiving module 2701, configured to execute step 1904;

a processing module 2702 configured to perform step 1905;

a sending module 2703, configured to execute step 1907.

Optionally, the processing module 2702 is configured to perform local forwarding processing on the sixth packet according to the bypass SID, so as to obtain an eighth packet; and obtaining a seventh message according to the eighth message.

It should be understood that the SFF provided in the embodiment of fig. 27 corresponds to the fourth SFF in the foregoing method embodiment, and each module and the other operations and/or functions described above in the embodiment of fig. 27 are respectively used to implement various steps and methods implemented by the fourth SFF in the method embodiment, and specific details may be referred to in the foregoing method embodiment and are not described herein again for brevity.

It should be understood that, when the SFF provided in the embodiment of fig. 27 performs fault protection on a service chain, only the division of the above function modules is illustrated, and in practical applications, the above function allocation may be completed by different function modules according to needs, that is, the internal structure of the SFF is divided into different function modules, so as to complete all or part of the functions described above. In addition, the SFF provided in the foregoing embodiment and the embodiment of the method for protecting the service chain in the foregoing embodiment in fig. 19 belong to the same concept, and details of a specific implementation process thereof are referred to in the method embodiment and are not described herein again.

The SFF of the present application is described above, and the possible product forms of the SFF are described below.

It should be understood that any product having any of the above SFF characteristics would fall within the scope of the present application. It should also be understood that the following description is by way of example only and does not limit the product form of the SFF of the embodiments of the present application to that.

The embodiment of the present application provides an SFF, where the SFF includes a processor, and the processor is configured to execute an instruction, so that the SFF executes the method for protecting a fault of a service chain provided in the foregoing method embodiments.

By way of example, the Processor may be a Network Processor (NP), a Central Processing Unit (CPU), an application-specific integrated circuit (ASIC), or an integrated circuit for controlling the execution of the program in the present application. The processor may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. The number of the processors may be one or more.

In some possible embodiments, the SFF may also include a memory.

The Memory may be a read-only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only Memory (EEPROM) or a failsafe read-only Memory of an electrically erasable programmable program chain, a compact disc read-only Memory (CD-ROM) or other optical disc storage, optical disc storage (including compact disc, laser disc, optical disc, digital versatile disc, blu-ray disc, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited to such.

The memory and the processor may be provided separately or may be integrated together.

In some possible embodiments, the SFF may also include a transceiver.

The transceiver is used to communicate with other devices or a communication network, which may be, but is not limited to, an ethernet, a Radio Access Network (RAN), a Wireless Local Area Network (WLAN), etc.

In some possible embodiments, the SFF or SF network element may be implemented as a network device, and a network processor in the network device may perform the steps of the method embodiments. For example, the network device may be a router, a switch, or a firewall, or may be other network devices that support a message forwarding function.

Referring to fig. 28, fig. 28 is a schematic structural diagram of a network device provided in an exemplary embodiment of the present application, where the network device may be configured as an SFF.

The network device 2800 includes: main control board 2810, interface board 2830, switch network board 2820 and interface board 2840. The main control board 2810 is used to perform functions such as system management, device maintenance, and protocol processing. The switch network board 2820 is used to complete data exchange between interface boards (interface boards are also called line cards or service boards). The interface boards 2830 and 2840 are used to provide various service interfaces (e.g., ethernet interfaces, POS interfaces, etc.) and implement packet forwarding. The main control board 2810, the interface boards 2830 and 2840, and the switch board 2820 are connected to the system backplane through the system bus to realize intercommunication. The central processing unit 2831 on the interface board 2830 is used for controlling and managing the interface board and communicating with the central processing unit 2811 on the main control board 2810.

If the network device 2800 is configured as an SFF, the physical interface card 2833 receives the first packet and sends it to the network processor 2832, and the network processor 2832 updates the destination address field to obtain a second packet, and sends it from the physical interface card 2833 after completing the link layer encapsulation according to the information such as the outgoing interface, so that the second packet is transmitted to a second SFF.

In one embodiment, the network processor 2832 replaces the proxy SID in the first message with the backup SID.

If the network device 2800 is configured as a second SFF, the physical interface card 2833 receives the second packet and sends the second packet to the network processor 2832, and the network processor 2832 performs local forwarding processing on the second packet according to the first slave SID; and obtaining a fourth message according to the third message. According to the information such as the outgoing interface, after the link layer encapsulation is completed, the fourth packet is sent out from the physical interface card 2833, so that the fourth packet is transmitted to the first SF network element.

If the network device 2800 is configured as the fourth SFF, the physical interface card 2833 receives the fifth packet and sends the fifth packet to the network processor 2832, the network processor 2832 updates the destination address field to obtain a sixth packet, and sends the sixth packet from the physical interface card 2833 after the link layer encapsulation is completed according to the information such as the outgoing interface, so that the sixth packet is transmitted to the fifth SFF.

If the network device 2800 is configured as the fifth SFF, the physical interface card 2833 receives the sixth packet and sends the sixth packet to the network processor 2832, and the network processor 2832 obtains a seventh packet according to the sixth packet. According to the information such as the outgoing interface, after the link layer encapsulation is completed, the seventh packet is sent out from the physical interface card 2833, so that the seventh packet is transmitted to the third SF network element.

It should be understood that the operations on the interface board 2840 in this embodiment are consistent with the operations of the interface board 2830, and therefore, for brevity, the description is omitted. It should be understood that the network device 2800 of this embodiment may correspond to the SFF in each method embodiment described above, and the main control board 2810, the interface board 2830 and/or 2840 in the network device 2800 may implement the functions of the SFF and/or various steps implemented in each method embodiment described above, which are not described herein again for brevity.

It should be noted that there may be one or more main control boards, and when there are more main control boards, the main control boards may include a main control board and a standby main control board. The interface board may have one or more blocks, and the stronger the data processing capability of the network device, the more interface boards are provided. There may also be one or more physical interface cards on an interface board. The exchange network board may not have one or more blocks, and when there are more blocks, the load sharing redundancy backup can be realized together. Under the centralized forwarding architecture, the network device does not need a switching network board, and the interface board undertakes the processing function of the service data of the whole system. Under the distributed forwarding architecture, the network device can have at least one switching network board, and the data exchange among a plurality of interface boards is realized through the switching network board, so that the high-capacity data exchange and processing capacity is provided. Therefore, the data access and processing capabilities of network devices in a distributed architecture are greater than those of devices in a centralized architecture. Optionally, the form of the network device may also be only one board card, that is, there is no switching network board, and the functions of the interface board and the main control board are integrated on the one board card, at this time, the central processing unit on the interface board and the central processing unit on the main control board may be combined into one central processing unit on the one board card to perform the function after the two are superimposed, and the data switching and processing capability of the device in this form is low (for example, network devices such as a low-end switch or a router, etc.). Which architecture is specifically adopted depends on the specific networking deployment scenario, and is not limited herein.

Fig. 29 is a schematic structural diagram of an interface board 2830 in the network device shown in fig. 28 according to an embodiment of the present application, where the network device where the interface board 2830 is located may be any node in the system architecture embodiment of the above figure, for example, may be an SFF or SF network element. The interface board 2830 may include a Physical Interface Card (PIC) 2930, a Network Processor (NP) 2910, and a traffic management module (traffic management) 2920.

The PIC is a physical interface card (physical interface card) for implementing a physical layer docking function, from which an original flow enters an interface board of the network device, and a processed message is sent from the PIC card.

The network processor NP 2910 is configured to implement forwarding processing of the packet. Specifically, the processing of the uplink packet includes: processing of the message ingress interface, forwarding table lookup (related to the relevant content of the first forwarding table or the second forwarding table as in the above embodiments); and (3) downlink message processing: forwarding table lookup (related to the relevant contents of the first forwarding table or the second forwarding table as in the above embodiments), and so on.

The traffic management TM 2920 is used to implement QoS, line-speed forwarding, large-capacity caching, queue management, and other functions. Specifically, the uplink traffic management includes: uplink Qos processing (such as congestion management and queue scheduling) and slicing processing; the downlink traffic management comprises the following steps: packet processing, multicast replication, and downstream Qos processing (e.g., congestion management and queue scheduling).

It is understood that, in case of a network device having a plurality of interface boards 2830, the plurality of interface boards 2830 can communicate with each other through the switching network 2940.

It should be noted that fig. 29 only shows an exemplary process flow or module inside the NP, the processing order of each module in the specific implementation is not limited thereto, and other modules or process flows may be deployed as required in practical applications. The embodiment of the present application does not limit this.

In some possible embodiments, the SFF may be implemented as a computing device, and a central processor in the computing device may perform the steps of the above method embodiments. For example, the computing device may be a host computer, a server, a personal computer, or the like. The computing device may be implemented by a generic bus architecture.

Referring to fig. 30, fig. 30 is a schematic diagram illustrating a structure of a computing device according to an exemplary embodiment of the present application. The computing device may be any device involved in all or part of the description of the method embodiments, such as an SFF or SF network element, etc. The computing device includes at least one processor 3001, a communication bus 3002, memory 3003, and at least one communication interface 3004.

The processor 3001 may be a general-purpose Central Processing Unit (CPU), a Network Processor (NP), a microprocessor, or may be one or more integrated circuits such as an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof for implementing the present solution. The PLD may be a Complex Programmable Logic Device (CPLD), a Field Programmable Gate Array (FPGA), a Generic Array Logic (GAL), or any combination thereof.

The communication bus 3002 is used to transfer information between the above components. The communication bus 3002 may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus.

The Memory 3003 may be a read-only Memory (ROM) or other type of static storage device that may store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that may store information and instructions, an electrically erasable programmable read-only Memory (EEPROM) or a failsafe programmable read-only Memory (eprom) of an electrically erasable programmable program chain), a compact disc read-only Memory (CD-ROM) or other optical disk storage, optical disk storage (including compact disc, laser disk, optical disk, digital versatile disk, blu-ray disk, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto. The memory 3003 may be separate and coupled to the processor 3001 via a communication bus 3002. The memory 3003 may also be integrated with the processor 3001.

Communication interface 3004 uses any transceiver or the like for communicating with other devices or communication networks. Communication interface 3004 includes a wired communication interface and may also include a wireless communication interface. The wired communication interface may be an ethernet interface, for example. The ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a Wireless Local Area Network (WLAN) interface, a cellular network communication interface, or a combination thereof.

In particular implementations, processor 3001 may include one or more CPUs, such as CPU0 and CPU1 shown in fig. 30, as one embodiment.

In particular implementations, as an embodiment, a computing device may include multiple processors, such as processor 3001 and processor 3005 shown in FIG. 30. Each of these processors may be a single-Core Processor (CPU) or a multi-Core Processor (CPU). A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

In particular implementations, a computer device may also include an output device and an input device, as one embodiment. An output device is in communication with the processor 3001 and can display information in a variety of ways. For example, the output device may be a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display device, a Cathode Ray Tube (CRT) display device, a projector (projector), or the like. The input device is in communication with the processor 3001 and may receive user input in a variety of ways. For example, the input device may be a mouse, a keyboard, a touch screen device, or a sensing device, among others.

In some embodiments, the memory 3003 is used to store program code 3010 for implementing aspects of the present application, and the processor 3001 may execute the program code 3010 stored in the memory 3003. That is, the computing device may implement the method for fault protection of a service chain provided in the method embodiment through the processor 3001 and the program code 3010 in the memory 3003.

The computing device of the embodiment of the present application may correspond to the SFF in the above-described respective method embodiments, and the processor 3010, the transceiver 3020, and the like in the computing device may implement the functions of the SFF in the above-described respective method embodiments and/or various steps and methods implemented. For brevity, no further description is provided herein.

In some possible embodiments, the SFF described above may be implemented as a virtualized device.

For example, the virtualized device may be a Virtual Machine (VM) running a program for sending messages, and the VM is deployed on a hardware device (e.g., a physical server). A virtual machine refers to a complete computer system with complete hardware system functionality, which is emulated by software, running in a completely isolated environment. The virtual machine may be configured as an SFF. For example, SFF may be implemented based on a general purpose physical server in conjunction with Network Functions Virtualization (NFV) technology. The SFF is a virtual host, a virtual router, or a virtual switch. Through reading the application, a person skilled in the art can simulate the SFF with the above functions on the general physical server by combining the NFV technology. And will not be described in detail herein.

For example, a virtualization appliance may be a container, which is an entity for providing an isolated virtualization environment, e.g., a container may be a docker container. The container may be configured as a SFF. For example, an SFF may be created through a corresponding mirror, for example, 2 container instances, namely, container instance proxy-container1, container instance proxy-container2, container instance proxy-container1 as a first SFF, and container instance proxy-container2 as a fourth SFF may be created for proxy-container through a mirror of proxy-container (a container providing proxy service). When the container technology is adopted for implementation, the SFF can be operated by using a kernel of the physical machine, and a plurality of SFFs can share an operating system of the physical machine. Different SFFs can be isolated by container technology. The containerized SFF may run in a virtualized environment, such as a virtual machine, or directly in a physical machine.

For example, the virtualization device may be Pod, and Pod is kubernets (kubernets is a container arrangement engine of google open source, abbreviated as K8s in english) which is a basic unit for deploying, managing and arranging containerized applications. The Pod may include one or more containers. Each container in the same Pod is typically deployed on the same host, so each container in the same Pod can communicate through the host and can share the storage resources and network resources of the host. The Pod may be configured as an SFF. For example, a Pod as a service (hereinafter, referred to as a container as a service, which is a container-based PaaS service) may be specifically instructed to create a Pod and provide the Pod as an SFF.

Of course, SFF may also be other virtualization devices, which are not listed here.

In some possible embodiments, the SFF described above may also be implemented by a general purpose processor. For example, the general purpose processor may be in the form of a chip. Specifically, the general-purpose processor for implementing SFF includes a processing circuit, an input interface and an output interface, the input interface and the output interface are connected and communicated with the processing circuit, the processing circuit is configured to execute the message generating step in each of the above method embodiments through the input interface, the processing circuit is configured to execute the receiving step in each of the above method embodiments through the input interface, and the processing circuit is configured to execute the sending step in each of the above method embodiments through the output interface. Optionally, the general-purpose processor may further include a storage medium, and the processing circuit is configured to execute the storage steps in the above-described method embodiments through the storage medium. The storage medium may store instructions for execution by a processing circuit that executes the instructions stored by the storage medium to perform the various method embodiments described above.

As a possible product form, the SFF in the embodiment of the present application can also be implemented using the following: one or more Field Programmable Gate Arrays (FPGAs), Programmable Logic Devices (PLDs), controllers, state machines, gate logic, discrete hardware components, any other suitable circuitry, or any combination of circuitry capable of performing the various functions described throughout this application.

In some possible embodiments, the SFF described above may also be implemented using a computer program product. Specifically, the present application provides a computer program product, which when running on a first SFF, causes the first SFF to execute the method for protecting a fault of a service chain in the above method embodiments. The embodiment of the present application further provides a computer program product, which when running on the second SFF, causes the second SFF to execute the method for protecting a fault of a service chain in the foregoing method embodiment. The present application provides a computer program product, which when running on a fourth SFF, causes the fourth SFF to execute the method for protecting a service chain in the foregoing method embodiments. The embodiment of the present application further provides a computer program product, which when running on a fifth SFF, causes the fifth SFF to execute the method for protecting a fault of a service chain in the foregoing method embodiment.

It should be understood that the SFFs of the above various product forms respectively have any functions of the SFFs of the above method embodiments, and are not described herein again.

Those of ordinary skill in the art will appreciate that the various method steps and elements described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both, and that the steps and elements of the various embodiments have been described above generally in terms of their functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It can be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the unit is only one logical functional division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may also be an electric, mechanical or other form of connection.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiments of the present application.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be substantially implemented or contributed to by the prior art, or all or part of the technical solution may be embodied in a software product, which is stored in a storage medium and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method in the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only for the specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive various equivalent modifications or substitutions within the technical scope of the present application, and these modifications or substitutions should be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer program instructions. When loaded and executed on a computer, produce, in whole or in part, the procedures or functions according to the embodiments of the application. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer program instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer program instructions may be transmitted from one website site, computer, server, or data center to another website site, computer, server, or data center by wire or wirelessly. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that includes one or more of the available media. The available media may be magnetic media (e.g., floppy disks, hard disks, tapes), optical media (e.g., Digital Video Disks (DVDs), or semiconductor media (e.g., solid state disks), among others.

It will be understood by those skilled in the art that all or part of the steps for implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disk, etc.

The above description is intended only to be an alternative embodiment of the present application, and not to limit the present application, and any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.

Claims

1. A method for fault protection of a service chain, the method comprising:

a first service function forwarding device (SFF) in a service chain receives a first message, wherein a destination address field of a message header of the first message comprises an agent Segment Identifier (SID) corresponding to a first Service Function (SF) network element in the service chain, and the first SFF is an SFF accessed by the first SF network element;

if the link between the first SFF and the first SF network element fails, the first SFF updates the destination address field of the first message to obtain a second message, the destination address field of the second message includes a first subordinate SID, the first subordinate SID is a local SID of a second SFF in the service chain, the second SFF is another SFF in a protection group except the first SFF, the protection group includes a plurality of SFFs accessed by the first SF network element, and the second message includes a load of the first message;

and the first SFF sends the second message.

2. The method of claim 1, wherein the type of the first subordinate SID is an endpoint End type.

3. The method of claim 1, further comprising:

and the first SFF replaces the proxy SID in the first message with a backup SID, wherein the backup SID is used for indicating that the second SFF does not update the destination address field of the second message to be a second subordinate SID, and the second subordinate SID is a local SID of the first SFF.

4. The method as recited in claim 1, wherein the protected group is an anycast group, and the proxy SID issued by different SFFs in the anycast group is an anycast SID.

5. A method for fault protection of a service chain, the method comprising:

a second service function forwarding device (SFF) in a service chain receives a second message, wherein a destination address field of a message header of the second message comprises a first subordinate Segment Identifier (SID), and the first subordinate SID is a local SID of the second SFF;

the second SFF carries out local forwarding processing on the second message according to the first subordinate SID to obtain a third message;

the second SFF obtains a fourth message according to the third message, wherein the fourth message comprises the load of the third message and does not comprise a segment list;

and the second SFF sends the fourth message to the first SF network element in the service chain.

6. The method of claim 5, wherein the type of the first subordinate SID is an endpoint End type.

7. The method of claim 5, wherein a destination address field of a header of the third packet includes a proxy SID corresponding to the first SF network element, and wherein the sending, by the second SFF, the fourth packet to the first SF network element in the service chain includes:

and the second SFF sends the fourth message to the first SF network element through an output interface corresponding to the proxy SID.

8. The method of claim 5, wherein the destination address field of the header of the third packet includes a backup SID, the backup SID is used to instruct the second SFF not to update the destination address field of the second packet to a second subordinate SID, the second subordinate SID is a SID local to the first SFF, and the second SFF sends the fourth packet to a first SF network element in the service chain, and the method includes:

9. The method according to any of claims 5 to 8, wherein the destination address field of the header of the third packet comprises a backup SID, the method further comprising:

if the output interface corresponding to the backup SID fails, the second SFF updates the destination address field of the third message to obtain an eighth message, wherein the destination address field of the message header of the eighth message comprises a drainage SID, and the drainage SID is a local SID of the third SFF;

and the second SFF sends the eighth message.

10. The method of claim 9, further comprising:

and if the outlet interface corresponding to the backup SID fails and the local SID table of the second SFF does not have the drainage SID, the second SFF discards the third message.

11. A method for fault protection of a service chain, the method comprising:

a fourth service function forwarding device (SFF) in a service chain receives a fifth message, wherein a destination address of a message header of the fifth message comprises an agent Segment Identifier (SID) corresponding to a second SF network element in the service chain, and the fourth SFF is an SFF accessed by the second SF;

if the second SF network element is in a fault state, the fourth SFF updates the destination address field of the fifth message to obtain a sixth message, the destination address of the message header of the sixth message includes a drainage SID, the drainage SID is a local SID of the fifth SFF, the fifth SFF is an SFF accessed by a third SF network element, the third SF network element is another SF network element except the second SF network element, and the sixth message includes a load of the fifth message;

and the fourth SFF sends the sixth message.

12. The method of claim 11,

the drainage SID is an End type SID; alternatively, the first and second electrodes may be,

13. The method of claim 11, wherein before the fourth SFF updates the destination address field of the fifth packet to obtain a sixth packet, the method further comprises:

if an output interface corresponding to the agent SID is in an open state and each virtual machine where the second SF network element is located is unreachable, the fourth SFF detects that the second SF network element is in a fault state, and the agent SID is used for indicating that the second SF network element executes agent operation; or the like, or, alternatively,

if at least one of the egress interface corresponding to the backup SID or the egress interface corresponding to the proxy SID has a link failure, the fourth SFF detects that the second SF network element is in a failure state, the backup SID is used to indicate that the fourth SFF does not update the destination address field of the second packet to a third subordinate SID, the third subordinate SID is a local SID of a fifth SFF, the fifth SFF is another SFF except the fourth SFF in a protection group, and the protection group includes a plurality of SFFs accessed by the second SF network element.

14. The method according to any one of claims 11 to 13,

the third SF network element is a backup SF network element of the second SF network element; or the like, or, alternatively,

15. A method for fault protection of a service chain, the method comprising:

a fifth service function forwarding device (SFF) in a service chain receives a sixth message, wherein a destination address field of a message header of the sixth message comprises a drainage SID, the drainage SID is a local SID44 of the fifth SFF, and the fifth SFF is an SFF accessed by a SF network element of a third service function;

the fifth SFF obtains a seventh message according to the sixth message, wherein the seventh message comprises the load of the sixth message and does not comprise a segment list;

and the fifth SFF sends the seventh message to the third SF network element.

16. The method of claim 15,

SID of End type of the drainage SID; alternatively, the first and second electrodes may be,

17. The method of claim 15, wherein the obtaining, by the fifth SFF, a seventh packet from the sixth packet comprises:

the fifth SFF performs local forwarding processing on the sixth message according to the drainage SID to obtain an eighth message, where a destination address field of a message header of the eighth message includes an agent SID corresponding to the third SF network element, and the eighth message includes a load of the sixth message;

and the fifth SFF obtains the seventh message according to the eighth message.

18. The method according to any one of claims 15 to 17,

the third SF network element is a backup SF network element of a second SF network element, and the second SF network element is an SF network element in a fault state; or the like, or, alternatively,

19. A service function forwarding device SFF, the SFF being a first SFF in a network, the network comprising a plurality of SFFs, wherein the first SFF comprises:

a receiving module, configured to receive a first message, where a destination address field of a header of the first message includes an agent segment identifier SID corresponding to a first service function SF network element in the service chain, and the first SFF is an SFF accessed by the first SF network element;

an updating module, configured to update the destination address field of the first packet to obtain a second packet if a link between the first SFF and the first SF network element fails, where the destination address field of the second packet includes a first subordinate SID, the first subordinate SID is a local SID of a second SFF in the service chain, the second SFF is another SFF in a protection group other than the first SFF, the protection group includes multiple SFFs accessed by the first SF network element, and the second packet includes a load of the first packet;

and the sending module is used for sending the second message.

20. The SFF of claim 19, wherein said first SFF further comprises:

a replacing module, configured to replace the proxy SID in the first packet with a backup SID, where the backup SID is used to indicate that the second SFF does not update the destination address field of the second packet to a second subordinate SID, and the second subordinate SID is a local SID of the first SFF.

21. A service function forwarding device SFF, the SFF being a second SFF in a network, the network comprising a plurality of SFFs, wherein the second SFF comprises:

a receiving module, configured to receive a second packet, where a destination address field of a packet header of the second packet includes a first subordinate segment identifier SID, and the first subordinate SID is a local SID of the second SFF;

the processing module is used for carrying out local forwarding processing on the second message according to the first subordinate SID to obtain a third message; obtaining a fourth message according to the third message, wherein the fourth message comprises the load of the third message and does not comprise a segment list;

a sending module, configured to send the fourth packet to the first SF network element in the service chain.

22. The SFF of claim 21, wherein the destination address field of the header of the third packet includes a proxy SID corresponding to the first SF network element, and the sending module is configured to send the fourth packet to the first SF network element through an egress interface corresponding to the proxy SID.

23. The SFF of claim 21, wherein a destination address field of a header of the third packet includes a backup SID, the backup SID is used to indicate that the second SFF does not update the destination address field of the second packet to a second slave SID, the second slave SID is a local SID of the first SFF, and the sending module is used to send the fourth packet to the first SF network element through an egress interface corresponding to the backup SID.

24. The SFF according to any of claims 21 to 23, wherein the destination address field of the header of the third packet comprises a backup SID;

the updating module is further configured to update the destination address field of the third packet to obtain an eighth packet if an outgoing interface corresponding to the backup SID fails, where the destination address field of a packet header of the eighth packet includes a drainage SID, and the drainage SID is a local SID of a third SFF;

the sending module is further configured to send the eighth packet.

25. A service function forwarding device SFF, the SFF being a fourth SFF in a network, the network including a plurality of SFFs, the fourth SFF comprising:

a receiving module, configured to receive a fifth packet, where a destination address of a packet header of the fifth packet includes an agent segment identifier SID corresponding to a second SF network element in the service chain, and the fourth SFF is an SFF accessed by the second SF;

an updating module, configured to update the destination address field of the fifth packet if the second SF network element is in a fault state, to obtain a sixth packet, where the destination address of a packet header of the sixth packet includes a drainage SID, the drainage SID is a local SID of a fifth SFF, the fifth SFF is an SFF accessed by a third SF network element, the third SF network element is another SF network element except the second SF network element, and the sixth packet includes a load of the fifth packet;

and the sending module is used for sending the sixth message.

26. The SFF of claim 24, wherein said fourth SFF further comprises:

the detection module is used for detecting that the second SF network element is in a fault state if an output interface corresponding to the proxy SID is in an open state and each virtual machine where the second SF network element is located is unreachable, and the proxy SID is used for indicating that proxy operation is executed for the second SF network element; or, if at least one of an egress interface corresponding to the backup SID or an egress interface corresponding to the proxy SID has a link failure, detecting that the second SF network element is in a failure state, where the backup SID is used to indicate that the fourth SFF does not update the destination address field of the second packet to a third subordinate SID, the third subordinate SID is an endpoint SID local to a fifth SFF, the fifth SFF is another SFF except the fourth SFF in a protection group, and the protection group includes multiple SFFs accessed by the second SF network element.

27. A service function forwarding device SFF, the SFF being a fifth SFF in a network, the network comprising a plurality of SFFs, wherein the fifth SFF comprises:

a receiving module, configured to receive a sixth packet, where a destination address field of a packet header of the sixth packet includes a drainage SID, the drainage SID is a local SID of a fifth SFF, and the fifth SFF is an SFF accessed by a SF network element of a third service function;

a processing module, configured to obtain a seventh packet according to the sixth packet, where the seventh packet includes a load of the sixth packet and does not include a segment list;

a sending module, configured to send the seventh packet to the third SF network element.

28. The SFF according to claim 26, wherein the processing module is configured to perform local forwarding processing on the sixth packet according to the drainage SID to obtain an eighth packet, a destination address field of a packet header of the eighth packet includes an agent SID corresponding to the third SF network element, and the eighth packet includes a payload of the sixth packet; and obtaining the seventh message according to the eighth message.

29. A service function forwarding device, SFF, comprising a processor for executing instructions such that the SFF performs the method of any of claims 1 to 18.

30. A fault protection system for a service chain, characterized in that the system comprises an SFF according to any of claims 19 to 20 and an SFF according to any of claims 21 to 24; or the like, or, alternatively,

the system comprising the SFF of any one of claims 25 to 26 and the SFF of any one of claims 27 to 28.

31. A computer-readable storage medium, characterized in that the storage medium has stored therein at least one instruction that is read by a processor to cause a traffic function forwarding device SFF to perform the method of any one of claims 1 to 18.