CN117376233A - Data processing method, device and system - Google Patents

Data processing method, device and system Download PDF

Info

Publication number
CN117376233A
CN117376233A CN202210772718.7A CN202210772718A CN117376233A CN 117376233 A CN117376233 A CN 117376233A CN 202210772718 A CN202210772718 A CN 202210772718A CN 117376233 A CN117376233 A CN 117376233A
Authority
CN
China
Prior art keywords
message
node
segment
sff
list
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210772718.7A
Other languages
Chinese (zh)
Inventor
路君
曾毅
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Priority to CN202210772718.7A priority Critical patent/CN117376233A/en
Priority to PCT/CN2023/098698 priority patent/WO2024001701A1/en
Publication of CN117376233A publication Critical patent/CN117376233A/en
Pending legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/34Source routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/74Address processing for routing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks
    • H04L45/76Routing in software-defined topologies, e.g. routing between virtual machines

Abstract

The application discloses a data processing method, device and system, wherein the method comprises the following steps: under the condition that SF equipment is connected into a first SFF node and a second SFF node in a double-return mode, after the first SFF node receives the first segment list, the first segment list is sent to the second SFF node according to the list synchronization operation indicated by the first segment identification in the first message, so that the second SFF node can carry out SRH encapsulation on the message sent by the SF node according to the first segment list. Therefore, the second SFF node can package SRH for the message sent by the SF node according to the first segment list sent by the first SFF node even if the second SFF node does not receive the first message, so that message transmission failure caused by the fact that the second SFF node cannot forward the message received from the SF node based on SRv protocol is avoided, link stability between the second SFF node and the SF node is guaranteed, and reliability of message transmission is improved.

Description

Data processing method, device and system
Technical Field
The present disclosure relates to the field of communications, and in particular, to a data processing method, apparatus, and system.
Background
Segment routing (segment routing ipv, SRv 6) based on internet protocol version six (internet protocol version, ipv 6) is a new generation internet protocol (internet protocol, IP) bearer protocol. The service function chain (Service Function Chaining, SFC) is an important means of orderly handling traffic (e.g., messages) on demand in NFV (Network Function Virtualization ) virtual networks. Typically, SFC includes a traffic class (service classifier, SC) node, a traffic function forwarding (service function forwarder, SFF) node, a traffic function (SF) node. The SC node is configured to traffic classify messages entering the SFC domain and encapsulate a network service header (network service header, NSH). The SFF node communicates with the SF node for forwarding the message according to the network service header. The SF node is used for providing value-added service function and processing service function for the received message.
SRv6 technology combines with SFC technology, when SF node that does not support SRv6 protocol communicates with two SFF nodes, for example, a certain SF node can communicate with SFF1 and SFF2, SFF1 and SFF2 adopt dynamic proxy (dynamic proxy) mode to realize message transmission of SF node, because SFF1 node strips SRv6 message segment route header (segment routing header, SRH), SFF2 node can not know SRH of SRv6 message, so SFF2 node can not encapsulate SF node sent message according to SRv protocol, resulting in message transmission failure.
Disclosure of Invention
The embodiment of the application provides a data processing method, device and system, which can solve the problem that an SFF node cannot package a message sent by the SF node according to a SRv protocol under the scene that the SF node is connected with the SFF node in a double-return manner, thereby improving the reliability of message transmission.
In a first aspect, a data processing method is provided, which is executed by a first SFF node, the first SFF node being connected to a second SFF node, the first SFF node and the second SFF node being connected to SF nodes, respectively, the method comprising: the first SFF node acquires a first Segment identifier (Segment Identifier, SID) and a first Segment List (Segment List), wherein the first Segment identifier is used for indicating the first SFF node and the second SFF node to synchronize the List, so that the first SFF node sends the first Segment List to the second SFF node, and the synchronization of the second SFF node and the Segment List of the first SFF node is realized.
When the second SFF node needs to forward the message processed by the SF node and the first SFF node peels off the SRH of the first message, and the second SFF node cannot learn the SRH of the first message, the first SFF node sends the first segment list to the second SFF node, so that the second SFF node is synchronous with the segment list of the first SFF node, the second SFF node packages the SRH with the message processed by the SF node according to the first segment list, and forwards the message received from the SF node based on SRv protocol. Therefore, message transmission failure is avoided, link stability between the second SFF node and the SF node is ensured, and reliability of message transmission is improved.
In order to make the first SFF node and the second SFF node carry out load sharing on the message sent by the SF node, the SF node is connected to the first SFF node and the second SFF node in a double-return mode. After the SF node is connected with the first SFF node and the second SFF node in a double-homing way, the messages sent to the SF node by the first SFF node and the second SFF node according to the received first message are the same, the messages sent to the next hop node by the first SFF node and the second SFF node according to the received messages processed by the SF node are the same, the SF node can process the service function of the messages received from the first SFF node and then send the messages to the second SFF node for forwarding, and can also process the service function of the messages received from the second SFF node and then send the messages to the first SFF node for forwarding.
Optionally, a local SID table (also called a local segment identifier list) of each of the first SFF node and the second SFF node is provided with a first segment identifier, where the first segment identifier may be an Anycast segment identifier (Anycast-SID), and the first SFF node and the second SFF node issue the same address, so that the first SFF node and the second SFF node perceived by the SF node are the same device, and thus the first SFF node and the second SFF node may perform load sharing on a packet sent by the SF node.
As a possible implementation manner, the first segment identifier and the first segment list may be obtained from a first packet. For example, the first message is sent by the traffic classification SC node to the first SFF node, or the first message is sent by the spine node to the first SFF node.
Optionally, the first message is a SRv message including an SRH, and the first message includes a first segment identifier and a first segment list.
For example, the first segment identifier and the first segment list are set in the SRH of the header of the first message. The first segment list is a segment list contained in the SRH of the first message. The first segment identifier is a segment identifier indicated by a Segment Left (SL) field of the SRH of the first message. The segment remaining field is used to indicate the number of intermediate nodes to be accessed before the message reaches the destination node.
For another example, the load of the first packet includes a first segment identifier and a first segment list, and the first SFF node may read the first segment list and the first segment identifier from the load of the first packet after obtaining the first packet.
The first segment identification may also be a destination address (destination address, DA) in an IPv6 header of the first message.
The scheme does not limit the formats of the first section identifier and the first section list in the message, and improves the flexibility of data processing.
As one possible implementation, the first segment identification may also be used to instruct the first SFF node to maintain the first segment list.
Optionally, the first segment identifier indicates that the first SFF node sends the first segment list to the second SFF node when the first segment identifier included in the first packet hits the local segment identifier and the first segment identifier is not stored in a cache (cache) of the first SFF node.
Therefore, after the second SFF node has stored the first segment list, the first SFF node does not send the first segment list to the second SFF node each time the first segment list-containing message is received, and waste of communication resources between the first SFF node and the second SFF node is reduced.
As a possible implementation manner, the first packet may be a packet received by the first SFF node from a previous-hop node, and the previous-hop node may be an SFF node or an SC node in the SFC. The first message is a message generated by an SC node in SFC according to a service message sent by a terminal, the first message comprises a message header and a load, the message header comprises SRH, and the load comprises the service message.
After receiving the first message, the first SFF node can also strip the SRH of the first message according to the first segment identification to obtain a third message, and send the third message to the SF node. Here, the first segment identifier is further used for indicating the first SFF node to strip the SRH of the first message, obtain a third message, and send the third message to the SF node.
As another possible implementation, the first packet may be a test packet received by the first SFF node from the previous-hop node. The test message can simulate the forwarding and processing of the service message. The test message is generated by the SC node in the SFC when creating the SRv traffic engineering Policy (segment routing ipv6 traffic engineering Policy, SRv6 TE Policy), the test message includes a message header, which may not carry a load, and the message header includes an SRH, so that the first SFF node receives the first message, and identifies the synchronization list according to a first segment in the SRH of the first message.
Based on the implementation manner, the first SFF node can synchronize the list with the second SFF node when receiving the first message, so that SRv message forwarding capability of the second SFF node in the transmission process of the first message is ensured. The first SFF node can synchronize the list with the second node when receiving the test message, so that the problem that the second SFF node cannot package SRH for the message sent by the SF node due to the fact that the second SFF node receives the message sent by the SF node before receiving the first segment list from the first SFF node is avoided.
As a possible implementation manner, the first SFF node sends the first segment list to the second SFF node in the form of a message, that is, the first SFF node sends the second message to the second SFF node, where the second message includes the first segment list.
Alternatively, the second message may be a network layer reachability message (Network Layer Reachability Information, NLRI) message, a redundant user information message, or a network multisystem link aggregation group (Multichassis Link Aggregation Group, M-LAG) message.
For example, the second message is a network layer reachability message, and the second message may include a route identifier (Route Distinguisher, RD) field, an Ethernet segment (Ethernet Segment Identifier, ESI) field, an Ethernet label (Ethernet Tag ID) field, a segment list length field, a segment remaining field, and a first segment list. The segment list length field is used to indicate the length of the first segment list in the second message. The route specifier field, the ethernet segment field, and the ethernet label field are common contents in the network layer reachability message packet, and are not described herein.
For another example, the second packet is a network multisystem link aggregation group packet, where the second packet may include a packet Header and a payload, where the packet Header is a custom message Header (Msg Header), the payload includes a first packet received by the first SFF node, and the first packet includes an SRH, where the SRH includes a first segment list.
Therefore, the first SFF node in the scheme can send the first section identification to the second SFF node based on different message formats to synchronize the list, so that the data processing method is suitable for various network transmission protocols, and the applicability and flexibility of the data processing method are improved.
In a second aspect, a data processing method is provided, which is executed by a second SFF node, the second SFF node being connected to a first SFF node, the second SFF node and the first SFF node being connected to SF nodes, respectively, the method comprising: the second SFF node receives the first segment list sent by the first SFF node, and stores the first segment list, so that the synchronization of the second SFF node and the segment list of the first SFF node is realized.
Based on the scheme, the second SFF node receives and stores the first segment list from the first SFF node, and the second SFF node and the first SFF node synchronize the list, so that the second SFF node can package SRH for the first message sent by the SF node according to the first segment list, and the SRH indicates the message to be forwarded to the next hop, thereby avoiding that the second SFF node cannot package SRH for the message received from the SF node, resulting in failure of message transmission, ensuring the link stability between the second SFF node and the SF node, and improving the reliability of message transmission.
Optionally, the SF node is dual-homed to access the first SFF node and the second SFF node. After the SF node is connected with the first SFF node and the second SFF node in a double-homing way, the messages sent to the SF node by the first SFF node and the second SFF node according to the received first message are the same, the messages sent to the next hop node by the first SFF node and the second SFF node according to the received messages processed by the SF node are the same, the SF node can process the service function of the messages received from the first SFF node and then send the messages to the second SFF node for forwarding, and can also process the service function of the messages received from the second SFF node and then send the messages to the first SFF node for forwarding.
As a possible implementation manner, the first segment list received by the second SFF node is in a message form, that is, the second SFF node receives a first message sent by the first SFF node, where the first message includes the first segment list.
Alternatively, the first message may be a network layer reachability message, a redundant user information message, or a network multisystem link aggregation group message.
For example, the first message is a network layer reachability message, and the first message may include a route specifier, an ethernet segment field, an ethernet label field, a segment list length field, a segment remaining field, and a first segment list. The segment list length field is used to indicate the length of the first segment list in the first message. The route specifier field, the ethernet segment field, and the ethernet label field are common contents in the network layer reachability message packet, and are not described herein.
And under the condition that the first message is a network layer reachability message, the second SFF node determines a first segment list in the first message according to the segment list length field, and stores the first segment list.
For another example, the first message is a network multisystem link aggregation group message, the first message may include a message header and a load, the message header is a custom message header, the load includes a second message received by the first SFF node, the second message includes an SRH, and the SRH includes a first segment list.
And under the condition that the third message is a network multisystem link aggregation group message, the second SFF node extracts the SRH from the second message by utilizing a SRv function and stores a first segment list in the SRH.
Optionally, the second SFF node further stores a segment remaining field in the first packet, so that the second SFF node determines a segment identifier of a next hop node of the first packet when performing SRH encapsulation on the first packet.
Therefore, the second SFF node in the scheme can receive the first section identification sent by the first SFF node based on different message formats to synchronize the list, so that the data processing method is suitable for various network transmission protocols, and the applicability and flexibility of the data processing method are improved.
In a third aspect, a data processing apparatus is provided, the apparatus comprising means for performing the first aspect or any one of the possible implementations of the first aspect, or the second aspect and any one of the possible implementations of the second aspect.
In a fourth aspect, a service function forwarding device is provided, where the service function forwarding device is configured to perform the operation steps of the data processing method in the first aspect or any of the possible implementations of the first aspect, or in the second aspect and any of the possible implementations of the second aspect.
In a fifth aspect, there is provided a processor, which when run in the traffic function forwarding device of the fourth aspect, causes the traffic function forwarding device to perform the steps of the data processing method of the first aspect or any of the possible implementations of the first aspect, or of the second aspect and any of the possible implementations of the second aspect.
In a sixth aspect, a system is provided, the system comprising a service function forwarding device in the fourth aspect, the service function forwarding device being configured to perform the operation steps of the data processing method in the first aspect or any of the possible implementations of the first aspect, or in the second aspect and any of the possible implementations of the second aspect.
In a seventh aspect, a computer readable storage medium is provided, comprising instructions. The instructions, when executed on a computer, cause the computer to perform the data processing method as provided in the first or second aspect above.
In an eighth aspect, a computer program product is provided. The computer program product, when run on a computer, causes the computer to perform the data processing method as provided in the first or second aspect above.
The descriptions of the third, fourth, fifth, sixth, seventh and eighth aspects of the present application may be referred to the detailed descriptions of the first and second aspects; further, the advantages of the third, fourth, fifth, sixth, seventh and eighth aspects may be referred to the analysis of the advantages of the first and second aspects, and are not described here again.
Drawings
Fig. 1 is a schematic structural diagram of a SRv message provided in an embodiment of the present application;
fig. 2 is a schematic structural diagram of SRv SID provided in an embodiment of the present application;
FIG. 3 is a schematic diagram of a system according to an embodiment of the present application;
FIG. 4 is a schematic diagram of a data processing method according to an embodiment of the present disclosure;
Fig. 5 is a schematic structural diagram of an NLRI according to an embodiment of the present application;
fig. 6 is a schematic structural diagram of an M-LAG message according to an embodiment of the present application;
FIG. 7 is a schematic diagram of another data processing method according to an embodiment of the present disclosure;
FIG. 8 is a schematic diagram of a data processing apparatus according to an embodiment of the present application;
FIG. 9 is a schematic diagram of another data processing apparatus according to an embodiment of the present disclosure;
fig. 10 is a schematic structural diagram of another data processing apparatus according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application. In this application, "at least one" means one or more, and "a plurality" means two or more. "and/or", describes an association relationship of an association object, and indicates that there may be three relationships, for example, a and/or B, and may indicate: a alone, a and B together, and B alone, wherein a, B may be singular or plural. The character "/" generally indicates that the context-dependent object is an "or" relationship. "at least one of" or the like means any combination of these items, including any combination of single item(s) or plural items(s). For example, at least one (one) of a, b or c may represent: a, b, c, a and b, a and c, b and c, or a and b and c, wherein a, b and c may be single or plural. In addition, in order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, the terms "first", "second", and the like are used to distinguish the same item or similar items having substantially the same function and effect, and those skilled in the art will understand that the terms "first", "second", and the like do not limit the number and execution order. For example, in the embodiment of the present application, "first" of the first message and "second" of the second message are only used to distinguish different messages. The first, second, etc. descriptions in the embodiments of the present application are only used for illustrating and distinguishing the description objects, and no order division is used, nor does it indicate that the number of the devices in the embodiments of the present application is particularly limited, and no limitation on the embodiments of the present application should be construed.
In this application, the terms "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" should not be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.
The data processing method provided by the embodiment of the application can be applied to a scene of a service function chain (also called a service chain) in the field of Segment Routing (SR). Hereinafter, SRv technology, SFC technology and SR SFC technology will be briefly described, respectively.
SRv6 the SR technology is applied to the IPv6 network, that is, the existing IPv6 forwarding technology is adopted, and by expanding the header of the IPv6 message, the message is subjected to processing similar to label forwarding (for example, packet forwarding based on multiprotocol label switching (Multi-Protocol Label Switching, MPLS)).
SR is a tunneling technique based on source route forwarding mode. The SR technique includes an IPv6 data plane, which is called SRv6.SRv6 a list of segments (SID list, also called segment list or SID list) is typically carried using SRH. One or more SIDs in the SID list are used to indicate a forwarding path for the SRv message, which constitutes an SR Tunnel (SR Tunnel). The SR tunnel refers to a segment list designated by a head node, and encapsulates the segment list into a tunnel formed in a header. The tunnel generally refers to a set of end-to-end paths between two points, namely a start point and an end point of the tunnel, wherein the start point of the tunnel is a head node, and the end point of the tunnel is a tail node.
The SR technique is generally described above, and how the SRv technique can be applied to an IPv6 network will be described below.
SRv6 SIDs are coded using IPv6 addresses and encapsulated in SRH. When forwarding the message, the node supporting SRv6 queries the local SID table according to the destination address in the message, and when the destination address of the message matches any SID in the local SID table, it is confirmed that the destination address hits the local SID table, and then, based on the topology, instruction or service corresponding to the SID, a corresponding operation is performed. If the destination address of the message is not matched with each SID in the local SID table, inquiring the IPv6 routing forwarding table according to the destination address, and forwarding the message according to the routing hit by the destination address in the routing forwarding table. The node receiving the message may be used as a node with different functions in different transmission paths, and the operation on the message is different, so that the node has a local SID table, and different SIDs exist in the local SID table.
The local SID table is a table maintained by the SRv enabled node. The functions of the local SID table are mainly three. First, a locally generated SID, such as an end.x SID, is defined. Second, instructions bound to these SIDs are specified. Third, forwarding information associated with these instructions is stored, such as out-interfaces and next hops, etc.
Since SRv6 typically uses a SRH carried segment list, SRv6 packets may be IPv6 packets containing SRHs. The IPv6 packet includes an IPv6 header, an extension header, and a payload, and SRH is an extension header added to implement SRv based on the IPv6 forwarding plane. The SRH includes a segment list, and the SRH designates an IPv6 display path according to the segment list. The head node adds SRH in the IPv6 message, and the intermediate node can forward the message according to the display path appointed by the SRH. By adding the extension head in this way, the SR technique is combined with the original IPv6 forwarding plane.
For example, as shown in fig. 1, the SRv6 message includes an IPv6 header, an SRH, and a payload, wherein the IPv6 header includes a destination address, and the SRH includes a segment list, a segment remaining field, and an extension header length. The details of the respective fields are explained below.
(1) Segment list
The segment list may include one or more SIDs, each of which may be in the form of an IPv6 address, so that the segment list may also be understood as an explicit IPv6 address stack. The segment list may be denoted as segment list [ n ] with a segment length (segment length) n bits. If the segment length is 128 bits, then the segment list [ n ] length is 128 x n bits. segment list is in the form of an IPv6 address.
(2) Remaining section
A Segment Left (SL) field is used to indicate the number of intermediate nodes visited before reaching the destination node. The SL field may also be referred to as a remaining node field. The value of the SL field may indicate the active SID in the segment list. The length of SL may be 8 bits. For example, the segment list includes 5 SIDs, where the 5 SIDs include SID0, SID1, SID2, SID3 and SID4, and the SL has a value of 2, which indicates that the nodes corresponding to two SIDs in the segment list are not accessed by the message, such as SID0 and SID1, and the current node in the segment list is to perform an operation on the message according to SID2, and the nodes corresponding to two SIDs in the segment list are accessed by the message, such as SID3 and SID4.
(3) Extension head Length (header Extended Length, hdr Ext Len)
The extension header length field is used to indicate the length of the SRH header. The length of the SRH header mainly refers to the length of the segment list, e.g., the length occupied from segment list [0] to segment list [ n ].
In addition to the above segment list, the segment remaining field, and the extension Header Length field, the SRH may further include a Type-Length-Value (TLV) field, a Next Header (Next Header) field, a Routing Type (Routing Type) field, a Last Entry (Last Entry) field, a Flag (Flag) field, a Tag (Tag) field, and a payload, and the specific roles and formats of the fields are described in reference to the SRv protocol for description of the SRH format, which is not repeated herein.
The structure of SRv message is described above, and SID SRv message is used to indicate the forwarding operation of SRv6 message in the forwarding process of SRv message, and the SRv SID is described below in connection with fig. 2.
Fig. 2 is a schematic structural diagram of SRv SID according to an embodiment of the present application. The SID includes location (Locator) information and Function (Function) information, and the SID has a format of Locator: function. Optionally, the SID may also include parameter (images) information, and the SID is in the format of Locator Function to images. After SRv SID is generated, the local SID table of the node is added, and the local SID table can be published through a routing protocol. In actual forwarding, the positioning information in SRv SID is used to route other nodes in the network, find SRv generation node of SID, and forward SRv6 message to the node. The function information is used for indicating the SRv SID generating node to perform corresponding function operation. The specific content of the positioning information and the functional information in SRv may refer to the description of SRv SID in SRv protocol, and will not be described herein.
The SRv technology and the SFC technology are combined, and processing and forwarding of the service chain message in the SFC domain can be achieved based on the SRv technology. SFC is a technique that provides ordered services to the application layer. SFC is used to logically link traffic functions on network devices together to form an ordered combination of services.
The SRv SFC technique is described below in connection with one system 300 illustrated in FIG. 3. The system 300 is illustrative of the architecture of SRv SFC. The system 300 comprises a software defined network (Software Defined Networking, SDN) controller 301, a terminal 308 and a server 309.SDN controller 301 is used to perform flow control in system 300. For example, SDN controller 301 establishes a traffic function path (service function path, SFP) by means of border gateway protocol link state (border gateway protocol-link state, BGP-LS) or path computation element communication protocol (path computation element communication protocol, PCEP) to collect and compute paths, so that a message sent by terminal 308 to server 309 may be transmitted to server 309 via the traffic function path in the SFC domain. The terminal 308 may be a cell phone terminal, a tablet computer, a notebook computer, a Virtual Reality (VR) device, an augmented Reality (augmented Reality, AR) device, a Mixed Reality (MR) device, an Extended Reality (ER) device, a camera or a vehicle terminal, etc., or may be an edge device (e.g., a box carrying a chip with processing capability), etc. The server 309 is configured to receive, through the SFC domain included in the system 300, a message sent by the terminal 308, perform service function processing on the message, or return, according to the message, data requested by the terminal 308 to the terminal 308, for example, the address allocated by the server 309 is requested by the terminal 308.
In the scenario shown in fig. 3, the SFC domain includes an SC node 302, a first SFF node 303, a second SFF node 304, and an SF node 305. The terminal 308, the SC node 302, the first SFF node 303, the second SFF node 304, and the server 309 are connected in this order. In order to enable the SFF nodes in the network to realize load sharing, the SF nodes can be connected with at least two SFF nodes, and the at least two SFF nodes process messages of the SF nodes. For example, the SF node 305 connects the first SFF node 303 and the second SFF node 304 in a dual-homing connection manner, i.e., the SF node 305 connects the first SFF node 303 and the second SFF node 304.
The SF node 305 performs dual-homing access to the first SFF node 303 and the second SFF node 304, which means that the first SFF node 303 and the second SFF node 304 use the same communication parameter configuration (e.g., the IP address of the node, the Anycast-SID, etc.) to communicate with the SF node 305, and perform the same operation on the received message. For example, the first SFF node 303 or the second SFF node 304 sends a message to the SF node 305 according to the received message, and sends the same message to the next hop node according to the received message processed by the SF node 305. The first SFF node 303 can communicate with the SF node 305 instead of the second SFF node 304, and the second SFF node 304 can also communicate with the SF node 305 instead of the first SFF node 303, thereby supporting load balancing or dual-homed link protection between the first SFF node 303 and the second SFF node 304.
The SC node 302 is configured to perform traffic classification on a packet entering the SFC domain. For example, SC node 302 determines the tunnel identity corresponding to the five-tuple (source IP address, source port, destination IP address, destination port, and transport layer protocol) from one or more elements in the five-tuple included in the message. The tunnel identifications include a head node (head) identification and a destination node (Endpoint) identification. SC node 302 determines SRv Policy matching the tunnel identification based on SRv Policy, which contains a head node (head) identification and a destination node (Endpoint) identification, and the tunnel identification. SRv6 Policy also includes a segment list that corresponds to the candidate path for processing the message. Optionally, the tunnel identifier further comprises a Color (Color) identifier. SC node 302 may determine a tunnel identity from one or more elements in the five-tuple included in the message, the tunnel identity comprising a head node (head) identity, a destination node (Endpoint) identity, and a color identity. SC node 302 determines SRv6 Policy matching the tunnel identifier based on SRv Policy, which includes a head node (head) identifier, a destination node (Endpoint) identifier, and a color identifier, and the tunnel identifier. SRv6 Policy also includes a segment list that corresponds to candidate paths that satisfy traffic demands that can be distinguished by color identification, such as low latency demands that can be identified with a color identification having a value of 100. The first SFF node 303 and the second SFF node 304 are configured to forward the received SRv message. For example, the first SFF node 303 receives the SRv message sent by the SC node 302, and forwards the message to the SF node 305 according to the SRH included in the SRv message. The first SFF node 303 is further configured to send the first segment list to the second SFF node 304 when receiving the SRv message from the SC node 302. The second SFF node 304 is further configured to receive the first segment list sent by the first SFF node 303, to perform SRH encapsulation on the message received from the SF node 305, and send the message after SRH encapsulation to the server 309.
As a possible implementation, the communication between the first SFF node 303, the second SFF node 304 and the SF node 305 may be implemented using SFC Proxy. SFC Proxy includes four types, also known as four Proxy modes. Specifically, SR proxy includes static proxy (static proxy), dynamic proxy (dynamic proxy), pseudo proxy (masquerading proxy), and shared-memory proxy (shared-memory proxy).
The manner of static proxy is based on end.as SID implementation. The end.as SID is used to identify one SF node in SRv SFC. The forwarding actions corresponding to the end.as SID are: before the message is sent from the SFF node to the SF node, the SFF node firstly unpacks the message and then forwards the message according to an output interface associated with the end.AS SID; after the message goes from the SF node to the SFF node, the SFF node repackages the message according to the input interface of the message or the End.AS SID and configuration thereof associated with the virtual local area network (Virtual Local Area Network, VLAN) corresponding to the input interface.
The dynamic proxy approach is based on end.ad SID implementation. The end.ad SID is used to identify one SF node in SRv SFC. The forwarding actions corresponding to the end.ad SID are: before a message is sent from an SFF node to an SF node, the SFF node strips SRH from SRv message to obtain a message which does not contain SRH, the message which does not contain SRH is sent to the SF node, and the SFF node caches the SRH; the SFE node receives the message which does not contain the SRH, processes the message, and returns the processed message to the SFF node; after receiving the message which does not contain the SRH and is returned by the SF node, the SFF node acquires the SRH from the buffer memory, repackages the processed message into the SRH, restores the message into a SRv message, and forwards SRv message.
The manner of pseudo-proxy implementation is based on end.am SID. The end.am SID is used to identify one SF node in SRv SFC. The forwarding actions corresponding to the end.am SID are: before the message is sent from the SFF node to the SF node, the SFF node firstly modifies the destination address of the SRv message into a first SID value in the SRH, and then forwards the message according to an output interface associated with the end.AM SID. After the message is sent from the SF node to the SFF node, the SFF sets the destination address of the SRv message as the SID value indicated by SL in SRH, and forwards the message according to the normal SRv message forwarding flow.
In this embodiment, taking a dynamic Proxy as an example, the first SFF node 303 and the second SFF node 304 utilize the SFC Proxy function to forward a received packet to the SF node 305 or forward a packet received from the SF node 305, and the operations of forwarding the received packet and forwarding the packet received from the SF node 305 are dynamic Proxy operations corresponding to an endpoint dynamic Proxy SID (End.
Alternatively, the end.ad SID configured by the first SFF node 303 and the second SFF node 304 may be an Anycast-SID, that is, an Anycast end.ad SID, so that the first SFF node 303 and the second SFF node 304 perform the same dynamic proxy operation corresponding to the Anycast end.ad SID when sending a message to the SF node 305 or receiving a message sent by the SF node 305. In this embodiment, the dynamic proxy operation corresponding to the Anycast end.Ad SID may further include an operation of synchronizing the list, and the operation of synchronizing the list is specifically referred to step 402 and will not be described herein.
SF node 305 performs service function processing on the message. For example, the type of traffic function processing performed by the SF node 305 on the message may be, but is not limited to, firewall, load balancing, application accelerator, lawful interception, network address translation (Network Address Translation, NAT), bandwidth control, virus detection, cloud storage, deep packet inspection (Deep Packet Inspection, DPI), intrusion detection or intrusion prevention, and the like. SF nodes are divided into SF (SRv-aware SF) nodes that are aware of SRv encapsulation and SF (SRv 6-unaware SF) nodes that are not aware of SRv encapsulation. SRv6-aware SF nodes can recognize and process the received SRv6 message, SRv-unaware SF nodes do not recognize SRv message, and discard it after reception. In this embodiment, taking an example that the SF node 305 is a SRv6-unaware SF node, the SF node 305 needs the first SFF node 303 and the second SFF node 304 to use a dynamic proxy function to implement message transmission between the SF node 305 and the SFF node. In the SFC field, the SF node 305 is also called Value-added Service (VAS). In this embodiment, after processing a packet sent by the first SFF node 303, the SF node 305 sends the processed packet to the first SFF node 303 or the second SFF node 304.
As a possible implementation manner, the SFC domain may also be constructed based on the leaf-ridge topology network structure, because the leaf-ridge topology network structure has strong scalability and can improve network communication efficiency. For example, the SFC domain further includes a Spine (Spine) node 306 and a Tail End node (Tail End) 307, and the SC node 302 is connected to the first SFF node 303, the second SFF node 304, and the Tail End node 307 via the Spine node 306, respectively, and the Tail End node 307 is further connected to a server 309. The spine node 306 and the tail node 307 belong to nodes for forwarding the message in the spine topology network structure, and the load of the message is not processed, and the mode of processing the message by the spine node 306 and the tail node 307 is not repeated here.
When the SFC domain is built based on a Leaf-spine topology network, the SC node 302 acts as an in-chain Leaf (Access Leaf) in the Leaf-spine topology network, and the first SFf node 303 and the second SFf node 304 act as service leaves (Server Leaf) in the Leaf-spine topology network.
It should be noted that, in the embodiment of the present application, the specific form of the node is not limited, and the node may be a physical device or a virtual machine. For example, the SC node 302, the first SFF node 303, the second SFF node 304, the spine node 306, and the tail-end node 307 may each be a physical device or a virtual machine, such as a router, switch, or the like. At least one node is deployed on the same physical device. In addition, the physical entity of SF node 305 may be a physical device or a virtual machine, such as a server, a host, a personal computer, a network device, or a terminal device.
In a possible implementation, one or more network devices may also be included between the terminal 308 and the SC node 302, between the SC node 302 and the spine node 306, between the spine node 306 and the tail end node 307, and between the tail end node 307 and the server 309, and the specific structure of the system 300 is not limited in this embodiment.
The embodiment of the application provides a data processing method, when one SFF node connected with SF node dual-homing receives SRv message, the SFF node connected with SF node dual-homing but not receiving SRv message sends SRv segment list in SRH of 6 message. Compared with the scheme that the SFF node which does not receive the SRv message does not know the SRH of the SRv message and does not have the function of carrying out SRH encapsulation on the message processed by the SF node, the message transmission is terminated at the SFF node, and the message transmission fails, the data processing method provided by the embodiment enables the SFF node which does not receive the SRv message to be capable of continuously transmitting the message based on SRv protocol for the message encapsulation SRH processed by the SF node according to the segment list, and improves the reliability of the message transmission.
The data processing method provided in the embodiment of the present application may be applied to a scenario in which an SF node in SRv SFC is dual-homed to access two SFF nodes, and the following embodiment is exemplified by the system 300. Fig. 4 is a schematic diagram of a data processing method according to an embodiment of the present application, where the method may be applied to SFF nodes in SRv SFC, for example, the first SFF node 303 and the second SFF node 304 in the system 300, and the method includes steps 401-404.
Step 401, the first SFF node 303 receives a first segment identification and a first segment list.
The first segment identifier and the first segment list may be sent to the first SFF node 303 in the form of a first packet, where the first packet is a SRv packet sent by a last hop node of the first SFF node 303, and the SRv6 packet includes a header and a payload. The last hop node of the first SFF node 303 is the leaf ridge node 306. In further embodiments, the last hop node of the first SFF node 303 may also be a network device other than the spine node 306, such as the SC node 302.
The message header contains an IPv6 header and an SRH, the destination address in the IPv6 header contains a first segment identification, e.g., an Anycast end. The first segment list includes orderly arranged segment identifiers for indicating a transmission path of the first message and a dynamic proxy operation corresponding to the first message at each node. For example, the first segment list indicates, with the segment identifiers arranged in order, that the transmission path of the first message is: leaf spine node 306- > SF node 305- > leaf spine node 306- > tail end node 307- > server 309. The first segment identification is used to instruct the first SFF node 303 to perform the operation of synchronizing the list. The operation of the first segment identifying the corresponding synchronization list may include: the first SFF node 303 sends the first segment list to the second SFF node 304, causing the second SFF node 304 and the first SFF node 303 to synchronize the list.
In other embodiments, the first segment list may not be set in the SRH, for example, the payload of the first packet includes the first segment list, or a new extension header is added to the header of the first packet to carry the first segment list.
In some possible embodiments, the SF node 305 returns the processed message to the first SFF node 303, and the first SFF node 303 needs to have a function of SRH packaging the processed message by the SF node 305. Therefore, the dynamic proxy operation corresponding to the first segment identifier may further include the first SFF node 303 storing the first segment list, so that the first SFF node 303 also has the capability of performing SRH encapsulation according to the first segment list, and can forward the message sent by the SF node 305. For example, the first SFF node 303 caches the first segment list into a cache memory for holding the segment list according to the first segment identification, and the cached segment list in the cache memory may be referred to as a cahce list. It should be noted that the operation of the synchronization list in this embodiment may be to perform cache synchronization on the cahce list of the first SFF node 303 and the cahce list of the second SFF node 304.
Step 402, the first SFF node 303 sends the first segment list to the second SFF node according to the first segment identifier.
The first SFF node 303 queries the local SID table according to the destination address in the IPv6 header of the first packet, and if the destination address hits the first segment identifier in the local SID table, performs a dynamic proxy operation corresponding to the first segment identifier, where the dynamic proxy operation includes an operation of synchronizing the list, that is, the first SFF node 303 sends the first segment list to the second SFF node 304 according to the first segment identifier.
Alternatively, the first SFF node 303 may send the first segment list to the second SFF node 304 when the first segment identification is not held in the cache memory of the first SFF node 303. The first segment identifier is not stored in the cache memory of the first SFF node 303, which may mean that the cache memory used for storing the segment list in the first SFF node 303 is empty, or that the cache list stored in the cache memory is different from the first segment list. Thus, in the case that the second SFF node 304 has cached the first segment list, the first SFF node 303 sends the first segment list to the second SFF node 304 again, so as to reduce the waste of communication resources.
As a possible implementation, the first SFF node 303 sends the first segment list to the second SFF node 304 in the form of a message. For example, the first SFF node 303 generates a second packet according to the first segment list, and sends the second packet including the first segment list to the second SFF node 304, so that the second SFF node 304 can obtain the first segment list from the second packet, and encapsulates the packet SRH sent by the SF node 305.
For example, the second message may be an NLRI message, i.e., an Update message containing an NLRI. Referring to fig. 5, fig. 5 is a schematic structural diagram of an NLRI according to an embodiment of the present application. The present embodiment adds a new type of NLRI, which includes a segment list length field, a segment remaining field, and a first segment list. The segment list length is used to indicate the length of the first segment list. The segment remaining field is used to indicate the SID of the destination address hit in the first message received by the current device, i.e., the first SFF node 303.
Since the segment identifier length of SRv is usually 128 bits (bit), when the number of segment identifier layers increases, the header overhead is larger, which will affect the forwarding efficiency, and when forwarding SRv packets, there is a case of compressing the SID carried by the SRH. Optionally, the NLRI provided in this embodiment may further include a compression type (compressed type) field and a compression segment remaining (CL) field, so that the first SFF node 303 can identify the compression segment identifier. The compression type field is used to indicate the protocol (e.g., G-SRv6 protocol) used to compress the SID carried by the SRH. The compressed segment remaining field is used to indicate the compressed segment identification (e.g., G-SID (Generalized SID)) of the destination address hit in the first message received by the current device (e.g., first SFF node 303).
It should be noted that the NLRI further includes conventional data carried by the NLRI such as a route specifier field, an ethernet segment field, and an ethernet label segment. The route specifier field is used to indicate the value of the route specifier (Route Distinguisher, RD) set under the EVPN (Ethernet Virtual Private Network) instance. The ethernet segment field is used to indicate the unique identification of the connection with the peer, i.e., the second SFF node 304. The ethernet label segment is used to indicate the VLAN ID actually configured by the current device, i.e. the first SFF node 303.
Optionally, the length of the route specifier, the ethernet segment field, the segment list length, and the segment remaining field in the NLRI may be flexibly adjusted according to the message structure. For example, the route specifier field may contain 8 bytes, the ethernet segment field may contain 10 bytes, the segment list length field may contain 1 byte, the segment remainder field may contain 1 byte, the compression type field may contain 1 byte, and the compression segment remainder field may contain 2 bytes.
As another example, the second message may be an M-LAG message. Referring to fig. 6, fig. 6 is a schematic structural diagram of an M-LAG message according to an embodiment of the present application. The M-LAG message in this embodiment includes a first message, where the first message includes a first segment list, so that the second SFF node 304 obtains the first segment list according to the first message including the first segment list after receiving the M-LAG message.
Specifically, the first message includes a message Header and a payload, the message Header is a custom message Header (Msg Header), the payload includes a Type (Type) field, a Length (Length) field, and a Value (Value) field, and the Value field includes an M-LAG ID and the first message. The custom Header (Msg Header), type field, length field, value field, and M-LAG ID may be described in the M-LAG protocol, and will not be described herein.
The encapsulation format of the second message is not limited in this embodiment, for example, the second message may also be a message encapsulated based on a redundant user information (Redundancy User Information, RUI) protocol. The RUI protocol is used to realize backup of user information between devices, and is carried on a transmission control protocol (TCP, transmission Control Protocol), and specifies which user information is transferred between two devices, the format and number of transferring user information, and the like.
Step 403, the second SFF node 304 stores the first segment list sent by the first SFF node.
The second SFF node 304 receives the first segment list from the first SFF node 303 and maintains the first segment list.
The first segment list is a segment list included in the SRH in the first packet received by the first SFF node 303. As one possible implementation, the first segment list may be sent in a message to the second SFF node 304.
For example, the second packet is an NLRI packet, and the second SFF node 304 determines the position of the first segment list in the second packet according to the segment list length included in the NLRI of the NLRI packet, extracts the first segment list, and stores the first segment list and the segment remaining fields in the cache memory.
For another example, the third message is an M-LAG message, and the second SFF node 304 may utilize SRv function to strip SRH from the first message included in the value field of the M-LAG message, and store the first segment list and the segment remaining field in the SRH into the cache.
The second SFF node 304 stores the first segment list, which may be that the second SFF node 304 stores the first segment list in the cache list to a cache memory used by the second SFF node 304 to store the segment list.
Optionally, after the second SFF node 304 stores the first segment list, the second SFF node 304 may further forward the packet received from the SF node 305 according to the first segment list and the segment remaining field after receiving the packet package SRH, which is described in step 714 below, and will not be described herein.
In the data processing method provided in the embodiment of the present application, when the SF node 305 is dual-homed to access the first SFF node 303 and the second SFF node 304, the first SFF node 303 sends the segment list of the received SRv packet to the second SFF node 304, so that the cache synchronization is implemented by using the caches of the first SFF node 303 and the second SFF node 304 for storing the segment list. Therefore, when the second SFF node 304 receives the message processed by the SF node 305, the first segment list stored in the cache memory of the second SFF node 304 can be the packet SRH. Thereby avoiding failure of message transmission caused by the fact that the second SFF node 304 cannot forward the message received from the SF node 305 based on the SRv protocol, ensuring the link stability between the second SFF node 304 and the SF node 305, and improving the reliability of message transmission.
The data processing methods applied to the first SFF node 303 and the second SFF node 304 are described above in connection with FIGS. 4-6, and steps performed by the various nodes in the system 300 in the data processing methods are described in exemplary fashion.
Before the SC node 302 sends the SRv message to the first SFF node 303, the SC node 302 may further send a test message including the SRH to the first SFF node 303 when receiving the SRv Policy issued by the controller 301, so that the first SFF node 303 sends the segment list in the SRH to the second SFF node 304, and list presynchronization is completed. The test message may be a bidirectional forwarding detection protocol (Bidirectional Forwarding Detection, BFD) message. The test message includes a message header, and the test message differs from the first message in that the test message may not carry a load. The header of the test message contains the SRH determined by the SC node 302 according to SRv Policy.
The first SFF node 303 receives the test message, and the destination address of the test message hits a segment identifier in the local SID table of the first SFF node 303, where the segment identifier is used to indicate an operation of executing a synchronization list corresponding to the segment identifier, and the operation of synchronizing the list includes sending the segment list to the second SFF node 304. The operation of the first SFF node 303 to perform the synchronization list according to the segment identification is not described herein.
The following describes a specific manner in which each node of the system 300 processes a message during list presynchronization, taking steps 701-704 of fig. 7 as an example.
Step 701, SC node 302 sends a message a to leaf node 306.
The SC node 302 receives the SRv Policy sent by the controller 301, generates a packet a before the SR tunnel represented by the segment list included in the SRv Policy is successfully established according to the bidirectional forwarding detection protocol, and sends the packet a to the leaf node 306. SRv6 Policy is used to direct messages across the network by encapsulating the segment list for messages received by SC node 302 at SC node 302 using the source routing mechanism of segment routing. The SC node 302 in this embodiment includes a segment list of (6:5:1:3:1:1) according to SRv6 Policy. 6 is the segment identity of the server 309, 5 is the segment identity of the tail end node 307, 3 is the first segment identity of the SFC Proxy, 1 is the segment identity of the spine node 306.
Message a is a test message generated by SC node 302 according to SRv6 Policy. The IPv6 header of message a includes IPv6 da=1:: indicates that the destination address is segment identification 1:: of the spine node 306. The SRH of message a includes SRH (sl=4) (6::, 5:, 1:, 3:, 1:, sl=4 indicates that the value of the segment remaining field is 4 and the segment list is (6:, 5:, 1:, 3:, 1:). 6 represents the segment identity of the server 309, 5 represents the segment identity of the tail end node 307, 3 represents the first segment identity of the SFC Proxy, 1 represents the segment identity of the spine node 306. It should be noted that SFC may not be a strongly constraint path hop-by-hop, and the segment list in the SRH of message A may contain a minimum set, namely segment identification 3:: containing SFC Proxy and segment identification 5::: of tail-end node 307.
Step 702, the spine node 306 sends a message B to the first SFF node 303.
After the leaf spine node 306 receives the message a, a message B is generated according to the message a, and the message B is forwarded according to the destination address of the message B. The destination address 1 of the message a is shown as a segment identifier 1 in the local SID table of the hit spine node 306, the segment identifier 1 is used for indicating that the spine node 306 subtracts one from the value of the segment remaining field included in the SRH of the message a, so that sl=3, determines the segment identifier 3 of the next hop node, i.e. the first SFF node 303, according to the segment list and the segment remaining field (with the value of 3), and uses the segment identifier 3 as the destination address in the IPv6 header of the message B to obtain the message B. The spine node 306 sends message B to the first SFF node 303 according to the destination address 3 of message B.
Step 703, the first SFF node 303 sends the segment list to the second SFF node 304.
After the first SFF node 303 receives the packet B, the destination address 3 of the packet B hits the segment identifier 3 in the local SID table of the first SFF node 303, where the segment identifier 3 is used to indicate that the operation of executing the segment identifier 3 to the corresponding synchronization list is performed. The operation of the corresponding synchronous list comprises the following steps: the first SFF node 303 extracts the segment list from message B (6:5:1:3:1:1) and sends the segment list to the second SFF node 304. The operation of the first SFF node 303 to perform the synchronization list according to the first segment identifier may refer to step 402, which is not described herein.
Optionally, the first SFF node 303 encapsulates the segment list to send the segment list to the second SFF node 304 in the form of a message, for example, encapsulates it as a message C, and sends the message C to the second SFF node 304, where the message C includes the segment list.
Step 704, the second SFF node 304 receives and saves the segment list.
The operation of the second SFF node 304 to receive and save the segment list may refer to step 403, which is not described herein.
Because the SC node 302 uses the message a to trigger the operation of the synchronization list of the first SFF node 303 before sending the first message to the SFC domain according to the service message sent by the terminal 308, the problem that the second SFF node 304 does not save the first segment list when receiving the message returned by the SF node 305, and the second SFF node 304 cannot encapsulate the SRH for the message, and cannot continue forwarding the message based on the SRv protocol, which results in failure of message transmission is avoided.
After the first SFF node 303 completes list presynchronization according to the test message and the second SFF node 304, the destination address of the IPv6 header of the message received by the first SFF node 303 is 3. If the segment list carried by the message is the same as the segment list stored in the cache memory of the first SFF node 303, the first SFF node 303 does not need to execute the operation of synchronizing the list again. If the segment list carried by the message is different from the segment list stored in the cache memory of the first SFF node 303, for example, the cache memory is empty or the stored cahce list is different from the segment list carried by the message received by the first SFF node 303, the first SFF node 303 performs the operation of synchronizing the list again.
The SC node 302 generates SRv message according to the service message sent by the terminal 308, and sends SRv message to the first SFF node 303. The service message contains IP layer information such as a source IP address, a destination IP address, etc., where the source IP address is an IP address of the terminal 308, the destination IP address is an IP address of the server 309, and a transmission path of the SRv message is: SC node 302- > leaf spine node 306- > SF node 305- > leaf spine node 306- > tail end node 307- > server 309.
Since the first SFF node 303 and the second SFF node 304 communicate with the SF node 305 using the SFC Proxy function, the SRv message sent by the spine node 306 to the SF node 303 needs to be forwarded through the first SFF node 303 or the second SFF node 304. For example, the first SFF node 303 strips the SRH of the SRv message, sends the SRH-stripped message to the SF node 305, and sends the segment list in the SRH to the second SFF node 304.
The SF node 305 performs service processing on the SRH stripped packet received from the first SFF node 303, and then sends the processed packet to the second SFF node 304.
The second SFF node 304 performs SRH encapsulation on the processed message according to the segment list sent by the first SFF node 303, to obtain a repackaged SRv message, and sends the repackaged SRv6 message to the server 309.
The following describes a specific manner in which each node of the system 300 is configured to synchronize the list and forward the message according to the service message, taking steps 705-716 in fig. 7 as an example.
Step 705, the terminal 308 sends a service packet to the SC node 302.
The traffic message contains five tuples and/or data such as application log files, geospatial service data, etc. of the terminal 308. The source IP address in the five-tuple of the service message is the IP address of the terminal 308, and the destination IP address is 6, namely the IP address of the server 309.
Step 706, SC node 302 determines SRv Policy for service message matching.
The SC node 302 determines SRv Policy matching the service packet according to matching between one or more elements in the five-tuple of the service packet and the header node identifier and the destination node identifier of SRv Policy.
Step 707, the SC node 302 encapsulates the service packet according to SRv Policy to obtain a packet D.
The SC node 302 determines, according to the color identifier included in the service packet, a segment list included in a candidate path matched with the service packet in the Policy SRv, and encapsulates the service packet to obtain a packet D. Message D is a SRv message containing an IPv6 header, SRH and payload. The IPv6 header of message D includes IPv6 da=1:: indicates that the destination address is segment identification 1:: of the spine node 306. The SRH of message D includes SRH (sl=4) (6::, 5:, 1:, 3:, 1:, sl=4 indicates that the value of the segment remaining field is 4 and the segment list is (6:, 5:, 1:, 3:, 1:).
Step 708, SC node 302 sends message D to leaf ridge node 306.
The SC node 302 sends the message D to the leaf node 306 according to the destination address 1 of the IPv6 header of the message D.
Step 709, the spine node 306 sends a message E to the first SFF node 303.
After receiving the message D, the leaf node 306 generates a message E according to the message D, and forwards the message E according to the destination address of the message E.
The destination address of the message D hits the segment identifier 1 in the local SID table of the spine node 306, where the segment identifier 1 is used to instruct the spine node 306 to subtract one from the value of the remaining segment field included in the SRH of the message D, let sl=3, determine the segment identifier of the next hop node as 3 from the first segment list and the remaining segment field (with the value of 3), that is, the segment identifier of the first SFF node 303, and use the segment identifier 3 as the destination address in the IPv6 header of the message E to obtain the message E. The spine node 306 sends message E to the first SFF node 303 according to the destination address 3 of message E.
Step 710, the first SFF node 303 sends the segment list to the second SFF node 304.
After receiving the message E, the first SFF node 303 extracts the segment list from the message E, and sends the segment list to the second SFF node 304. The first SFF node 303 extracts the segment list from message E as (6::, 5:, 1:, 3:, 1:. Optionally, the first SFF node 303 sends the segment list to the second SFF node 304 in the form of a message F, which contains the segment list.
The destination address 3 of the message E hits in the segment identifier 3 in the local SID table of the first SFF node 303, the segment identifier 3 is used to instruct the first SFF node to perform the operation of segment identifier 3 in the corresponding synchronization list, and the operation of segment identifier 3 in the corresponding synchronization list includes sending the segment list to the second SFF node 304. The operation of the first SFF node 303 to perform list synchronization according to the first segment identifier may refer to step 402, which is not described herein.
Step 711, the second SFF node 304 receives and saves the segment list.
The operation of the second SFF node 304 to receive and save the segment list may refer to step 403, which is not described herein.
Step 712, the first SFF node 303 sends a message G to the SF node 305.
After the first SFF node 303 receives the packet E, the SRH of the packet E is stripped to obtain a packet G, and the packet G is sent to the SF node 305.
The destination address of the message E hits in the segment identifier 3 in the local SID table of the first SFF node 303, where the segment identifier 3 is further used to instruct the first SFF node 303 to strip the SRH of the message E to obtain the message G, send the message G to the SF node 305, and buffer the SRH of the message E.
Step 713, the SF node 305 sends a message H to the second SFF node 304.
After receiving the message G sent by the first SFF node 303, the SF node 305 performs service function (e.g. firewall, load balancing, application accelerator, lawful interception, network address conversion, bandwidth control, virus detection, cloud storage, deep packet inspection, intrusion detection or intrusion prevention) on the message G, so as to obtain a processed message H. The SF node 305 sends a message H to the second SFF node 304.
Alternatively, the SF node 305 may implement load sharing of the first SFF node 303 and the second SFF node 304 based on an interior gateway protocol (Interior Gateway Protocol, IGP), and the SF node 305 may determine that the second SFF node 304 is sending the message H when the idle computational power of the second SFF node 304 is higher than the first SFF node 303.
Step 714, the second SFF node 304 sends a message I to the spine node 306.
After receiving the message H sent by the SF node 305, the second SFF node 304 performs SRH encapsulation on the message H to obtain a message I, and sends the message I to the leaf node 306.
The local SID tables of the second SFF node 304 and the first SFF node 303 are configured with the same segment identifier 3, where the segment identifier 3 is further used to instruct the second SFF node 304 to perform SRH encapsulation on the message H to obtain a message I, and send the message I to the leaf ridge node 306.
The second SFF node 304 extracts the segment list (6:5:1:3:1:1) from cahce based on segment identity 3:1:1:encapsulating SRH for message H to obtain message I, message I comprising IPv6 DA=1:1:srH comprising SRH (SL=2) (6:5:1:3:1:1:1, determines the segment identity of the next hop node, i.e. the segment identity of the leaf ridge node 306 based on the first segment list and the remaining segment fields (value 2), and takes the segment identity 1:1:1:as the destination address in the IPv6 header of message I to obtain message I. The second SFF node 304 sends message I to the leaf ridge node 306 based on the destination address 1:1:1:1 of message I.
Step 715, the spine node 306 sends message J to the tail-end node 307.
After receiving the message I sent by the second SFF node, the leaf spine node 306 generates a message J according to the message I, and forwards the message J according to the destination address of the message J. The destination address of the message I hits the segment identifier 1 in the local SID table of the spine node 306, the segment identifier 1 is used to instruct the spine node 306 to subtract one from the value of the segment remaining field included in the SRH of the message I, let sl=1, determine the segment identifier of the next hop node as 5 from the first segment list and the segment remaining field (with the value of 1), i.e. the segment identifier of the tail end node 307, and use the segment identifier 5 of the tail end node 307 as the destination address in the IPv6 header of the message J to obtain the message J. The spine node 306 sends message J to the tail-end node 307 based on the destination address 5 of message J.
Step 716, tail end node 307 sends message K to server 309.
After receiving the message J sent by the leaf node 306, the tail node 307 generates a message K according to the message J, and forwards the message K according to the destination address of the message K.
The destination address of the message J hits in the segment identifier 5 in the local SID table of the tail node 307, the segment identifier 5 is used to instruct the tail node 307 to subtract one from the value of the segment remaining field contained in the SRH of the fifth message, to make sl=0, to determine the segment identifier of the next hop node as 6 from the first segment list and the segment remaining field (with a value of 0), i.e. the segment identifier of the server 309, and to use the segment identifier 6 of the server 309 as the destination address in the IPv6 header of the message J to obtain the message K. The tail-end node 307 sends message K to the server 309 according to the destination address 6 of message K.
It should be noted that, the processing manner of the message K after the server 309 receives the message K is not limited in the embodiment of the present application. For example, the server 309 returns data requested by the terminal 308 to the terminal 308 according to the message K.
It will be appreciated that in order to implement the functionality of the above-described embodiments, the computing device includes corresponding hardware structures and/or software modules that perform the various functions. Those of skill in the art will readily appreciate that the elements and method steps of the examples described in connection with the embodiments disclosed herein may be implemented as hardware or a combination of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application scenario and design constraints imposed on the solution.
The data processing method provided according to the present embodiment is described in detail above with reference to fig. 1 to 7, and the data processing apparatus provided according to the present embodiment will be described below with reference to fig. 8, 9, and 10.
Fig. 8 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application. The data processing apparatus may be configured to implement the function of the first SFF node 303 in the above-described method embodiment, so that the foregoing method embodiment also has the beneficial effects. In this embodiment, the data processing apparatus may be the first SFF node 303 as shown in fig. 3, or may be a module (e.g. a chip) applied to a server.
As shown in fig. 8, the data processing apparatus 800 includes: an acquisition module 801 and a transmission module 802. Illustratively, the acquisition module 801 is configured to support the data processing apparatus 800 to acquire data. The transmitting module 802 is configured to support the data processing apparatus 800 to transmit data. Optionally, if the data processing apparatus 800 includes a storage unit, the data processing apparatus 800 may further execute a program or instructions stored in the memory, so as to implement the methods and functions related to any of the foregoing embodiments.
By way of example, the acquisition module 801 may be used to perform, for example, step 401 in fig. 4, and/or other processes for the techniques described herein. The above-described transmitting module 802 may be used to perform, for example, step 402 in fig. 4, and/or other processes for the techniques described herein. All relevant contents of each step related to the above method embodiment may be cited to the functional description of the corresponding functional module, which is not described herein.
Illustratively, on a hardware implementation, the functions of the acquisition module 801, the transmission module 802 may be performed by a transceiver (transmitter/receiver) and/or a communication interface.
Fig. 9 is a schematic structural diagram of another data processing apparatus according to an embodiment of the present application. The data processing apparatus may be configured to implement the function of the second SFF node 304 in the above-described method embodiment, so that the foregoing method embodiment also has the beneficial effects. In this embodiment, the data processing apparatus may be the second SFF node 304 shown in fig. 3, or may be a module (e.g., a chip) applied to a server.
As shown in fig. 9, the data processing apparatus 900 includes: a receiving module 901 and a processing module 902. Illustratively, the receiving module 901 is configured to support the data processing apparatus 900 to receive a message. The processing module 902 is configured to control and manage the operations of the data processing apparatus 900. Alternatively, if the data processing apparatus 900 includes a storage unit, the processing module 902 may further execute a program or instructions stored in the memory, so that the data processing apparatus 900 implements the methods and functions related to any of the foregoing embodiments.
Illustratively, the receiving module 901 may be configured to perform the step of receiving the first segment list sent by step 402 in fig. 4, and/or other processes for the techniques described herein. The processing module 902 described above may be used to perform, for example, step 403 in fig. 4, and/or other processes for the techniques described herein. All relevant contents of each step related to the above method embodiment may be cited to the functional description of the corresponding functional module, which is not described herein.
Illustratively, in a hardware implementation, the functions of the receiving module 901 may be performed by a transceiver (transmitter/receiver) and/or a communication interface, and the functions of the processing module 902 may be performed by a processor, where the processing module 902 may be embedded in hardware or independent of a processor of the data processing apparatus 900, or may be stored in software in a memory of the data processing apparatus 900, so that the processor invokes operations corresponding to the above functional units.
As shown in fig. 10, the present embodiment also provides yet another data processing apparatus 1000, the data processing apparatus 1000 including a memory 1001, a processor 1002, and a communication interface 1003. The memory 1001 is configured to store computer program code, which includes computer instructions, and the communication interface 1003 is configured to receive and transmit a message, for example, to perform the functions of the acquisition module 801 in the data processing apparatus 800 described above. When the processor 1002 executes the computer instructions, the data processing apparatus 1000 performs the steps of the first SFF node 303 or the second SFF node 304 in the data processing method as described above in fig. 4 or fig. 7, and may also perform the functions of the processing module 902 in the data processing apparatus 900.
Embodiments of the present application also provide a computer-readable storage medium having stored therein computer-executable instructions that, when executed by at least one processor of a device, perform the steps of the data processing method shown in fig. 4 or fig. 7.
Embodiments of the present application also provide a computer program product comprising computer-executable instructions stored in a computer-readable storage medium; the at least one processor of the apparatus may read the computer-executable instructions from the computer-readable storage medium, the at least one processor executing the computer-executable instructions causing the apparatus to perform the steps of executing the first SFF node 303 or the second SFF node 304 in the data processing method illustrated in FIG. 4 or FIG. 7.
The steps of a method or algorithm described in connection with the disclosure herein may be embodied in hardware, or may be embodied in software instructions executed by a processor. The software instructions may be comprised of corresponding software modules that may be stored in random access memory (Random Access Memory, RAM), flash memory, erasable programmable read-only memory (Erasable Programmable ROM, EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disk, a removable disk, a compact disc read-only memory (CD-ROM), or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. In addition, the ASIC may be located in a core network interface device. The processor and the storage medium may reside as discrete components in a core network interface device.
Those of skill in the art will appreciate that in one or more of the examples described above, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, these functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer.
The foregoing embodiments have been provided for the purpose of illustrating the technical solution and advantageous effects of the present application in further detail, and it should be understood that the foregoing embodiments are merely illustrative of the present application and are not intended to limit the scope of the present application, and any modifications, equivalents, improvements, etc. made on the basis of the technical solution of the present application should be included in the scope of the present application.

Claims (23)

1. A data processing method performed by a first service function forwarding, SFF, node in communication with a service function, SF, node, the method comprising:
acquiring a first segment identifier and a first segment list, wherein the first segment identifier is used for indicating a synchronous list;
and sending the first segment list to a second SFF node which communicates with the SF node according to the first segment identifier, wherein the first segment list is used for packaging the message from the SF node.
2. The method of claim 1, wherein obtaining the first segment identification and the first segment list comprises:
receiving a first message from a service classification SC node, wherein the first message comprises the first segment identifier and the first segment list; or alternatively
And receiving a first message from a spine node, wherein the first message comprises the first segment identifier and the first segment list.
3. The method of claim 1 or 2, wherein transmitting the first segment list to a second SFF in communication with the SF node in accordance with the first segment identification comprises:
and sending a second message to the second SFF according to the first segment identifier, wherein the second message comprises the first segment list.
4. A method according to claim 3, wherein the payload of the second message comprises the first segment list; or the load of the second message comprises the first message, and the first message comprises the first segment list.
5. The method according to any of claims 1-4, wherein the second message is a network layer reachability message, a redundant user information message, or a network multisystem link aggregation group message.
6. The method according to any of claims 1-5, wherein the first message comprises a segment routing header, SRH, the SRH comprising the first segment identity and the first segment list.
7. The method of any of claims 1-6, wherein the first segment identification is further used to indicate that the first segment list is to be saved, the method further comprising:
And storing the first segment list according to the first segment identification.
8. A data processing method performed by a second service function forwarding, SFF, node in communication with a service function, SF, node, the method comprising:
receiving a first segment list sent by a first SFF node in communication with the SF node;
and storing the first segment list, wherein the first segment list is used for packaging SRH for the message from the SF node to guide forwarding to the next hop.
9. The method of claim 8, wherein receiving the first segment list sent by the first SFF node in communication with the SF node comprises:
and receiving a first message sent by the first SFF node, wherein the first message comprises the first segment list.
10. The method according to claim 8 or 9, wherein the payload of the first message contains the first segment list, or wherein the first message comprises a second message, wherein the payload of the second message contains the first segment list.
11. The method according to claim 9 or 10, wherein the first message is a network layer reachability message, a redundant user information message, or a network multisystem link aggregation message.
12. A data processing apparatus, the apparatus being arranged at a first service function forwarding, SFF, node in communication with a service function, SF, node, the apparatus comprising:
the device comprises an acquisition module, a synchronization module and a synchronization module, wherein the acquisition module is used for acquiring a first segment identifier and a first segment list, and the first segment identifier is used for indicating the synchronization list;
and the sending module is used for sending the first segment list to a second SFF node which communicates with the SF node according to the first segment identifier, and the first segment list is used for packaging the message from the SF node.
13. The apparatus of claim 12, wherein the obtaining module is specifically configured to:
receiving a first message from a service classification SC node, wherein the first message comprises the first segment identifier and the first segment list; or alternatively
And receiving a first message from a spine node, wherein the first message comprises the first segment identifier and the first segment list.
14. The apparatus according to claim 12 or 13, wherein the sending module is specifically configured to:
and sending a second message to the second SFF according to the first segment identifier, wherein the second message comprises the first segment list.
15. The apparatus of claim 14, wherein the payload of the second message comprises the first segment list; or the load of the second message comprises the first message, and the first message comprises the first segment list.
16. The apparatus according to any of claims 12-15, wherein the second message is a network layer reachability message, a redundant user information message, or a network multisystem link aggregation group message.
17. The apparatus according to any of claims 12-16, wherein the first message comprises a segment routing header, SRH, the SRH comprising the first segment identity and the first segment list.
18. The apparatus according to any one of claims 12-17, wherein the apparatus further comprises:
and storing the first segment list according to the first segment identification.
19. A data processing apparatus, the apparatus being arranged at a second service function forwarding, SFF, node in communication with a service function, SF, node, the apparatus comprising:
a receiving module, configured to receive a first segment list sent by a first SFF node in communication with the SF node;
and the processing module is used for storing the first segment list, and the first segment list is used for packaging SRH for the message from the SF node so as to guide forwarding to the next hop.
20. The apparatus of claim 19, wherein the receiving module is specifically configured to: and receiving a first message sent by the first SFF node, wherein the first message comprises the first segment list.
21. The apparatus of claim 19 or 20, wherein the payload of the first message comprises the first segment list or the first message comprises a second message, wherein the payload of the second message comprises the first segment list.
22. The apparatus according to claim 20 or 21, wherein the first message is a network layer reachability message, a redundant user information message, or a network multisystem link aggregation message.
23. A system comprising a data processing apparatus as claimed in any one of claims 12 to 18 and a data processing apparatus as claimed in any one of claims 19 to 22.
CN202210772718.7A 2022-06-30 2022-06-30 Data processing method, device and system Pending CN117376233A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202210772718.7A CN117376233A (en) 2022-06-30 2022-06-30 Data processing method, device and system
PCT/CN2023/098698 WO2024001701A1 (en) 2022-06-30 2023-06-06 Data processing method, apparatus and system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210772718.7A CN117376233A (en) 2022-06-30 2022-06-30 Data processing method, device and system

Publications (1)

Publication Number Publication Date
CN117376233A true CN117376233A (en) 2024-01-09

Family

ID=89382814

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210772718.7A Pending CN117376233A (en) 2022-06-30 2022-06-30 Data processing method, device and system

Country Status (2)

Country Link
CN (1) CN117376233A (en)
WO (1) WO2024001701A1 (en)

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106411738A (en) * 2015-07-30 2017-02-15 中兴通讯股份有限公司 Processing method and apparatus of packaging of IPV6 message
CN110557329A (en) * 2018-05-30 2019-12-10 中兴通讯股份有限公司 message forwarding method, device and node
CN112787931B (en) * 2019-11-06 2022-09-23 华为技术有限公司 Message transmission method, proxy node and storage medium
CN112787921B (en) * 2019-11-08 2023-05-19 华为技术有限公司 Message transmission method, proxy node and storage medium
CN114338498B (en) * 2021-12-28 2024-04-09 中国电信股份有限公司 SRv 6-based message processing method, SRv-based message processing system, electronic equipment and medium

Also Published As

Publication number Publication date
WO2024001701A1 (en) 2024-01-04

Similar Documents

Publication Publication Date Title
US10757231B2 (en) Providing network efficiencies in forwarding packets among provider networks and applying segment routing policies
CN112787931B (en) Message transmission method, proxy node and storage medium
US8942238B2 (en) Apparatus and method for establishing tunnels between nodes in a communication network
CN112787921B (en) Message transmission method, proxy node and storage medium
EP3958521A1 (en) Method and apparatus for providing service for service flow
US20230078123A1 (en) Method for Forwarding Packet in SRV6 Service Function Chain and SF Device
US10791051B2 (en) System and method to bypass the forwarding information base (FIB) for interest packet forwarding in an information-centric networking (ICN) environment
WO2022001835A1 (en) Method and apparatus for sending message, and network device, system and storage medium
US20220255772A1 (en) Packet sending method, apparatus, and system
CN109936492B (en) Method, device and system for transmitting message through tunnel
CN112671628A (en) Business service providing method and system
CN111937358A (en) Multiple VRF generic device internet protocol addresses for fabric edge devices
WO2020182085A1 (en) Transmission method and device for message
WO2022184169A1 (en) Packet forwarding method and system, storage medium, and electronic device
WO2022117018A1 (en) Packet transmission method and apparatus
CN110022263B (en) Data transmission method and related device
CN112187584B (en) Path fault detection method, system, server and storage medium
WO2024001701A1 (en) Data processing method, apparatus and system
CN111447131B (en) Message de-encapsulation method and device and message encapsulation method and device
CN113497767A (en) Method and device for transmitting data, computing equipment and storage medium
CN113824608A (en) BIER OAM detection method, equipment and system
CN113055268A (en) Method, device, equipment and medium for tunnel traffic load balancing
US11979322B2 (en) Method and apparatus for providing service for traffic flow
CN117376232A (en) Message transmission method, device and system
WO2023040782A1 (en) Message processing method and system, and device and storage medium

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication