WO2017024818A1

WO2017024818A1 - Method and device for processing data message

Info

Publication number: WO2017024818A1
Application number: PCT/CN2016/080538
Authority: WO
Inventors: 王翠; 孟伟; 黄孙亮
Original assignee: 中兴通讯股份有限公司
Priority date: 2015-08-07
Filing date: 2016-04-28
Publication date: 2017-02-16
Also published as: CN106453204A; CN106453204B

Abstract

A method for processing data message includes: obtaining an enhanced context data header type; encapsulating the enhanced context data header type into a network service header, and encapsulating the network service header into a data message; transmitting the data message along a service forwarding path.

Description

Method and device for processing data message

Technical field

The present application relates to, but is not limited to, the field of communications, and in particular, to a method and apparatus for processing data messages.

Background technique

A technology of a service function chain (SFC) is proposed in the related art, that is, all services are integrated, and a service overlay layer is virtualized to form a service topology and decoupled from the underlying network. No longer limited by the underlying network structure, the architecture is shown in Figure 1. It can be seen that the SFC technology includes the following components: a classifier, a service function forwarder (SFF), a service function (SF), and a network service header proxy (Network Service Header Proxy). NSH Proxy). The Classifier is responsible for classifying the traffic, and according to the classification result, the network service header (NSH) is encapsulated in the traffic, that is, the service function path of the packet is determined on the Classifier, and the overlay layer is further encapsulated. And forwarding, the packet is forwarded to the next hop SFF through the overlay technology, the SFF receives the packet, decapsulates the overlay layer, and parses the received packet carrying the NSH header, according to the information in the NSH header. The SF is responsible for forwarding the packet to the corresponding SF. The SF is responsible for performing the corresponding service function processing on the received packet. After the processing, the NSH header is further updated and the updated packet is forwarded to its SFF. Further, the corresponding transport layer encapsulation is searched according to the information in the NSH packet, and the NSH packet is encapsulated and the packet is forwarded to the next hop SFF. The NSH Proxy mainly represents the SFF and interacts with the SF that does not perceive the NSH header. For example, as shown in Figure 2, the complete packet format sent from the Classifier after using the overlay technology of IPv4-GRE (Generic Routing Encapsulation) is shown in the outer packet of the original packet. NSH header, IPv4-GRE header, L2 header.

From the control point of view, the classification rules and service function chain definitions of the SFC and the NSH are issued or locally configured by the SFC controller; from the data plane encapsulation, the entire NSH of the service function chain and the service is as shown in FIG. 3, Including Base Header, Service Path Header (Service Path) Header), context header (Context Header), and variable length optional context data; wherein the basic header mainly identifies the version number, length, context data type, and next protocol number; the core of the service path header identifies the entire service function The service function path information of the chain, including the service path identifier (Service Path ID) and the service index (Service Index), wherein the service path identifier is globally delivered, and the node confirms, according to the service path identifier and the service index, where the current packet should be forwarded. A service function chain and which service function to process; the mandatory context header (Mandatory Context Header) is used to carry the context information that must be carried. The optional variable length Context Headers are used for optional carrying. Contextual information. The context information refers to information shared between the classifier and the service function SF, between the SFs, between the service function SFs and the service function forwarder SFFs, and information that needs to be transmitted.

Currently, in the IETF (Internet Engineering Task Force) SFC working group, there are two definitions of context data headers: one MD-type (Metadata type) = 1 (required support), In this case, the NSH packet header must carry a 4-byte mandatory context data header in addition to the optional variable-length context data header. The packet format is as shown in Figure 3. The other is MD-type (Metadata type) = 2 (optional support), the NSH packet header does not need to carry a 4-byte mandatory context data header. The format of the packet is as shown in Figure 4; whether it is MD-type=1 or MD-type=2, where The variable length optional context data format is shown in Figure 5.

Summary of the invention

The following is an overview of the topics detailed in this document. This Summary is not intended to limit the scope of the claims.

In the current IETF SFC working group, when MD-type=1, an extended definition is defined for a mandatory context data header that must carry 4 bytes. There are two main types of extension definitions: one is the mandatory context header extension definition for the data center scenario, as shown in Figure 6; the other is the mandatory context header extension definition for the mobile scenario, as shown in Figure 7. However, when a node receives an NSH packet carrying a context header, it does not know how to parse the context header. For example, it is not known whether to use the context header as the context data of the data center scene, or The context data of the moving scene is parsed, or it is parsed as context data in another scene. If the parsing error occurs, the context data information cannot be read correctly, causing the business process to fail.

This document provides a method and apparatus for processing data messages to enhance the recognition of context header types.

An embodiment of the present invention provides a method for processing a data packet, which is applied to a node supporting a service function chain, and the method includes:

Get an enhanced context data header type;

Encapsulating the enhanced context data header type in a network service header, and encapsulating the network service header in a data packet;

The data packet is sent along the service forwarding path.

Optionally, the enhanced context data header type includes any one of the following:

The context data header type of the data center scene, the context data header type of the mobile scene, and the context data header type of the broadband network scenario.

Optionally, the enhanced context data header type is configured according to network deployment conditions and/or context data header data information.

Optionally, the enhanced context data header type is locally configured or sent by a centralized controller.

Optionally, the data packet is composed of original data and a network service header, or is composed of original data, a network service header, and an overlay network packet header.

The embodiment of the invention further provides a computer readable storage medium storing computer executable instructions, the method for processing the data message being implemented when the computer executable instructions are executed.

The embodiment of the invention further provides a device for processing a data message, which is applied to a node supporting a service function chain, and the device includes:

The obtaining module is configured to: obtain an enhanced context data header type; the enhanced context data header type includes any one of the following: a context data header type of the data center scene, a context data header type of the mobile scene, and a broadband network scenario. Context data header type;

The encapsulating module is configured to: encapsulate the enhanced context data header type in a network service header, and encapsulate the network service header in a data packet, where the data packet is composed of original data and a network service header. Or consisting of original data, network traffic headers, and overlay network headers;

The sending module is configured to: send the data packet along a service forwarding path.

Optionally, the device further includes:

The configuration module is configured to: configure the enhanced context data header type according to network deployment conditions and/or context data header data information.

Optionally, the obtaining module is further configured to: obtain the enhanced context data header type that is locally configured or sent by the centralized controller.

The embodiment of the present invention further provides a method for processing a data packet, which is applied to a node supporting a service function chain, and the method includes:

Receiving a data packet carrying a network service header;

Parsing an enhanced context data header type in the network traffic header;

Reading context data information in the data message according to the enhanced context data header type.

Optionally, after the reading the context data information in the data packet according to the enhanced context data header type, the method further includes:

The context data information and/or the enhanced context data header type are updated when it is determined that the context data information needs to be updated.

Optionally, after the receiving the data packet carrying the network service header, the method further includes: parsing the service forwarding path information in the data packet;

After the context data information in the data packet is read according to the enhanced context data header type, the method further includes:

And forwarding the data packet or the updated data packet according to the service forwarding path information.

The receiving module is configured to: receive a data packet carrying a network service header;

a parsing module, configured to: parse an enhanced context header class in the network traffic header type;

The processing module is configured to: read context data information in the data packet according to the enhanced context data header type.

Optionally, the device further includes:

The update module is configured to: update the context data information and/or the enhanced context data header type when it is determined that the context data information needs to be updated.

Optionally, the parsing module is further configured to: parse the service forwarding path information in the data packet;

The processing module is further configured to: forward the data packet or the updated data packet according to the service forwarding path information.

In the foregoing SFC network, the context data header type identifier is further added to enhance the further identification of the context data header on the node supporting the service chain.

Other aspects will be apparent upon reading and understanding the drawings and detailed description.

BRIEF abstract

Figure 1 is a schematic diagram of an SFC technology architecture;

2 is a schematic diagram of a complete message structure sent from a Classifier component under SFC technology;

3 is a schematic diagram of a network service packet header NSH of MD-type=1 encapsulated in a data plane under SFC technology;

4 is a schematic diagram of a network service packet header NSH of MD-type=2 in a data plane encapsulation under SFC technology;

5 is a schematic diagram of an optional variable length context data header structure in an NSH;

6 is a schematic diagram of a mandatory context header extension definition of a data center scenario;

7 is a schematic diagram of a mandatory context data header extension definition of a mobile scenario;

FIG. 8 is a flowchart of a method for processing a data message on a sending node side according to an embodiment of the present invention;

FIG. 9 is a flowchart of a method for processing a data message on a receiving node side according to an embodiment of the present invention;

10 is a schematic diagram of a message reference format for enhancing a context data header type in an NSH according to an embodiment of the present invention;

11 is a schematic diagram of processing a data packet based on a data center scenario according to Embodiment 1 of the present invention;

FIG. 12 is a schematic diagram of processing a data packet based on a mobile scenario according to Embodiment 2 of the present invention; FIG.

13 is a schematic diagram of updating an enhanced context data header type on an intermediate node according to Embodiment 3 of the present invention;

FIG. 14 is a schematic diagram of an apparatus for processing a data message on a transmitting side according to an embodiment of the present invention; FIG.

FIG. 15 is a schematic diagram of an apparatus for processing a data message on a receiving side according to an embodiment of the present invention.

Preferred embodiment of the invention

Embodiments of the present invention will be described below with reference to the accompanying drawings. It should be noted that the embodiments in the present application and the various manners in the embodiments may be combined with each other without conflict.

FIG. 8 is a flowchart of a method for processing a data packet on a sending node side according to an embodiment of the present invention. As shown in FIG. 8 , the method is applied to a node supporting a service function chain, including:

Step 11. Obtain an enhanced context data header type.

Step 12: Encapsulating the enhanced context data header type in a network service header, and encapsulating the network service header in a data packet;

Step 13: Send the data packet along a service forwarding path.

Optionally, the enhanced context data header type includes any one of the following: a context data header type of the data center scenario, a context data header type of the mobile scenario, and a context data header type of the broadband network scenario.

Optionally, the enhanced context data header type is configured according to a network deployment situation and/or context data header data information, and may be locally configured; or may be delivered by a centralized controller;

Optionally, the data packet is composed of the original data and the network service header, or is composed of the original data, the network service header, and the overlay network packet header, where the original data is included in the data packet before the encapsulation. The included data; the overlay network header can be seen in Figure 2. The part in front of the NSH is the overlay network header.

FIG. 9 is a flowchart of a method for processing a data packet on a receiving node side according to an embodiment of the present invention. As shown in FIG. 9, the method includes:

Step 21: Receive a data packet carrying a network service header.

Step 22: Parsing an enhanced context data header type in the network service header;

Step 23: Read context data information in the data packet according to the enhanced context data header type.

The method can be applied to nodes that support a business function chain.

Optionally, the receiving node may update the context data information and/or the enhanced context data header type according to actual deployment conditions.

As shown in FIG. 10, it is a packet reference format based on an NSH extended enhanced context data header type field in an embodiment of the present invention; wherein an E-MD-ty identifier is an Enhanced MD-type, that is, an enhanced context data header type field; In the reference format, 4 bits are reserved in 8 bits (bits) of the MD-type to be applied to the embodiment of the present invention.

Embodiment 1:

As shown in Figure 11, the service function chain SFC1 in the data center can be SF2->SF5; SF1 and SF2 are connected to TOR (Top-of-Rack, set-top switch) 1/SFF1, and SF3 is connected to TOR2/SFF2. SF4 and SF5 are connected to TOR3/SFF3; that is, the service forwarding path experienced by the service function chain is SFP1: SFF1->SF2>SFF3->SF5.

The packet is sent to the data center gateway device. The gateway device is used as the classifier in the service function chain technology to classify the packet. The packet is forwarded to the service chain SFC1, that is, the corresponding service forwarding path is SFP1. Can include:

Step 101: Classifier node classification finds that an enhanced context data header type is obtained, and the traffic needs to enter the data center for processing, so that information about the service forwarding path and context data header information belonging to the data center scenario are acquired to form an NSH header. The NSH header is encapsulated in the original data packet and forwarded to the next hop node TOR1/SFF1 according to the service forwarding path.

Step 102: After receiving the packet, TOR1/SFF1 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data in the packet according to the enhanced context data header type field. Information, to determine whether there is context data information required by the TOR1/SFF1 node; if there is, the context data information is correctly read and used according to the enhanced context data header type field (for example, the first 16 bits of the mandatory context data header are interpreted as D/F/Source Node ID/Source Interface ID); if it needs to update the context data information after use, it is updated; if not, the context data information is not updated; TOR1/SFF1 forwards the message to the corresponding according to the service forwarding path information. SF2 to handle;

Step 103: After receiving the packet, the SF2 correctly parses the context data information in the packet according to the enhanced context data header type field to determine whether there is context data information required by the SF2 node; if yes, according to the enhanced context data header The type field correctly reads the context data information and processes the corresponding service (for example, interpreting the fourth 16 bits of the mandatory context data header as A/Service Tag), and if necessary, updating the context data related information after processing; if not , the context data related information is not updated; then the message is forwarded to TOR1/SFF1;

Step 104: After receiving the packet, the SFF1 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data information in the packet according to the enhanced context data header type field. Determine whether there is context data information required by the TOR1/SFF1 node; if so, correctly read and use the context data information according to the enhanced context data header type field, and update if the context data information needs to be updated after use; if not , the context data information is not updated; the TOR1/SFF1 forwards the message to the next hop TOR3/SFF3 according to the service forwarding path information;

Step 105: After receiving the packet, the TOR3/SFF3 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data in the packet according to the enhanced context data header type field. Information to determine if there is a context required by the TOR3/SFF3 node Data information; if so, the context data information is correctly read and used according to the Enhanced Context Data Header Type field (for example, the first 16 bits of the mandatory context data header is interpreted as the D/F/Source Node ID/Source Interface ID) If the context data information needs to be updated after the use, the context data information is updated; if not, the context data information is not updated; the TOR3/SFF3 forwards the message to the corresponding SF5 for processing according to the service forwarding path information;

Step 106: After receiving the packet, the SF5 correctly parses the context data information in the packet according to the enhanced context data header type field, and determines whether there is context data information required by the SF5 node; if yes, according to the enhanced context data header The type field correctly reads the context data information and processes the corresponding service (for example, interpreting the fourth 16 bits of the mandatory context data header as A/Service Tag), and if necessary, updating the context data related information after processing; if not , the context data related information is not updated; then the message is forwarded to TOR3/SFF3;

Step 107: After receiving the packet, the TOR3/SFF3 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data in the packet according to the enhanced context data header type field. Information, to determine whether there is context data information required by the TOR3/SFF3 node; if there is, the context data information is correctly read and used according to the enhanced context data header type field, after use, the NSH header is stripped, and the message is based on The destination IP address in the original packet is forwarded.

Embodiment 2:

As shown in FIG. 12, the service function chain SFC2 in the mobile scenario may be SF2->SF5; wherein SF1 and SF2 are connected to SFF1, SF3 is connected to SFF2, and SF4 and SF5 are connected to SFF3; that is, the service experienced by the service function chain The forwarding path is SFP2: SFF1->SF2>SFF3->SF5.

The packet arrives at the mobile network gateway device (P-GW), and the gateway device is used as a classifier in the service function chain technology to classify the packet and find that the packet is forwarded to the service chain SFC2, that is, the corresponding service forwarding path is SFP2. The forwarding process of the packet may include:

Step 201: Classifier node classification finds that an enhanced context data header type is obtained, and the traffic needs to enter the mobile network data center for processing, so that information about the service forwarding path and context data header information belonging to the mobile scenario are obtained to form an NSH header. The NSH header is encapsulated in the original data packet and forwarded to the next hop node SFF1 according to the service forwarding path.

Step 202: After receiving the packet, the SFF1 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data information in the packet according to the enhanced context data header type field. Determine whether there is context data information required by the SFF1 node; if so, correctly read and use the context data information according to the enhanced context data header type field (for example, interpret the first 16 bits of the mandatory context header as a Flow Cookie) If the context data information needs to be updated after the use, the update is performed; if not, the context data information is not updated; the SFF1 forwards the message to the corresponding SF2 for processing according to the service forwarding path information;

Step 203: After receiving the packet, the SF2 correctly parses the context data information in the packet according to the enhanced context data header type field, and determines whether there is context data information required by the SF2 node; if yes, according to the enhanced context data header. The type field correctly reads the context data information and processes the corresponding service (for example, interpreting the second 16 bits of the mandatory context data header as the TenTy/Tenant ID), and if necessary, updating the context data related information after processing; if not , the context data related information is not updated; then the message is forwarded to SFF1;

Step 204: After receiving the packet, the SFF1 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data information in the packet according to the enhanced context data header type field. Determining whether there is context data information required by the SFF1 node; if so, correctly reading the context data information according to the enhanced context data header type field and using it, and updating if necessary to update the context data information after use; if not, then The context data information is not updated; the SFF1 forwards the packet to the next hop SFF3 according to the service forwarding path information;

Step 205: After receiving the packet, the SFF3 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data information in the packet according to the enhanced context data header type field. Determine whether there is context data information required by the SFF3 node; if so, correctly read and use the context data information according to the enhanced context header type field (for example, interpret the first 16 bits of the mandatory context header as a Flow Cookie) If the context data information needs to be updated after the use, the update is performed; if not, the context data information is not updated; the SFF3 forwards the message to the corresponding SF5 for processing according to the service forwarding path information;

Step 206: After receiving the packet, the SF5 correctly parses the context data information in the packet according to the enhanced context data header type field, and determines whether there is a context data packet required by the SF5 node. Interest; if there is, the context data information is correctly read according to the enhanced context data header type field and the corresponding service is processed (for example, the second 16 bits of the mandatory context data header is interpreted as TenTy/Tenant ID), after processing If it needs to update the context data related information, it is updated; if not, the context data related information is not updated; then the message is forwarded to SFF3;

Step 207: After receiving the packet, the SFF3 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data information in the packet according to the enhanced context data header type field. Determine whether there is context data information required by the SFF3 node; if yes, read the context data information correctly according to the enhanced context data header type field and use it. After use, strip the NSH header and use the packet according to the original packet. The destination IP address is forwarded.

Embodiment 3:

As shown in Figure 13, for data traffic that needs to go through a broadband network and then enter the data center, the service function chain SFC3 can be SF2->SF3->SF5; where SF1 and SF2 are connected to SFF1, which is a broadband network domain, and SF3 is connected to SFF2, SF4 and SF5 are connected to the SFF3, which is the data center network domain; that is, the service forwarding path experienced by the service function chain is SFP3: SFF1->SF2->SFF2->SF3->SFF3->SF5. On SFF2, reclassification occurs. The subsequent new service forwarding path is SFP4: SFF1->SF2->SFF2->SF3->SFF3->SF4;

The packet is sent to the broadband network device (BNG). The gateway device is used as the classifier in the service function chain technology to classify the packet and finds that the packet is forwarded to the service chain SFC3, that is, the corresponding service forwarding path is SFP3. The forwarding process can include:

Step 301: Classifier node classification finds that an enhanced context data header type is obtained, and the traffic needs to be processed into a broadband network for processing, so that information about the service forwarding path and context data header information belonging to the broadband network scenario are acquired to form an NSH header. The NSH header is encapsulated in the original data packet and forwarded to the next hop node SFF1 according to the service forwarding path.

Step 302: After receiving the packet, the SFF1 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data information in the packet according to the enhanced context data header type field. In the broadband network scenario, it is determined whether there is context data information required by the SFF1 node; if yes, the context data information is correctly read and used according to the enhanced context data header type field; if the context data information needs to be updated after use More New; if not, the context data information is not updated; the SFF1 forwards the message to the corresponding SF2 for processing according to the service forwarding path information;

Step 303: After receiving the packet, the SF2 correctly parses the context data information in the packet according to the enhanced context data header type field into a broadband network scenario, and determines whether there is context data information required by the SF2 node; if yes, The context data information is correctly read according to the enhanced context data header type field and processed by the corresponding service, and updated if the context data related information needs to be updated after processing; if not, the context data related information is not updated; then the message is updated Forward to SFF1;

Step 304: After receiving the packet, the SFF1 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data information in the packet according to the enhanced context data header type field. Determining whether there is context data information required by the SFF1 node; if so, correctly reading the context data information according to the enhanced context data header type field and using it, and updating if necessary to update the context data information after use; if not, then The context data information is not updated; the SFF1 forwards the packet to the next hop SFF2 according to the service forwarding path information;

Step 305: After receiving the packet, the SFF2 re-classifies the information, re-acquires the service forwarding path information SFP4, and the enhanced context data header type and context data header information in the data center scenario to form an NSH header, and the established NSH header. Encapsulated in the original data packet and forwarded to the next hop node SF3 according to the service forwarding path;

Step 306: After receiving the packet, the SF3 correctly parses the context data information in the packet according to the received enhanced context data header type field into a data center scenario, and determines whether there is context data information required by the SF2 node; If yes, the context data information is correctly read according to the enhanced context data header type field and the corresponding service is processed. If the context data related information needs to be updated after the processing, the context data related information is updated; if not, the context data related information is not updated; Forward the packet to SFF2.

Step 307: After receiving the packet, the SFF2 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data information in the packet according to the enhanced context data header type field. Determining whether there is context data information required by the SFF2 node; if so, correctly reading the context data information according to the enhanced context data header type field and Used to update the context data information if it needs to be updated after use; if not, the context data information is not updated; SFF2 forwards the message to the next hop SFF3 according to the service forwarding path information;

Step 308: After receiving the packet, the SFF3 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data information in the packet according to the enhanced context data header type field. In the data center scenario, it is determined whether there is context data information required by the SFF3 node; if yes, the context data information is correctly read and used according to the enhanced context data header type field; if the context data information needs to be updated after use Update; if not, the context data information is not updated; the SFF3 forwards the message to the corresponding SF5 for processing according to the service forwarding path information;

Step 309: After receiving the message, the SF5 correctly parses the context data information in the packet according to the received enhanced context data header type field into a data center scenario, and determines whether there is context data information required by the SF5 node; If yes, the context data information is correctly read according to the enhanced context data header type field and the corresponding service is processed. If the context data related information needs to be updated after the processing, the context data related information is updated; if not, the context data related information is not updated; Forward the packet to SFF3.

Step 310: After receiving the data packet, the SFF3 parses and reads the service forwarding path information and the enhanced context data header type in the packet, and correctly parses the context data information in the packet according to the enhanced context data header type field. , to determine whether there is context data information required by the SFF3 node; if there is, the context data information is correctly read and used according to the enhanced context data header type field, after use, the NSH header is stripped, and the message is based on the original message. The destination IP address is forwarded.

Embodiment 4:

When the enhanced context data header type is not recognized on the intermediate node, this field can be ignored; optionally, the intermediate node interprets the context data header information according to certain rules.

FIG. 14 is a schematic diagram of an apparatus for processing a data packet on a sending side according to an embodiment of the present invention. As shown in FIG. 14, the apparatus of the embodiment is applied to a node supporting a service function chain, including:

An acquisition module, configured to: obtain an enhanced context data header type; the enhanced context The data header type includes any one of the following: a context data header type of the data center scenario, a context data header type of the mobile scenario, and a context data header type of the broadband network scenario;

The encapsulating module is configured to: encapsulate the enhanced context data header type in a network service header, and encapsulate the network service header in a data packet;

The data packet may be composed of original data and a network service header, or may be composed of original data, a network service header, and an overlay network packet header.

In an optional embodiment, the method may further include:

In an optional embodiment, the obtaining module may be further configured to: acquire the enhanced context data header type that is locally configured or sent by the centralized controller.

Figure 15 is a schematic diagram of an apparatus for processing a data packet on a receiving side according to an embodiment of the present invention. As shown in Figure 15, the apparatus of the present embodiment is applied to a node supporting a service function chain, and may include:

a parsing module, configured to: parse an enhanced context data header type in the network service header;

In an optional embodiment, the apparatus may further include:

In an optional embodiment, the parsing module may be further configured to: parse the service forwarding path information in the data packet;

The processing module may be further configured to: forward the data packet or the updated data packet according to the service forwarding path information.

One of ordinary skill in the art will appreciate that all or part of the steps of the above embodiments may be used. The computer program can be implemented in a computer readable storage medium, the computer program being executed on a corresponding hardware platform (such as a system, device, device, device, etc.), when executed, including One or a combination of the steps of the method embodiments.

Alternatively, all or part of the steps of the above embodiments may also be implemented by using an integrated circuit. These steps may be separately fabricated into individual integrated circuit modules, or multiple modules or steps may be fabricated into a single integrated circuit module. achieve.

The devices/function modules/functional units in the above embodiments may be implemented by a general-purpose computing device, which may be centralized on a single computing device or distributed over a network of multiple computing devices.

When the device/function module/functional unit in the above embodiment is implemented in the form of a software function module and sold or used as a stand-alone product, it can be stored in a computer readable storage medium. The above mentioned computer readable storage medium may be a read only memory, a magnetic disk or an optical disk or the like.

Industrial applicability

Obtaining an enhanced context data header type by using the solution of the embodiment of the present invention; encapsulating the enhanced context data header type in a network service header, and encapsulating the network service header in a data packet; The packet is sent along the service forwarding path. Thus, through the solution of the embodiment of the present invention, in the foregoing SFC network, a context data header type identifier is further added to enhance further identification of the context data header on the node supporting the service chain.

Claims

A method for processing data messages, applied to nodes supporting a service function chain, including:

Get an enhanced context data header type;

Encapsulating the enhanced context data header type in a network service header, and encapsulating the network service header in a data packet;

The data packet is sent along the service forwarding path.
The method of claim 1 wherein said enhanced context data header type comprises any of the following:

The context data header type of the data center scene, the context data header type of the mobile scene, and the context data header type of the broadband network scenario.
The method of claim 1 or 2, wherein the enhanced context data header type is configured according to network deployment conditions and/or context data header data information.
The method of claim 1 or 2, wherein the enhanced context data header type is locally configured or issued by a centralized controller.
The method of claim 1 wherein said data message consists of raw data and network traffic headers or consists of raw data, network traffic headers, and overlay network headers.
A device for processing data messages, applied to nodes supporting a service function chain, including:

The obtaining module is configured to: obtain an enhanced context data header type; the enhanced context data header type includes any one of the following: a context data header type of the data center scene, a context data header type of the mobile scene, and a broadband network scenario. Context data header type;

The encapsulating module is configured to: encapsulate the enhanced context data header type in a network service header, and encapsulate the network service header in a data packet, where the data packet is composed of original data and a network service header. Or consisting of original data, network traffic headers, and overlay network headers;

The sending module is configured to: send the data packet along a service forwarding path.
The apparatus of claim 6 further comprising:

The configuration module is configured to: configure the enhanced context data header type according to network deployment conditions and/or context data header data information.
The apparatus according to claim 6 or 7, wherein the obtaining module is further configured to: acquire the enhanced context data header type that is locally configured or sent by the centralized controller.
A method for processing data messages, applied to nodes supporting a service function chain, including:

Receiving a data packet carrying a network service header;

Parsing an enhanced context data header type in the network traffic header;

Reading context data information in the data message according to the enhanced context data header type.
The method of claim 9, after the reading the context data information in the data packet according to the enhanced context data header type, further comprising:

The context data information and/or the enhanced context data header type are updated when it is determined that the context data information needs to be updated.
The method of claim 9 or 10, after the receiving the data packet carrying the network service header, the method further includes: parsing the service forwarding path information in the data packet;

After the reading the context data information in the data packet according to the enhanced context data header type, the method further includes:

And forwarding the data packet or the updated data packet according to the service forwarding path information.
A device for processing data messages, applied to nodes supporting a service function chain, including:

The receiving module is configured to: receive a data packet carrying a network service header;

a parsing module, configured to: parse an enhanced context data header type in the network service header;

The processing module is configured to: read context data information in the data packet according to the enhanced context data header type.
The apparatus of claim 12, further comprising:

The update module is configured to: update the context data information and/or the enhanced context data header type when it is determined that the context data information needs to be updated.
The apparatus according to claim 12 or 13, wherein the parsing module is further configured to: parse the service forwarding path information in the data packet;

The processing module is further configured to: forward the data packet or the updated data packet according to the service forwarding path information.