Message forwarding method, device, SFF node and storage medium
By pre-storing SFC entries in SFF nodes and re-encapsulating SRv6 headers using dedicated identifiers, the interface limitation problem in SRv6 SFC is solved, enabling more efficient packet forwarding and larger-scale service capabilities.
Patent Information
- Application Number
- CN202411389363.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-30
- Publication Date
- 2025-10-28
- Estimated Expiration
- 2044-09-30
AI Technical Summary
In SRv6 SFC, the SFF node needs to configure an independent interface for each SFC service instance, resulting in a limited number of interfaces, which restricts the scale of SFC services, and the implementation and maintenance of the packet forwarding scheme are highly complex.
SFF nodes pre-store SFC entries, determine the original identifier and SRH information through the special identifier of IPv6 packets, re-encapsulate the SRv6 header, and realize packet forwarding, avoiding the need to configure an independent interface for each service instance.
This reduces the complexity of implementing and maintaining the message forwarding scheme, increases the scale of SFC services, and ensures the accuracy of message forwarding.
Smart Images

Figure CN119341964B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technology, and in particular to a message forwarding method, apparatus, SFF node, and storage medium. Background Technology
[0002] Segment Routing Internet Protocol Version 6 (SRv6) Service Function Chain (SFC) is a technology that guides packets through application layer service devices along a specified path by adding SRv6 path information to the original packets. However, SRv6 SFCs contain application service (SF) nodes that cannot recognize SRv6 packets.
[0003] For this type of SF node, the Service Function Forwarder (SFF) node in the SRv6 SFC needs to decapsulate the SRv6 message to obtain the original message and forward the original message to the SF node; and, according to the corresponding SRv6 path information, encapsulate the original message from the SF node to obtain the SRv6 message and forward the SRv6 message according to the specified path.
[0004] Currently, to ensure that SFF nodes accurately forward raw packets from SF nodes, SRv6 path information needs to be associated with the interfaces on the SFF nodes that connect to the SF nodes. That is, each SFC service instance occupies a separate interface, and different SFC service instances cannot share an interface to ensure that packets are forwarded along the specified path. This solution is relatively complex to implement and maintain. Furthermore, the number of interfaces on an SFF node is limited, which restricts the number of SFC service instances that an SFF node can provide, thus limiting the service scale of SFC. Summary of the Invention
[0005] The purpose of this application is to provide a message forwarding method, apparatus, SFF node, and storage medium to reduce the complexity of message forwarding scheme implementation and maintenance, and improve the service scale of SFC. The specific technical solution is as follows:
[0006] In a first aspect, embodiments of this application provide a message forwarding method applied to an SFF node, the method comprising:
[0007] The first IPv6 packet sent by the SF node is received through the target interface. The header of the first IPv6 packet carries a target-specific identifier.
[0008] Based on the pre-stored SFC table entries, the target original identifier and target SRH information corresponding to the target special identifier are determined. The SFC table entries record the special identifier, the original identifier, and the SRH information.
[0009] The target-specific identifier carried in the header of the first IPv6 packet is modified to the original target identifier to obtain the second IPv6 packet;
[0010] Based on the target SRH information, an SRv6 header is encapsulated in the second IPv6 packet to obtain the first SRv6 packet;
[0011] The first SRv6 message is forwarded according to the SRH information carried in the first SRv6 message.
[0012] In some embodiments, the step of determining the target original identifier and target SRH information corresponding to the target-specific identifier based on pre-stored SFC entries includes: searching for a target SFC entry recording the target-specific identifier from pre-stored SFC entries; obtaining the original identifier from the target SFC entry as the target original identifier corresponding to the target-specific identifier, and obtaining the SRH information from the target SFC entry as the target SRH information corresponding to the target-specific identifier; or,
[0013] The target-specific identifier includes a target service instance identifier, and the SFC entry also records a service instance identifier. The step of determining the target original identifier and target SRH information corresponding to the target-specific identifier based on the pre-stored SFC entries includes: extracting the target service instance identifier from the target-specific identifier; searching for a target SFC entry that records the target service instance identifier from the pre-stored SFC entries; obtaining the original identifier from the target SFC entry as the target original identifier corresponding to the target-specific identifier, and obtaining the SRH information from the target SFC entry as the target SRH information corresponding to the target-specific identifier.
[0014] In some embodiments, the target-specific identifier includes an SFC flag bit;
[0015] Before determining the target original identifier and target SRH information corresponding to the target-specific identifier based on the pre-stored SFC table entries, the method further includes:
[0016] Determine whether the SFC flag bit included in the target dedicated identifier is a first preset value, wherein the first preset value indicates that the first IPv6 packet belongs to an SFC service flow;
[0017] If so, then the step of determining the target original identifier and target SRH information corresponding to the target special identifier based on the pre-stored SFC table entry is executed;
[0018] If not, forward the first IPv6 packet.
[0019] In some embodiments, before determining the target original identifier and target SRH information corresponding to the target-specific identifier based on pre-stored SFC entries, the method further includes:
[0020] Determine whether the target interface has SFC functionality enabled;
[0021] If so, then the step of determining the target original identifier and target SRH information corresponding to the target special identifier based on the pre-stored SFC table entry is executed;
[0022] If not, forward the first IPv6 packet.
[0023] In some embodiments, the method further comprises:
[0024] Receive a second SRv6 message sent by other nodes. The payload of the second SRv6 message is a third IPv6 message, and the destination IP address of the second SRv6 message is the target IP address.
[0025] If the target IP address is a segment identifier (SID) of a preset type, then the target dedicated identifier corresponding to the target IP address is determined according to the pre-stored SFC table entry, and the SFC table entry also records the IP address;
[0026] The target original identifier carried in the header of the third IPv6 packet is modified to the target special identifier to obtain the fourth IPv6 packet;
[0027] The fourth IPv6 message is sent to the SF node so that the SF node can send the first IPv6 message back to the SFF node.
[0028] In some embodiments, the step of determining the target private identifier corresponding to the target IP address based on a pre-stored SFC table entry includes:
[0029] Search for the target SFC entry that records the target IP address from the pre-stored SFC entries;
[0030] If the target SFC entry is found, the special identifier is obtained from the target SFC entry and used as the target special identifier corresponding to the target IP address;
[0031] If the target SFC entry is not found, a target SFC entry is generated, and the special identifier recorded in the target SFC entry is used as the target special identifier corresponding to the target IP address.
[0032] In some embodiments, the step of generating the target SFC table entry includes:
[0033] Extract the target original identifier carried in the header of the third IPv6 packet, and obtain the target SRH information corresponding to the target IP address;
[0034] Determine the target-specific identifier corresponding to the original target identifier;
[0035] A target SFC entry is generated based on the target IP address, the target original identifier, the target special identifier, and the target SRH information.
[0036] In some embodiments, the step of determining the target-specific identifier corresponding to the target original identifier includes:
[0037] Assign a target service instance identifier to the target IP address;
[0038] By combining the first preset value, the second preset value, and the target service instance identifier, a target dedicated identifier is obtained. The first preset value indicates that the first IPv6 packet belongs to the SFC service flow.
[0039] In some embodiments,
[0040] The step of generating a target SFC entry based on the target IP address, the target original identifier, the target special identifier, and the target SRH information includes: recording the correspondence between the target IP address, the target original identifier, the target special identifier, and the target SRH information to obtain the target SFC entry; or,
[0041] The target-specific identifier includes the target service instance identifier; the step of generating a target SFC entry based on the target IP address, the target original identifier, the target-specific identifier, and the target SRH information includes: recording the correspondence between the target IP address, the target original identifier, the target-specific identifier, the target service instance identifier, and the target SRH information to obtain the target SFC entry.
[0042] In some embodiments, the flow label field in the header of the first IPv6 packet carries the target-specific identifier.
[0043] In some embodiments, the target dedicated identifier includes an SFC flag bit, a second preset value, and a target service instance identifier, and the flow tag field includes an SFC flag bit subfield, a reserved bit field, and a service instance identifier subfield;
[0044] The SFC flag bit subfield is used to carry the SFC flag bit;
[0045] The reserved position subfield is the second preset value;
[0046] The service instance identifier subfield is used to carry the identifier of the target service instance.
[0047] Secondly, embodiments of this application provide a message forwarding device applied to an SFF node, the device comprising:
[0048] The first receiving module is used to receive the first IPv6 packet sent by the SF node through the target interface. The header of the first IPv6 packet carries a target-specific identifier.
[0049] The first obtaining module is used to determine the target original identifier and the target segment routing header (SRH) information corresponding to the target dedicated identifier based on the pre-stored SFC table entries. The SFC table entries record the dedicated identifier, the original identifier, and the SRH information.
[0050] The first modification module is used to modify the target special identifier carried in the header of the first IPv6 packet to the target original identifier to obtain the second IPv6 packet;
[0051] An encapsulation module is used to encapsulate an SRv6 header for the second IPv6 packet according to the target SRH information, so as to obtain a first SRv6 packet;
[0052] The forwarding module is used to forward the first SRv6 message according to the SRH information carried in the first SRv6 message.
[0053] In some embodiments, the first obtaining module is specifically configured to: search for a target SFC entry recording the target-specific identifier from a pre-stored SFC entry; obtain the original identifier from the target SFC entry as the target original identifier corresponding to the target-specific identifier, and obtain SRH information from the target SFC entry as the target SRH information corresponding to the target-specific identifier; or,
[0054] The target-specific identifier includes a target service instance identifier, and the SFC entry also records a service instance identifier; the first obtaining module is specifically used for: extracting the target service instance identifier from the target-specific identifier; searching for a target SFC entry that records the target service instance identifier from pre-stored SFC entries; obtaining the original identifier from the target SFC entry as the target original identifier corresponding to the target-specific identifier, and obtaining SRH information from the target SFC entry as the target SRH information corresponding to the target-specific identifier.
[0055] In some embodiments, the target-specific identifier includes an SFC flag bit;
[0056] The first obtaining module is further configured to: before determining the target original identifier and target SRH information corresponding to the target dedicated identifier according to the pre-stored SFC table entry, determine whether the SFC flag bit included in the target dedicated identifier is a first preset value, wherein the first preset value indicates that the first IPv6 packet belongs to an SFC service flow; if yes, then execute the step of determining the target original identifier and target SRH information corresponding to the target dedicated identifier according to the pre-stored SFC table entry; if no, then forward the first IPv6 packet.
[0057] In some embodiments, the first obtaining module is further configured to: determine whether the target interface has SFC functionality enabled before determining the target original identifier and target SRH information corresponding to the target dedicated identifier according to the pre-stored SFC table entry; if yes, then perform the step of determining the target original identifier and target SRH information corresponding to the target dedicated identifier according to the pre-stored SFC table entry; if no, then forward the first IPv6 packet.
[0058] In some embodiments, the apparatus further comprises:
[0059] The second receiving module is used to receive a second SRv6 message sent by other nodes. The payload of the second SRv6 message is a third IPv6 message, and the destination IP address of the second SRv6 message is the target IP address.
[0060] The second obtaining module is used to determine the target private identifier corresponding to the target IP address based on the pre-stored SFC table entry if the target IP address is a segment identifier SID of a preset type. The SFC table entry also records the IP address.
[0061] The second modification module is used to modify the target original identifier carried in the header of the third IPv6 packet to the target special identifier to obtain the fourth IPv6 packet;
[0062] The sending module is used to send the fourth IPv6 packet to the SF node so that the SF node can send the first IPv6 packet back to the SFF node.
[0063] In some embodiments, the second obtaining module is specifically used for:
[0064] Search for the target SFC entry that records the target IP address from the pre-stored SFC entries;
[0065] If the target SFC entry is found, the special identifier is obtained from the target SFC entry and used as the target special identifier corresponding to the target IP address;
[0066] If the target SFC entry is not found, a target SFC entry is generated, and the special identifier recorded in the target SFC entry is used as the target special identifier corresponding to the target IP address.
[0067] In some embodiments, the second obtaining module is specifically used for:
[0068] Extract the target original identifier carried in the header of the third IPv6 packet, and obtain the target SRH information corresponding to the target IP address;
[0069] Determine the target-specific identifier corresponding to the original target identifier;
[0070] A target SFC entry is generated based on the target IP address, the target original identifier, the target special identifier, and the target SRH information.
[0071] In some embodiments, the second obtaining module is specifically used for:
[0072] Assign a target service instance identifier to the target IP address;
[0073] By combining the first preset value, the second preset value, and the target service instance identifier, a target dedicated identifier is obtained. The first preset value indicates that the first IPv6 packet belongs to the SFC service flow.
[0074] In some embodiments, the second obtaining module is specifically used to: record the correspondence between the target IP address, the target original identifier, the target special identifier, and the target SRH information to obtain a target SFC entry; or,
[0075] The target-specific identifier includes the target service instance identifier; the second obtaining module is specifically used to: record the correspondence between the target IP address, the target original identifier, the target-specific identifier, the target service instance identifier and the target SRH information, and obtain the target SFC entry.
[0076] In some embodiments, the flow label field in the header of the first IPv6 packet carries the target-specific identifier.
[0077] In some embodiments, the target dedicated identifier includes an SFC flag bit, a second preset value, and a target service instance identifier, and the flow tag field includes an SFC flag bit subfield, a reserved bit field, and a service instance identifier subfield;
[0078] The SFC flag bit subfield is used to carry the SFC flag bit;
[0079] The reserved position subfield is the second preset value;
[0080] The service instance identifier subfield is used to carry the identifier of the target service instance.
[0081] Thirdly, embodiments of this application provide an SFF node, including a processor and a machine-readable storage medium, the machine-readable storage medium storing machine-executable instructions that can be executed by the processor, the processor being prompted by the machine-executable instructions to implement any of the methods described in the first aspect above.
[0082] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the methods described in the first aspect above.
[0083] Fifthly, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the computer to perform any of the methods described in the first aspect of the above embodiments.
[0084] Beneficial effects of the embodiments in this application:
[0085] In the technical solution provided in this application embodiment, the SFF node pre-stores SFC entries recording the original identifier and SRH information. After receiving an IPv6 packet sent by the SF node, the SFF node determines the original identifier and SRH information corresponding to the IPv6 packet based on the special identifier carried in the packet header. It then modifies the special identifier in the packet header back to the original identifier and re-encapsulates the SRv6 header according to the SRH information to obtain the SRv6 packet. Subsequently, the SFF node can forward the obtained SRv6 packet based on the SRH information. Applying the technical solution provided in this application embodiment, the SFF node does not need to configure an independent interface for each SFC service instance. Instead, it determines the corresponding SRH and SRv6 path information by carrying a special identifier, performs re-encapsulation and forwarding, reduces the complexity of packet forwarding implementation and maintenance, and ensures the accuracy of packet forwarding. Simultaneously, the number of SFC service instances that the SFF node can provide is not limited by the number of interfaces on the SFF node, increasing the service scale of SFC.
[0086] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description
[0087] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.
[0088] Figure 1 This is a schematic diagram of a first type of message forwarding method provided in an embodiment of this application;
[0089] Figure 2 A schematic diagram of the IPv6 standard header;
[0090] Figure 3 A schematic diagram of a stream label field provided in an embodiment of this application;
[0091] Figure 4 A schematic diagram of an SFC entry provided in an embodiment of this application;
[0092] Figure 5 This is a second flowchart illustrating the message forwarding method provided in the embodiments of this application;
[0093] Figure 6 A schematic diagram of the third type of message forwarding method provided in the embodiments of this application;
[0094] Figure 7A schematic diagram of the fourth type of message forwarding method provided in the embodiments of this application;
[0095] Figure 8 A fifth flowchart illustrating the message forwarding method provided in this application embodiment;
[0096] Figure 9 A sixth flowchart illustrating the message forwarding method provided in this application embodiment;
[0097] Figure 10 A schematic diagram of message forwarding provided in an embodiment of this application;
[0098] Figure 11 This is a schematic diagram of a first structure of a message forwarding device provided in an embodiment of this application;
[0099] Figure 12 This is a second structural schematic diagram of the message forwarding device provided in the embodiments of this application;
[0100] Figure 13 This is a schematic diagram of an SFF node provided in an embodiment of this application. Detailed Implementation
[0101] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.
[0102] The relevant concepts involved in the embodiments of this application are explained below.
[0103] Segment Routing (SR): Employs a source node path selection mechanism. The source node pre-encapsulates the segment identifier (SID) of the segment the path will pass through. When a packet passes through an SR node, the SR node forwards the packet based on the packet's SID.
[0104] SRv6: In Internet Protocol Version 6 (IPv6) networks, SR nodes are used to forward packets using IPv6 addresses as SIDs.
[0105] SRH: A route extension header with a route type value of 4. The source node adds an SRH to the IPv6 packet, and intermediate nodes can forward the packet according to the path information contained in the SRH.
[0106] SRv6 SFC: A technology that guides packets through application layer service devices sequentially along a specified path by adding SRv6 path information to the original packets.
[0107] Service Classifier (SC) node: Located at the edge of the SRv6 SFC network, it is the origin node of the service chain path. SC can use different traffic redirection methods to introduce service data packets into the SRv6 Traffic Engineering Policy (TE) policy tunnel for forwarding.
[0108] SF Node: A node that provides specific application services for service traffic (i.e., service data packets). SF nodes that cannot recognize SRv6 packets are called unrecognizable SRv6 (SRv6-unaware) SF nodes, while SF nodes that can recognize SRv6 packets are called recognizable SRv6 (SRv6-aware) SF nodes.
[0109] SFF Node: Acting as a service chain proxy for SF Nodes, it forwards received packets to several SF Nodes associated with the SFF Node based on SRv6 encapsulation information. After processing the packet, the SF Node returns the packet to the SFF Node, which then decides whether to continue forwarding the packet.
[0110] Virtual Local Area Network (VLAN): A VLAN divides a physical Local Area Network (LAN) into multiple logical LANs. Hosts in the same VLAN (such as SFF nodes and SF nodes mentioned above) can communicate directly, while hosts in different VLANs cannot communicate directly, thus enhancing LAN security. After VLAN segmentation, broadcast packets are restricted to the same VLAN; each VLAN is a broadcast domain, effectively limiting the scope of the broadcast domain. VLANs can also group different hosts into different workgroups, and hosts in the same workgroup can be located in different physical locations, making network construction and maintenance more convenient and flexible.
[0111] Currently, to meet users' needs for security and stability, data packets often need to pass through various service nodes sequentially according to business logic when transmitted in the network, such as firewalls, intrusion prevention systems, application accelerators, and network address translation. SRv6 SFC technology can easily meet these requirements. However, there are SF nodes in SRv6 SFC that cannot recognize SRv6 packets.
[0112] For these types of SF nodes, the SFF node needs to decapsulate the SRv6 packets to obtain the original packets and forward them to the SF node; and, according to the corresponding SRv6 path information, encapsulate the original packets from the SF node to obtain SRv6 packets and forward them according to the specified path. In SRv6 SFC, different SRv6 path information and VLANs correspond to different SFC service instances (SFC Instances).
[0113] To ensure that the SFF node accurately forwards the original packets from the SF node, the SRv6 path information needs to be associated with the interface on the SFF node that connects to the SF node. That is, one SFC service instance occupies an independent interface, and different SFC service instances cannot share an interface, so as to ensure that the packets are forwarded along the specified path.
[0114] In existing solutions, the proxy modes of SFF nodes can be divided into service chain static proxy mode (Static SRProxy SFC) and service chain dynamic proxy mode (Dynamic SR Proxy SFC). For ease of description, the service chain static proxy mode will be referred to as static proxy mode, and the service chain dynamic proxy mode will be referred to as dynamic proxy mode.
[0115] In static proxy mode, the SFF node receives SRv6 packets sent by other nodes, decapsulates the SRv6 packets to obtain the service chain static proxy (End.AS) SID representing the SF node in the SRv6 SFC, and maps the End.AS to the SFC service instance. Through the outgoing interface associated with the SFC service instance, it forwards the original packet to the SF node. After receiving the original packet from the SF node, the SFF node determines whether to continue forwarding the packet in the SRv6 SFC network. If it continues to forward the packet in the SRv6 SFC network, the SFF node needs to recapsulate the processed original packet from the SF node according to the ingoing interface or the ingoing interface and VLAN associated with the SFC service instance, and according to the manually configured SID list (i.e., SRv6 path information) corresponding to the SFC service instance.
[0116] In dynamic proxy mode, SFF nodes can dynamically learn the SID list from SRv6 packets without manual configuration. When an SFF node receives SRv6 packets from other nodes, it decapsulates the packets to obtain the Service Chain Dynamic Proxy (End.AD) SID representing the SF node in the SRv6 SFC. Based on the End.AD SID, it maps the SFC service instance and forwards the original packet to the SF node through the outgoing interface associated with that SFC service instance. Upon receiving the original packet from the SF node, if the SFF node decides to continue forwarding packets in the SRv6 SFC network, it needs to recapsulate the processed original packet from the SF node according to the incoming interface or the VLAN associated with the incoming interface, which corresponds to the SFC service instance.
[0117] In both of these modes, since the original packets no longer carry any SFC-related information when forwarded from the SF node to the SFF node, it is necessary to associate each SFC service instance with an interface on the SFF node. When a user needs to purchase, cancel, or change an SFC service, the interface configuration on the SFF node may need to be modified. This poses significant challenges to the manual configuration of SFCs, orchestrators, and controllers, as well as the implementation and maintenance of SFCs. For example, the design of orchestrators and controllers must consider the relationship between interfaces, interface addresses, VLANs, and SFCs, making the implementation and maintenance of the solution quite complex. Furthermore, the number of interfaces on an SFF node is limited, which means that the number of SFC service instances that an SFF node can provide is limited by the number of interfaces on the SFF node, thus limiting the service scale of SFCs.
[0118] To reduce the complexity of implementing and maintaining message forwarding schemes and improve the service scale of SFC, this application provides a message forwarding method applied to SFF nodes, where the SFF nodes are connected to one or more SF nodes that cannot recognize SRv6 messages. See also... Figure 1 , Figure 1 This is a schematic flowchart of a first message forwarding method provided in an embodiment of this application. The message forwarding method includes the following steps.
[0119] Step S11: Receive the first IPv6 packet sent by the SF node through the target interface. The header of the first IPv6 packet carries a target-specific identifier.
[0120] Step S12: Based on the pre-stored SFC table entries, determine the target original identifier and target SRH information corresponding to the target special identifier. The SFC table entries record the special identifier, the original identifier, and the SRH information.
[0121] Step S13: Modify the target-specific identifier carried in the header of the first IPv6 packet to the original target identifier to obtain the second IPv6 packet.
[0122] Step S14: Based on the target SRH information, encapsulate the second IPv6 packet with an SRv6 header to obtain the first SRv6 packet.
[0123] Step S15: Forward the first SRv6 message according to the SRH information carried in the first SRv6 message.
[0124] In the technical solution provided in this application embodiment, the SFF node pre-stores SFC entries recording the original identifier and SRH information. After receiving an IPv6 packet sent by the SF node, the SFF node determines the original identifier and SRH information corresponding to the IPv6 packet based on the special identifier carried in the packet header. It then modifies the special identifier in the packet header back to the original identifier and re-encapsulates the SRv6 header according to the SRH information to obtain the SRv6 packet. Subsequently, the SFF node can forward the obtained SRv6 packet based on the SRH information. Applying the technical solution provided in this application embodiment, the SFF node does not need to configure an independent interface for each SFC service instance. Instead, it determines the corresponding SRH and SRv6 path information by carrying a special identifier, performs re-encapsulation and forwarding, reduces the complexity of packet forwarding implementation and maintenance, and ensures the accuracy of packet forwarding. Simultaneously, the number of SFC service instances that the SFF node can provide is not limited by the number of interfaces on the SFF node, increasing the service scale of SFC.
[0125] In step S11 above, the target interface is any interface on the SFF node; the first IPv6 packet is any IPv6 packet sent from any SF node connected to the SFF node to the SFF node; the target special identifier is a special identifier carried in the header of the first IPv6 packet, which is used to indicate the SFC service instance to which the first IPv6 packet belongs.
[0126] An SFF node can receive an IPv6 packet sent by any SF node through the target interface and use that IPv6 packet as the first IPv6 packet.
[0127] In this embodiment of the application, the header of the IPv6 packet received by the SFF node is the standard IPv6 header, such as... Figure 2The IPv6 standard header shown includes: Version (Ver) field, Traffic Class field, Flow Label field, Payload Length field, Next Header field, Hop Limit field, Source Address (SA) field, and Destination Address (DA) field. The numbers 0, 11, and 31 above the header indicate bit positions.
[0128] The special identifier can be carried in a predefined field in the header of an IPv6 packet that does not affect the SF node's processing and forwarding of the packet. For example, the predefined field can be the flow label field, meaning the flow label field carries the special identifier, and the length of the special identifier is the same as the length of the flow label field, which is 20 bits. In this case, the flow label field in the header of the first IPv6 packet carries the target special identifier. After receiving the first IPv6 packet, the SFF node can extract the content of the flow label field to obtain the target special identifier.
[0129] Other fields in the IPv6 packet header can also carry a special identifier. For example, these fields could be a traffic class field or a next header field. Correspondingly, the length of the special identifier is the same as the length of the other field; for example, the special identifier could be 8 bits long. In this case, the other fields in the header of the first IPv6 packet (such as the traffic class field or the next header field) carry the target special identifier. After receiving the first IPv6 packet, the SFF node can extract the content of these other fields to obtain the target special identifier. For ease of description, the flow label field will be used to carry the special identifier thereafter, and this does not imply any limitation.
[0130] In this embodiment, the dedicated identifier may include an SFC flag bit, a second preset value, and a service instance identifier. The SFC flag bit indicates whether the IPv6 packet belongs to an SFC service flow. When the SFC flag bit is the first preset value, it indicates that the IPv6 packet belongs to an SFC service flow, and the SFF node enters the SFC processing flow to process the IPv6 packet. When the SFC flag bit is not the first preset value, it indicates that the IPv6 packet does not belong to an SFC service flow, and the SFF node forwards the IPv6 packet normally. The second preset value is a reserved bit value. The service instance identifier is the identifier of the SFC service instance to which the IPv6 packet belongs.
[0131] When using a flow label field to carry a dedicated identifier, the flow label field can include an SFC flag subfield, a reserved slot field, and a service instance identifier subfield, such as... Figure 3The stream label field shown has numbers 0, 1, 3, and 19 above the header indicating bit positions.
[0132] The SFC flag (S) subfield is used to carry the SFC flag bits included in the special identifier. It can be 2 bits long and is located in bits 0 and 1. The first preset value can be 11, or other values, which are not limited.
[0133] The Reserved (R) subfield is the second preset value, a field that can be used by other extended functions. It can be 2 bits long and is located in the 2nd and 3rd positions. The second preset value can be 00 or other values; there are no restrictions on this.
[0134] The Service Instance Identifier (IDentity, ID) subfield is used to carry the service instance identifier, which is a dedicated identifier. It can be 16 bits long and has a value range of 0 to 65535, located in the 4th to 19th positions.
[0135] The length of each subfield and its position in the flow tag field are not limited here.
[0136] In this embodiment of the application, when the dedicated identifier includes the SFC flag bit, the second preset value, and the service instance identifier, the target dedicated identifier obtained by the SFF node may include the SFC flag bit, the second preset value, and the target service instance identifier. The SFC flag bit is used to indicate whether the first IPv6 packet belongs to the SFC service flow, and the target service instance identifier is the identifier of the SFC service instance to which the first IPv6 packet belongs. The positions of the SFC flag bit, the second preset value, and the target service instance identifier in the target dedicated identifier are the same as the positions of the corresponding subfields in the flow label field.
[0137] In the Flow Label field of the header of the first IPv6 packet, the SFC flag subfield is used to carry the SFC flag bit included in the Target Specific Identifier, and the Service Instance Identifier subfield is used to carry the target service instance identifier included in the Target Specific Identifier. After receiving the first IPv6 packet, the SFF node can extract the content of the SFC flag subfield to obtain the SFC flag bit, and extract the content of the Service Instance Identifier subfield to obtain the target service instance identifier.
[0138] In step S12 above, SFF nodes pre-store SFC entries. Each SFC entry corresponds to an SFC service instance processed by the SFF node. Each SFC entry records the dedicated identifier, original identifier, and SRH information of the corresponding SFC service instance, indicating the correspondence between the dedicated identifier, original identifier, and SRH information of the SFC service instance.
[0139] The original identifier is the original content of the corresponding dedicated identifier in the IPv6 packet. That is, it's the original content carried by the preset fields (such as the flow label field) that carry the corresponding dedicated identifier, with the same length as the dedicated identifier. For example, the original identifier can also be 20 bits long. The SRH information is the SRv6 path information of the corresponding SFC service instance. The SRH information includes a list of SIDs. This SID list can be a manually configured SID list in static proxy mode, or it can be a SID list obtained from the SRv6 packet corresponding to the first IPv6 packet (such as the second SRv6 packet) in dynamic proxy mode; there is no limitation on this. The second SRv6 packet is a packet sent by other nodes to the SFF node that needs to be processed by the SF node. The process of the SFF node processing the second SRv6 packet will be described in detail later, and will not be elaborated here. The SRH information may also include other fields from the SRH, such as the Segments Left (SL) and Routing Type. The method for obtaining these other fields is the same as the method for obtaining the SID list mentioned above, and there is no limitation on this.
[0140] In this embodiment, the SFC entry may also record a service instance identifier and / or IP address. The service instance identifier is the identifier of the corresponding SFC service instance. The IP address is the destination IP address of the SFF node receiving the second SRv6 message sent by other nodes. The IP address is a SID of a preset type, which can be the End.AS SID or End.AD SID representing the SF node. Other nodes can be other SFF nodes, SC nodes, endpoints, or other switching devices, etc., and are not limited thereto.
[0141] like Figure 4 The SFC entry shown is illustrated using an example where the SFC entry records an IP address, service instance identifier, SRH information, original identifier, and special identifier. The SFC entry includes: End.ASSID / End.AD SID (i.e., the IP address of the SFC service instance), service instance identifier (i.e., the identifier of the SFC service instance), SRH (i.e., the SRH information of the SFC service instance), Original Flow Label (i.e., the original identifier of the SFC service instance), and SFC Exclusive Flow Label (i.e., the special identifier of the SFC service instance). The SRH may include a Segments Left (SL) index and a list of SIDs. In this embodiment, the lengths of the IP address, service instance identifier, SRH information, original identifier, and special identifier recorded in the SFC entry may be different. Figure 4 The examples provided are merely illustrative and do not constitute a limitation.
[0142] In this embodiment, after obtaining the target dedicated identifier, the SFF node determines the SFC service instance represented by the target dedicated identifier (such as the target SFC service instance) according to the pre-stored SFC table entry. The target SFC service instance is the SFC service instance to which the first IPv6 packet belongs. Then, the SFF node determines the original identifier and SRH information corresponding to the target SFC service instance. The original identifier is the target original identifier corresponding to the target dedicated identifier, and the SRH information is the target SRH information corresponding to the target dedicated identifier.
[0143] In this embodiment of the application, the SFF node may be unable to determine the target SFC service instance, that is, it may be unable to determine the target original identifier and the target SRH information. If the SFF node determines that the first IPv6 packet does not need to be forwarded in the SRv6 SFC network, it can forward the first IPv6 packet normally according to the packet header of the first IPv6 packet.
[0144] In step S13 above, after obtaining the target original identifier, the SFF node modifies the target dedicated identifier carried in the header of the first IPv6 packet to the target original identifier. That is, it modifies the content of the preset field in the header of the first IPv6 packet to the target original identifier, and obtains the modified IPv6 packet. This modified IPv6 packet is the second IPv6 packet.
[0145] In step S14 above, after obtaining the target SRH information, the SFF node decrements the SL value recorded in the target SRH information by 1 to obtain the processed target SRH information, that is, the processed target SRH. The SFF node constructs an SRv6 header including an IPv6 header and the processed target SRH. The IPv6 header is the same as the header of the second IPv6 packet, and the destination IP address of the IPv6 header is the IP address of the next node after the SF node in the SID list. The SFF node encapsulates the SRv6 packet header in the second IPv6 packet to re-encapsulate the SRv6 path information of the corresponding SFC service instance in the second IPv6 packet, obtaining the encapsulated SRv6 packet, which is the first SRv6 packet.
[0146] In step S15 above, the SFF node forwards the first SRv6 message according to the SRH information carried in the first SRv6 message, that is, according to the SRv6 path information of the corresponding SFC service instance.
[0147] In some embodiments, the SFF node can implement step S12 in the following two ways.
[0148] Method 1: The SFF node can directly match the target-specific identifier in the SFC table entry to obtain the target original identifier and target SRH information. Step S12 above can be implemented through the following steps: Search for the target SFC table entry recording the target-specific identifier from the pre-stored SFC table entries; obtain the original identifier from the target SFC table entry as the target original identifier corresponding to the target-specific identifier; and obtain the SRH information from the target SFC table entry as the target SRH information corresponding to the target-specific identifier.
[0149] In this embodiment, after the SFF node extracts the target special identifier from the first IPv6 packet, it searches for the target special identifier in the special identifiers recorded in the pre-stored SFC table entries. The SFC table entry that records the target special identifier is the target SFC table entry. By searching the target SFC table entry, the SFF node determines whether the target special identifier is the same as the special identifier recorded in the pre-stored SFC table entries, and thus determines whether the target special identifier is pre-stored in the SFF node.
[0150] When the target dedicated identifier includes the target service instance identifier, the SFF node searches for the dedicated identifier that includes the target service instance identifier in the dedicated identifier records of the pre-stored SFC table entries. For example, the SFF node can search for the dedicated identifier where bits 4 to 19 are the target service instance identifier. When the target dedicated identifier includes both the SFC flag bit and the target service instance identifier, the SFF node searches for the dedicated identifier that includes both the SFC flag bit and the target service instance identifier in the dedicated identifier records of the pre-stored SFC table entries. For example, the SFF node can search for the dedicated identifier where bits 0 to 1 are the SFC flag bit and bits 4 to 19 are the target service instance identifier.
[0151] In this embodiment of the application, during the process of finding the target dedicated identifier and determining the target SFC table entry, the reserved bits may not be matched, and only the SFC flag bit and the target service instance identifier may be matched.
[0152] If a target SFC entry is found, the SFF node determines that the target's unique identifier is the same as the unique identifier of the pre-stored SFC entry record. It then retrieves the original identifier of the record from the target SFC entry as the target's original identifier and retrieves the SRH information recorded in the target SFC entry as the target's SRH information.
[0153] If the target SFC entry is not found, the SFF node determines that the target special identifier is different from the special identifier recorded in the pre-stored SFC entry. The first IPv6 packet does not need to be forwarded in the SRv6 SFC network. The SFF node can then forward the first IPv6 packet normally according to the packet header.
[0154] Method 2: When the target-specific identifier includes the target service instance identifier, and the SFC entry also records the service instance identifier, the SFF node can also match the target service instance identifier in the SFC entry to obtain the target original identifier and target SRH information. Step S12 above can be implemented through the following steps: extract the target service instance identifier from the target-specific identifier; search for the target SFC entry recording the target service instance identifier from the pre-stored SFC entries; obtain the original identifier from the target SFC entry as the target original identifier corresponding to the target-specific identifier, and obtain the SRH information from the target SFC entry as the target SRH information corresponding to the target-specific identifier.
[0155] In this embodiment of the application, the SFC table entries pre-stored in the SFF node also record the service instance identifier. That is, each SFC table entry pre-stored in the SFF node records the service instance identifier, special identifier, original identifier and SRH information of the corresponding SFC service instance, indicating the correspondence between the service instance identifier, special identifier, original identifier and SRH information of the SFC service instance.
[0156] The SFF node extracts the value of the service instance identifier in the target special identifier, such as extracting the value of the 4th to 19th positions of the target special identifier to obtain the target service instance identifier included in the target special identifier.
[0157] The SFF node searches for the target service instance identifier in the service instance identifiers recorded in the pre-stored SFC table entries. The SFC table entry that records the target service instance identifier is the target SFC table entry. By searching the target SFC table entry, the SFF node determines whether the target service instance identifier is the same as the service instance identifier recorded in the pre-stored SFC table entries, and thus determines whether the target service instance identifier is pre-stored in the SFF node.
[0158] If a target SFC table entry is found, the SFF node determines that the target service instance identifier is the same as the service instance identifier recorded in the pre-stored SFC table entry. It then retrieves the original identifier of the record from the target SFC table entry as the target original identifier and retrieves the SRH information recorded in the target SFC table entry as the target SRH information.
[0159] If the target SFC entry is not found, the SFF node determines that the target service instance identifier is different from the service instance identifier recorded in the pre-stored SFC entry. The first IPv6 packet does not need to be forwarded in the SRv6 SFC network. The SFF node can then forward the first IPv6 packet normally according to the packet header.
[0160] In this embodiment of the application, when the target-specific identifier includes the target service instance identifier and the SFC table entry also records the service instance identifier, the SFF node can also use the above method 1 to obtain the target original identifier and target SRH information. For details, please refer to the relevant description of the above method 1, and there is no limitation on it.
[0161] In some embodiments, where the target-specific identifier includes the SFC flag, the SFF node can process the first IPv6 packet based on the SFC flag. See also Figure 5 , Figure 5 This is a second flowchart illustrating the message forwarding method provided in this application embodiment. The message forwarding method may further include the following steps.
[0162] Step S51: Receive the first IPv6 packet sent by the SF node through the target interface. The header of the first IPv6 packet carries a target-specific identifier. This is the same as step S11 above.
[0163] Step S52: Determine whether the SFC flag bit included in the target dedicated identifier is a first preset value. The first preset value indicates that the first IPv6 packet belongs to an SFC service flow. If yes, proceed to step S53; otherwise, proceed to step S57.
[0164] Step S53: Based on the pre-stored SFC table entries, determine the target original identifier and target SRH information corresponding to the target special identifier. The SFC table entries record the special identifier, original identifier, and SRH information. This is the same as step S12 above.
[0165] Step S54: Modify the target-specific identifier carried in the header of the first IPv6 packet to the original target identifier to obtain the second IPv6 packet. This is the same as step S13 above.
[0166] Step S55: Based on the target SRH information, encapsulate the second IPv6 packet with an SRv6 header to obtain the first SRv6 packet. This is the same as step S14 above.
[0167] Step S56: Forward the first SRv6 message according to the SRH information carried in the first SRv6 message. This is the same as step S15 above.
[0168] Step S57: Forward the first IPv6 packet.
[0169] In the technical solution provided in this application embodiment, the SFF node first determines whether the first IPv6 packet belongs to the SFC service flow based on the SFC flag bit included in the target dedicated identifier. If it is determined that the first IPv6 packet belongs to the SFC service flow, subsequent processing is performed to improve packet processing and forwarding efficiency.
[0170] In step S53 above, the SFF node extracts the SFC flag bit from the target-specific identifier, that is, extracts the value of the position of the SFC flag bit in the target-specific identifier, such as extracting the value of the 0th to 1st bit of the target-specific identifier, to obtain the SFC flag bit included in the target-specific identifier.
[0171] The SFF node determines whether the SFC flag is at the first preset value in order to determine whether the first IPv6 packet belongs to the SFC service flow.
[0172] If the SFC flag is set to the first preset value, the SFF node determines that the first IPv6 packet belongs to the SFC service flow, and the SFF node can execute steps S53 to S56 for subsequent processing and forwarding.
[0173] If the SFC flag is not the first preset value, the SFF node determines that the first IPv6 packet does not belong to the SFC service flow, and the first IPv6 packet does not need to be forwarded in the SRv6 SFC network. The SFF node can execute step S57 and forward the first IPv6 packet normally according to the packet header of the first IPv6 packet.
[0174] In some embodiments, the SFF node can process the first IPv6 packet based on whether the target interface receiving the first IPv6 packet has SFC functionality enabled. See also Figure 6 , Figure 6 This is a schematic diagram of a third message forwarding method provided in an embodiment of this application. The message forwarding method described above may further include the following steps.
[0175] Step S61: Receive the first IPv6 packet sent by the SF node through the target interface. The header of the first IPv6 packet carries a target-specific identifier. This is the same as step S11 above.
[0176] Step S62: Determine whether the target interface has SFC functionality enabled. If yes, proceed to step S63; otherwise, proceed to step S67.
[0177] Step S63: Based on the pre-stored SFC table entries, determine the target original identifier and target SRH information corresponding to the target special identifier. The SFC table entries record the special identifier, original identifier, and SRH information. This is the same as step S12 above.
[0178] Step S64: Modify the target-specific identifier carried in the header of the first IPv6 packet to the original target identifier to obtain the second IPv6 packet. This is the same as step S13 above.
[0179] Step S65: Based on the target SRH information, encapsulate the second IPv6 packet with an SRv6 header to obtain the first SRv6 packet. This is the same as step S14 above.
[0180] Step S66: Forward the first SRv6 message according to the SRH information carried in the first SRv6 message. This is the same as step S15 above.
[0181] Step S67: Forward the first IPv6 packet.
[0182] In the technical solution provided in this application embodiment, the SFF node first determines whether the target interface has the SFC function enabled. If the target interface has the SFC function enabled, subsequent processing is then performed to improve packet processing and forwarding efficiency.
[0183] In step S62 above, the SFF node determines whether the target interface has the SFC function enabled. If the target interface has the SFC function enabled, the SFF node can execute steps S63 to S66 for subsequent processing and forwarding.
[0184] If the target interface does not have the SFC function enabled, the SFF node determines that the first IPv6 packet does not need to be forwarded in the SRv6 SFC network. The SFF node can then execute step S67 to forward the first IPv6 packet normally according to its header.
[0185] See Figure 7 , Figure 7 This is a fourth flowchart illustrating the message forwarding method provided in this application embodiment. The message forwarding method may further include the following steps.
[0186] Step S71: Received IPv6 packet.
[0187] In this embodiment of the application, the SFF node receives the IPv6 packet sent by the SF node (i.e., the first IPv6 packet mentioned above).
[0188] Step S72: Determine whether the interface enables the SFC function.
[0189] In this embodiment, the SFF node determines whether the interface receiving the IPv6 packet (i.e., the target interface mentioned above) has the SFC function enabled. If yes, step S73 is executed; otherwise, step S78 is executed.
[0190] Step S73: Check the Flow Label field in the IPv6 header.
[0191] In this embodiment of the application, the IPv6 standard header is the header of the received IPv6 packet. The SFF node obtains the value of the flow label field in the header of the IPv6 packet, and the obtained value of the flow label field is the aforementioned target-specific identifier.
[0192] Step S74: Determine whether the value of the lower 2 bits in the stream label field is a preset value.
[0193] In this embodiment, the SFF node determines whether the value of the 0th to 1st bits in the flow tag field is a preset value (i.e., the first preset value), that is, whether the value of the 0th to 1st bits of the target special identifier is the preset value 11. If yes, then step S75 is executed; otherwise, step S78 is executed.
[0194] Step S75: Retrieve the SFC index of the 4th to 19th positions of the stream label field.
[0195] In this embodiment of the application, the SFF node extracts the 4th to 19th bits of the flow tag field as the SFC index, which is the target service instance identifier. Step S75 is that the SFF node extracts the target service instance identifier from the target dedicated identifier.
[0196] Step S76: Determine whether the SFC index is the same as the locally configured SFC instance identifier.
[0197] In this embodiment, the locally configured SFC instance identifier is the service instance identifier recorded in the pre-stored SFC table entry in the SFF node. Step S75 is that the SFF node determines whether the target service instance identifier is the same as the service instance identifier recorded in the pre-stored SFC table entry. If yes, then step S77 is executed; otherwise, step S78 is executed.
[0198] Step S77: Replace the value of the flow label field with the original flow label value recorded in the SFC table entry corresponding to the SFC instance identifier, and re-encapsulate the SRv6 packet according to the SRH including the SID list configured in static proxy mode, or the SRH including the SID list obtained in dynamic proxy mode. The SL value in the SRH is the recorded SL value minus 1.
[0199] In this embodiment, the SFF node replaces the value in the flow label field of the IPv6 packet with the original flow label value (i.e., the target original identifier) recorded in the SFC table entry (i.e., the target SFC table entry) corresponding to the SFC instance identifier with the same SFC index. That is, the target-specific identifier is modified to the target original identifier. The SFF node obtains the SRH (i.e., the target SRH information) recorded in the SFC table entry corresponding to the SFC instance identifier with the same SFC index. In static proxy mode, this SRH includes a manually configured SID list; in dynamic proxy mode, this SRH includes a directly obtained SID list. The SFF node decrements the SL value in the SRH by 1 and re-encapsulates the processed SRH to obtain the SRv6 packet.
[0200] Step S78: Forward the received IPv6 packets as ordinary IPv6 packets.
[0201] In this embodiment of the application, the SFF node forwards the first IPv6 packet normally according to the IPv6 standard header of the IPv6 packet.
[0202] For details of steps S71 to S78 above, please refer to the above. Figures 1 to 6 Related descriptions.
[0203] Applying the technical solution provided in this application, the SFF node first determines whether the target interface has SFC functionality enabled. If the target interface has SFC functionality enabled, the flow label field is checked, and the SFC flag is used to determine whether the IPv6 packet belongs to an SFC service flow. If the IPv6 packet belongs to an SFC service flow, the SFC index and corresponding SRH are looked up, and the IPv6 packet is re-encapsulated with an SRv6 header. The SFF node does not need to configure a separate interface for each SFC service instance, reducing the complexity of packet forwarding implementation and maintenance, ensuring packet forwarding accuracy, and the number of SFC service instances that the SFF node can provide is not limited by the number of interfaces on the SFF node, increasing the service scale of SFC and improving packet processing and forwarding efficiency.
[0204] In some embodiments, the SFF node can send IPv6 packets to the SF node, see [link to documentation]. Figure 8 , Figure 8 This is a fifth flowchart illustrating the message forwarding method provided in this application embodiment. The above message forwarding method may further include the following steps.
[0205] Step S81: Receive a second SRv6 message sent by other nodes. The payload of the second SRv6 message is a third IPv6 message, and the destination IP address of the second SRv6 message is the target IP address.
[0206] Step S82: Determine whether the target IP address is a SID of a preset type. If yes, proceed to step S83; otherwise, proceed to step S86.
[0207] Step S83: Determine the target private identifier corresponding to the target IP address based on the pre-stored SFC table entry. The SFC table entry also records the IP address.
[0208] Step S84: Modify the original target identifier carried in the header of the third IPv6 packet to the target-specific identifier to obtain the fourth IPv6 packet.
[0209] Step S85: Send the fourth IPv6 message to the SF node so that the SF node can send the first IPv6 message back to the SFF node.
[0210] Step S86: Forward the second SRv6 message.
[0211] In the technical solution provided in this application, after receiving SRv6 packets sent by other nodes, the SFF node determines a special identifier based on the destination IP address of the SRv6 packet. The determined special identifier corresponds to the original identifier carried in the header of the SRv6 packet payload (i.e., the IPv6 packet) and the SRH information of the SRv6 packet. The SFF node sends the IPv6 packet carrying the special identifier to the SF node, so that the IPv6 packet returned by the SF node also carries the special identifier. Thus, the SFF node can determine the corresponding original identifier and SRH information through the special identifier. Applying the technical solution provided in this application, the SFF node does not need to configure an independent interface for each SFC service instance. Instead, it determines the SRH and SRv6 path information by carrying the corresponding special identifier, and then re-encapsulates and forwards the packet, reducing the complexity of packet forwarding implementation and maintenance, and ensuring the accuracy of packet forwarding. At the same time, the number of SFC service instances that the SFF node can provide is not limited by the number of interfaces on the SFF node, increasing the service scale of SFC.
[0212] In step S81 above, the second SRv6 message is any SRv6 message sent by any other node to the SFF node. For a detailed description of the other nodes, please refer to the section of step S12 above.
[0213] The SFF node receives any SRv6 message sent by any other node and treats it as the second SRv6 message. The SFF node decapsulates the second SRv6 message and parses its destination IP address. That is, it extracts the destination IP address from the destination address field in the header of the second SRv6 message, and this destination IP address is the target IP address.
[0214] In step S82 above, the SFF node determines whether the target IP address is a SID of a preset type, in order to determine whether the second SRv6 packet needs to be processed and forwarded to the SF node. For a detailed description of the preset type of SID, please refer to step S12 above.
[0215] If the SFF node determines that the target IP address is a SID of the preset type, it means that the SFF node needs to process the second SRv6 packet, and the SFF node executes step S83.
[0216] If the SFF node determines that the target IP address is not a SID of the preset type, it means that the SFF node does not need to process the second SRv6 packet and forward it to the SF node. The SFF node executes step S86 and forwards the second SRv6 packet directly according to the SRH information carried in the second SRv6 packet.
[0217] In step S83 above, the SFC table entries pre-stored in the SFF node also record the IP address of the corresponding SFC service instance. That is, each SFC table entry pre-stored in the SFF node records the IP address, special identifier, original identifier, and SRH information of the corresponding SFC service instance, indicating the correspondence between the IP address, special identifier, original identifier, and SRH information of the SFC service instance.
[0218] The SFF node determines the SFC service instance (e.g., the target SFC service instance) corresponding to the target IP address based on pre-stored SFC table entries. The target SFC service instance is the SFC service instance to which the second SRv6 packet belongs. Then, the SFF node determines the target-specific identifier corresponding to the target SFC service instance, which is the target-specific identifier corresponding to the target IP address.
[0219] In step S84 above, after the SFF node decapsulates the second SRv6 message, it can remove the header of the second SRv6 message to obtain the payload of the second SRv6 message. This payload is an IPv6 message, which is the third IPv6 message.
[0220] Since the second SRv6 packet belongs to the target SFC service instance, the original identifier carried in the header of the third IPv6 packet is the original identifier of the target SFC service instance, which is the target original identifier. The SFF node modifies the target original identifier carried in the header of the third IPv6 packet to the target-specific identifier, resulting in a modified IPv6 packet, which is the fourth IPv6 packet.
[0221] In step S85 above, the SFF node sends the fourth IPv6 packet to the SF node. The SF node receives the fourth IPv6 packet, processes it, and obtains the processed IPv6 packet, which is the first IPv6 packet. The SF node then sends the first IPv6 packet back to the SFF node. The SFF node receives the first IPv6 packet and performs subsequent processing, as detailed above. Figure 1 Related descriptions for some parts.
[0222] In some embodiments, the SFF node can match the target IP address in the SFC table entry to obtain the target private identifier. Step S83 above can be implemented through the following steps: searching for a target SFC table entry recording the target IP address from pre-stored SFC table entries; if a target SFC table entry is found, obtaining the private identifier from the target SFC table entry as the target private identifier corresponding to the target IP address; if no target SFC table entry is found, generating a target SFC table entry and using the private identifier recorded in the target SFC table entry as the target private identifier corresponding to the target IP address.
[0223] In this embodiment of the application, the SFF node searches for the target IP address in the IP addresses recorded in the pre-stored SFC table entries, and the SFC table entry that records the target IP address is the target SFC table entry.
[0224] If a target SFC table entry is found, the SFF node retrieves the record's unique identifier from the target SFC table entry as the target unique identifier.
[0225] If no target SFC entry is found, the SFF node generates an SFC entry. That is, it obtains the original identifier, special identifier, and SRH information corresponding to the target IP address as the target original identifier, target special identifier, and target SRH information, respectively, establishes the correspondence between the target IP address, target original identifier, target special identifier, and target SRH information, and obtains the target SFC entry.
[0226] The SFF node can directly use the special identifier obtained during the generation of the target SFC table entry as the target special identifier corresponding to the target IP address, or it can obtain the special identifier of the record from the target SFC table entry as the target special identifier corresponding to the target IP address, without any limitation.
[0227] In the technical solution provided in this application embodiment, after receiving an SRv6 message sent by another node, the SFF node searches for the target SFC entry based on the destination IP address to determine whether the SFC entry for the corresponding SFC service instance has been stored, thereby determining whether the corresponding original identifier and SRH information have been stored. If the target SFC entry is found, the corresponding dedicated identifier is directly obtained; if the target SFC entry is not found, a target SFC entry is generated and the corresponding dedicated identifier is obtained.
[0228] In some embodiments, an SFF node may generate a target SFC entry by the following steps: extracting the target original identifier carried in the header of a third IPv6 packet and obtaining the target SRH information corresponding to the target IP address; determining the target special identifier corresponding to the target original identifier; and generating a target SFC entry based on the target IP address, the target original identifier, the target special identifier, and the target SRH information.
[0229] In this embodiment of the application, the SFF node obtains the target original identifier, target SRH information and target special identifier corresponding to the target IP address.
[0230] The SFF node extracts the original identifier from the header of the third IPv6 packet as the target original identifier. When the SFF node uses a preset field (such as the flow label field) in the header of the third IPv6 packet to carry a special identifier, the SFF node can extract the content of the flow label field in the header of the third IPv6 packet to obtain the target original identifier.
[0231] The SFF node can obtain the SID list and SL value corresponding to the target IP address to get the SRH information as the target SRH information. Depending on the proxy mode, different methods are used to obtain the target SRH information. In static proxy mode, the target IP address is End.ASSID. The SFF node can obtain manually configured SRH information as the target SRH information, or it can extract the SRH from the header of the second SRv6 packet. In dynamic proxy mode, the target IP address is End.AD SID. The SFF node can extract the SRH from the header of the second SRv6 packet as the target SRH information. The method by which the SFF node obtains the target SRH information is not limited here.
[0232] The SFF node generates a dedicated identifier representing the SFC service instance with the same length as the original target identifier, thus obtaining the target dedicated identifier. The SFF node can allocate a target service instance identifier to the target IP address; that is, it selects a service instance identifier from among unused service instance identifiers as the target service instance identifier. The SFF node can randomly select a service instance identifier as the target service instance identifier, or it can select the service instance identifier with the smallest value to reduce the space occupied by the service instance identifier and the dedicated identifier; there is no limitation on this.
[0233] After determining the target service instance identifier, the SFF node combines a first preset value, a second preset value, and the target service instance identifier to indicate that the first IPv6 packet belongs to an SFC service flow, thus obtaining a target-specific identifier. The first preset value is the SFC flag bit, located in the SFC flag bit subfield included in the flow label field; the second preset value is the reserved bit, located in the reserved bit subfield included in the flow label field; and the target service instance identifier is located in the service instance identifier subfield included in the service instance identifier field. See the above for details. Figure 3 The relevant description is as follows: The SFF node can fill the first preset value, the second preset value, and the target service instance identifier into the SFC flag field, the reserved field, and the service instance identifier field, respectively, to obtain the target-specific identifier.
[0234] In this embodiment, the SFF node generates a target SFC entry after the target original identifier, target SRH information, and target-specific identifier. The SFF node can generate the target SFC entry in the following two ways.
[0235] Method 3: The SFF node records the correspondence between the target IP address, the target original identifier, the target dedicated identifier, and the target SRH information to obtain the target SFC entry. That is, the target SFC entry does not include the target service instance identifier. In this case, after receiving the first IPv6 packet, the SFF node can use Method 1 above to determine the target original identifier and target SRH information corresponding to the target dedicated identifier.
[0236] Method 4: When the target-specific identifier includes the target service instance identifier, the SFF node records the correspondence between the target IP address, the target original identifier, the target-specific identifier, the target service instance identifier, and the target SRH information, thus obtaining the target SFC entry. That is, the target SFC entry includes the target service instance identifier, such as... Figure 4 The SFC entry is shown below. In this case, after receiving the first IPv6 packet, the SFF node can use either method 1 or method 2 described above to determine the target original identifier and target SRH information corresponding to the target dedicated identifier.
[0237] See Figure 9 , Figure 9 This is a sixth flowchart illustrating a message forwarding method provided in an embodiment of this application. The message forwarding method described above may include the following steps.
[0238] Step S91: Receive a second SRv6 message sent by another node. The payload of the second SRv6 message is a third IPv6 message, and the destination IP address of the second SRv6 message is the target IP address. This is the same as step S81 above.
[0239] Step S92: Determine whether the target IP address is a SID of a preset type. If yes, proceed to step S93; otherwise, proceed to step S911. This is the same as step S82 above.
[0240] Step S93: Determine the target private identifier corresponding to the target IP address based on the pre-stored SFC table entries. The SFC table entries record the IP address, private identifier, original identifier, and SRH information.
[0241] Step S94: Modify the original target identifier carried in the header of the third IPv6 packet to a target-specific identifier to obtain the fourth IPv6 packet. This is the same as step S84 above.
[0242] Step S95: Send the fourth IPv6 packet to the SF node so that the SF node can send the first IPv6 packet back to the SFF node. This is the same as step S85 above.
[0243] Step S96: Receive the first IPv6 packet sent by the SF node through the target interface. The header of the first IPv6 packet carries a target-specific identifier. This is the same as step S11 above.
[0244] Step S97: Determine the target original identifier and target SRH information corresponding to the target special identifier based on the pre-stored service chain SFC table entry.
[0245] Step S98: Modify the target-specific identifier carried in the header of the first IPv6 packet to the original target identifier to obtain the second IPv6 packet. This is the same as step S13 above.
[0246] Step S99: Based on the target SRH information, encapsulate the second IPv6 packet with an SRv6 header to obtain the first SRv6 packet. This is the same as step S14 above.
[0247] Step S910: Forward the first SRv6 message according to the SRH information carried in the first SRv6 message. This is the same as step S15 above.
[0248] Step S911: Forward the second SRv6 message. This is the same as step S86 above.
[0249] In steps S91 to S95 and S911 above, the SFF node receives messages sent by other nodes and sends messages to the SF node. See the above for details. Figure 8 The relevant descriptions are as follows: In steps S96 to S910 above, the SFF node receives the messages sent by the SF node; for details, please refer to the above. Figures 1 to 7 Related descriptions for some parts.
[0250] In the technical solution provided in this application, after receiving SRv6 packets sent by other nodes, the SFF node determines a special identifier based on the destination IP address of the SRv6 packet and sends the IPv6 packet carrying the special identifier to the SF node. This ensures that the IPv6 packet returned by the SF node also carries the special identifier. The SFF node can then use the special identifier to determine the corresponding original identifier and SRH information, modify the special identifier carried in the IPv6 packet returned by the SF node back to the original identifier, and re-encapsulate the SRv6 header according to the SRH information to obtain the SRv6 packet for forwarding. Applying the technical solution provided in this application, the SFF node does not need to configure an independent interface for each SFC service instance. Instead, by carrying the special identifier, it determines the corresponding SRH and SRv6 path information, performs re-encapsulation and forwarding, reducing the complexity of packet forwarding implementation and maintenance, and ensuring the accuracy of packet forwarding. Furthermore, the number of SFC service instances that the SFF node can provide is not limited by the number of interfaces on the SFF node, increasing the service scale of SFC.
[0251] The following is through Figure 10 The message forwarding method provided in the embodiments of this application will be described in detail. Figure 10 This is a schematic diagram illustrating message forwarding provided in an embodiment of this application. A message is sent from an SC node to an end node. The message forwarding path also includes an SFF node and an SF node, where the SF node cannot recognize SRv6 messages. The SRv6 message forwarding process is specifically as follows: the SC node sends a message to the SFF node, the SFF node sends a message to the SF node, the SF node sends a message to the SFF node, and the SFF node sends a message to the end node, as shown below. Figure 10 Processes 1 through 4.
[0252] The SC node sends an SRv6 message (i.e., the second SRv6 message) to the SFF node. The SRv6 message includes the newly added IPv6 header, SRH, and payload. The payload is the original IPv6 message (i.e., the third IPv6 message), including the payload IPv6 header (i.e., the standard IPv6 header) and the payload of the original IPv6 message, such as... Figure 10 The message sent from the SC node to the SFF node.
[0253] After receiving an SRv6 packet, the SFF node decapsulates the SRv6 packet and parses the DIP (i.e., the destination IP address) in the newly added IPv6 header into either End.ASSID or End.AD SID type, then proceeds to the SFC service processing flow. The SFF node generates an SFC entry (i.e., the target SFC entry) and records in the SFC entry the SFC service instance identifier corresponding to the DIP (i.e., the target service instance identifier), the SRH carried in the SRv6 packet and the SL value within the SRH (i.e., the target SRH information), the original flow label in the flow label field of the payload IPv6 header (i.e., the target original identifier), and the SFC-specific flow label obtained based on the SFC service instance identifier (i.e., the target specific identifier). Before generating an SFC entry, the SFF node can match the DIP with the IP address in the stored SFC entries to find the corresponding SFC entry. If a corresponding SFC entry is found, the SFF node does not need to generate an SFC entry.
[0254] The SFF node removes the newly added IPv6 header and SRH, and modifies the flow label field of the payload IPv6 header to the SFC-specific flow label from the SFC table entry, resulting in the modified IPv6 packet (i.e., the fourth IPv6 packet). Figure 10 The message sent from the SFF node to the SF node.
[0255] After receiving and processing the modified IPv6 packet, the SF node sends an IPv6 packet (i.e., the first IPv6 packet) back to the SFF node. The flow label field in the IPv6 header of this IPv6 packet remains the SFC-specific flow label. Figure 10 The message sent from the SF node to the SFF node.
[0256] The SFF node receives the IPv6 packet from the SF node and determines whether the interface receiving the IPv6 packet has SFC enabled. If SFC is enabled, the SFF node extracts the SFC-specific flow label from the flow label field of the IPv6 payload header and checks if the lower 2 bits of the SFC-specific flow label (i.e., the SFC flag subfield) are 11 (i.e., the first preset value). If the lower 2 bits are 11, the SFF node extracts the values of bits 4 to 19 of the SFC-specific flow label (i.e., the service instance identifier subfield) (i.e., the target service instance identifier) and checks if this value is the same as the locally configured SFC service instance identifier. Under the same conditions, the SFF node replaces the SFC-specific flow label in the flow label field of the payload IPv6 header with the original flow label recorded in the corresponding SFC entry. It then constructs an SRv6 header based on the SRH recorded in the corresponding SFC entry and the newly added IPv6 header. The SL value in the SRH is the recorded SL value minus 1, and the DIP in the newly added IPv6 header is the IP address of the end node (i.e., the end node SID). The SFF node re-encapsulates the packet based on the SRv6 header to obtain the encapsulated SRv6 packet (i.e., the first SRv6 packet). See the above for details. Figure 7 Related descriptions for some parts.
[0257] The process of sending messages from the end node to the SC node is similar to the process described above, and will not be described in detail here.
[0258] By applying the technical solution provided in the embodiments of this application, when a packet is forwarded from the SF node to the SFF node, the SFF node no longer needs to configure a physical interface or sub-interface for each SFC service instance. The SFF node determines the associated SFC service instance based on the flow label field in the IPv6 header of the original packet, thereby simplifying the service implementation. The number of SFC service instances is not limited by the device interface specifications of the SFF node.
[0259] Corresponding to the above message forwarding method, this application also provides a message forwarding apparatus, see [link to relevant documentation]. Figure 11 Applied to SFF nodes, the above-mentioned packet forwarding device includes:
[0260] The first receiving module 111 is used to receive the first IPv6 packet sent by the SF node through the target interface. The header of the first IPv6 packet carries a target-specific identifier.
[0261] The first obtaining module 112 is used to determine the target original identifier and target SRH information corresponding to the target special identifier based on the pre-stored SFC table entries. The SFC table entries record the special identifier, the original identifier and the SRH information.
[0262] The first modification module 113 is used to modify the target special identifier carried in the header of the first IPv6 packet to the target original identifier to obtain the second IPv6 packet;
[0263] Encapsulation module 114 is used to encapsulate an SRv6 header for the second IPv6 packet according to the target SRH information to obtain the first SRv6 packet;
[0264] The forwarding module 115 is used to forward the first SRv6 message according to the SRH information carried in the first SRv6 message.
[0265] In the technical solution provided in this application embodiment, the SFF node pre-stores SFC entries recording the original identifier and SRH information. After receiving an IPv6 packet sent by the SF node, the SFF node determines the original identifier and SRH information corresponding to the IPv6 packet based on the special identifier carried in the packet header. It then modifies the special identifier in the packet header back to the original identifier and re-encapsulates the SRv6 header according to the SRH information to obtain the SRv6 packet. Subsequently, the SFF node can forward the obtained SRv6 packet based on the SRH information. Applying the technical solution provided in this application embodiment, the SFF node does not need to configure an independent interface for each SFC service instance. Instead, it determines the corresponding SRH and SRv6 path information by carrying a special identifier, performs re-encapsulation and forwarding, reduces the complexity of packet forwarding implementation and maintenance, and ensures the accuracy of packet forwarding. Simultaneously, the number of SFC service instances that the SFF node can provide is not limited by the number of interfaces on the SFF node, increasing the service scale of SFC.
[0266] In some embodiments, the first obtaining module 112 described above is specifically used for: searching for a target SFC entry recording a target-specific identifier from a pre-stored SFC entry; obtaining the original identifier from the target SFC entry as the target original identifier corresponding to the target-specific identifier, and obtaining SRH information from the target SFC entry as the target SRH information corresponding to the target-specific identifier; or,
[0267] The target-specific identifier includes the target service instance identifier, and the SFC table entry also records the service instance identifier; the first obtaining module 112 is specifically used for: extracting the target service instance identifier from the target-specific identifier; searching for the target SFC table entry that records the target service instance identifier from the pre-stored SFC table entries; obtaining the original identifier from the target SFC table entry as the target original identifier corresponding to the target-specific identifier, and obtaining SRH information from the target SFC table entry as the target SRH information corresponding to the target-specific identifier.
[0268] In some embodiments, the target dedicated identifier includes an SFC flag bit; the first obtaining module 112 is further configured to: before determining the target original identifier and target SRH information corresponding to the target dedicated identifier according to the pre-stored SFC table entry, determine whether the SFC flag bit included in the target dedicated identifier is a first preset value, the first preset value indicating that the first IPv6 packet belongs to an SFC service flow; if yes, then perform the step of determining the target original identifier and target SRH information corresponding to the target dedicated identifier according to the pre-stored SFC table entry; if no, then forward the first IPv6 packet.
[0269] In some embodiments, the first obtaining module 112 is further configured to: determine whether the target interface has SFC function enabled before determining the target original identifier and target SRH information corresponding to the target dedicated identifier according to the pre-stored SFC table entry; if yes, then perform the step of determining the target original identifier and target SRH information corresponding to the target dedicated identifier according to the pre-stored SFC table entry; if no, then forward the first IPv6 packet.
[0270] In some embodiments, such as Figure 12 As shown, the above-mentioned message forwarding device also includes:
[0271] The second receiving module 121 is used to receive a second SRv6 message sent by other nodes. The payload of the second SRv6 message is a third IPv6 message, and the destination IP address of the second SRv6 message is the target IP address.
[0272] The second module 122 is used to determine the target private identifier corresponding to the target IP address based on the pre-stored SFC table entry if the target IP address is a segment identifier SID of a preset type. The SFC table entry also records the IP address.
[0273] The second modification module 123 is used to modify the target original identifier carried in the header of the third IPv6 packet to the target special identifier to obtain the fourth IPv6 packet.
[0274] The sending module 124 is used to send the fourth IPv6 packet to the SF node so that the SF node can send the first IPv6 packet back to the SFF node.
[0275] In some embodiments, the second obtaining module 122 described above is specifically used for:
[0276] Find the target SFC entry that records the target IP address from the pre-stored SFC entries;
[0277] If the target SFC entry is found, the special identifier is obtained from the target SFC entry and used as the target special identifier corresponding to the target IP address;
[0278] If no target SFC entry is found, a target SFC entry is generated, and the special identifier recorded in the target SFC entry is used as the target special identifier corresponding to the target IP address.
[0279] In some embodiments, the second obtaining module 122 described above is specifically used for:
[0280] Extract the target original identifier carried in the header of the third IPv6 packet, and obtain the target SRH information corresponding to the target IP address;
[0281] Determine the target-specific identifier corresponding to the original target identifier;
[0282] Generate a target SFC entry based on the target IP address, target original identifier, target special identifier, and target SRH information.
[0283] In some embodiments, the second obtaining module 122 described above is specifically used for:
[0284] Assign a target service instance identifier to the target IP address;
[0285] The first preset value, the second preset value, and the target service instance identifier are combined to obtain the target dedicated identifier. The first preset value indicates that the first IPv6 packet belongs to the SFC service flow.
[0286] In some embodiments, the second obtaining module 122 is specifically used to: record the correspondence between the target IP address, the target original identifier, the target special identifier and the target SRH information to obtain the target SFC entry;
[0287] or,
[0288] The target-specific identifier includes the target service instance identifier; the second obtaining module 122 mentioned above is specifically used to: record the correspondence between the target IP address, the target original identifier, the target-specific identifier, the target service instance identifier and the target SRH information, and obtain the target SFC table entry.
[0289] In some embodiments, the flow label field in the header of the first IPv6 packet carries a target-specific identifier.
[0290] In some embodiments, the target-specific identifier includes an SFC flag bit, a second preset value, and a target service instance identifier, and the flow tag field includes an SFC flag bit subfield, a reserved bit field, and a service instance identifier subfield.
[0291] The SFC flag bit subfield is used to carry the SFC flag bit;
[0292] The reserved space subfield is the second preset value;
[0293] The Service Instance Identifier subfield is used to carry the identifier of the target service instance.
[0294] This application also provides an SFF node, such as... Figure 13 As shown, it includes a processor 131 and a machine-readable storage medium 132, the machine-readable storage medium 132 storing machine-executable instructions that can be executed by the processor 131, the processor 131 being prompted by the machine-executable instructions to implement the steps of any of the above-described message forwarding methods.
[0295] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.
[0296] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of any of the above-described message forwarding methods.
[0297] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the message forwarding methods described above.
[0298] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid state disk (SSD)).
[0299] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0300] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of methods, apparatus, SFF nodes, computer-readable storage media, and computer program products are basically similar to the method embodiments, and therefore the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.
[0301] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.
Claims
1. A message forwarding method, characterized in that, The method, applied to service chain forwarding SFF nodes, includes: The first IPv6 packet sent by the application service SF node is received through the target interface. The header of the first IPv6 packet carries a target-specific identifier. Based on the pre-stored Service Chain (SFC) entries, determine the target original identifier and target segment routing header (SRH) information corresponding to the target dedicated identifier. The SFC entries record the dedicated identifier, the original identifier, and the SRH information. The target-specific identifier carried in the header of the first IPv6 packet is modified to the original target identifier to obtain the second IPv6 packet; Based on the target SRH information, an SRv6 header is encapsulated in the second IPv6 packet to obtain the first SRv6 packet; Forward the first SRv6 message according to the SRH information carried in the first SRv6 message; The target-specific identifier is used to indicate the SFC service instance to which the first IPv6 packet belongs.
2. The method according to claim 1, characterized in that, The step of determining the target original identifier and target SRH information corresponding to the target special identifier based on the pre-stored SFC table entries includes: searching for the target SFC table entry that records the target special identifier from the pre-stored SFC table entries; obtaining the original identifier from the target SFC table entry as the target original identifier corresponding to the target special identifier, and obtaining the SRH information from the target SFC table entry as the target SRH information corresponding to the target special identifier; or, The target-specific identifier includes a target service instance identifier, and the SFC entry also records a service instance identifier. The step of determining the target original identifier and target SRH information corresponding to the target-specific identifier based on the pre-stored service chain SFC entries includes: extracting the target service instance identifier from the target-specific identifier; searching for the target SFC entry that records the target service instance identifier from the pre-stored SFC entries; obtaining the original identifier from the target SFC entry as the target original identifier corresponding to the target-specific identifier, and obtaining the SRH information from the target SFC entry as the target SRH information corresponding to the target-specific identifier.
3. The method according to claim 1, characterized in that, The target-specific identifier includes the SFC flag bit; Before determining the target original identifier and target SRH information corresponding to the target-specific identifier based on the pre-stored SFC table entries, the method further includes: Determine whether the SFC flag bit included in the target dedicated identifier is a first preset value, wherein the first preset value indicates that the first IPv6 packet belongs to an SFC service flow; If so, then the step of determining the target original identifier and target SRH information corresponding to the target special identifier based on the pre-stored SFC table entry is executed; If not, forward the first IPv6 packet.
4. The method according to claim 1, characterized in that, Before determining the target original identifier and target SRH information corresponding to the target-specific identifier based on the pre-stored SFC table entries, the method further includes: Determine whether the target interface has SFC functionality enabled; If so, then the step of determining the target original identifier and target SRH information corresponding to the target special identifier based on the pre-stored SFC table entry is executed; If not, forward the first IPv6 packet.
5. The method according to claim 1, characterized in that, The method further includes: Receive a second SRv6 message sent by other nodes. The payload of the second SRv6 message is a third IPv6 message, and the destination IP address of the second SRv6 message is the target IP address. If the target IP address is a segment identifier (SID) of a preset type, then the target dedicated identifier corresponding to the target IP address is determined according to the pre-stored SFC table entry, and the SFC table entry also records the IP address; The target original identifier carried in the header of the third IPv6 packet is modified to the target special identifier to obtain the fourth IPv6 packet; The fourth IPv6 message is sent to the SF node so that the SF node can send the first IPv6 message back to the SFF node.
6. The method according to claim 5, characterized in that, The step of determining the target private identifier corresponding to the target IP address based on the pre-stored SFC table entry includes: Search for the target SFC entry that records the target IP address from the pre-stored SFC entries; If the target SFC entry is found, the special identifier is obtained from the target SFC entry and used as the target special identifier corresponding to the target IP address; If the target SFC entry is not found, a target SFC entry is generated, and the special identifier recorded in the target SFC entry is used as the target special identifier corresponding to the target IP address.
7. The method according to claim 6, characterized in that, The step of generating the target SFC table entry includes: Extract the target original identifier carried in the header of the third IPv6 packet, and obtain the target SRH information corresponding to the target IP address; Determine the target-specific identifier corresponding to the original target identifier; A target SFC entry is generated based on the target IP address, the target original identifier, the target special identifier, and the target SRH information.
8. The method according to claim 7, characterized in that, The step of determining the target-specific identifier corresponding to the target original identifier includes: Assign a target service instance identifier to the target IP address; By combining the first preset value, the second preset value, and the target service instance identifier, a target dedicated identifier is obtained. The first preset value indicates that the first IPv6 packet belongs to the SFC service flow.
9. The method according to claim 7, characterized in that, The step of generating a target SFC entry based on the target IP address, the target original identifier, the target special identifier, and the target SRH information includes: recording the correspondence between the target IP address, the target original identifier, the target special identifier, and the target SRH information to obtain the target SFC entry; or, The target-specific identifier includes the target service instance identifier; the step of generating a target SFC entry based on the target IP address, the target original identifier, the target-specific identifier, and the target SRH information includes: recording the correspondence between the target IP address, the target original identifier, the target-specific identifier, the target service instance identifier, and the target SRH information to obtain the target SFC entry.
10. The method according to any one of claims 1-9, characterized in that, In the header of the first IPv6 packet, the flow label field carries the target-specific identifier.
11. The method according to claim 10, characterized in that, The target-specific identifier includes an SFC flag bit, a second preset value, and a target service instance identifier; the flow tag field includes an SFC flag bit subfield, a reserved bit field, and a service instance identifier subfield. The SFC flag bit subfield is used to carry the SFC flag bit; The reserved position subfield is the second preset value; The service instance identifier subfield is used to carry the identifier of the target service instance.
12. A message forwarding device, characterized in that, The device, applied to a Service Chain Forwarding (SFF) node, includes: The first receiving module is used to receive a first IPv6 packet sent by the application service SF node through the target interface. The header of the first IPv6 packet carries a target-specific identifier. The first obtaining module is used to determine the target original identifier and target segment routing header (SRH) information corresponding to the target dedicated identifier based on the pre-stored service chain (SFC) table entries. The SFC table entries record the dedicated identifier, the original identifier, and the SRH information. The first modification module is used to modify the target special identifier carried in the header of the first IPv6 packet to the target original identifier to obtain the second IPv6 packet; An encapsulation module is used to encapsulate an SRv6 header for the second IPv6 packet according to the target SRH information, so as to obtain a first SRv6 packet; The forwarding module is used to forward the first SRv6 message according to the SRH information carried in the first SRv6 message; The target-specific identifier is used to indicate the SFC service instance to which the first IPv6 packet belongs.
13. The apparatus according to claim 12, characterized in that, The device further includes: The second receiving module is used to receive a second SRv6 message sent by other nodes. The payload of the second SRv6 message is a third IPv6 message, and the destination IP address of the second SRv6 message is the target IP address. The second obtaining module is used to determine the target private identifier corresponding to the target IP address based on the pre-stored SFC table entry if the target IP address is a segment identifier SID of a preset type. The SFC table entry also records the IP address. The second modification module is used to modify the target original identifier carried in the header of the third IPv6 packet to the target special identifier to obtain the fourth IPv6 packet; The sending module is used to send the fourth IPv6 packet to the SF node so that the SF node can send the first IPv6 packet back to the SFF node.
14. The apparatus according to any one of claims 12-13, characterized in that, In the header of the first IPv6 packet, the flow label field carries the target dedicated identifier; the target dedicated identifier includes the SFC flag bit, the second preset value, and the target service instance identifier, and the flow label field includes the SFC flag bit subfield, the reserved bit field, and the service instance identifier subfield; The SFC flag bit subfield is used to carry the SFC flag bit; The reserved position subfield is the second preset value; The service instance identifier subfield is used to carry the identifier of the target service instance.
15. A Service Chain Forwarding (SFF) node, characterized in that, The method includes a processor and a machine-readable storage medium storing machine-executable instructions that can be executed by the processor, the processor being prompted by the machine-executable instructions to perform the method of any one of claims 1-11.
16. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-11.
Citation Information
Patent Citations
Message forwarding method and device
CN112953831A
Method for forwarding message in SRv6 service chain, SFF and SF equipment
CN113691448A