WO2016118052A1

WO2016118052A1 - Implementing a service chain in a software-defined networking environment

Info

Publication number: WO2016118052A1
Application number: PCT/SE2015/050050
Authority: WO
Inventors: Calin Curescu; Daniel TURULL; Vinay YADHAV
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2015-01-21
Filing date: 2015-01-21
Publication date: 2016-07-28

Abstract

Implementing a service chain in a software-defined networking environment is disclosed. A datapath node receives, via a network, a packet that includes flow identification information and a header comprising a path identifier (ID). Based on the path ID, it is determined that the packet is to be forwarded to a network service function. The flow identification information is stored, and the packet is modified to remove the header from the packet. The datapath node forwards the packet to the network service function.

Description

IMPLEMENTING A SERVICE CHAIN IN A SOFTWARE-DEFINED

NETWORKING ENVIRONMENT

TECHNICAL FIELD

[0001] The embodiments relate to a software-defined networking (SDN) environment and, in particular, to implementing a service chain of one or more network service functions in an SDN environment. BACKGROUND

[0002] Software-defined networking (SDN) is a network architecture wherein the forwarding plane (sometimes referred to as the data plane) and the control plane, which are conventionally implemented in a single network node, are separated and implemented in two distinct network nodes. Such distinct network nodes may be referred to as a datapath node and a controller node, respectively. An example of a specification of an SDN architecture is the OpenFlow Switch Specification, version 1.3.

[0003] Theoretically, by separating the forwarding function and the control function into different network nodes, multiple relatively inexpensive datapath nodes may be coupled together and controlled by a single controller node, resulting in an overall lower network cost. Another potential advantage of an SDN architecture is that a single controller node can be more easily programmed to implement new network functionality than would be possible by programming multiple conventional network nodes that combine the control plane and the forwarding plane, thereby simplifying the implementation of additional networking functions in the network.

[0004] Each datapath node includes a flow table that contains flow table entries that identify flows and forwarding instructions for the flows. Upon receipt of a packet, a datapath node extracts flow identification information from the packet, accesses the flow table, and finds the appropriate flow table entry for the respective flow. The datapath node may then perform one or more actions on the packet and forwards the packet in accordance with the forwarding instructions in the flow table entry. In relatively large networks, the number of flow table entries in a flow table can be substantial, increasing flow table entry lookup time.

[0005] Many networks implement network service functions that process certain, or all, of the packets in one or more flows as the packets traverse the network. The particular sequence of network service functions associated with a flow may be referred to as a service chain. A network service function may, for example, process packets for charging and/or billing purposes, transcoding purposes, authentication purposes, and the like. A network service function is often implemented in a physical or logical "middle box" apparatus, and therefore switching and routing devices must be configured to forward packets of a flow to one or more middle boxes in accordance with a particular service chain associated with the flow. In an SDN environment, this involves setting up multiple flow table entries in one or more datapath nodes along the path of each flow. This may result in a relatively large number of flow entries in the flow tables of the datapath nodes and increase flow table entry lookup time.

[0006] Efforts to simplify implementing service chains in a non-SDN environment have included appending packets with headers based on a policy associated with a subscriber. However, this requires that the middle boxes be programmed or otherwise engineered to interpret and understand the appended header to ensure the header remains intact after processing of the packet. This is impractical in environments that do not have a capability of altering the functionality of the middle boxes used to implement network service functions and, where middle box functionality can be altered, adds complexity and increases a likelihood of introducing processing bugs into the middle box.

[0007] Accordingly, it would be desirable if service chains could be

implemented in an SDN environment that does not require re-programming of middle box functionality and reduces the number of flow table entries in datapath nodes. SUMMARY

[0008] The embodiments implement service chains in a software-defined networking (SDN) environment in a manner that, among other advantages, reduces the number of flow table entries in datapath nodes in a flow path and eliminates a need to reprogram middle boxes that implement network service functions. In one embodiment, a method for routing a packet of a flow to a network service function is provided. A datapath node receives, via a network, a packet that includes flow identification information and a header comprising a path identifier (ID). Based on the path ID, it is determined that the packet is to be forwarded to a network service function. The flow identification information is stored, and the packet is modified to remove the header from the packet. The datapath node forwards the packet to the network service function.

[0009] In one embodiment, the datapath node receives, from the network service function, the packet. The datapath node modifies the packet to include the header and forwards the packet over the network.

[0010] In one embodiment, to store the flow identification information, the datapath node generates a transient flow table entry that includes the flow identification information and stores the transient flow table entry in a transient flow table.

[0011] In one embodiment, the datapath node generates the transient flow table entry that includes the flow identification information to include the header and a timeout value that identifies a timeout period of time.

[0012] In one embodiment, the datapath node receives the packet from the network service function and, based on flow identification information contained in the packet, accesses the transient flow table entry. The packet is modified to include the header, and the datapath node forwards the packet over the network.

[0013] In one embodiment, the header has a format substantially similar to a multiprotocol label switching (MPLS) header or a virtual local area network (VLAN) header. [0014] In one embodiment, the flow identification information comprises one or more of a source internet protocol (IP) address, a destination IP address, a source port ID, a destination port ID, and a protocol ID.

[0015] In one embodiment, it is determined that the timeout period of time has expired, and, in response, the transient flow table entry is removed from the transient flow table.

[0016] In one embodiment, a second packet that includes the flow

identification information and the header comprising the path ID is received. It is determined, based on the path ID, that the second packet is to be forwarded to the network service function. The transient flow table entry from the transient flow table is accessed based on the flow identification information. The timeout value that identifies the timeout period of time is extended. The second packet is modified to remove the header from the second packet, and the second packet is forwarded to the network service function.

[0017] In one embodiment, determining that the packet is to be forwarded to the network service function includes accessing a flow table entry in a flow table based on the flow identification information, and determining that the flow table entry includes an add transient flow action.

[0018] In one embodiment, the datapath node comprises a first flow table, a second flow table, and a transient flow table. To determine that the packet is to be forwarded to the network service function, the datapath node accesses the first flow table and, based on an input port associated with the packet, accesses a first flow table entry in the first flow table that corresponds to the input port. Based on the first flow table entry, the second flow table is accessed. Based on the path ID of the packet, a second flow table entry in the second flow table is accessed. Based on the second flow table entry, the flow identification information is stored in the transient flow table. The packet is modified to remove the header from the packet, and the packet is forwarded to the network service function.

[0019] In another embodiment, a method for associating a path ID with a packet is provided. A datapath node receives, from a controller node, a configuration message that identifies a path ID and flow identification information that identifies a flow. The datapath node receives a packet from a host node via a network. It is determined that the packet is in the flow. Based on determining that the packet is in the flow, the packet is modified to include a header that includes the path ID, and the packet is forwarded to a downstream datapath node.

[0020] In another embodiment, a datapath node for routing a packet of a flow to a network service function is provided. The datapath node includes a transceiver configured to communicate with a network and a processor device that is coupled to the transceiver. The processor device is configured to receive, via the network, a packet that includes flow identification information and a header comprising a path ID. Based on the path ID, it is determined that the packet is to be forwarded to a network service function that is configured to return the packet. The processor device is further configured to store the flow identification information and modify the packet to remove the header from the packet. The processor device is further configured to forward the packet to the network service function.

[0021] In another embodiment, a computer program product is provided. The computer program product is stored on a non-transitory computer-readable storage medium and includes instructions configured to cause a processor device to carry out steps, including receiving, via a network, a packet that includes flow identification information and a header comprising a path ID. The steps further include determining, based on the path ID, that the packet is to be forwarded to a network service function that is configured to return the packet and storing the flow identification information. The steps further include modifying the packet to remove the header from the packet and forwarding the packet to the network service function.

[0022] In another embodiment, a datapath node for associating a path ID with a packet is provided. The datapath node comprises a transceiver configured to communicate with a network and a processor device coupled to the transceiver. The processor device is configured to receive, from a controller node, a configuration message that identifies a path ID and flow identification information that identifies a flow. The processor device is further configured to receive, via a network, a packet from a host node and determine that the packet is in the flow. The processor device is further configured to, based on determining that the packet is in the flow, modify the packet to include a header that includes the path ID and forward the packet to a downstream datapath node.

[0023] Those skilled in the art will appreciate the scope of the disclosure and realize additional aspects thereof after reading the following detailed description of the embodiments in association with the accompanying drawing figures.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

[0024] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0025] Figure 1 is a block diagram of a system and network in which embodiments may be practiced;

[0026] Figure 2 is a flowchart of a method for adding a header that contains a path identifier (ID) to a packet, according to one embodiment;

[0027] Figure 3 is a flowchart of a method for routing a packet of a flow to a service function node, according to one embodiment;

[0028] Figure 4 is a flowchart of a method for processing a packet after the packet is returned from a service function node to the datapath node, according to one embodiment;

[0029] Figure 5 is a block diagram of the system illustrated in Figure 1 , depicting three flows of packets, according to one embodiment;

[0030] Figures 6A - 6D illustrate a state of flow tables at a particular instance in time in respective datapath nodes as the flows illustrated in Figure 5 are being transported through the network, according to one embodiment;

[0031] Figure 7 is a flowchart of a method for implementing an Add Transient Flow action by a datapath node, according to one embodiment; [0032] Figure 8 is a block diagram of a transient flow table, according to another embodiment;

[0033] Figure 9 illustrates example headers suitable for use in the

embodiments;

[0034] Figure 10 illustrates an example format of a transient flow table entry, according to another embodiment;

[0035] Figure 1 1 is a block diagram of the datapath node, according to one embodiment;

[0036] Figure 12 is a functional block diagram of a datapath node that is configured to route a packet of a flow to a network service function, according to one embodiment; and

[0037] Figure 13 is a functional block diagram of a datapath node that is configured to associate a path ID with a packet, according to one embodiment. DETAILED DESCRIPTION

[0038] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure and the accompanying claims.

[0039] Any flowcharts discussed herein are necessarily discussed in some sequence for purposes of illustration, but unless otherwise explicitly indicated, the embodiments are not limited to any particular sequence of steps. The use herein of ordinals in conjunction with an element is solely for distinguishing what might otherwise be similar or identical labels, such as "first packet" and "second packet," and does not imply a priority, a type, an importance, or other attribute, unless otherwise stated herein.

[0040] The embodiments implement service chains in a software-defined networking (SDN) environment in a manner that, among other advantages, reduces the number of flow table entries in datapath nodes in a flow path and eliminates a need to reprogram middle boxes that implement network service functions. An SDN environment is any networking environment that includes devices wherein forwarding plane functionality, sometimes referred to as data plane functionality, is implemented in a plurality of network nodes, referred to herein as datapath nodes, under the control of control plane functionality that is implemented in a separate network node, referred to herein as a controller node. An example of a specification of an SDN architecture is the OpenFlow Switch Specification, version 1 .3 (hereinafter "OpenFlow Switch Specification"), available from the Open Networking Foundation. However, the OpenFlow Switch Specification is but one example of an SDN architecture, and the embodiments described herein are not limited to any particular type of SDN architecture, and indeed are applicable in any network architecture wherein forwarding plane functionality is separated from control plane functionality in different devices.

[0041] Figure 1 is a block diagram of a system 10 and a network 12 in which embodiments may be practiced. The network 12 is an SDN environment and includes a controller node 14 and a plurality of datapath nodes 16-1 - 16-4 (generally, datapath nodes 16). While in practice the network 12 may comprise multiple controller nodes 14 and any number of datapath nodes 16, for purposes of illustration, only one controller node 14 and four datapath nodes 16 are depicted. Each of the datapath nodes 16 may be communicatively coupled to other devices, including the other datapath nodes 16, via communication links 18. As will be discussed in greater detail herein, a communication link 18 may be coupled to a particular port 20 of a datapath node 16, which may impact how traffic, in the form of packets, is processed. The ports 20 may be physical ports or may be logical ports. Each datapath node 16 may also be communicatively coupled to the controller node 14.

[0042] One or more of the datapath nodes 16 may be coupled to devices or networks outside of the network 12. For example, the datapath node 16-1 is coupled to host devices 22-1 , 22-2; the datapath node 16-2 is coupled to host devices 22-3, 22-4, the datapath node 16-3 is coupled to an external network 24, which in turn is coupled to a host device 22-7, and the datapath node 16-4 is coupled to host devices 22-5, 22-6. The host devices 22-1 - 22-7 may be referred to generally as host devices 22. A host device 22 can be any type of computing device that is capable of communicating one or more packets of data, referred to herein as packets, to a datapath node 16 in the network 12, or any type of computing device that is capable of receiving one or more packets from a datapath node 16 in the network 12. A datapath node 16 that is coupled to a device or network outside the network 12 may operate as an ingress datapath node 16 for data that is entering the network 12 via the respective datapath node 16, and/or as an egress datapath node 16 for data that is leaving the network 12 via the respective datapath node 16.

[0043] A packet is processed in the network 12 based on the "flow" with which the respective packet is associated. A respective flow may be identified based on flow identification information contained in the packet, such as, by way of non- limiting example, one or more of a source media access control (MAC) address, a source IP address, a source port address, a destination MAC address, a destination IP address, a destination port address, a protocol, or the like. By way of non-limiting example, flow identification information may comprise the following five fields of information from a transmission control protocol/internet protocol (TCP/IP) header of a packet: source IP address, destination IP address, protocol number, source port number, and destination port number. The flow identification information and forwarding instructions are stored in each datapath node 16 in a flow table.

[0044] As an example of setting up a flow in the network 12, assume that the host device 22-1 communicates a packet to the datapath node 16-1 that is destined for the host device 22-6. The datapath node 16-1 accesses the flow table stored in the datapath node 16-1 to determine if the datapath node 16-1 has already received instructions from the controller node 14 for the flow with which the packet is associated. If a flow table entry associated with the flow is located, the datapath node 16-1 forwards the packet via a particular port 20 based on instructions contained in the flow table entry. If there is no flow table entry associated with the flow, the datapath node 16-1 informs the controller node 14.

[0045] The controller node 14 determines a path of datapath nodes 16 that packets associated with the flow will follow. The controller node 14 then configures an appropriate flow table entry in each datapath node 16 in the path. Upon receipt of a packet associated with the flow, each datapath node 16 accesses the appropriate flow table entry and sends the packet to a designated downstream datapath node 16, or to a host device 22 or external network 24.

[0046] A flow may be associated with a particular service chain. A service chain is a sequence of one or more network service functions that are performed on the packets associated with a flow. Each network service function may process the packets for a particular purpose, such as, by way of non-limiting example, charging and/or billing purposes, transcoding purposes, authentication purposes, and the like. A network service function is often implemented in a physical or logical "middle box" apparatus, referred to herein as a service function node. In Figure 1 , the datapath node 16-3 is illustrated as being coupled to a service function node 26, which implements a particular service function. While for purposes of illustration the network 12 is illustrated as having a single service function node 26, in practice the network 12 may have any number of service function nodes 26, and a packet in a flow may be processed by multiple service function nodes 26 as the packet traverses the network 12.

[0047] In a conventional SDN environment, implementing service chains involves setting up multiple flow table entries in the datapath nodes 16 along the path of a flow to ensure each packet is properly processed by one or more service function nodes 26, and in the desired sequence. This may result in a relatively large number of flow table entries in the flow tables of the datapath nodes, and increase flow table entry lookup time.

[0048] The embodiments, among other advantages, implement service chains in a manner that substantially reduces the number of flow table entries in the datapath nodes 16. Generally, in one embodiment, ingress datapath nodes 16 modify packets to include a header that contains a path identifier (ID). Each path ID identifies a particular service chain. As the packet traverses the datapath nodes 16 in the network 12, each datapath node 16 processes the packet in accordance with the path ID contained in the header. Prior to routing a packet to a service function node 26, a datapath node 16 modifies the packet to remove the header from the packet, stores the header, and communicates the packet to the service function node 26 for processing. Among other advantages, this eliminates a need to reprogram service function nodes 26 to make the service function nodes 26 aware of the header. The service function node 26 processes the packet and returns the packet to the datapath node 16. The datapath node 16 identifies the stored header based on flow identification information

associated with the packet, modifies the packet to include the stored header, and forwards the packet in accordance with forwarding rules in the flow tables of the datapath node 16.

[0049] Figure 2 is a flowchart of a method for adding a header that contains a path ID to a packet, according to one embodiment. Figure 2 will be discussed in conjunction with Figure 1. Assume for purposes of discussion that the host device 22-1 will communicate a series of packets to the datapath node 16-1 that are destined for the host device 22-6. The datapath node 16-1 receives, from the controller node 14, a configuration message that identifies a path ID and flow identification information that identifies the flow with which the series of packets will be associated (Figure 2, block 1000). In one embodiment, the datapath node 16-1 may receive such configuration message before the first packet is received from the host device 22-1. In particular, the controller node 14 may proactively associate flows with service chains, and send appropriate configuration messages to the datapath nodes 16. This may be particularly suitable when flows are aggregated via one or more wildcard entries. For example, all traffic, irrespective of the specific source host device 22, that arrives from a particular external network, may be assigned to a particular service chain.

[0050] Alternatively, the datapath node 16-1 may receive a first packet from the host device 22-1 , access a flow table based on the flow identification information from the first packet, and determine that no flow table entry exists for the first packet. The datapath node 16-1 may then communicate the packet to the controller node 14. The controller node 14 recognizes the first packet as being part of a new flow and determines a path through the network 12 to the host device 22-6. Assume that the controller node 14 determines the path to be datapath node 16-1 , datapath node 16-3, datapath node 16-4, and host device 22-6. The controller node 14 then sends configuration messages to the datapath nodes 16-1 , 16-3, and 16-4 that identify the flow, contain forwarding rules, and contain the path ID. The datapath nodes 16-1 , 16-3, and 16-4 are then each populated with appropriate flow table entries for processing the flow when packets associated with the flow are received.

[0051] In either situation, the datapath node 16-1 receives a packet from the host device 22-1 and determines that the packet is in a flow associated with the path ID (Figure 2, blocks 1002, 1004). The datapath node 16-1 modifies the packet to include a header that includes the path ID (Figure 2, block 1006). The header may comprise any desired format. Examples of headers are not discussed in greater detail herein. The datapath node 16-1 then forwards the packet to the downstream datapath node 16-3 in accordance with the flow table entry configured by the controller node 14.

[0052] Figure 3 is a flowchart of a method for routing a packet associated with a flow to a service function node, according to one embodiment. Figure 3 will be discussed in conjunction with Figure 1. The discussion of Figure 3 will utilize the same example provided with regard to Figure 2, but will discuss functionality of the datapath node 16-3 upon receipt of the packet from the datapath node 16-1. Assume, as discussed above with regard to Figure 2, that the datapath node 16- 3 has been configured by the controller node 14 to contain a flow table entry for the flow with which the packet is associated. The datapath node 16-3 receives the packet, which contains the header that includes a path ID that identifies the service chain for this particular flow (Figure 3, block 2000). The datapath node 16-3 accesses a flow table and, based at least in part on the path ID, determines that the packet is to be forwarded to the service function node 26 (Figure 3, block 2002). The datapath node 16-3 stores the flow identification information, and at least the path ID, associated with the packet (Figure 3, block 2004). The flow identification information and path ID, for example, may be stored in a searchable data structure. The datapath node 16-3 modifies the packet to remove the header from the packet (Figure 3, block 2006). The datapath node 16-3 then forwards the packet to the service function node 26 (Figure 3, block 2008). The service function node 26 processes the packet and then returns the packet to the datapath node 16-3.

[0053] Figure 4 is a flowchart of a method for processing the packet after the packet is returned to the datapath node 16-3, according to one embodiment. The datapath node 16-3 receives the packet from the service function node 26 (Figure 4, block 3000). The datapath node 16-3, utilizing flow identification information from the packet, locates the path ID that was previously stored, as discussed above with regard to Figure 3. The datapath node 16-3 modifies the packet to include the header, which contains the path ID (Figure 4, block 3002). The datapath node 16-3 then forwards the packet in accordance with the flow table entry associated with the flow (Figure 4, block 3004). For this particular flow, as discussed above with regard to Figures 2 and 3, the datapath node 16-3 forwards the packet to the datapath node 16-4.

[0054] Figure 5 is a block diagram of the system 10 illustrated in Figure 1 , depicting three flows 28-1 - 28-3 (generally, flows 28) of packets. For purposes of clarity, the textual labels of datapath nodes 16-1 - 16-4 have been removed from Figure 5. Certain of the ports 20 in the datapath nodes 16 are individually identified by numerals and will be referred to herein by such numerals, such as, for example, port #1 of the datapath node 16-1. Figures 6A - 6D illustrate a state of flow tables within respective datapath nodes 16-1 - 16-4 at a particular instance in time as the flows 28 are being transported through the network 12. In particular, Figure 6A illustrates a state of flow tables in datapath node 16-1 , Figure 6B illustrates a state of flow tables in datapath node 16-2, Figure 6C illustrates a state of flow tables in datapath node 16-3, and Figure 6D illustrates a state of flow tables in datapath node 16-4. Figures 5 and 6A - 6D will be discussed in conjunction with one another. [0055] Flow 28-1 is a flow of packets from the host device 22-2 (HD-B) to the host device 22-5 (HD-E). Flow 28-2 is a flow of packets from the host device 22- 1 (HD-A) to the host device 22-6 (HD-F). Flow 28-3 is a flow of packets from the host devices 22-3 (HD-C), 22-4 (HD-D) to the host device 22-7 (HD-G).

[0056] Figure 6A illustrates a state of four flow tables 30-1 - 30-4 (generally, flow tables 30) within the datapath node 16-1 after flows 28-1 , 28-2 have been set up in the four flow tables 30. Upon receipt of a packet in the flow 28-1 , the datapath node 16-1 accesses the flow table 30-1 (Flow Table 0) and matches the incoming port 20 of the packet (port #2) with the flow table entry 32. Thus, for the flow table 30-1 , the flow identification information associated with the packet is the incoming port 20 of the datapath node 16-1. Based on an action 34 (i.e., "GOTO TABLE 1") of the flow table entry 32, the datapath node 16-1 accesses the flow table 30-2 (Flow Table 1 ). The datapath node 16-1 accesses the flow table 30-2 and matches the incoming port, the source IP address of the host device 22-2 (identified as @HD-B), and the destination IP address of the host device 22-5 (identified as @HD-E) with the flow table entry 36. In this example, the source port (SRC. PORT), destination port (DEST.PORT), and protocol fields of the packet are not relevant because such fields are "wild-carded," as indicated by the asterisks in such fields of the respective flow table entry 36.

[0057] An action 38 (i.e., "PUSH PATH ID 102, GOTO TABLE 3") associated with the flow table entry 36 indicates that the packet should be modified to contain a header that identifies a path ID of 102 for the packet. The path ID 102 represents a particular service chain. The action 38 also directs the datapath node 16-1 to next access the flow table 30-4 (Flow Table 3). The datapath node 16-1 modifies the packet to contain a header that identifies a path ID of 102. The datapath node 16-1 accesses the flow table 30-4 and matches the incoming port of the packet (port #2) and the path ID 102 to the flow table entry 40. Based on an action 42 (i.e., "OUTPUT PORT 3"), the datapath node 16-1 sends the packet to port #3, which is connected to the datapath node 16-3. Processing performed by the datapath node 16-3 on the packet will be described below with respect to Figure 6C. [0058] Upon receipt of a packet in the flow 28-2, the datapath node 16-1 would perform similar processing functionality, but due to the configuration of the flow tables 30-1 , 30-2, and 30-3, such packets would be modified to contain a header that has a path ID of 101 prior to being communicated to the datapath node 16-3. The path ID 101 represents a particular service chain that is different from the service chain identified by the path ID 102. The above discussion thus illustrates an example of a manner in which the ingress datapath node 16-1 may add a header containing a particular path ID that identifies a particular service chain to packets that are entering the network 12.

[0059] Note that the flow table 30-3 contains no flow table entries. This is because the flow table 30-3 is a Transient Flow Table that is utilized to maintain the path ID of packets prior to sending such packets to a service function node 26, as will be discussed in greater detail below with regard to Figure 6C.

Because in this example the datapath node 16-1 is not coupled to a service function node 26, the flow table 30-3 contains no entries.

[0060] Figure 6B illustrates a state of four flow tables 44-1 - 44-4 (generally, flow tables 44) in the datapath node 16-2 after flow 28-3 has been set up in the four flow tables 44. The datapath node 16-2 receives packets from the host device 22-3 (HD-C) and the host device 22-4 (HD-D). The manner of processing such packets is similar to that described above with regard to Figure 6A. Based on action fields 46, 48 of respective flow table entries of the flow table 44-2, the datapath node 16-2 associates packets from both host devices 22-3, 22-4 with the same service chain identified by the path ID 103. Thus, packets from both host devices 22-3, 22-4 form the single flow 28-3 that exits the datapath node 16- 2.

[0061] Figure 6C illustrates a state of four flow tables 50-1 - 50-4 (generally, flow tables 50) in the datapath node 16-3 after flows 28-1 , 28-2, 28-3 have been set up in the four flow tables 50. Upon receipt of a packet of the flow 28-1 (path I D 102) via the port #1 , the datapath node 16-3 accesses the flow table 50-1 (Flow Table 0) and matches the incoming port 20 of the packet (port #1 ) with a flow table entry 52. Based on an action 54 (i.e., "GOTO TABLE 3") of the flow table entry 52, the datapath node 16-3 accesses the flow table 50-4 (Flow Table 3). The datapath node 16-3 matches the incoming port #1 and the path ID 102 contained in the header of the packet with a flow table entry 56. According to one embodiment, the flow table entry 56 contains an action 58 ("ADD

TRANSIENT FLOW, OUTPUT 2") that indicates the datapath node 16-3 is to perform an Add Transient Flow action on the packet. Thus, in this example, the service chain identified by the path ID 102 includes a service function node that will process the packet.

[0062] The Add Transient Flow action is an action wherein the datapath node 16-3 populates the flow table 50-3 (Transient Flow Table) with a transient flow table entry that 1 ) identifies the packet based on flow identification information, 2) contains a copy of the header, or merely the path ID contained in the header, and 3) optionally contains a timeout value that identifies a period of time after which the transient flow table entry is to be removed from the flow table 50-3. The datapath node 16-3 accesses the flow table 50-3 to first determine whether a transient flow table entry already exists for the flow 28-1. The datapath node 16-3 attempts to match flow identification information that is extracted from the packet with a flow table entry in the flow table 50-3. In this example, the flow

identification information comprises a source IP address of the originator of the packet (in this example, the host device 22-2 (HD-B)), the destination IP address (in this example, the host device 22-5 (HD-E)), a logical source port, a logical destination port, and a protocol type.

[0063] Assume that the datapath node 16-3 matches the flow identification information with a transient flow table entry 60 and thus determines that a transient flow table entry currently exists for the flow 28-1. In this event, the datapath node 16-3 may merely reset the timeout value identified in the transient flow table entry 60 to extend the timeout period of time. The datapath node 16-3 then modifies the packet to remove the header from the packet, which completes the performance of the Add Transient Flow action, according to one embodiment. After completing the Add Transient Flow action, in accordance with the action 58, the datapath node 16-3 communicates the packet to port #2. Port #2 is coupled to the service function node 26, and the packet is thus communicated to the service function node 26. For purposes of discussion, if the transient flow table entry 60 did not already exist, the datapath node 16-3 would create the transient flow table entry 60 to include the flow identification information, and to contain an action 62 that will be performed upon receipt of a packet that matches the flow identification information ("PUSH PATH 102, GOTO TABLE 3"). The action 62 will be discussed below with regard to the return of the packet from the service function node 26. Optionally, the transient flow table entry 60 may also include a timeout value in a timeout field 63 that identifies a period of time. After such period of time has expired, the datapath node 16-3 removes the transient flow table entry 60 from the flow table 50-3.

[0064] After the service function node 26 processes the packet, the service function node 26 sends the packet back to the datapath node 16-3 via port #3. Upon receipt of the packet via the port #3, the datapath node 16-3 accesses the flow table 50-1 (Flow Table 0) and matches the incoming port 20 of the packet (port #3) with a flow table entry 64. Based on an action 68 (i.e., "GOTO TABLE 2") of the flow table entry 64, the datapath node 16-3 accesses the flow table 50- 3 (Flow Table 2, Transient Flow Table). The datapath node 16-3 extracts flow identification information from the packet and matches the flow identification information with the transient flow table entry 60. The datapath node 16-3 then performs the action 62. The action 62 indicates that a header containing the path ID 102 is to be added to the packet (i.e., "PUSH PATH ID 102"). The datapath node 16-3 modifies the packet to include a header that contains the path ID 102. The action 62 also indicates the datapath node 16-3 should next process the packet against the flow table 50-4 (Flow Table 3) (i.e., "GOTO TABLE 3").

[0065] The datapath node 16-3 accesses the flow table 50-4 (Flow Table 3) and matches the incoming port 20 of the packet (port #3) and the path ID (102) with a flow table entry 66. Based on an action 68, the datapath node 16-3 sends the packet to port #4, which is coupled to the datapath node 16-4. In summary, the processing of the packet by the datapath node 16-3 includes modifying the packet to remove the header containing the path ID from the packet, storing the header, and sending the modified packet to the service function node 26. Upon receipt of the packet from the service function node 26, the datapath node 16-3 accesses the Transient Flow Table to identify the correct header, modifies the packet to add the header back to the packet, and forwards the packet to a downstream destination. Among other advantages, such processing eliminates the need for the service function node 26 to be programmed to be aware of the existence of the header containing the path ID.

[0066] According to one embodiment, upon occurrence of the timeout contained in the timeout field 63, the datapath node 16-3 removes the transient flow table entry 60 from the flow table 50-3. If, after removal of the transient flow table entry 60, another packet in the flow 28-1 arrives at the datapath node 16-3, the datapath node 16-3 will add a transient flow table entry to the flow table 50-3 in the manner described above. Among other advantages, periodically removing transient flow table entries from the flow table 50-3 helps minimize the size of the flow table 50-3 and ensures transient flow table entries do not remain in the flow table 50-3 after a flow has ended.

[0067] Figure 6D illustrates a state of four flow tables 70-1 - 70-4 (generally, flow tables 70) in the datapath node 16-4 after flows 28-1 , 28-2 have been set up in the four flow tables 70. Upon receipt of a packet of the flow 28-1 (path ID 102) via the port #1 of the datapath node 16-4, the datapath node 16-4 accesses the flow table 70-1 (Flow Table 0) and matches the incoming port 20 of the packet (port #1 ) with a flow table entry 72. Based on an action 74 (i.e., "GOTO TABLE 3") of the flow table entry 72, the datapath node 16-4 accesses the flow table 70- 4 (Flow Table 3). The datapath node 16-4 matches the incoming port #1 and the path ID 102 contained in the header of the packet with a flow table entry 76.

Based on an action 78 ("POP PATH ID") of the flow table entry 76, the datapath node 16-4 modifies the packet to remove the header containing the path ID from the packet. The datapath node 16-4 then sends the packet to the port #2, which is coupled to the host device 22-5 (HD-E). Thus, the POP PATH ID action directs the datapath node 16-4 to remove the header that was added to the packet by the datapath node 16-1 prior to sending the packet outside of the network 12.

[0068] Figures 6A - 6D describe a mechanism by which packets entering the network 12 can be modified by an ingress datapath node 16 to include a header containing a path ID that identifies a particular service chain. Each packet can then be relatively quickly processed by downstream datapath nodes 16 based on an incoming port number and the path ID. Flow tables in the datapath nodes 16 can be configured with one or more Add Transient Flow actions to ensure appropriate modification of the packet occurs both prior to and subsequent to processing by a service function, to eliminate the need for the service function to be aware of the header. Egress datapath nodes 16 remove the header from the packet prior to exit of the packet from the network 12, such that the use of the path ID is transparent to external host devices 22 and networks 24. While for purposes of illustration a service chain having only a single service function has been discussed, it will be apparent that a service chain can have any number of service function nodes 26.

[0069] Figure 7 is a flowchart of a method for implementing an Add Transient Flow action by a datapath node 16, according to one embodiment. Figure 7 will be discussed in conjunction with Figure 5 and Figure 6C. Assume, as discussed above with regard to Figure 6C, that the datapath node 16-3 receives a packet of the flow 28-1 (path ID 102) via the port #1 (Figure 7, block 4000). The datapath node 16-3 ultimately matches the packet with the flow table entry 56 of the flow table 50-4. Based on the action 58 of the flow table entry 56 ("ADD TRANSIENT FLOW, OUTPUT 2"), the datapath node 16-3 accesses the transient flow table 50-3 (Transient Flow Table) with the appropriate match criteria, which in this example is the source IP address of the originator of the packet, the destination IP address, a logical source port, a logical destination port, and a protocol type (Figure 7, block 4002). If a flow table entry that matches the flow identification information of the packet is located, the datapath node 16-3 re-initializes the timeout value contained in the timeout field 63 (Figure 7, blocks 4004, 4006). If a flow table entry that matches the flow identification information of the packet is not located, the datapath node 16-3 adds a new transient flow table entry to the transient flow table 50-3 that contains information that sets the match criteria of the transient flow table entry to the flow identification information associated with the packet, adds a "PUSH PATH ID 102" action, and adds an appropriate timeout (Figure 7, blocks 4004, 4008). The datapath node 16-3 then removes the header from the packet and forwards the packet to the service function node 26 (Figure 7, blocks 4010, 4012).

[0070] Figure 8 is a block diagram of a transient flow table 80, according to another embodiment. In this embodiment, the transient flow table 80 is used for processing fragmented packets. The flow identification information in a transient flow table entry 82 may comprise, for example, the IP address of the originator host device 22, the IP address of the destination host device 22, and the IP fragment ID field of the fragment. In this embodiment, the transient flow table entry 82 may be immediately removed from the transient flow table 80 after being processed by the datapath node 16 upon return of the packet fragment from the service function node 26.

[0071] Figure 9 illustrates example headers suitable for use in the

embodiments. A header 84 contains a single field suitable for storing a path ID to associate packets of a flow with a particular service chain. The field may be any desired length and may be dependent on a particular system

implementation. A header 86 is substantially similar to, or identical to, a multiprotocol label switching (MPLS) label. The use of a header such as the header 86 having a known and predetermined format may simplify

implementation of the embodiments in the datapath nodes 16. In this example, an MPLS label field 88 may be utilized to store the path ID to associate packets of a flow with a particular service chain. A header 90 is substantially similar to, or identical to, a virtual local area network (VLAN) header. In this example, a VLAN ID (VID) field 92 may be utilized to store the path ID to associate packets of a flow with a particular service chain. While several examples of header formats have been provided herein, the embodiments are not limited to any particular header format. [0072] Figure 10 illustrates an example format 94 of a transient flow table entry, according to another embodiment. In this embodiment, the format 94 includes a match criteria field 96 which contains the flow identification information associated with the respective packet. As discussed above, the flow

identification information can comprise any suitable information, including, by way of non-limiting example, the incoming port number of the packet, the source IP address of the originator of the packet, the destination IP address, a logical source port, a logical destination port, and a protocol type, each of which may be extracted from the packet. A flow ID field 98 can be utilized to store a flow ID of the packet. An action field 100 can include the "PUSH" action, which directs the datapath node 16 to add a header containing the appropriate path ID to the packet upon return from a service function node 26. A timeout field 102 can be used to specify a timeout value for the transient flow table entry.

[0073] While the datapath node 16 may be implemented in any type of hardware or any combination of hardware and software, Figure 1 1 is a block diagram of the datapath node 16, according to one embodiment. The datapath node 16 includes, for example, a transceiver 140 and a processor device 142. The transceiver 140 generally includes components configured to facilitate sending and receiving data to and from other nodes, such as other datapath nodes 16 and/or host devices 22. Of course, the detailed operation for the transceiver 140 and the processor device 142 will vary depending on both the particular implementation and the standard or standards supported by the datapath node 16. Those skilled in the art will appreciate that the block diagram of the datapath node 16 necessarily omits numerous features that are not necessary to a complete understanding of this disclosure. Although all of the details of the processor device 142 are not illustrated, the processor device 142 comprises one or several general-purpose or special-purpose processors or other microcontrollers programmed with suitable software programming instructions and/or firmware to carry out some or all of the functionality of the datapath node 16 described herein. In addition, or alternatively, the processor device 142 comprises various digital hardware blocks (i.e., one or more Application Specific Integrated Circuits (ASICs), one or more off-the-shelf digital or analog hardware components, or a combination thereof) configured to carry out some or all of the functionality of the datapath node 16 described herein.

[0074] The datapath node 16 may also include one or more storage media 144 and a memory 146 for storing data necessary and/or suitable for

implementing the functionality described herein, as well as for storing complex programming instructions which, when executed on the processor device 142, may implement all or part of the functionality described herein. One embodiment of the disclosure may be implemented as a computer program product that is stored on a computer-readable storage medium, the computer program product including complex programming instructions that are configured to cause the processor device 142 to carry out the steps described herein. In one

embodiment, a carrier containing the computer program is provided, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, or the computer readable storage medium (i.e., a non-transitory computer readable medium).

[0075] Figure 12 is a functional block diagram of a datapath node 16 that is configured to route a packet of a flow to a network service function, according to one embodiment. While the functionality of the datapath node 16 discussed herein may be implemented in any number of modules, dependent on desired design criteria, in one embodiment, the datapath node 16 includes a packet receiving module 148 that is configured to receive a packet that contains flow identification information and a header that includes a path ID. A network service function determination module 150 is configured to determine, based on the path ID, that the packet is to be forwarded to a network service function. A flow identification information storage module 152 is configured to store the flow identification information associated with the packet. A packet modification module 154 is configured to modify the packet to remove the header from the packet. A packet forwarding module 156 is configured to forward the packet to the network service function. [0076] Figure 13 is a functional block diagram of a datapath node 16 that is configured to associate a path ID with a packet, according to another

embodiment. While the functionality of the datapath node 16 discussed herein may be implemented in any number of modules, dependent on desired design criteria, in one embodiment, the datapath node 16 includes a configuration message processing module 158 that is configured to receive, from a controller node, a configuration message that identifies a path ID and flow identification information that identifies a flow. A packet receiving module 160 is configured to receive a packet from a host node. A flow determination module 162 is configured to determine that the packet is in the flow. A packet modification module 164 is configured to modify the packet to include a header that includes a path ID. A packet forwarding module 166 is configured to forward the packet to a downstream datapath node 16.

[0077] The following acronyms are used throughout this disclosure.

• SDN Software-Defined Networking

• ID Identifier

• IP Internet Protocol

• MPLS Multiprotocol Label Switching

• VLAN Virtual Local Area Network

• VID VLAN Identifier

• MAC Media Access Control

• TCP/IP Transmission Control Protocol/Internet Protocol

• ASIC Application Specific Integrated Circuits

[0078] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered within the scope of the concepts disclosed herein and the claims that follow.

Claims

CLAIMS What is claimed is:

1. A method for routing a packet of a flow (28) to a network service function (26), comprising:

receiving, by a datapath node (16) via a network (12), a packet that includes flow identification information and a header (84, 86, 90) comprising a path identifier (ID);

determining, based on the path ID, that the packet is to be forwarded to a network service function (26);

storing the flow identification information;

modifying the packet to remove the header (84, 86, 90) from the packet; and

forwarding the packet to the network service function (26).

2. The method of claim 1 , further comprising:

receiving, by the datapath node (16) from the network service function (26), the packet;

modifying the packet to include the header (84, 86, 90); and

forwarding the packet over the network (12).

3. The method of claim 1 , wherein storing the flow identification information comprises:

generating a transient flow table entry (60) that includes the flow identification information; and

storing the transient flow table entry (60) in a transient flow table (50-3).

4. The method of claim 3, wherein generating the transient flow table entry (60) that includes the flow identification information further comprises:

generating the transient flow table entry (60) to include:

the header (84, 86, 90); and a timeout value (63) that identifies a timeout period of time.

5. The method of claim 4, further comprising:

receiving, from the network service function (26), the packet;

based on the flow identification information contained in the packet, accessing the transient flow table entry (60);

modifying the packet to include the header (84, 86, 90); and

forwarding the packet over the network (12).

6. The method of claim 4, further comprising:

determining that the timeout period of time has expired; and

removing the transient flow table entry (60) from the transient flow table

(50-3).

7. The method of claim 4, further comprising:

receiving a second packet that includes the flow identification information and the header (84, 86, 90) comprising the path ID;

determining, based on the path ID, that the second packet is to be forwarded to the network service function (26);

accessing the transient flow table entry (60) from the transient flow table

(50-3) based on the flow identification information;

extending the timeout value (63) that identifies the timeout period of time; modifying the second packet to remove the header (84, 86, 90) from the second packet; and

forwarding the second packet to the network service function (26).

8. The method of claim 1 , wherein determining that the packet is to be forwarded to the network service function (26) comprises:

accessing a flow table entry (56) in a flow table (50-4) based on the flow identification information; and determining that the flow table entry (56) includes an add transient flow action.

9. The method of claim 1 , wherein the header (84, 86, 90) has a format substantially similar to a multiprotocol label switching (MPLS) header (86) or a virtual local area network (VLAN) header (90).

10. The method of claim 1 , wherein the flow identification information comprises one or more of a source internet protocol (IP) address, a destination IP address, a source port ID, a destination port ID, and a protocol ID.

1 1 . The method of claim 1 , wherein forwarding the packet to the network service function (26) comprises transmitting the packet via a port (20) associated with the network service function (26).

12. The method of claim 1 , wherein the datapath node (16) comprises a first flow table (50-1 ), a second flow table (50-4), and a transient flow table (50-3), and wherein determining that the packet is to be forwarded to the network service function (26) comprises:

accessing the first flow table (50-1 );

based on an input port (20) associated with the packet, accessing a first flow table entry (52) in the first flow table (50-1 ) that corresponds to the input port (20);

based on the first flow table entry (52), accessing the second flow table (50-4);

based on the path ID of the packet, accessing a second flow table entry (56) in the second flow table (50-4); and

based on the second flow table entry (56):

storing the flow identification information in the transient flow table (50-3); modifying the packet to remove the header (84, 86, 90) from the packet; and

forwarding the packet to the network service function (26).

13. A method for associating a path identifier (ID) with a packet, comprising: receiving, by a datapath node (16) from a controller node

(14), a configuration message that identifies a path ID and flow identification information that identifies a flow (28);

receiving, by the datapath node (16) via a network (12), a packet from a host node (22);

determining that the packet is in the flow (28);

based on determining that the packet is in the flow (28), modifying the packet to include a header (84, 86, 90) that includes the path ID; and

forwarding the packet to a downstream datapath node (16).

A datapath node (16), comprising:

a transceiver (140) configured to communicate with a network (12); and a processor device (142) coupled to the transceiver (140) and configured to:

receive, via the network (12), a packet that includes flow identification information and a header (84, 86, 90) comprising a path ID; determine, based on the path ID, that the packet is to be forwarded to a network service function (26);

store the flow identification information;

modify the packet to remove the header (84, 86, 90) from the packet; and

forward the packet to the network service function (26).

15. The datapath node (16) of claim 14, wherein the processor device (142) is further configured to:

receive, from the network service function (26), the packet; modify the packet to include the header (84, 86, 90); and forward the packet over the network (12).

16. The datapath node (16) of claim 14, wherein to store the flow identification information the processor device (142) is further configured to:

generate a transient flow table entry (60) that includes the flow

identification information; and

store the transient flow table entry (60) in a transient flow table (50-3).

17. The datapath node (16) of claim 16, wherein to generate the transient flow table entry (60) that includes the flow identification information the processor device (142) is further configured to:

generate the transient flow table entry (60) to include:

the header (84, 86, 90); and

a timeout value (63) that identifies a timeout period of time.

18. The datapath node (16) of claim 17, wherein the processor device (142) i further configured to:

receive, from the network service function (26), the packet;

based on the flow identification information contained in the packet, access the transient flow table entry (60);

modify the packet to include the header (84, 86, 90); and

forward the packet over the network (12).

19. The datapath node (16) of claim 17, wherein the processor device (142) is further configured to:

receive a second packet that includes the flow identification information and the header (84, 86, 90) comprising the path ID;

determine, based on the path ID, that the second packet is to be forwarded to the network service function (26); access the transient flow table entry (60) from the transient flow table (50- 3) based on the flow identification information;

extend the timeout value (63) that identifies the timeout period of time; modify the second packet to remove the header (84, 86, 90) from the second packet; and

forward the second packet to the network service function (26).

20. A computer program product stored on a non-transitory computer- readable storage medium and including instructions configured to cause a processor device (142) to carry out the steps of:

receiving, via a network (12), a packet that includes flow identification information and a header (84, 86, 90) comprising a path ID;

determining, based on the path ID, that the packet is to be forwarded to a network service function (26) that is configured to return the packet;

storing the flow identification information;

modifying the packet to remove the header (84, 86, 90) from the packet; and

forwarding the packet to the network service function (26).

A datapath node (16), comprising:

a transceiver (140) configured to communicate with a network (12); and a processor device (142) coupled to the transceiver (140) and configured receive, from a controller node (14), a configuration message that identifies a path ID and flow identification information that identifies a flow (28);

receive, via a network (12), a packet from a host node (22);

determine that the packet is in the flow (28);

based on determining that the packet is in the flow (28), modify the packet to include a header (84, 86, 90) that includes the path ID; and forward the packet to a downstream datapath node (16).