WO2020010557A1

WO2020010557A1 - Implementation of service function chain on basis of software-defined network

Info

Publication number: WO2020010557A1
Application number: PCT/CN2018/095336
Authority: WO
Inventors: 胡志远; 陈端; 骆志刚
Original assignee: 上海诺基亚贝尔股份有限公司; 诺基亚通信公司; 诺基亚技术有限公司
Priority date: 2018-07-11
Filing date: 2018-07-11
Publication date: 2020-01-16
Also published as: CN112385185B; EP3823222A4; CN112385185A; EP3823222A1; US11616718B2; US20210273883A1

Abstract

The embodiments of the present disclosure relate to the implementation of a service function chain on the basis of a software-defined network (SDN). Provided in some embodiments is a method for implementation at a service function chain controller. The method comprises: creating a service function chain for a packet, the service function chain comprising a group of ordered service functions to be used for processing the packet; and directly or indirectly configuring a corresponding forwarding rule that relates to the service function chain to a plurality of network nodes in an SDN, the corresponding forwarding rule indicating how the plurality of network nodes forward the packet to the group of ordered service functions in the service function chain. By employing the described method, a service function chain may be implemented in a SDN.

Description

Implementation of Business Function Chain Based on Software Defined Network

Technical field

Embodiments of the present disclosure generally relate to the field of networking, and in particular, to the implementation of a service function chain (SFC) based on a software-defined network (SDN).

Background technique

With the emergence of technologies such as Network Function Virtualization (NFV), Software Defined Networking (SDN), and Service Function Chain (SFC), network operators can transform their networks to make them programmable and reduce costs. Therefore, applications based on these technologies can be deployed quickly and easily. SDN technology enables fine-grained network-side control of service flows, and therefore supports automatic and dynamic application deployment and reconfiguration. SFC technology enables service providers to dynamically provide various business functions without changing the underlying network deployment. Such service functions include network service functions such as mobility management and session management in mobile networks, authentication, firewalls, intrusion detection systems, deep packet inspection, traditional IP network address interpretation (NAT), and the like. SFC technology can also be used to provide application-specific functions.

Generally, SDN technology and SFC technology are deployed separately. For example, in order to provide dynamic business functions, a control plane SFC controller needs to be deployed in the network, and a classifier for managing the business function chain for packets and a classifier for forwarding packets to corresponding business functions need to be deployed in the data plane. Service Function Repeater (SFF). In an SDN-based network, an SDN controller in the control plane needs to be deployed, and a switch to support packet forwarding is deployed in the data plane.

Summary of the invention

A brief overview of the various embodiments is given below to provide a basic understanding of some aspects of the various embodiments. Note that the summary section is not intended to identify key points of the elements or to describe the scope of the various embodiments. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is described later.

In a first aspect, a method implemented at a business function chain controller is provided. The method includes creating a business function chain for a packet, the business function chain including an ordered set of business functions to be used to process the packet; and directly or indirectly configuring a forwarding rule associated with the business function chain to a plurality of software-defined networks For network nodes, the forwarding rule instructs multiple network nodes how to forward packets to a set of ordered business functions in a business function chain.

In a second aspect, a method is provided that is implemented at a network node in a software-defined network. The method includes: receiving a packet from an upstream node in a software-defined network; obtaining a forwarding rule associated with a packet's business function chain from a business function chain controller, the business function chain including an ordered set of business functions to be used to process the packet And the forwarding rule instructs the network node how to forward the packet to a business function in a group of ordered business functions; and based on the forwarding rule, the packet is forwarded to a downstream node that is communicatively coupled with the business function in a group of ordered business functions.

In a third aspect, a method is provided that is implemented at a software-defined network controller. The method includes receiving, from a business function chain controller, a corresponding forwarding rule associated with a business function chain created for a packet, the business function chain including an ordered set of business functions to be used to process the packet, and the corresponding forwarding rule instructs the software-defined network How multiple network nodes in a group forward packets to a set of ordered business functions in a business function chain; and provide corresponding forwarding rules to multiple network nodes.

In a fourth aspect, a communication device is provided. The device includes a processor; and a memory storing instructions that, when executed by the processor, cause the device to perform a method according to the first aspect, the second aspect, or the third aspect.

In a fifth aspect, there is provided a computer-readable storage medium having stored thereon a computer program that, when executed by a processor, implements a method according to the first aspect, the second aspect, or the third aspect.

It should be understood that what is described in the Summary section is not intended to limit key or important features of the embodiments of the present disclosure, nor is it intended to limit the scope of the present disclosure. Other features of the present disclosure will become readily understood from the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

The objects, advantages and other features of the present disclosure will become more apparent from the following disclosure and claims. For the purpose of example only, a non-limiting description of a preferred embodiment is given with reference to the drawings, in which:

FIG. 1 shows an exemplary architecture diagram of a typical system for providing SFC;

FIG. 2 illustrates an exemplary architecture diagram of a system implementing SFC based on SDN according to an embodiment of the present disclosure; FIG.

FIG. 3 shows an example structure diagram of a flow table for forwarding a packet based on a label protocol in an SDN network; FIG.

4A and 4B illustrate an example structure diagram of a flow table used for packet forwarding in the system of FIG. 2 according to an embodiment of the present disclosure;

4C illustrates an example of a processing action defined in a flow entry according to an embodiment of the present disclosure;

5 illustrates an example structure of a path label according to an embodiment of the present disclosure;

6 illustrates an example of an SDN-based SFC system according to an embodiment of the present disclosure;

7A to 7N illustrate example structural diagrams of a flow table used in the example of FIG. 6;

8 illustrates a flowchart of a method implemented at an SFC controller according to an embodiment of the present disclosure;

9 illustrates a flowchart of a method implemented at a network node in an SDN network according to an embodiment of the present disclosure;

10 illustrates a flowchart of a method implemented at an SDN controller according to an embodiment of the present disclosure; and

FIG. 11 illustrates a schematic block diagram of an example device that can be used to implement embodiments of the present disclosure.

In the drawings, the same or corresponding reference numerals represent the same or corresponding parts.

detailed description

In the following description, many details are set forth for the purpose of illustration. However, one of ordinary skill in the art will recognize that the present disclosure may be implemented without the use of these specific details. Therefore, this disclosure is not intended to be limited to the illustrated embodiments, but will be given the broadest scope consistent with the principles and features described herein.

It should be understood that the terms "first", "second", etc. are only used to distinguish one element from another. In fact, the first element can also be called the second element, and vice versa. It should also be understood that "including" and "including" are only used to describe the existence of stated features, elements, functions or components, but do not exclude the presence of one or more other features, elements, functions or components.

FIG. 1 illustrates an exemplary architecture diagram of a typical system 100 for providing SFC. The system 100 may include one or more controllers in a control plane, which may be distributed across one or more physical hosts and / or virtual hosts. As shown in FIG. 1, the system 100 may include a service function chain (SFC) controller 110.

As shown in FIG. 1, the SFC controller 110 can communicate with each node on the data plane and configure each node on the data plane. For example, the data plane may include a classifier 120, one or more service function repeaters (SFF) 130-1, 130-2, 130-3, 130-4 (collectively referred to as SFF 130 for ease of description), and corresponding Service functions (SF) 140-1, 140-2, 140-3, 140-4, etc. (For ease of description, they are collectively referred to as SF 140).

In the system 100 that provides SFC, the classifier 120 provides a classification function to classify packets into matching business function chains (SFCs). Classification policies can be user-specific, network-specific, or business-specific. The classifier 120 may include a classification table 121 for determining a match of the packet to the SFC.

SF 140 is used to perform specific processing on the received packet. SF 140 may be a logic element, which may be implemented as a virtual element in a physical network device or embedded therein. SF 140 can provide general network service functions or application-specific functions. Examples of SF140 can include, but are not limited to, firewalls, access control, entity authentication, unified threat management (UTM), intrusion detection system (IDS), intrusion prevention system (IPS), virtual private network (VPN), security gateway, deep packet Detection (DPI), lawful interception (LI), traffic cleaning, data integrity verification, data confidentiality protection, data desensitization, data encryption, data decryption, etc.

SFF 130 is used to forward packets to SF 140 connected to it, and to receive processed packets from SF 140. SFF 130 may include service function path (SFP) tables 150-1, 150-2, 150-3, and 150-4 (for ease of description, usually SFP table 150). The SFF 130 determines how to forward a packet based on the SFP table 150. SFF 130 can be implemented as a virtual element in a physical network device or embedded in it.

In the system 100, the SFC controller 110 may create a business function chain (SFC) for a packet. SFC can sometimes be referred to as the service chain (SC) for short, and each SFC includes an ordered set of SFs 140. Packets classified into a specific SFC will be processed by the SF 140 involved in the chain. If the SFs in the SFC all involve data security functions, the SFC can also be referred to as the Security Service Chain (SSC).

In the example of FIG. 1, two SFCs are shown, which are used to transmit packets from the host 170-1 to the host 170-2 and from the host 170-1 to the host 170-3, respectively. The paths of the two SFCs correspond to SFPs 161 and 162, of which SFP 161 involves: host 170-1-> classifier 120-> SFF 130-1-> SF 140-1-> SFF 130-1-> SFF 130-2 -> SF 140-2-> SFF 130-2-> SFF 130-4-> SF 140-4-> SFF 130-4-> Host 170-2. SFP 162 involves: host 170-1-> classifier 120-> SFF 130-1-> SFF 130-3-> SF 140-3-> SFF 130-3-> host 170-3. In SFP161, the packets from host 170-1 to host 170-2 are processed by an SFC composed of an ordered set of SFs 140-1, 140-2, 140-3, and 140-4. In the SFP 162, packets from the host 170-1 to the host 170-3 are processed by the SFC composed of the SF 140-3.

It should be understood that the architecture of the system 100 shown in FIG. 1 is merely exemplary. In practical applications, the system 100 may include more components, fewer components, or different components.

In network deployment, there is a network communication based on software-defined network (SDN) technology. There are SDN controllers and one or more switches in the SDN network. The SDN controller controls the forwarding of the packet by the switch according to the specified control protocol, so that the switch can transmit the packet from the source address to the destination address. The core of the SDN network is to separate the control plane and data plane of the network equipment to achieve flexible control of network traffic and make the network more intelligent as a pipe.

As mentioned above, SDN technology and SFC technology are deployed separately. The SFC controller and the SDN controller separately control the data plane components to achieve the corresponding functions. It is expected that the network equipment in the SDN network can be used to implement SFC, so that the advantages brought by the two technologies can be obtained.

According to an embodiment of the present disclosure, a scheme for implementing SFC based on SDN is proposed. In this scheme, an SFC component (such as a classifier, SFF) for supporting SFC is implemented as a forwarding rule of a network node in an SDN network, such as a flow table. The forwarding rule instructs the network node how to forward the packet to the SF of the corresponding SFC. The SFC controller can communicate with the SDN controller or the network node to configure such forwarding rules to the network node. Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings.

FIG. 2 illustrates an example structural diagram of a system 200 for implementing SFC based on SDN according to an embodiment of the present disclosure. In the system 200, the control plane includes an SFC controller 210 for controlling the SFC of a packet. The control plane also includes an SDN controller 212 for controlling network nodes (such as network nodes 220-1, 220-2, etc.) in the SDN network. The network nodes 220-1, 220-2 may be collectively referred to as the network node 220, which is responsible for packet forwarding. The network node 220 may also be referred to as a network device, a switch, a switching device, or the like. Network node 220-2 is also connected to SF 240-1. SF 240-1 is used to process packets to provide specific business functions.

It should be understood that the number and deployment of the devices shown in FIG. 2 is only an example. In other cases, the system 200 may further include more network nodes and more SFs, and each network node may be connected to more than one SF.

The SDN controller 212 and the network node 220 in the SDN network can interact with various control protocols. An example of a control protocol is the OpenFlow protocol. Under this protocol, the network node 220 may also be referred to as an OpenFlow switch, and the SDN controller 212 may be referred to as an OpenFlow controller. Other protocols that support interaction between the control and data planes can also be used, such as the Virtual Extended Local Area Network (VXLAN) protocol. In the following, the embodiments of the present disclosure are described using the OpenFlow protocol as an example, but it should be understood that these embodiments can also be applied to the case where the SDN controller 212 and the network node 220 use other communication protocols. It should also be noted that, in communication based on the OpenFlow protocol, communication to a packet can also be referred to as communication to a data flow.

In operation, the SFC controller 210 creates an SFC for the packet, which SFC includes an ordered set of SFs (SF 240-1 in the example of Figure 2) to be used to process the packets. SFC can be user-specific, application-specific, network-specific, and so on. In this case, packets from a specific user or a specific application or packets transmitted in a specific network (such as the system 200) will be processed by the SF in the SFC. The SFC controller 210 configures a corresponding forwarding rule associated with the created SFC to the network node 220 in the SDN. The forwarding rule instructs the network node 220 how to forward the packet to each SF in the created SFC. The forwarding rule associated with the created SFC may involve the forwarding of multiple network nodes, so the SFC controller 210 may configure the corresponding forwarding rule to each network node 220, and the forwarding rule obtained by each network node 220 specifies the network node 220 itself forwards the packet.

In a pure SFC implementation, after an SFC is created, a packet for the SFC will be classified by the classifier into the SFC and provided to the corresponding SFF, and then forwarded to the corresponding SF for processing via the SFF. In order to implement such a function in SDN, according to an embodiment of the present disclosure, the delivery of a packet to an SFC by a classifier and SFF is configured as a forwarding rule of a network node in SDN. After being configured with such a forwarding rule, the network node 220 will forward the packet based on the forwarding rule so that the packet can be correctly transmitted to the SF involved in the SFC created by the SFC controller 210.

As shown in FIG. 2, the network node 220-1 may receive a packet from an upstream node. The upstream node that provides the packet to the network node 220-1 may be a host device or other user equipment that generates the packet. The network node 220-1 forwards the packet to the downstream network node 220-2 (also referred to as the next hop) based on the forwarding rule 202-1 configured by the SFC controller 210. Network node 220-2 is connected to SF 240-1. Based on the configured forwarding rule 202-2, the network node 220-2 can provide the packet to SF 240-1 for processing and forward the packet to the downstream node, also known as the next hop (for example, the next network node or the purpose of the packet Ground equipment).

The SFC controller 210 may directly or indirectly configure a forwarding rule to the network node 220. In some embodiments, the SFC controller 210 may directly transmit the forwarding rules to the network node 220. For example, in an example where the network node 220 is an OpenFlow switch, the SFC controller 210 may communicate directly with the network node 220 using, for example, an extended NETCONF protocol to transmit a forwarding rule to the network node 220. In such an embodiment, the communication protocol between the SDN controller 212 and the network node 220 may not be changed.

Alternatively, the SFC controller 210 may provide the forwarding rules to the network node 220 via the SDN controller 212. In other words, the SDN controller 212 acts as a communication intermediary between the SFC controller 210 and the network node 220 to achieve indirect configuration of the forwarding rules. In such an implementation, the SDN controller 212 may include an SFC implementation module 214 for supporting communication with the SFC controller 210. The SFC controller 210 transmits the forwarding rule to the SDN controller 212 (for example, the SFC implementation module 214 therein). After obtaining the forwarding rule, the SDN controller 212 transmits the forwarding rule to the network node 220 according to a communication protocol (for example, the OpenFlow protocol) with the network node 220. The conventional communication between the SDN controller 212 and the network node 220 will be changed to support the transmission of forwarding rules. For example, the message configuration for transmission between the SDN controller 212 and the network node 220 needs to be updated to support the transmission of forwarding rules associated with the SFC.

In some embodiments, in order to create an SFC and generate a forwarding rule, the SFC controller 210 also requests the SDN controller 212 for network related information, such as network topology information. The network topology information indicates the topology between the network nodes 220 in the system 200, between the network nodes 220 and the host devices that initiate and receive packets, and between the network nodes 220 and the SF 240-1. The SFC controller 210 sends a request for the network topology information to the SDN controller 212. In response to the request, the SDN controller 212 transmits the network topology information to the SFC controller 210. The SFC controller 210 may create an SFC based on such network topology information. The network topology information can indicate the deployment of SF in the network, the network nodes connected to it, and so on, which can promote the SFC controller 210 to generate SFC. When configuring a forwarding rule, the SFC controller 210 may also refer to the obtained network topology information, for example, so that the forwarding rule may indicate which network node how to forward packets to which SFs. The communication related to the SFC controller 210 may be implemented by the SFC implementation module 214 in the SDN controller 212.

In some embodiments, the SFC controller 210 may also request information about the deployment status and operation status of the network node 220 and / or SF 240-1 to support the configuration of SFC creation and forwarding rules. The deployment status of the network node 220 and / or SF 240-1 may be obtained from a device such as Management and Orchestration (MANO). The MANO device (not shown in Figure 2) is responsible for performing management, maintenance, and provisioning of virtual machine (VM) management and virtualized network functions in the SDN network. The MANO device can provide the SFC controller 210 with the deployment status and operation status of the network nodes 220 and / or SF 240-1, such as the throughput, latency, IP address, flexibility and availability of running business functions, and so on.

The following will discuss in detail how the SFC controller 210 configures the forwarding rules so that the network node 220 can forward the packets to the corresponding SFs that make up a particular SFC. In the implementation of SFC, a classification function is needed to achieve the classification of packets into corresponding SFCs. In addition, Service Function Forwarding (SFF) is also required to realize the transmission of packets classified to the corresponding SFC in the SFP, and to provide the packets to the corresponding SF for processing. In the SDN-based SFC implementation, both the classification function and the SFF function are configured as forwarding rules in the network node 220.

In an OpenFlow protocol-based SDN network, the network node 220 performs packet forwarding based on a flow table. In a conventional SDN network, the flow table is configured by the SDN controller. A flow table includes one or more flow entries, each flow entry indicating an action to be performed on a packet by a network node. After receiving the packet, the network node 220 looks up the flow table to determine the flow entry that matches the packet and performs corresponding actions based on the flow entry, such as encapsulation or decapsulation of the packet header, multipath forwarding, and output to one or several Ports, go to other flow tables to continue processing, and so on.

FIG. 3 shows an example structure of a flow entry 300 for forwarding a label protocol-based flow table in an SDN network. The flow entry 300 includes a matching field in which information (also referred to as matching information) for packet matching is recorded. If a packet contains information that matches one or more of the information in the matching field of a flow entry, the packet matches the flow entry. In the example of FIG. 3, the matching fields include an input port, an input label, and a destination Internet Protocol (IP) address. The input port indicates a port to which a packet is input to a network node. The input label indicates the label of the switched path from which the network node received the packet in the case where the SDN controller instructs the forwarding of the network node according to the path label service. The path label may include, for example, a multiprotocol label switching (MPLS) label, a general routing encapsulation (GRE) label, a virtual extended local area network-generic path encapsulation (VXLAN-GRE) label, and the like. The input label may further indicate the input path of the packet. The destination IP address in the match field indicates the IP address of the destination to which the packet will be forwarded. Although multiple fields are included, one or more of the matching fields of the flow entry 300 may not be configured with corresponding information depending on the actual forwarding needs. The matching field may also include other information used for matching, such as the source IP address, source port number, destination IP address, destination port number, protocol type adopted by the packet, input port, and so on.

As shown in FIG. 3, the flow entry 300 further includes an output label field, which is used to instruct the network node to output the path label of the packet in the case that the SDN controller instructs the forwarding of the network node according to the path label service. The flow entry 300 also includes an instruction field indicating the corresponding operation to be performed by the network node. The "application action" part of the instruction field may include an "update packet header" field, which indicates a corresponding operation on the header of the packet, such as inserting specific information, removing specific information, and the like. The "application action" section may also include an "output port" field, which instructs the network node to output a packet from the output port indicated by this field. In some examples, the instruction field of the flow entry 300 may also include a field "to the flow table". This field is usually used when the network node includes multiple flow tables. If the network node includes multiple flow tables, the network node may need to perform pipeline processing of the flow table. That is, after processing a packet based on a flow entry of a flow table, if the "to flow table" field of the flow entry indicates the next flow table, the network node also continues to process the packet according to the matching flow entry in the next flow table. .

The flow entries of the flow table shown in FIG. 3 are just an example illustration. According to the OpenFlow protocol, flow entries can also have other variations.

In some embodiments of the present disclosure, in order to support SFC implementation in SDN, the SFC controller configures the forwarding rules associated with the SFC created for the packet as a flow entry in a network node. Compared with regular flow entries, in order to support the classification and SFP forwarding functions required by SFC, the flow entries in the flow table need to be expanded or modified. An example of the flow entry for supporting classification and SFP forwarding required for supporting SFC is described below in conjunction with the examples of FIGS. 4A and 4B. The SDN controller 212 is going to expand the flow table of the network node 220 to support such flow entries.

FIG. 4A shows a classified flow entry 410 for SFC. The flow entry 410 includes a new Network Service Header (NSH) field to indicate the NSH of the packet. In the classification of the SFC, after the group is classified into the created SFC, the group is encapsulated with NSH. The format of the NSH may be, for example, a header format defined in an SFC-related protocol, such as a header defined in the IETF RFC8300 protocol. Generally, the NSH may include an identifier of the SFC, such as a service path identifier (SPI), a service index (SI), and the like. The NSH may also include a "next protocol" field indicating the protocol type of the data (payload) encapsulated by the packet. The NSH may also optionally include a "context header" field indicating the metadata (ie, context data) of the SFC. NSH has different types, and the structure of NSH shown in FIG. 4A is only an example. According to the definition of the SFC related protocol, the NSH may include more information, different information, or less information (for example, the next protocol field and the context message field may be omitted).

The flow entry 410 may also include a new "next hop" field indicating the next SF in a group of ordered SFs to which the packet is to be forwarded, for example, it may include the address of the next SF. The indication of the "next hop" field is usually based on the next hop position in the service packet path (SFP) of the SFC, which is indicated based on the SPI and SI. The "next hop" field may also be consistent with the packet transfer in the SFC as defined in the SFC-related protocol, such as defined in the IETF RFC8300 protocol. The "next hop" of the SFC can be used to transmit packets encapsulated with NSH in a transmission path established based on the underlying network protocol. Generally, at the time of classification, the "next hop" field in the flow entry 410 indicates the first SF in a set of ordered SFs of the SFC. In some embodiments, a forwarding path, such as a label switched path (LSP), may be established between the current network node and a node associated with the "next hop" according to the "next hop" indication. Some SFCs may need to build multiple LSPs (eg if multiple SFs are included). Multiple LSPs can constitute the forwarding of packets throughout the network.

In some embodiments, the flow entry 410 may also indicate some specific processing actions on the packet. As described with respect to FIG. 3, the regular flow entry includes an "instruction" field, where the "application action" section defines the processing action that the network node needs to perform on the packet. Considering the implementation of SFC, the processing actions to be performed by network nodes can be extended. In some implementations, the flow entry 410 may indicate a processing action associated with an SFC-related header (ie, an NSH header). In the implementation of the classification function, the action field of the "update packet header" of the flow entry 410 can be extended to indicate the following processing action: insert NSH into the packet. The insertion of NSH is usually performed when classifying packets into the path of the SFC.

The "application action" of the flow entry 410 may further include an additional action field "Update Header Matching Field" to indicate a processing action of replacing the destination address of the packet with the address of the SF indicated by the next hop. By applying this processing action, the destination address of the packet is replaced in order to support the establishment of an LSP with the next hop.

In some embodiments, in order to support finer classification of packets, the matching field of flow entry 410 is in addition to the matching information of a conventional flow table (such as the source IP address, source port number, destination IP address, destination port of the packet Number, protocol type, input port, etc.), it can also include additional matching information in SFC scenarios. Examples of such additional matching information may include the application type of the packet, indicating what type of application the payload in the packet belongs to. The additional matching information may also include user information of the group, indicating related information of the user or the host device of the user who initiated the group. One or more of these matching information can be configured. Therefore, the flow entries in the general flow table of SDN are expanded to include the above field types for carrying these additional configuration information. For example, in the specifications of the OpenFlow protocol, the matching field can be extended to include the field type "OFPXMT_OFB_APPLICATION_TYPE = xx, / * Application type. * /" To indicate the application type of the packet carried in the matching field. The matching field can also be extended to include the field type "OFPXMT_OFB_USER_INFORMATION = xx, / * User information. * /", Which is used to indicate that the user information of the packet is carried in the matching field.

In some embodiments, if the flow entry 410 is set in a network node with multiple flow tables, the flow entry 410 also includes a "to flow table" field, which is used to indicate the processing in the pipeline of the flow table of the network node. Next class table. In some embodiments, in the pipeline processing of the flow table of the network node, the flow table containing the flow entry 410 may be the second flow table in the pipeline processing.

FIG. 4A shows an example structure of a classified flow entry for SFC. After the SFC controller 210 creates the SFC, it can configure the created SFC and the flow entries used for the classification of the SFC into the flow table of the corresponding network node. In the case where the network node 220 includes a plurality of flow tables, a flow table configured with flow entries for classification as exemplarily illustrated in FIG. 4A may be used in the pipeline processing of the flow table together with other flow tables.

FIG. 4B shows SFP forwarded flow entries 420 for SFC. In conventional SFC, SFP forwarding is usually implemented by components such as SFF. In an embodiment of the present disclosure, the SFF forwarding function is implemented as a flow entry in a flow table of a network node. The flow entry 420 is used to cause the network node 220 to forward the packet to the corresponding SF for processing, and further forward the packet returned by the SF processing to the next node.

As shown in FIG. 4B, the flow entry 420 indicates an identifier of the SFC, which may be included in the matching field of the flow entry 420 as matching information. The identifier of the SFC may include SPI and / or SI. In SFP forwarding, the received packet is usually encapsulated with an NSH header, which contains the identifier of the SFC (ie, SPI and / or SI). Therefore, in the match field of the flow entry, whether the packet matches the entry can be determined by the identifier of the SFC. In some embodiments, the matching field of the flow entry 420 may include other matching information in addition to the identifier of the SFC, such as the matching information described above with respect to FIG. 3 or FIG. 4A. Therefore, the flow entries in the general flow table of SDN are expanded to include the above field types for carrying these additional configuration information. For example, in the specifications of the OpenFlow protocol, the matching field can be extended to include the field type "OFPXMT_OFB_NSH_SPI_LABEL = xx, / * NSH SPI label. * /", Which is used to indicate that the SFC SPI ID is carried in the matching field. The matching field can also be extended to include the field type "OFPXMT_OFB_NSH_SI_LABEL = xx, /*NSHSIlabel.*/", which is used to indicate that the SI identifier of the SFC is carried in the matching field.

In some embodiments, similar to flow entry 410, flow entry 420 may also include a new "next hop" field indicating the next SF in a group of ordered SFs to which the packet is to be forwarded, for example, it may include the next The address of SF. The "next hop" field may also be consistent with the definition in the SFC-related protocol, such as defined in the IETF RFC8300 protocol. The "next hop" of the SFC can be used to transmit packets encapsulated with NSH in a transmission path established based on the underlying network protocol. Generally, when SFP is forwarded, the "next hop" field in the flow entry 420 indicates some intermediate SF or the last SF in a set of ordered SFs of the SFC. In some embodiments, a forwarding path, such as a label switched path (LSP), may be established between the current network node and a node associated with the "next hop" according to the "next hop" indication.

In some embodiments, the flow entry 420 may also indicate some specific processing actions on the packet. In some implementations, the flow entry 420 may indicate a processing action associated with an SFC-related header (ie, an NSH header). In the implementation of the SFP function, the action field of "Update Packet Header" of the flow entry 410 may be extended to indicate the following processing action: Remove NSH from the packet. The removal of the NSH header is usually when the SF to be provided for packet processing does not support SFC, or when the packet is to be provided to the destination device, or the next hop of the network does not support SFC, or when the packet is about to leave the SFC domain Be executed.

The "application action" of the flow entry 420 may also include an additional action field "Update Header Matching Field" to indicate a processing action of replacing the destination address of the packet with the address of the SF indicated by the next hop. By applying this processing action, the destination address of the packet is replaced in order to support the establishment of an LSP with the next hop.

In some embodiments, if the flow entry 420 is set in a network node having multiple flow tables, the flow entry 420 further includes a "to flow table" field, which is used to indicate that in the pipeline processing of the flow table of the network node Next class table. In some embodiments, in the pipeline processing of the flow table of the network node, the flow table containing the flow entry 420 may be the second flow table in the pipeline processing.

The flow table for classification and the flow table for SFP forwarding have been discussed above with respect to FIGS. 4A and 4B. In the examples of FIGS. 4A and 4B, to support the implementation of SFC, the flow entry will also indicate NSH-related processing actions. These actions are summarized in table 430 in FIG. 4C. As shown in FIG. 4C, the flow entry may include an action label of "Push NSH header" or "Remove NSH header", respectively, indicating that a new NSH header is inserted into the packet and an NSH header is removed from the packet. Table 430 also indicates the type of data associated with the action tag "Push NSH header", such as the Ethernet data type.

In some embodiments, as mentioned above, when forwarding between the network nodes 220, the SDN controller 212 may control the network nodes to implement packet forwarding according to the path labels. The SDN controller 212 may create a forwarding path of the SDN for transmission of packets in the SDN based on the forwarding rules. For example, the SDN controller 212 may map a path (ie, SFP) of the SFC created for the SFC controller 210 to a multiprotocol label switching path (ie, MPLS) in the SDN.

Generally, protocols for path labels, such as the MPLS protocol, are independent of network layer protocols. The SDN controller 212 may include an MPLS management module and a path calculation element (PCE) server (control element) for determining a MPLS label switched path (LSP) between the network nodes 220. The network node 220 may include a PCE client for supporting MPLS-based switching path forwarding. The network node 220 may perform packet forwarding based on the input or output tags of the packet. In such an implementation, the SDN controller 212 and the network node 220 may support a PCE communication protocol, such as the protocol specifications defined in IETF RFC4665, IETF RFC5440. MPLS management can also be implemented according to the corresponding protocol specifications, such as IETF RFC3209.

When forwarding based on a path label, if a packet is inserted into the NSH header, the label indicating the multi-protocol label switching path indicates whether the NSH header exists in the packet. FIG. 5 illustrates an example structure 500 of an MPLS-based path label. Generally, the path label 500 includes a label field indicating a label value, and the length may be, for example, 20 bits. The path label 500 may further include a reserved field, also referred to as an experimental use field, which is reserved for experimental use, and may be, for example, 3 bits in length. The path label 500 may further include an S field, which indicates the bottom of the label stack and is 1 bit in length. The S field is used in the case of a label stack (for example, when there are multiple path labels). The path label 500 also includes a time-to-live (TTL) field, which indicates the time-to-live of the path label 500, which may be 8 bits in length. In the implementation of SFC, during the forwarding of the packet, an indication of the existence of the NSH header of the packet may be added to the path label. For example, a one-bit portion 510 (represented by N) in a reserved field in the path label 500 may be used to indicate the presence of an NSH header in the packet. This means that in the forwarding of the network node, the payload of the packet and the NSH header inserted therein need to be forwarded.

The above discussed how to configure the flow entry of a network node as a forwarding rule associated with SFC when implementing SFC in SDN. Generally, a packet is first received by the network node 220 in the data plane. If there is no flow entry for forwarding the packet in the network node 220, the network node 220 will determine that no SFC matching the packet is found and cannot be forwarded. In this case, the network node 220 provides an indication to the SFC controller 210 that no SFC matching the packet was found. For example, the network node 220 may directly transmit header information in a packet without a matching SFC to the SFC controller 210 or forward it to the SFC controller 210 via the SDN controller 212. The direct communication between the network node 220 and the SFC controller 210 may be implemented based on the extended NETCONF protocol, for example. If forwarded via the SDN controller 212, packets can be provided from the network node 220 to the SDN controller 212 via a "Packet-in" message. In other implementations, the network node 220 may also provide an indirect indication that a certain packet has no matching SFC and cannot be forwarded.

In response to an indication from the network node 220 that the packet cannot be forwarded because there is no matching SFC (such as the packet itself or the header information of the packet that cannot be forwarded), the SFC controller 210 may create an SFC for the packet, and The created SFC-associated forwarding rule is configured to other network nodes 220 involved in obtaining the packet network node 220 from it and implementing the forwarding of the business functions of the packet to the SFC.

The above embodiments discussed how to configure a forwarding rule (eg, a flow entry of a flow table) to the network node 220. In some embodiments, the SFC controller 210 may update or delete the corresponding SFC depending on the application. In this case, the SFC controller 210 configures the network node 220 with a forwarding rule associated with the updated SFC, and instructs the network node 220 to discard the forwarding rule associated with the old or deleted SFC. This communication between the SFC controller 210 and the network node 220 may also be performed directly or completed via the SDN controller 212.

In some embodiments, in addition to being configured with a forwarding rule (e.g., a flow entry in a flow table), the network node 220 may forward the packet based on the forwarding rule so that the packet can be forwarded to the corresponding SF involved in the SFC to For processing. It should be understood that in the process of packet forwarding by the network node 220, in addition to the flow entries of the flow table used for the classification of the SFC and the SFP forwarding function, other flow entries are configured in the network node 220 to implement the network node and the network. Packet forwarding between nodes, network nodes and SF, and network nodes and host devices.

Upon flow entry-based forwarding, the network node 220 will extract the header of the packet and determine whether the header contains matching information indicated by the flow entry. If the header contains such matching information, this means that the packet matches the flow entry. In this case, the network node can process the packet based on the matching flow entry. Processing of packets may be performed by information in the instruction field of the flow entry.

In the example of FIG. 2, the network node 220-1 will be configured with forwarding rules related to the classification function of the SFC, such as a flow entry indicating the information as shown in FIG. 4A. The network node 220-1 may determine how to forward a packet based on such a flow entry. Specifically, if the network node 220-1 determines that the header of the packet contains matching information of the flow entry, the processing action indicated by the flow entry is performed on the packet, such as inserting an NSH header into the packet, and / or replacing the destination address of the packet Is the address of the SF indicated by the flow entry. The network node 220-1 may forward a packet to a downstream node (e.g., the network node 220-2) that is communicatively coupled with the SF based on such a destination address.

The network node 220-2 may be configured with forwarding rules related to SFP forwarding, such as a flow entry indicating information as shown in FIG. 4B. The network node 220-2 may determine how to forward packets based on such flow entries. Specifically, if the network node 220-2 determines that the header of the packet contains matching information (such as an identifier of the SFC) of the flow entry, the processing action indicated by the flow entry may be performed on the packet, such as removing the NSH header from the packet, and / Or, the destination address of the packet is replaced with the address of the SF indicated by the flow entry. The network node 220-2 may forward a packet to a downstream node that is communicatively coupled with the SF based on such a destination address.

Because the network node 220-2 is connected to SF 240-1 (that is, communication coupling) and SF 240-1 is included in the packet SFC, the network node 220-2 can also be configured with another forwarding rule, which instructs the packet to be forwarded Go to SF 240-1 for processing. Such a rule may also be configured by the SFC controller 210 as a flow entry in the flow table of the network node 220-2.

A specific example of a system 200 implemented in an SDN-based SFC will be described below with reference to FIG. 6 to specifically discuss how a network node implements packet forwarding to each SF of an SFC. In the example of FIG. 6, for the purpose of explanation, in addition to the network nodes 220-1, 220-2, the system 200 includes additional network nodes 620-3, 620-4, and 620-5, which are respectively related to SF640 -2, SF 640-2 and 640-3. These network nodes 620-3, 620-4, and 620-5 function similarly to the network node 220, and can also obtain forwarding rules from the SFC controller 210 for performing packet-to-SF forwarding. In the example of FIG. 6, the forwarding rules associated with the SFC configured by the SFC controller 210 are implemented as flow entries in the flow table 602 in the network node. Each network node may include multiple flow tables, and pipeline processing of the flow tables needs to be performed to perform packet forwarding.

FIG. 6 shows the SFC provided for the group 611 from the host 650-1 to the host 650-2, which involves SF 240-1, SF 640-2, and SF 640-4. Figure 6 also shows the SFC provided for the packet 612 from host 650-1 to host 650-3, which involves SF640-3. In the example of FIG. 6, the SDN controller 212 maps the SFC into an MPLS path among network nodes. The paths of SFCs involving SF 240-1, SF 640-2, and SF 640-4 are mapped as LSP_1, LSP_2, and LSP_3. The path involving SFC of 640-3 is mapped as LSP_5.

In operation, the network nodes 220-1 and 220-2 and the network nodes 620-3, 620-4, and 620-5 perform packet forwarding according to the flow tables configured therein. 7A to 7N show examples of flow tables used by these network nodes when forwarding. The following will describe in detail how network nodes forward packets accordingly.

The network node 220-1 receives the packet 611 from the host 650-1, for example, via the input port 101. The network node 220-1 performs an operation on the classification of the SFC based on the flow table 710. Specifically, the network node 220-1 extracts a header from the packet, which includes, for example, a source IP address, a destination IP address, a protocol type, an input port, and the like of the packet. The network node 220-1 matches the extracted information with a matching field in a flow entry of the flow table 710 shown in FIG. 7A. If the information extracted from packet 611 matches the information in the matching field in the first flow entry in flow table 710 (for example, source IP address: 192.168.0.1, destination IP address: 192.168.0.2, protocol type is IPv4, and input port is 101), the network node 220-1 determines that the flow entry matches the packet 611. The network node 220-1 then performs a processing action on the packet 611 based on the flow entry. Specifically, the network node 220-1 determines that the flow entry indication processing action is "Push NSH header", and therefore inserts the NSH indicated by the flow entry into the packet 611. In addition, the network node 220-1 also replaces the destination IP address in the header of the packet with the destination IP address of the next hop indicated by the flow entry (that is, the IP address of SF 240-1: 202.0.0.11), and according to The pipeline processing of the flow table continues to refer to the flow table 12 to process the packet 611.

In some embodiments, if the network node 220-1 does not find a flow entry in the flow table 710 that matches the packet 611, the network node 220-1 will not be able to forward the packet. In this case, the network node 220-1 may directly transmit the packet 611 to the SFC controller 210 or forward the packet 611 to the SFC controller 210 via the SDN controller 212 according to the NETCONF protocol. In response to receiving such a packet, the SFC controller 210 may create an SFC for the packet and configure a flow table entry associated with the created SFC to the network node 220-1.

For receiving the packet 612 from the host 650-1, similarly, the network node 220-1 may also perform an operation on the classification of the SFC based on the flow table 710, and determine that the second flow entry in the flow table 710 matches the packet 612 . Based on the flow entry, the network node 220-1 inserts an NSH header into the packet 612, and modifies the destination IP address of the packet 612 to the destination IP address of the next hop indicated by the matching flow entry (that is, the IP of SF640-3 Address: 202.0.0.13), and continue to refer to the flow table 12 to process the packet 612 according to the pipeline processing of the flow table. If the network node 220-1 was not originally configured with a flow entry that matches the packet 612, the network node 220-1 may or may provide the packet 612 to the SFC controller 210 to obtain the correct flow entry from the SFC controller 210.

In the pipeline processing of the flow table, the network node 220-1 continues to refer to the flow table 12 to process the

packets

611 and 612. FIG. 7B shows an example structure 712 of the flow table 612 in the network node 220-1. For the packet 611, the network node 220-1 matches the information (for example, input port 101, destination IP address 202.0.0.11) extracted from the header of the packet 611 with the flow entry of the flow table 712. If a matching flow entry (for example, the first flow entry) is found from the flow table 712, the network node 220-1 sets the output label (MPLS label 1000) of the packet based on the flow entry, and updates the packet header of the packet 611 ( That is, push the MPLS label 1000), and forward the packet via the output port 102.

For the packet 612, the network node 220-1 matches the information (for example, input port 101, destination IP address 202.0.0.13) extracted from the header of the packet 612 with the flow entry of the flow table 712. If a matching flow entry (for example, a second flow entry) is found from the flow table 712, the network node 220-1 sets the output label (MPLS label 2000) of the packet based on the flow entry, and updates the packet header of the packet 612 ( That is, push the MPLS label 2000), and forward the packet via the output port 102.

After processing, the

packets

611 and 612 will be output by the output port 102 of the network node 220-1 and input to the network node 220-2 via the input port 201 of the network node 220-2. The network node 220-2 first performs forwarding of the

packets

611 and 612 based on the flow table 720 as shown in FIG. 7C. Specifically, in the network node 220-2, for the packet 611 received from the upstream node 220-1, the network node 220-2 extracts the header of the packet 611 (for example, it includes the input port 201, the input MPLS label 1100, the destination IP Address, NSH header inserted by network node 220-1, etc.). The network node 220-2 matches the extracted information with the flow entry of the flow table 720, and determines that the first flow entry (including the input port 201 and the input MPLS label 1100) in the flow table 720 matches. The network node 220-2 may perform a processing action on the packet 611 based on the flow entry. The network node 220-2 may update the packet header of the packet 611 to take out the MPLS label 1100, and output the packet 611 via the output port 202.

Network node 220-2 is communicatively coupled with SF 240-1 via output port 202. Therefore, SF 240-1 can receive packet 611 and perform corresponding processing on packet 611. In some examples, SF 240-1 uses the context header (e.g., C1) in the NSH header of packet 611 to process packet 611 and reduces the identifier SI in the NSH header of packet 611 (e.g., from 255 to 254) . After processing, SF 240-1 returns the packet 611 to the network node 220-2 via the input port 203 of the network node 220-2. After receiving the packet 611, the network node 220-2 extracts the header (for example, input port, input MPLS label, SPI and SI in NSH) of the packet 611. The network node 220-2 determines that the packet 611 matches the third flow entry in the flow table 720, which indicates the input port 203. Based on the flow entry, the network node 220-2 will continue to refer to the flow table 1 in the node to process the packet 611.

For the packet 612 received from the upstream node 220-1 via the input port 201, the network node 220-2 can also refer to the flow table 720 to similarly process the packet and determine the flow entry (e.g., the flow table 720) that matches the packet. The second flow entry in), and the processing action indicated by the matching flow entry is performed on the packet 612. Specifically, the network node 220-2 updates the header of the packet 612, that is, switches the MPLS label in the header from 2100 to the MPLS label 2200, and outputs the packet 612 via the output port 205.

For the packet 611, as mentioned above, the network node 220-2 needs to continue to refer to the flow table 1 for processing. FIG. 7D shows an example of the flow table 1 in the network node 220-2, that is, the flow table 722. The flow table 722 includes flow entries associated with SFP forwarding. The network node 220-2 matches the information extracted from the header of the packet 611 with the information in the matching field of the flow entry of the flow table 722, and determines that the flow entries indicating the SPI 25 and SI 254 are included in the NSH header of the packet 611 Matches the information. The network node 220-2 then determines the IP address of the next hop of the packet 611 (ie, the IP address 202.0.0.12 of 640-2). The network node 220-2 also performs the processing action indicated by the flow entry on the packet 611, that is, the destination address in the header of the packet 611 is replaced with the IP address of the next hop, and then the reference flow is continued according to the pipeline processing of the flow table. Table 23 to process packet 611.

The flow table 23 of the network node 220-2 is shown as the flow table 724 in FIG. 7E. The network node 220-2 matches the information extracted from the header of the packet 611 with the information indicated in the matching field in the flow entry of the flow table 724, and determines the flow entry and packet indicating the input port 203 and the destination IP address 202.0.0.12. The information in the header of 611 matches. The network node 220-2 can therefore process the packet 611 based on the flow entry. Specifically, the network node 220-2 sets the output MPLS label of the packet 611 to the output label 1200 indicated by the flow entry, updates the header by inserting the MPLS label 1200 into the header of the packet 611, and outputs the packet via the output port 204.

The input port 301 of the network node 620-3 is connected to the output port 204 of the network node 220-2, so the network node 620-3 receives the packet 611. The network node 620-3 may process the packet 611 based on the flow table configured therein. Specifically, the network node 620-3 first looks for a flow entry matching the packet 611 in the flow table 730 shown in FIG. 7F. The network node 620-3 extracts the header information of the packet 611 (for example, input port 301, input MPLS label 1300, NSH header, destination IP address, etc.), and then determines that the extracted information matches the first flow entry in the flow table 730 The information in the fields (indicating that the input port 301 and the input MPLS label 1300) match. Thus, the network node 620-3 performs corresponding processing on the packet 611 based on the flow entry, for example, fetches the MPLS label 1300 in the header of the packet 611, and outputs the packet 611 via the output port 302.

Network node 620-3 is communicatively coupled with SF640-2 via output port 302. Therefore, SF640-2 can receive packet 611 and perform corresponding processing on packet 611. In some examples, SF640-2 utilizes the context header (e.g., C1) in the NSH header of packet 611 to process packet 611 and reduce the identifier SI (e.g., from 254 to 253) . After processing, SF640-2 returns packet 611 to network node 620-3 via input port 303 of network node 620-3. After receiving the packet 611, the network node 620-3 extracts the header (for example, the input port, the input MPLS label, the SPI and the SI in the NSH) of the packet 611. The network node 620-3 determines that the packet 611 matches the third flow entry of the flow table 730, which indicates the input port 303. Based on the flow entry, the network node 620-3 will continue to refer to the flow table 1 in the node to process the packet 611.

FIG. 7G shows an example of the flow table 1 in the network node 620-3, that is, the flow table 732. The flow table 732 includes flow entries associated with SFP forwarding. The network node 620-3 matches the information extracted from the header of the packet 611 with the information in the matching field of the flow entry of the flow table 732, and determines that the flow entries indicating the SPI 25 and SI 253 are included in the NSH header of the packet 611 Matches the information. Based on the matching flow entries, the network node 620-3 then determines the IP address of the next hop of the packet 611 (ie, the IP address 202.0.0.14 of SF640-4). The network node 620-3 also performs the processing action indicated by the flow entry on the packet 611, that is, the destination address in the header of the packet 611 is replaced with the IP address of the next hop, and then the reference flow is continued according to the pipeline processing of the flow table. Table 34 to process packet 611.

The flow table 34 of the network node 620-3 is shown as the flow table 734 in FIG. 7H. The network node 620-3 matches the information extracted from the header of the packet 611 with the information indicated in the matching field in the flow entry of the flow table 734, and determines the flow entry and packet indicating the input port 303 and the destination IP address 202.0.0.14. The information in the header of 611 matches. The network node 620-3 can therefore process the packet 611 based on the flow entry. Specifically, the network node 620-3 sets the output MPLS label of the packet 611 to the output label 1400 indicated by the flow entry, updates the header by inserting the MPLS label 1400 into the header of the packet 611, and then outputs the packet via the output port 304.

The input port 401 of the network node 620-4 is connected to the output port 304 of the network node 620-3, so the network node 620-4 receives the packet 611. The network node 620-4 may process the packet 611 based on the flow table configured therein. Specifically, the network node 620-4 first finds a flow entry matching the packet 611 in the flow table 740 shown in FIG. 7I. The network node 620-4 extracts the header information of the packet 611 (for example, input port 401, input MPLS label 1500, NSH header, destination IP address, etc.), and then determines that the extracted information matches the first flow entry in the flow table 740 The information in the fields (indicating that the input port 401 and the input MPLS label 1500) match. Then, the network node 620-4 performs a corresponding process on the packet 611 based on the flow entry, for example, takes out an MPLS label 1500 in the header of the packet 611, and outputs the packet 611 via the port 402.

The network node 620-4 is communicatively coupled with the SF 640-4 via the output port 402. Therefore, the SF 640-4 can receive the packet 611 and perform corresponding processing on the packet 611. In some examples, SF640-4 utilizes the context header (e.g., C1) in the NSH header of packet 611 to process packet 611 and reduce the identifier SI in the NSH header of packet 611 (e.g., from 253 to 252) . After processing, the packet 611 is returned to the network node 620-4 through the input port 403 of the SF640-4. After receiving the packet 611, the network node 620-4 determines that the header information (for example, input port, input MPLS label, SPI and SI in NSH) matches the indicated input port 403 in the flow table 740. Based on the flow entry, the network node 620-4 continues to refer to the flow table 1 in the node (ie, the flow table 742 shown in FIG. 7J) to process the packet 611.

According to the flow table 742, the network node 620-4 matches the information extracted from the header of the packet 611 with the information in the matching field of the flow entry of the flow table 742, and determines the flow entry indicating SPI 25 and SI 252 and the packet 611. The information contained in the NSH header matches. Based on the matching flow entries, the network node 620-4 then determines the IP address of the next hop of the packet 611 (ie, the IP address of the host 650-2 192.168.0.2). The network node 620-4 also executes the processing action indicated by the flow entry on the packet 611, that is, taking out the NSH header of the packet 611, and replacing the destination address in the header of the packet 611 with the IP address of the next hop, and The pipeline processing of the table continues to refer to the flow table 45 to process the packet 611.

The flow table 45 of the network node 620-4 is shown as the flow table 744 in FIG. 7K. The network node 620-4 matches the information extracted from the header of the packet 611 with the information indicated in the matching field in the flow entry of the flow table 744, and determines the flow entry and packet indicating the input port 403 and the destination IP address 192.168.0.2. The information in the header of 611 matches. The network node 620-4 can therefore process the packet 611 based on the flow entry. Specifically, the network node 620-4 outputs the packet 611 via the output port 404. Host 650-2 is connected to. The output port 404 of the network node 620-4, so the packet 611 can be obtained.

Processing of packet 612 continues. As described above, the packet 612 is output via the output port 205 of the network node 220-1. The input port 501 of the network node 620-5 and the output port 205 of the network node 220-1, so the network node 620-5 obtains the packet 612. The network node 620-5 may process the packet 612 based on the flow table configured therein. Specifically, the network node 620-5 looks up a flow entry matching the packet 612 in the flow table 750 shown in FIG. 7L. The network node 620-5 extracts the header information of the packet 612 (for example, input port 501, input MPLS label 2300, NSH header, destination IP address, etc.), and then determines that the extracted information matches the first flow entry in the flow table 750 The information in the fields (indicating that the input port 501 and the input MPLS label 2300) match. Thus, the network node 620-5 performs corresponding processing on the packet 612 based on the flow entry, for example, extracts an MPLS label 2300 in the header of the packet 612, and outputs the packet 612 via the output port 502.

Network node 620-5 is communicatively coupled with SF640-3 via output port 502. Therefore, SF640-3 can receive packet 612 and perform corresponding processing on packet 612. In some examples, SF640-3 utilizes the context header (e.g., C2) in the NSH header of packet 612 to process packet 612 and reduce the identifier SI in the NSH header of packet 612 (e.g., from 224 to 223) . After processing, SF640-3 returns the packet 612 to the network node 620-5 via the input port 502 of the network node 620-5. After receiving the packet 612, the network node 620-5 extracts the header (for example, the input port, the input MPLS label, the SPI and the SI in the NSH) of the packet 612. The network node 620-5 determines that the packet 612 matches the second flow entry of the flow table 750, which indicates the input port 503. Based on the flow entry, the network node 620-5 will continue to refer to the flow table 1 in the node to process the packet 612.

FIG. 7M shows an example of the flow table 1 in the network node 620-5, that is, the flow table 752. The network node 620-5 matches the information extracted from the header of the packet 612 with the information in the matching field of the flow entry of the flow table 752, and determines that the flow entry indicating SPI135 and SI223 is included in the NSH header of the packet 612 Matches the information. Based on the matching flow entries, the network node 620-3 then determines the IP address of the next hop of the packet 611 (ie, the IP address of the host 650-3 192.168.0.3). The network node 620-5 also performs the processing action indicated by the flow entry on the packet 612, that is, takes out the NSH header of the packet 612, and replaces the destination address in the header of the packet 612 with the IP address of the next hop, and then, The pipeline processing of the table continues with reference to the flow table 56 to process the packet 612.

The flow table 56 of the network node 620-5 is shown as the flow table 754 in FIG. 7N. The network node 620-5 matches the information extracted from the header of the packet 612 with the information indicated in the matching field in the flow entry of the flow table 754, and determines the flow entry and packet indicating the input port 503 and the destination IP address 192.168.0.3. The information in the header of 612 matches. The network node 620-5 may therefore process the packet 612 based on the flow entry. Specifically, the network node 620-5 outputs the packet 612 via the output port 504. Host 650-3 is connected to. The output port 504 of the network node 620-5, so the packet 612 can be obtained.

After the above, before being transmitted to the destination host, the

packets

611 and 612 can be processed via the SF in the corresponding SFC. According to an embodiment of the present disclosure, such an SFC can be implemented in an SDN network.

FIG. 8 shows a flowchart of a method 800 for communication according to an embodiment of the present disclosure. The method 800 may be, for example, at the SFC controller 210 shown in FIG. 2.

At block 802, a business function chain is created for a packet, the business function chain including an ordered set of business functions to be used to process the packet. At block 804, corresponding forwarding rules associated with the business function chain are configured to a plurality of network nodes in the software-defined network. Corresponding forwarding rules indicate how multiple network nodes forward packets to a set of ordered business functions in a business function chain.

In some embodiments, configuring the corresponding forwarding rule to multiple network nodes includes one of the following: directly transmitting the corresponding forwarding rule to multiple network nodes; or providing the corresponding forwarding rule via a software-defined network controller in a software-defined network To multiple network nodes.

In some embodiments, configuring the corresponding forwarding rule to multiple network nodes includes: configuring a first flow entry in a first flow table of the first network node, where the first flow entry indicates at least matching information, a packet network service header, The first service function in the group of ordered service functions to which the packet is forwarded and the first processing action to be performed on the packet by the first network node, the first processing action includes inserting a network service header into the packet and a destination address of the packet Replace with at least one of the addresses of the first business function.

In some embodiments, the network service header includes at least one of the following: an identifier of a service function chain, a protocol type of a payload in a packet, and a context header.

In some embodiments, the matching information includes at least one of the following: the source address of the packet, the source port number of the packet, the destination address of the packet, the destination port number of the packet, the protocol type of the packet, the input port of the packet, the Application type and grouped user information.

In some embodiments, configuring the corresponding forwarding rule to multiple network nodes includes: configuring a second flow entry into a second flow table of the second network node, where the second flow entry indicates at least an identifier of the service function chain, A second service function in a group of ordered service functions to which the packet is forwarded and a second processing action to be performed on the packet by the second network node, the second processing action includes removing the network service header from the packet and the purpose of the packet The local address is replaced with at least one of the addresses of the second service function.

In some embodiments, creating a business function chain includes: sending a request for software topology network topology information to a software-defined network controller in a software-defined network; receiving network topology information from the software-defined network controller; and based on the network topology Information to generate business function chains.

In some embodiments, creating a business function chain includes: in response to receiving an indication from a network node of a plurality of network nodes that a packet has no matching business function chain and cannot be forwarded, creating a business function chain for the packet.

FIG. 9 shows a flowchart of a method 900 for communication according to an embodiment of the present disclosure. The method 900 may be, for example, at the network node 220 shown in FIG. 2 or the network node 620-3, 620-4, or 620-5 shown in FIG.

At block 902, a packet is received from an upstream node in a software-defined network. At block 904, a forwarding rule associated with the packetized business function chain is obtained from the business function chain controller. The business function chain includes an ordered set of business functions to be used to process packets, and the forwarding rules instruct the network node how to forward packets to business functions in a set of ordered business functions. At block 906, based on the forwarding rules, the packet is forwarded to a downstream node communicatively coupled with a business function in a set of ordered business functions.

In some embodiments, obtaining a forwarding rule includes one of the following: directly receiving a forwarding rule from a business function chain controller; or receiving a forwarding rule forwarded from a business function chain controller via a software-defined network controller in a software-defined network.

In some embodiments, the forwarding rule includes a first flow entry in a first flow table. The first flow entry indicates at least matching information, a network service header of the packet, and a first service function in a group of ordered service functions to which the packet is to be forwarded. And a first processing action to be performed on the packet by the network node, the first processing action includes at least one of inserting a network service header into the packet and replacing a destination address of the packet with an address of the first service function. Forwarding the packet includes: in response to determining that the header of the packet includes matching information, performing a first processing action on the packet; and forwarding the packet to a downstream node that is communicatively coupled with the first service function based on the address of the first service function.

In some embodiments, the matching information includes at least one of: a source address of the packet, a destination address of the packet, a protocol type of the packet, an input port of the packet, an application type of the packet, and user information of the packet.

In some embodiments, the forwarding rule includes a second flow entry in a second flow table, the second flow entry indicating at least an identifier of a service function chain, a second service in a group of ordered service functions to which the packet is to be forwarded A function and a second processing action to be performed on the packet by the network node, the second processing action including at least one of removing a network service header from the packet and replacing a destination address of the packet with an address of the second service function. Forwarding the packet includes: in response to determining that the header of the packet includes the identifier of the business function chain of the second flow entry, performing a second processing action on the packet, and forwarding the packet to communicate with the second business function based on the address of the second business function Coupled downstream nodes.

In some embodiments, obtaining a forwarding rule includes: in response to determining when a packet is received that the packet has no matching business function chain and cannot be forwarded, providing an indication to the business function chain controller that the packet cannot be forwarded by a network node; and from The business function chain controller obtains the forwarding rule.

FIG. 10 shows a flowchart of a method 1000 for communication according to an embodiment of the present disclosure. The method 1000 may be, for example, at the SDN controller 212 shown in FIG. 2.

At block 1002, a corresponding forwarding rule associated with the business function chain created for the packet is received from the business function chain controller. The business function chain includes an ordered set of business functions to be used to process packets, and the corresponding forwarding rules instruct multiple network nodes in the software-defined network how to forward packets to an ordered set of business functions in the business function chain. At block 1004, the respective forwarding rules are provided to a plurality of network nodes.

In some embodiments, the method 1000 further includes: receiving a request for network topology information of the software-defined network from the business function chain controller; and providing the network function information to the business function chain controller in response to the request.

In some embodiments, the method 1000 further includes: receiving an indication from a network node of the plurality of network nodes that the packet cannot be forwarded by the network node; and providing the indication to the service function chain controller.

In some embodiments, the method 1000 further includes: mapping a path of the service function chain to a multi-protocol label switching path in the software-defined network for transmission of packets in the software-defined network.

In some embodiments, when a packet is inserted into a network service header, the presence of a network service header for the packet is indicated in a label of the multi-protocol label switching path.

Some embodiments of the present disclosure also provide a communication device. The communication device includes: a component for creating a business function chain for a packet, the business function chain including an ordered set of business functions to be used to process the packet; and a corresponding forwarding rule associated with the business function chain to configure to software A component that defines multiple network nodes in a network, and the corresponding forwarding rules instruct multiple network nodes how to forward packets to a group of ordered business functions in a business function chain.

In some embodiments, the communication device may include a service function chain controller.

In some embodiments, the means for configuring a corresponding forwarding rule to a plurality of network nodes includes one of the following: a means for directly transmitting a corresponding forwarding rule to a plurality of network nodes; or for via a software-defined network The software-defined network controller provides the corresponding forwarding rules to the components of multiple network nodes.

In some embodiments, the means for configuring the corresponding forwarding rule to multiple network nodes includes: means for configuring a first flow entry in a first flow table of the first network node, where the first flow entry indicates at least matching information, A packet network service header, a first service function in a group of ordered service functions to which the packet is to be forwarded, and a first processing action to be performed by the first network node on the packet. The first processing action includes inserting a network service into the packet. At least one of a header and a destination address of the packet is replaced with an address of the first service function.

In some embodiments, the means for configuring a corresponding forwarding rule to a plurality of network nodes includes: means for configuring a second flow entry in a second flow table of the second network node, the second flow entry indicating at least The identifier of the service function chain, the second service function in the group of ordered service functions to which the packet is to be forwarded, and the second processing action to be performed on the packet by the second network node, the second processing action includes removing from the packet At least one of a network service header and a destination address of the packet is replaced with an address of the second service function.

In some embodiments, the means for creating a business function chain includes: means for sending a request for a software-defined network's network topology information to a software-defined network controller in a software-defined network; and for controlling from a software-defined network A component for receiving network topology information; and a component for generating a business function chain based on the network topology information.

In some embodiments, the means for creating a business function chain includes: creating a service for a packet in response to receiving an indication from a network node of a plurality of network nodes that the packet has no matching business function chain and cannot be forwarded Functional chain components.

Other embodiments of the present disclosure also provide a communication device. The communication device includes: a component for receiving a packet from an upstream node in a software-defined network; and a component for obtaining a corresponding forwarding rule associated with a packetized business function chain from a business function chain controller. An ordered set of business functions for processing packets, and the corresponding forwarding rules instruct the network node how to forward packets to a set of ordered business functions; and for forwarding packets to a group of The components of the downstream node in which the business functions are communicatively coupled in the order business functions.

In some embodiments, the communication device includes a network node in a software-defined network.

In some embodiments, the means for obtaining the corresponding forwarding rule includes one of the following: means for directly receiving the corresponding forwarding rule from the business function chain controller; or for receiving a software-defined network controller in a software-defined network Parts of the corresponding forwarding rule forwarded from the business function chain controller.

In some embodiments, the corresponding forwarding rule includes a first flow entry in a first flow table, the first flow entry indicating at least matching information, a network service header of the packet, and a first service in a group of ordered service functions to which the packet is to be forwarded A function and a first processing action to be performed on the packet by the first network node, the first processing action including at least one of inserting a network service header into the packet and replacing a destination address of the packet with an address of the first service function. In some implementations, the means for forwarding a packet includes: means for performing a first processing action on the packet in response to determining that a header of the packet includes matching information; and applying the address based on the first service function to forward the packet to the The first service function is a component of a downstream node communicatively coupled.

In some embodiments, the corresponding forwarding rule includes a second flow entry in a second flow table, the second flow entry indicating at least an identifier of a business function chain, a second in a group of ordered business functions to which the packet is to be forwarded A service function and a second processing action to be performed on the packet by the second network node, the second processing action including at least one of removing a network service header from the packet and replacing a destination address of the packet with an address of the second service function. In some embodiments, the means for forwarding a packet includes means for performing a second processing action on the packet in response to determining that a header of the packet includes an identifier of a service function chain of a second flow entry, and for The address of the second service function is used to forward the packet to a component of a downstream node that is communicatively coupled with the second service function.

In some embodiments, the means for obtaining a corresponding forwarding rule includes: in response to determining when a packet is received that the packet does not have a matching business function chain and cannot be forwarded to the business function chain controller; providing the packet cannot be provided by a network node Means for forwarding instructions; and means for obtaining corresponding forwarding rules from the business function chain controller.

Other embodiments of the present disclosure also provide a communication device. The communication device includes means for receiving a corresponding forwarding rule associated with a business function chain created for a packet from a business function chain controller, the business function chain including an ordered set of business functions to be used to process the packet, and correspondingly Forwarding rules instruct multiple network nodes in a software-defined network how to forward packets to a set of ordered business functions in a business function chain; and means for providing corresponding forwarding rules to multiple network nodes.

In some embodiments, the communication device includes a software-defined network controller.

In some embodiments, the communication device further comprises: means for receiving a request for network topology information of the software-defined network from the service function chain controller; and providing network topology information to the service function chain controller in response to the request Of parts.

In some embodiments, the communication device further comprises: means for receiving an indication from a network node of the plurality of network nodes that the packet cannot be forwarded by the network node; and means for providing the indication to the service function chain controller.

In some embodiments, the communication device further comprises: means for mapping a path of the service function chain to a multi-protocol label switching path in the software-defined network for transmission of packets in the software-defined network.

FIG. 11 illustrates a schematic block diagram of an example device 1300 that can be used to implement embodiments of the present disclosure. As shown, the device 1100 includes a central processing unit (CPU) 1101, which can be loaded into a computer in a random access memory (RAM) 1103 according to computer program instructions stored in a read only memory (ROM) 1102 or from the storage unit 1108 Program instructions to perform various appropriate actions and processes. In the RAM 1103, various programs and data required for the operation of the device 1100 can also be stored. The CPU 1101, the ROM 1102, and the RAM 1103 are connected to each other through a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

Multiple components in the device 1100 are connected to the I / O interface 1105, including: an input unit 1106, such as a keyboard, a mouse, etc .; an output unit 1107, such as various types of displays, speakers, etc .; a storage unit 1108, such as a storage disk, an optical disc Etc .; and a communication unit 1109, such as a network card, a modem, a wireless communication transceiver, and the like. The communication unit 1109 allows the device 1100 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

The various processes and processes described above, such as method 800, method 900, and / or 1000, may be performed by the processing unit 1101. For example, in some embodiments, method 800, method 900, and / or 1000 may be implemented as a computer software program that is tangibly embodied on a machine-readable medium, such as storage unit 1108. In some embodiments, part or all of the computer program may be loaded and / or installed on the device 1100 via the ROM 1102 and / or the communication unit 1109. When the computer program is loaded into the RAM 1103 and executed by the CPU 1101, one or more actions of the method 800, method 900, and / or 1000 described above may be performed.

The present disclosure may be a method, an apparatus, a system, and / or a computer program product. The computer program product may include a computer-readable storage medium on which computer-readable program instructions for performing various aspects of the present disclosure are uploaded.

The computer-readable storage medium may be a tangible device that can hold and store instructions used by the instruction execution device. The computer-readable storage medium may be, for example, but not limited to, an electric storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of computer-readable storage media include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) Or flash memory), static random access memory (SRAM), portable compact disc read only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanical encoding device, such as a printer with instructions stored thereon A protruding structure in the hole card or groove, and any suitable combination of the above. Computer-readable storage media used herein are not to be interpreted as transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (for example, light pulses through fiber optic cables), or via electrical wires Electrical signal transmitted.

The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to various computing / processing devices, or downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in each computing / processing device .

Computer program instructions for performing the operations of the present disclosure may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, or in one or more programming languages. Source code or object code written in any combination. The programming languages include object-oriented programming languages such as Smalltalk, C ++, and the like, as well as conventional procedural programming languages such as the "C" language or similar programming languages. Computer-readable program instructions may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer, partly on a remote computer, or entirely on a remote computer or server carried out. In the case of a remote computer, the remote computer can be connected to the user's computer through any kind of network, including a local area network (LAN) or wide area network (WAN), or it can be connected to an external computer (such as through the Internet using an Internet service provider) connection). In some embodiments, electronic circuits such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) are personalized by using state information of computer-readable program instructions. The electronic circuits may Computer-readable program instructions are executed to implement various aspects of the present disclosure.

Various aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

These computer-readable program instructions can be provided to a processing unit of a general-purpose computer, special purpose computer, or other programmable data processing device, thereby producing a machine such that, when executed by a processing unit of a computer or other programmable data processing device , Means for implementing the functions / actions specified in one or more blocks in the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored in a computer-readable storage medium, and these instructions cause a computer, a programmable data processing apparatus, and / or other devices to work in a specific manner. Thus, a computer-readable medium storing instructions includes: An article of manufacture that includes instructions to implement various aspects of the functions / acts specified in one or more blocks in the flowcharts and / or block diagrams.

Computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other device, so that a series of operating steps can be performed on the computer, other programmable data processing device, or other device to produce a computer-implemented process , So that the instructions executed on the computer, other programmable data processing apparatus, or other equipment can implement the functions / actions specified in one or more blocks in the flowchart and / or block diagram.

The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagram may represent a module, a program segment, or a part of an instruction that contains one or more components for implementing a specified logical function. Executable instructions. In some alternative implementations, the functions marked in the blocks may also occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in the reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented in a dedicated hardware-based system that performs the specified function or action. , Or it can be implemented with a combination of dedicated hardware and computer instructions.

The embodiments of the present disclosure have been described above, the above description is exemplary, not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the various embodiments described. The terminology used herein is chosen to best explain the principles of the embodiments, practical applications or technical improvements to technologies in the market, or to enable other ordinary skilled persons in the art to understand the embodiments disclosed herein.

Claims

A method implemented at a business function chain controller includes:

Creating a business function chain for a group, the business function chain including an ordered set of business functions to be used to process the group; and

Directly or indirectly configure a corresponding forwarding rule associated with the business function chain to multiple network nodes in a software-defined network, and the corresponding forwarding rule instructs multiple network nodes how to forward the packet to the business function chain The set of ordered business functions in.
The method according to claim 1, wherein directly or indirectly configuring the corresponding forwarding rule to the plurality of network nodes comprises one of the following:

Directly transmitting the corresponding forwarding rules to the multiple network nodes; or

The corresponding forwarding rules are provided to the plurality of network nodes via a software-defined network controller in the software-defined network.
The method according to claim 1, wherein directly or indirectly configuring the corresponding forwarding rule to the plurality of network nodes comprises:

A first flow entry is directly or indirectly configured in a first flow table of a first network node, and the first flow entry indicates at least matching information, a network service header of the packet, and a group to which the packet is to be forwarded. A first service function in the sequence service function and a first processing action to be performed on the packet by the first network node, the first processing action includes inserting the network service header into the packet and inserting the network service header into the packet The destination address of the packet is replaced with at least one of the addresses of the first service function.
The method according to claim 3, wherein the network service header comprises at least one of: an identifier of the service function chain, a protocol type of a payload in the packet, and a context header.
The method according to claim 3, wherein the matching information includes at least one of: a source address of the packet, a source port number of the packet, a destination address of the packet, and a destination port of the packet Number, protocol type of the packet, input port of the packet, application type of the packet, and user information of the packet.
The method according to claim 1, wherein directly or indirectly configuring the corresponding forwarding rule to the plurality of network nodes comprises:

Directly or indirectly configuring a second flow entry into a second flow table of a second network node, the second flow entry indicating at least an identifier of the service function chain, the group to which the packet is to be forwarded A second service function in the ordered service function and a second processing action to be performed on the packet by the second network node, the second processing action including removing a network service header from the packet and The destination address of the packet is replaced with at least one of the addresses of the second service function.
The method of claim 1, wherein creating the business function chain comprises:

Sending a request for topology information of the software-defined network to a software-defined network controller in the software-defined network;

Receiving the network topology information from the software-defined network controller; and

The service function chain is generated based on the network topology information.
The method of claim 1, wherein creating the business function chain comprises:

In response to receiving an indication from a network node of the plurality of network nodes that the packet has no matching business function chain and cannot be forwarded, the business function chain is created for the packet.
A method implemented at a network node in a software-defined network includes:

Receiving a packet from an upstream node in the software-defined network;

Obtaining a forwarding rule associated with a business function chain of the packet from a business function chain controller, the business function chain including an ordered set of business functions to be used to process the packet, and the forwarding rule indicates that How the network node forwards the packet to a business function in the set of ordered business functions; and

Based on the forwarding rule, the packet is forwarded to a downstream node communicatively coupled with a business function in the set of ordered business functions.
The method according to claim 9, wherein obtaining the forwarding rule comprises one of the following:

Receiving the forwarding rule directly from the service function chain controller; or

Receiving the forwarding rule forwarded from the service function chain controller via a software-defined network controller in the software-defined network.
The method according to claim 9, wherein the forwarding rule comprises a first flow entry in a first flow table, the first flow entry indicating at least matching information, a network service header of the packet, and a packet to which the packet is to be forwarded. A first service function in the set of ordered service functions and a first processing action to be performed by the network node on the packet, the first processing action including inserting the network service header and Replacing the destination address of the packet with at least one of the addresses of the first service function; and

Wherein forwarding the packet includes:

Performing the first processing action on the packet in response to determining that a header of the packet includes the matching information; and

Based on the address of the first service function, forwarding the packet to the downstream node communicatively coupled to the first service function.
The method according to claim 11, wherein the network service header comprises at least one of: an identifier of the service function chain, a protocol type of a payload in the packet, and a context header.
The method according to claim 11, wherein the matching information includes at least one of: a source address of the packet, a source port of the packet, a destination address of the packet, a destination port of the packet, The protocol type of the packet, the input port of the packet, the application type of the packet, and the user information of the packet.
The method according to claim 9, wherein the forwarding rule includes a second flow entry in a second flow table, the second flow entry at least indicating an identifier of the service function chain, and the packet is to be forwarded to A second service function in the set of ordered service functions and a second processing action to be performed on the packet by the network node, the second processing action includes removing a network service header from the packet and Replacing the destination address of the packet with at least one of the addresses of the second service function; and

Wherein forwarding the packet includes:

Performing the second processing action on the packet in response to determining that a header of the packet includes the identifier of the business function chain of the second flow entry, and

Based on the address of the second service function, forwarding the packet to the downstream node communicatively coupled with the second service function.
The method according to claim 9, wherein obtaining the forwarding rule comprises:

In response to determining, when the packet is received, that the packet has no matching business function chain and cannot be forwarded, providing the business function chain controller with an indication that the packet cannot be forwarded by the network node; and

Obtaining the forwarding rule from the service function chain controller.
A method implemented at a software-defined network controller includes:

Receiving a corresponding forwarding rule associated with a business function chain created for a packet from a business function chain controller, the business function chain including an ordered set of business functions to be used to process the packet, and the corresponding forwarding rule indicates How a plurality of network nodes in a software-defined network forward the packet to the set of ordered business functions in the business function chain; and

The corresponding forwarding rules are provided to the plurality of network nodes.
The method according to claim 16, further comprising:

Receiving a request for network topology information of the software-defined network from the service function chain controller; and

In response to the request, the network function information is provided to the service function chain controller.
The method according to claim 16, further comprising:

Receiving an indication from a network node of the plurality of network nodes that the packet cannot be forwarded by the network node; and

Providing the indication to the service function chain controller.
The method according to claim 16, further comprising:

And mapping a path of the service function chain to a multi-protocol label switching path in the software-defined network for transmission of the packet in the software-defined network.
The method according to claim 19, wherein when the packet is inserted into a network service header, the presence of the network service header for the packet is indicated in a label of the multi-protocol label switching path.
A communication device includes:

Processor; and

A memory, which stores instructions that, when executed by the processor, cause the device to perform the method according to any one of claims 1-8.
A communication device includes:

Processor; and

A memory that stores instructions that, when executed by the processor, cause the device to perform the method according to any one of claims 9-15.
A communication device includes:

Processor; and

A memory that stores instructions that, when executed by the processor, cause the device to perform the method according to any one of claims 16-20.
A computer-readable storage medium having stored thereon a computer program that, when executed by a processor, implements the method according to any one of claims 1-8.
A computer-readable storage medium having stored thereon a computer program that, when executed by a processor, implements the method according to any one of claims 9-15.
A computer-readable storage medium having stored thereon a computer program that, when executed by a processor, implements the method according to any one of claims 16-20.