Network-based Service Function Chaining

Abstract

Network switch (400, 400A, 400B) with: a network flow interface (422) for the network switch (400, 400A, 400B), wherein the network flow interface (422) is configured to receive a network flow containing a packet (102, 660); a memory (440) configured to store a network service chain definition (442, 444, 446) that defines a sequence of service functions for packet processing, wherein the network service chain definition (442, 444, 446) includes a service function specification symbol of a service function that is maintained on a server resource separate from the network switch (400, 400A, 400B); and a service chain processing circuit (402) that is connected to the network flow interface (422) and the memory (440), wherein the service chain processing circuit (402) is configured to: Determine that the network service chain definition (442, 444, 446) applies to the network flow; Determine that packet (102, 660) should be processed next by the service function; and Updating a Service Function Index (SFI) pointing to the next service function to be executed on the received packet in order to trace the packet's path (102, 660) through the network service chain definition (442, 444, 446); Forwarding the packet (102, 660) from the network switch (400, 400A, 400B) to the service function on the server resource; where The service chain processing circuit (402) is further configured to: Obtain a flow classification for the packet (102, 660); and map the flow classification to the network service chain definition (442, 444, 446) to determine that the network service chain definition (442, 444, 446) applies to the network flow.

Description

[0001] The present disclosure relates to network function virtualization.

[0002] Processing power, storage capacity, available storage space, and other resources available to processing systems have increased exponentially. Computing resources have evolved to the point where a single physical server can host many virtual machines and virtualized functions. Each virtual machine typically provides virtualized processors, data storage, memory, network connectivity, and other resources. Simultaneously, high-speed data networks have emerged and matured, forming part of the backbone of what has become essential global data connectivity, including connectivity to virtual machine hosts. Improvements in virtualization drive the further development and use of virtualization functionality.

[0003] Document WO 2015 / 057404 A1 shows a network switch with a network flow interface. The network flow interface is configured to receive a network flow containing a packet. Furthermore, a memory is provided, and a service chain processing circuit is connected to the network flow interface and the memory. The service chain processing circuit is configured to determine which service function should process the packet next.

[0004] Publication US 2014 / 0307744 A1 discloses a packet transmission in a network with service functions, whereby the forwarding of data traffic is based on a corresponding service chain policy.

[0005] The invention aims to provide a novel method and a novel network switch, in particular to determine in an improved manner that a service chain definition applies to a network flow containing a packet.

[0006] The invention achieves this and other objectives through the subject matter of independent claims 1 and 9.

[0007] Advantageous embodiments of the invention are specified in the dependent claims. Advantageous:

[0008] Does the flow classification include an application identifier, a participant identifier, or both? Advantageous:

[0009] The network service chain definition specifies a sequential order for executing the service function in the network service chain definition; and the service chain processing circuit is further configured to: Reading a packet header of the package to determine a current index value; and Adjusting the current index value to the network service chain definition to determine which packet should be processed next by the service function. Advantageous:

[0010] The service chain processing circuit is further configured to update a service function index to condition the forwarding of the packet to the service function for processing. Advantageous:

[0011] The service chain processing circuit is further configured to receive the packet from the server resource after processing by the service function; and to determine a subsequent target in the network service chain definition based on the service function index. Advantageous:

[0012] The service chain processing circuit is further configured to: Re-updating the service function index for the packet to track the packet's progress through the network service chain definition; and forwarding the packet from the network switch to the next destination. Advantageous:

[0013] The next target is a different service function that is hosted on a different server resource. Advantageous:

[0014] The other server resource is connected via a separate network switch.

[0015] According to one aspect, a procedure includes: in a network switch that connects host servers, on which a first service function and a second service function are maintained: Define, in a memory, a network service chain definition that specifies a sequence of service functions, with: the first official function; and the second service function; which includes the network service chain definition: a first service function index for the first service function; and a second service function index for the second service function; where the first and second service function indices place the first service function before the second service function; Receiving a packet that is part of a network flow; Receiving classification information for the packet; determining, based on the classification information, that the network service chain applies to the network flow; Determine that the first service function should process the packet next; and Forwarding the package to the first service function. The procedure also advantageously includes:

[0016] Determining a service chain identifier and service function index for the packet after it has been received and it has been determined that the network service chain applies to the network flow. Advantageous:

[0017] The service chain identifier identifies the network service chain definition; and the service function index identifies the first service function. The procedure also advantageously includes:

[0018] Adding a service function chain header to the package, where the service function chain header contains the service function index and the service chain identifier. The procedure also advantageously includes:

[0019] Setting the service function index to point to the second service function before forwarding the packet to the first service function. The procedure also advantageously includes:

[0020] Mapping the service chain identifier and service function index to a network address for the first service function. The procedure also advantageously includes:

[0021] where the network address is a virtual switch address, a service function network address.

[0022] The procedure also advantageously includes: Before forwarding, add a data center routing header to the packet, where the data center routing header has: a virtual switch address of a virtual switch that serves as the host server for the first service function; and A service function network address for the first service function on the host server.

[0023] According to one aspect, a network switch has: a packet interface configured to receive packets into the network switch and to communicate packets from the network switch; a storage device configured to store: Network service chain definitions that include: a first network service chain definition that specifies a first sequence of service functions that constitute a first packet processing chain; and a first service chain identifier for the first network service chain definition; and a service chain diagram table which shows: a classification mapping from packet classification to the network service chain definitions in the memory; a service chain processor that is connected to the packet interface, wherein the service chain processor is configured to: Obtaining classification information for the packages; Determine, from the classification information and the service chain mapping table, that the first network service chain should handle the packets; Determine the next service function to be executed on the packages from the first sequence of service functions; Tracking the path of packets through the first network service chain by updating a service function header of the packets; Adding a routing header to the packets, where the routing header has: a virtual switch address of a virtual switch that is connected to a host server for the next service function; and a service function network address for the next service function on the host server; and

[0024] Forwarding the packets from the network switch to the next service function on the host server.

[0025] Advantageous: The service function header shows: the first service chain identifier; and a service function index in the first network service chain.

[0026] Advantageous: Is the network switch configured for this? to receive the packets back after processing by the next service function at the network switch; and wherein: the service chain processor is configured for this: to trace the process by changing the service function index in the first network service chain to point to a subsequent service function that follows the next service function for the packets; and to forward the packets received after processing by the next service function to the following service function in the first network service chain. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 shows an example of a network that has virtual machine hosts connected by network devices. Fig. Figure 2 shows a virtual machine host configured to run virtual machines and virtual functions. Fig. Figure 3 shows an example network for Service Function Chaining. Fig. Figure 4 shows an example of a top-of-rack switch. Fig. Figure 5 shows an overlay tunnel topology for network-based service function chaining. Fig. Figure 6 shows the routing in a service function chain in a rack. Fig. Figure 7 shows the routing in a service function chain that extends across racks via top-of-rack switches. Fig. Figure 8 shows an example Service Function Chain. Fig. Figure 9 shows another example of routing in a service function chain that extends across racks through top-of-rack switches. Fig. Figure 10 shows another example of routing in a service function chain that extends across racks through top-of-rack switches. Fig.Figure 11 shows another example of routing in a service function chain in a rack. Fig. Figure 12 shows an example of logic that can be implemented by a network node to perform network-based service function chaining. DETAILED DESCRIPTION Introduction

[0027] The Fig. 1 and Fig. Section 2 provides a context for further discussion of network-based Service Function Chaining, beginning with Fig. Section 3 is described in more detail below. Some of the SFC abbreviations used below are summarized in Table 1: Table 1 abbreviation Meaning SFC service function chaining SC service function chain SCID service chain identifier SF service function SFI service function index SCC service chain classifier SFF service function forwarder [Service function forwarder] VS virtual switch VM virtual machine STEP service tunnel endpoint XTEP data center endpoint [Data center endpoint] Goal top of rack

[0028] Fig.Figure 1 shows an example network 100. In network 100, network devices route packets (e.g., packet 102) from sources (e.g., source 104) to destinations (e.g., destination 106) across any number and any type of network (e.g., the Ethernet / TCP / IP network 108). Network devices can take many different forms and can exist in any number. Network 108, for example, can span multiple routers and switches. Examples of network devices include switches, bridges, routers, and hubs. However, other types of network devices can also be present in network 100.

[0029] Network 100 is not limited to a specific implementation or geographic area. To give just a few examples, Network 100 can represent a private, company-wide intranet, a remote distribution network for cable or satellite television, internet access, and audio and video streaming, or a global network (e.g., the internet) of smaller, interconnected networks. In this respect, Data Center 110 can represent a highly concentrated server installation 150 with associated network switch and router connectivity 152. Data Center 110 can support extremely high-volume e-commerce, search engines, cloud storage and cloud services, streaming video or audio services, or any other type of functionality.

[0030] In the example of Fig.The network comprises 100 operators and providers of cable or satellite television services, telephone services, and internet services. In this respect, it shows Fig. For example, Network 100 can have any number of Cable Modem Termination Systems (CMTSs) 112. The CMTSs 112 can provide services to any number of gateways, e.g., gateways 114, 116, 118. The gateways can represent cable modems, combined cable modems and wireless routers, or other types of entry point systems into any wide variety of locations 121, for example, homes, offices, schools, and government buildings. Network 100 can have other types of end systems and gateways. For example, Network 100 can have Digital Subscriber Line (DSL) end systems and DSL modems that serve as entry points into homes, offices, or other locations.

[0031] At any given location, the gateway can connect to any number and any type of node. For example, Fig. The nodes include digital receivers (set-top boxes; STBs), for example, STBs 120, 122, and 124. Other examples of nodes include network-connected smart TVs 126, audio-video receivers 128, digital video recorders (DVRs) 130, streaming media players 132, gaming systems 134, computer systems 136, and players for physical media (e.g., Blu-ray). The nodes can represent any type of customer premises equipment (CPE).

[0032] Fig.Figure 2 shows a virtual machine host 200 (“Host”) configured to run virtual switches, virtual machines, and virtual functions. Any of the devices in the network 100 can be Hosts, including nodes, gateways, CMTSs, switches, servers, sources, and destinations. The Hosts provide an environment in which any selected functionality can run, be reachable through the network 100, and form all or part of a chain of functionalities to perform any defined processing or content delivery task. The functionality can be virtual in the sense that, for example, the virtual functions, as software running on the Hosts, implement functions that were previously performed using dedicated hardware.

[0033] In Fig.2 The host 200 has one or more communication interfaces 202, system circuitry 204, input / output interfaces 206, and a display 208 on which the host 200 generates a user interface 209. The communication interfaces 202 can have transmitters and receivers (“transceivers”) 238 and any antennas 240 used by the transceivers 238. The transceivers 238 can provide physical layer interfaces for any of a wide range of communication protocols 242, for example, any type of Ethernet, Data Over Cable Service Interface Specification (DOCSIS), Digital Subscriber Line (DSL), Multimedia over Coax Alliance (MoCA), or another protocol. If the communication interfaces 202 support mobile connectivity, the host can also have a SIM card interface 210 and a SIM card 212.The Host 200 also features storage devices such as hard disk drives (HDDs) 214 and solid state disk drives (SSDDs) 216, 218.

[0034] The user interface 209 and the input / output interfaces 206 can include a graphical user interface (GUI), a touch-sensitive display, voice or face recognition inputs, buttons, switches, speakers, and other user interface elements. Additional examples of input / output interfaces 206 include microphones, video and still camera inputs, headphone and microphone input / output jacks, Universal Serial Bus (USB) connectors, memory card slots, and other types of inputs. Input / output interfaces 206 can also include magnetic or optical media interfaces (e.g., a CD-ROM or DVD drive), serial and parallel bus interfaces, and keyboard and mouse interfaces.

[0035] The System Circuit 204 can include any combination of hardware, software, firmware, or other logic. For example, the System Circuit 204 can be implemented using one or more systems on a chip (SoCs), application-specific integrated circuits (ASICs), discrete analog and digital circuits, and other circuitry. The System Circuit 204 is part of the implementation of any desired functionality in the Host 200. In this respect, the System Circuit 204 can include circuitry that facilitates, to name just a few examples, the running of virtual machines, switching and functions, the routing of packets between virtual machines and the network, and the switching of packets between virtual machines.

[0036] To give just one example, the system circuit 204 can have one or more processors 220 and memory 222. The memory 222 and the storage devices 214, 216, for example, store control instructions 224 and an operating system 226. The processor 220 executes the control instructions 243 and the operating system 226 to perform any desired functionality for the host 200. The control parameters 228 provide and specify configuration and operating options for the control instructions 224, the operating system 226, and other functionality of the host 200.

[0037] In some implementations, the control commands 224 refer to a hypervisor 230. The hypervisor 230 provides a monitoring software environment that runs one or more virtual machines (VMs), virtual switches (VSs) 232, virtual firewalls, virtual operating systems, virtual network interface cards (NICs), or any other desired virtualization components. In other implementations, the host 200 is a virtualization host directly on the hardware. That is, the host 200 does not need to run a separate operating system 226 on which the hypervisor 230 runs. Instead, the hypervisor 230 can communicate directly with and control the physical hardware resources in the host 220 without monitoring or intervention by a separate operating system.

[0038] The host 200 can run any number of VMs 234. Each VM can run any number or type of virtual functions (VFs) 236. The VFs can be software implementations of any desired functionality, ranging, for example, from highly specialized network functions to general-purpose processing functions.

[0039] To name just a few examples of service functions, VFs 236 can implement network firewalls, message spam filters, and network address translators. As another example of processing functions, VFs 236 can implement audio and video encoders and transcoders, digital rights management (DRM) processing, database lookups, e-commerce transaction processing (e.g., invoicing and payment), web hosting, content management, contextual advertising, and security processing such as High-bandwidth Digital Content Protection (HDCP) and Digital Transmission Content Protection (DTCP-IP). Additional examples of VFs 236 include audio, video, and image compression and decompression, such as H.264, MPG and MP4 compression and decompression, audio and video pre- and post-processing, server functionality such as video-on-demand servers, DVR servers, Over The Top (OTT) servers, storage, generation and application of secure keys, and display of 2D and 3D graphics. Network-based service chaining

[0040] Network-based Service Function Chaining (SFC) requires a service-aware network. Within the network itself, network devices such as Top of Rack (ToR) switches are aware of which service functions (SFs) exist, e.g., the VFs 236, which hosts execute the service functions, the connectivity paths between hosts and the network devices, and how to efficiently connect the service functions to form an end-to-end service chain (SC) of processing. Service functions can be virtual functions (VFs) running on a VM, non-virtualized functions of any type running on a physical server outside of a virtualization environment, or can be otherwise hosted on devices connected to the network.

[0041] The network devices (e.g., the ToR switches) monitor, generate, and store definitions of Service Packages (SCs) that define a sequence of service functions for any desired packet processing. The network devices determine the next hop for packets along any given SC and track their path through the SC. As a result, the Hosts 200, the VFs 236, and the Virtual Switches 234 do not need to store information about the forwarding state of the service chain. Instead, the Hosts 200 process the packets locally according to the hosted Service Functions (SFs) associated with any given SC and send these packets back to the network devices after processing. The network devices decide on the next SF and its location. Then, the network devices forward the packets to the appropriate destination for further processing by the SC.

[0042] The network's SFC capabilities enable it to create logical connections under and between one or more service functions in a specific order to provide a sequence of service functions that is independent of the underlying physical network topology. The architecture can implement several functional components as part of SFC, including an SFC Classifier (SCC) and a Service Function Forwarder (SFF). The SCC can map subscriber or customer packet flows or subflows to a specific service function, for example, in response to a defined policy for the customer, traffic type, quality of service level, time and date, source, or other mapping criteria.

[0043] The SFF forwards packets from one SF to the next in the context of the SC designated for packet flow. It is noted that instead of implementing the SCC and SFF functions in a server node (or other endpoint device), the architecture described below can implement these functions in the network devices themselves. In other implementations, the SFC classification information is determined by nodes that are distinct from the network devices performing SFC, and these nodes provide the classification information to the network devices performing SFC.

[0044] In other words, the architecture can implement SFC using the hardware processing capabilities of a network switch. As a specific example, the architecture can implement SFC in a Top-of-Range (ToR) switch. In some cases, the network switch is part of a data center and can share SFC responsibility with other network switches in the data center or elsewhere. That is, SFC can be distributed among multiple network devices, each responsible for a portion of the SFC.

[0045] Fig.Figure 3 shows an example network 300 for SFC. The SFC is network-based and uses SFC-enabled ToR switches 302, 304, and 306. The ToR switches can have scalable SFC processors that perform the SFC processing described below. In this implementation, only the ToR switches store SFC reachability tables and other state information for implementing SFC. That is, servers 308, 310, and 312 do not need to store reachability tables or other state information to support SFC.

[0046] A technical advantage is therefore the reduced number of touchpoints for provisioning, defining, and managing service centers. The architecture provides a better model for enforcing service level agreements (SLAs), with an improved operations and management (OAM) model for end-to-end visibility. Furthermore, the architecture delivers higher performance, allowing for more effective and efficient use of device nodes. The architecture is also suitable for use in facilities of any size, from small to very large.

[0047] Fig. Figure 4 shows two exemplary implementations of a network device, a top-of-rack Switch 400. Each of the components of the in Fig.The Switch 400 shown in the diagram can be implemented logically, physically, or as a combination of logical and physical elements. Switch 400A shows a multi-device implementation, while Switch 400B shows a single-device implementation. Switch 400 features a Service Chain Processor (SCP) 402 and an Underlay Switch 404. The Underlay Switch 404 can implement many different functions. To give two examples, the Underlay Switch 404 can implement a Data Center Tunnel Endpoint (XTEP) 406 and can include a Virtual Switch (VS) 408. As a specific example, Trident Series Ethernet Switch ASICs can implement the Underlay Switch 404. As another example, a Caladan 3 Network Processing Unit (NPU) can implement the SCP 402.When the SCP 402 and the Underlay Switch 404 are integrated into a single device, Qumran and Jericho Switch ASICs can implement the combined functionality. These NPUs and ASICs, along with other implementation options, vary in scalability and performance and are available from Broadcom in Irvine, CA.

[0048] As noted above, the in Fig.The four functional blocks shown can be implemented as separate devices or can exist in various combinations within one or more devices. For example, in some implementations, SCP-402 and Underlay Switch 404 are integrated into a single device, while in others they are implemented in separate devices. When integrated, the functional blocks can be distributed to form a flexible packet processing pipeline. An integrated implementation can be found, for example, in Qumran or Jericho switching devices. In other words, SCP-402 can be added to a switch architecture in the form of a separate NPU (as in the 400A implementation in...). Fig.4 is shown), or SCP 402, Underlay Switch 404 and any other functional blocks can be integrated into a single device, for example as part of a processing pipeline (such as by implementing 400B in Fig. 4 is shown).

[0049] In this example, the SCP 402 in the switch 400 implements an SCC 410. The SCC 410 can map incoming packet flows to a specific SC on any basis, such as any combination of customer, source application, destination application, QoS, time / date, or any other parameter. In some implementations, the SCC 410 performs the classification by mapping the {Application ID, Subscriber ID / Class} of received packets to the {Service Chain ID, Service Function Index}. This mapping can be done by traversing the service chain mapping table (SCMT) 448, which stores a classification map from packet classification to the network service chain definitions in memory 440.

[0050] The SCC 410 can also add a classification header to each packet in the packet flow as shown in the diagram, containing, for example, {Service Chain ID, Service Function Index}. The service chain ID (SCID) identifies a specific SC definition in memory 440, and the service function index (SFI) points to the next SF to be executed for the received packets. The initial packets received in a packet flow can be marked with an SFI pointing to the first SF to be executed in the SC to which the SCC 410 has mapped the packet flow. Memory 440 can store any number of SC definitions. Fig. 4 are three of the definitions referred to as SC definition 1 442, SC definition 444 and SC definition 'n' 446, each with unique SCIDs.

[0051] In the example of Fig.In section 4, SCP 402 also implements SFF 412. SFF 412 can forward packets from one Service Function (SF) to the next in a given SC, as described in more detail below. In one implementation, SFF 412 maps the Service Chain ID and Service Function Index (SFI) present in the packet classification header to the VS network address and SF network address. The SFF also decrements the SFI and updates the SFC header on the packets, which stores the SFI, to track and record the packets' path through the SFs in the mapped SC.

[0052] The SCP 402 can also implement a service tunnel end point (STEP) 414. STEP 414 can support service overlay networks for SF connectivity. STEP 414 can also add, delete, and update service overlay tunnel headers on packets subject to a service center (SC). These service overlay tunnel headers connect, for example, one SCP to another SCP or to a virtual service center (VS).

[0053] The SCP 402 can also implement a data center tunnel end point (XTEP) 416. The XTEP 416 supports a data center overlay network for VS connectivity. Specifically, the XTEP 416 can add, remove, and update service overlay tunnel headers on packets subject to a service center. The service overlay tunnel header can connect an SCP to a service server in a host that is, for example, directly connected to the top-of-range switch currently processing the packets.

[0054] It is noted that the underlay switch 404 can implement Layer 2 and Layer 3 forwarding using the outer headers of the packets. The packets can originate from any combination of SCP 402 and packet interfaces 418 and 420. Interface 418 can be an uplink interface, for example, to other ToR switches in the same data center or elsewhere. Interface 420 can be a server node interface, for example, to servers in the same rack as switch 400. Any combination of physical and logical interfaces 422 connects SCP 402 and the underlay switch 404.

[0055] Some of the technical advantages of Architecture 100 include the fact that server nodes do not have to incur the overhead of storing an SFC forwarding state. Furthermore, the ToR switches that make up the network architecture (which can include ToR switches in different server racks) can be fully or partially interconnected using data center overlay tunnels such as Virtual Extensible Local Area Network (VXLAN), Network Virtualization using Generic Routing Encapsulation (NVGRE), Generic Network Virtualization Encapsulation (Geneve), and Shortest Path Breaching (SPB). The tunnel endpoint can be an SCP in each ToR. Additionally, in some implementations, tunnel provisioning is static. That is, tunnel provisioning can be configured once and then selectively modified, for example, if the physical topology changes.

[0056] Further technical advantages include the ability to logically connect each ToR (Total of Reserves) in a rack to every server node in that rack using at least one data center overlay tunnel, such as VXLAN, NVGRE, Geneve, or SPB tunnels. The tunnel endpoint in the ToR is a Service Control Point (SCP), and the endpoint in the server can be a virtual switch (VS). If there are multiple VSs per server, each VS can be connected to the SCP in the ToR via a separate data center overlay tunnel. Furthermore, tunnel provisioning can be static, meaning it can be configured once and then selectively modified, for example, if the physical topology changes.

[0057] Additional technical advantages include the ability to logically connect each ToR in a rack to each VM that is a container for a SF in that rack, using a service overlay tunnel. The service tunnel endpoint in the ToR is the SCP, and in the server node, it is the VM. Service tunnel endpoint processing can be implemented for each VM in the server node in the virtual switch, in the VM's guest operating system (OS), or in the network function itself.

[0058] Fig.Figure 5 shows an example of an overlay tunnel topology 500 for network-based SFC. Each ToR SCP 502, 504, and 506 can store a reachability or forwarding state for SFs directly connected to it, for example, in the local rack 508, 510, and 512. If the next SF in the service chain is in a different rack, the source ToR SCP forwards the packet to the destination ToR SCP for that other rack, for example, by sending the packets to this destination ToR SCP in the other rack. The destination ToR SCP then forwards the packet to the destination SF, for example, by sending the packets to a VS connected to VMs running on a host connected to this destination ToR. The Underlay Core Switch (UCS) 514 represents the underlay switches in every ToR switch and can connect the ToR SCPs 502, 504 and 506 through any type of physical or logical network topology.

[0059] Fig.Figure 6 shows the forwarding 600 in an exemplary SC 650 in a rack of servers 652, 654 and 656, which are connected and served by a network switch 658. Fig. Figure 6 shows the beginning of service chain 650 (602) and the service overlay tunnel starting point. Fig. Figure 6 also shows the endpoint 604 of service chain 650 and the service overlay tunnel endpoint. Service chain 650 begins and ends in the same server rack, with the VFs hosted on servers 652, 653, and 656, which are connected to network switch 658.

[0060] It is noted that in this example, neither the SFs nor the VSs store any SFC forwarding state information. The VSs send packets belonging to the SC back to the local network switch 658 as determined by any identifying information, whether in the packet itself or according to VLAN, tunnel, or other network identifiers associated with the packet. In one implementation, the VSs return the packets by swapping the source (SRC) and destination (DST) both in the data center and in the service overlay tunnel headers on the packets. The swap is performed to return the packets to the ToR for further processing because no state is stored in the VS. In this respect, the VSs can be pre-configured with flow tables that specify the addresses (e.g., the ToR switch addresses) for which the VS will perform the swap.

[0061] Fig.Figure 6 also shows an example packet 660. This packet contains payload 662 and SFC headers. The SFC headers might include, for example, a data center overlay tunnel header 664, which routes packets to a specific VS connected to the VM hosting the next SF. The SFC headers might also include a service overlay tunnel header 666, which specifies the network address of the SF connected to the VS. The SFF 412 can create, add, update, and remove SFC headers as packets initially arrive at the ToR switch, are sequentially sent to specific SFs and received back from the SF after processing, and as packets complete their processing by the SC.

[0062] Fig. Figure 7 shows an example of network-based SFC 700, with one SC spanning multiple network devices 702, 704 and 706 and across racks 708, 710 and 712. Fig.Figure 7 shows the service chain start point 714 in the network device 702. The service chain start point 714 can be the service overlay tunnel start point, for example, where the network device 702 inserts the data center and service overlay tunnel headers into the packets. Fig. 7 also shows the service chain endpoint 716. The service chain endpoint 716 can be the service overlay tunnel endpoint, for example, where the network device 706 removes the data center and service overlay tunnel headers from the packets.

[0063] When packets subject to a service overlay (SC) are forwarded between two network devices, for example, from network device 702 to network device 704, the sending network device 702 does not need to modify the service overlay tunnel identifier in the packet. Instead, the receiving network device can update the service overlay tunnel header before sending the packet to its local service overlay.

[0064] It is noted that in this example as well, the SFs and VSs do not store SFC forwarding state information. The VSs send packets belonging to the SC back to their local network device as determined by any identification information, whether contained within the packet or according to VLAN, tunnel, or other network identifiers associated with the packet. For example, the VSs can return packets by swapping SRC and DST in both the data center and service overlay tunnel headers.

[0065] Fig.Figure 7 illustrates ToR switch-to-ToR switch traffic for handling SCs distributed across ToR switches. The SCP function updates the data center and service overlay tunnel headers at each ToR switch to route packets along the SC to the next hop. The SCP function only needs to process the portion of the SC at each ToR switch that contains the VSs, VMs, and SFs directly connected to that ToR switch. The SCP function can perform a service chain header lookup at each ToR switch (which might contain, for example, the service function index and service chain ID) to determine if that ToR switch is responsible for any part of the SC. That is, each ToR switch can perform a service function forwarding lookup, for example, for {SCID, SFI}, and update both the data center and service overlay tunnel headers in response.The service overlay tunnel header on packets traveling between ToR switches can simply be placeholder data and is replaced by the next ToR switch, which handles the next part of the SC, with network address data for the SF.

[0066] Fig. Figure 8 shows an example service function chain (SC) 800. An SC can be implemented as a predefined sequence of service functions (SFs). The sequence of SFs can provide a predetermined data plane service for packet flow through the network device(s) that implement the SC. As mentioned above, individual network devices can define, store, and manage SCs. Each SC can have a SCID, a unique identifier within the network that identifies the SC as a specific chain of SFs. The network devices can store a service function index (SFI) as an index for an SF within the specified SC.

[0067] A Service Computing Center (SCC) maps packet flows to a Service Chain Identification Number (SCID) by labeling packets with header information, for example, by mapping the Application ID and Subscriber ID / Class of received packets to the Service Chain ID and Service Function Index. The SCC can be implemented anywhere in the network. Upon entry, the SCC identifies and classifies traffic while mapping it to a specific SC (or no SC). The SCC can perform macro-level analysis, for example, based on any traffic from another network according to the network's IP address, or based on a network segment (e.g.,Port or subnetwork), based on the user or owner of the traffic, or based on the application generating the packets (to name just a few examples, a Voice over IP application, a file transfer application, a Virtual Private Network (VPN) application, an application generating encrypted content, or a video or audio streaming application). When performing mapping, the SCC can conduct Deep Packet Inspection (DPI) to determine a specific SC through which the packets should be processed.

[0068] The SFF forwards packets from one SF to the next within a SC. The SFF can forward packets by mapping {SCID, SFI} to a physical network address, e.g., {VS network address, SF network address} (VS network address, SF network address). The SF at the physical network address performs the next service function specified in the SC. Upon termination of the SC, a service chain termination (SCT) function removes the service chain identifiers / headers from the packets, and the packets return to non-SC routing through the network switches.

[0069] In the example of Fig.In section 8, the SCC determined that an incoming packet flow 802 should be subject to SC 800. Packet flow 802 passes through the SC, which defines four SFs in sequence: SF1, a Deep Packet Inspection; SF2, a Firewall; SF3, a Network Address Translation; and SF4, a Wide Area Network Optimizer. Before each SF, the SFF determines the next SF for the packet by storing the SFI (e.g., by incrementing or decrementing the SFI) to track which SF in the SC should process the packets next.

[0070] Fig.Figure 9 shows another example of routing 900 through a SC 902, which extends through ToR switches across racks 904, 906, and 908. SC 902 has four SFs in sequence: SF1, SF2, SF3, and then SF4. Before entering the SC, a subscriber classifier (SUBC) (Function Node A) identifies packet flows belonging to a subscriber and maps the flows to a specific flow ID. The SCC (Function Node B) maps the flow ID (and optionally additional properties such as the packet source) to an SC and marks the packets with an SFC classification header containing the SCID.

[0071] In other words, when packets arrive, a gateway node (e.g., a gateway router, GWR) can inspect and classify them. Some implementations offer two types of classification: application classification and source-of-flow classification. For application classification, the network node performing the classification examines the packets and determines their contents, such as video, HTTP data, or file transfer data, and generates a corresponding application identifier. For source-of-flow classification, the network node performing the classification can identify a source of the packets. For example, the source IP address can identify the source. The combination of application and source data can be used as a lookup to find a policy stored in the network node performing the classification.The policy can map application and source IDs (or other traffic characteristics) to a SCID. The network node can implement service header encapsulation, which provides the SCID and SFI, for example, in a classification header added to the packet. The SFF in the ToR switch responds to the classification header to route the packets through the SC to SFs by mapping the SCID and SFI to physical network addresses.

[0072] In the example of Fig. The first two SFs are located in hosts in server rack 908. Accordingly, the ToR switch 910 performs the SFF function three times, as shown in Fig.Figure 9 shows how to route the packets through two SFs and then to the next rack, 906, where the next SF is hosted in the SC. In the ToR switch 912, the ToR switch 912 performs SFF functions twice: once to direct the packets to SF 3 and once to direct the packets to the ToR switch 914, where the last SF, SF4, is hosted in server rack 904. The ToR switch 914 performs SFF functionality to direct the packets to SF4 and to return the packets to the network, where the SCT removes the packet headers used for SFC and sends the packets back to the network for general routing. It is noted that in Fig. 9. The Gateway Router (GWR) performs part of the SC processing, including SUBC, SCC and one case of SFF, and SCT.

[0073] Fig. 10 expands on the example of Fig.Figure 9 shows another example of forwarding 1000 through an SC 1002, which extends through ToR switches 1010, 1012, and 1014 across racks 1004, 1006, and 1008. It is noted that in Fig. Ten devices (for example, physical endpoints (PEs)) in the subscriber access network perform the SUBC function. In this example, the PEs can communicate the resulting subscriber IDs in MPLS labels to the following SCC function in the GWR. The SCC maps the subscriber ID to a SC, and the packets are processed by the SC as described above. Fig. 9 as specified, processed.

[0074] Fig.Figure 11 shows another example of forwarding 1100 in a service function chain 1102 in a rack 1104. In this example, the ToR switch 1106 performs the functions of SUBC, SCC, SFF, and SCT. As the ToR switch 1106 forwards packets to the next SF in the SC, it tracks the SFI to determine where to forward packets returning to the ToR switch 1106 from the hosts running the SFs. As the index traverses the SC, toward the end of the SC, the ToR switch 1106 recognizes that the packets have passed through the SC and performs the SCT function to remove the service and data center overlay tunnel headers that were used for the packets to support network-based SFC.

[0075] In the network-based SFC architectures described above, the forwarding state for SFC, and in particular the function that maps the logical address of a service file (SF) to a physical network address, is stored in the network device itself, for example, the top-of-rack (ToR) switch. The forwarding state and the mapping function do not need to be provided or stored in the virtual switch (VS). A key advantage is that the service chain controller only needs to manage the mapping table in the network device, and not in all of the endpoints. In typical scenarios with many servers per ToR switch (for example, 48 to 1) in a rack, this results in a significant reduction in administrative overhead.

[0076] The VS participates in network-based SFC by receiving packets and forwarding them to the SF, which is hosted in a VM. After processing by the SF, the VS sends the packets back to the original network device, for example, the original ToR switch. The VS does not need to store information about the next hop's SF in the SC; instead, it sends the packets back to the network device after processing to determine the next hop.

[0077] As another example of the use case, assume a service center (SC) has three service providers (SFs) in sequence: a DPI, followed by a firewall, and followed by a virtual router. The top-of-resort (ToR) switch has assigned a service ID (SCID) to the SC as part of maintaining the SC. A specific service function is addressed using tuple logic addressing, which in one implementation is the SCID and the SFI (Service Function Index). That is, each SF has an index within the SC. In this example, the index might start with index value 3 for the DPI SF, then index value 2 for the firewall SF, and then index value 1 for the router SF.

[0078] SCP 402, and specifically SFF 412, which is implemented by SCP 402, maps logical addresses, for example, (SCID 50, SFI 3), to a physical network address. In one implementation, the physical network address has two components: an overlay endpoint, which is the address of the VS that appends the SF, and the address of the SF within the VS. After the packets arrive, SFF 412 performs a lookup to map the SCID and SFI to the next SF. SFF 412 generates and adds (or updates) the data center overlay tunnel header on the packets, which routes the packets to the specific VS associated with the VM hosting the next SF. SFF 412 also generates and adds (or updates) the service overlay tunnel header on the packets, which specifies the address of the SF associated with the VM hosting the next SF. which is connected to the VS, is specified.This means that, as a result of the lookup by the SFF 412, the SFF 412 can create, add, modify, or delete the service tunnel header and the data center overlay tunnel.

[0079] The SFC tracks the path of packets through their mapped SCs, for example, by decrementing the SFI for the packets. For instance, upon returning from the DIP SF, the SFC might decrement the SFI from 3 to 2 and update the packet header, which carries the SCID and SFI. The next lookup in this example is for (SCID 50, SFI 2) to find the network address of the next SF (the firewall SF), which is the next SF to process the packets in the SC. The SFC continues in this way until the SFI becomes zero. At that point, the SFC recognizes that the packet has reached the end of the SC, removes the SFC headers, and forwards the packet as it would normally be without SFC processing.

[0080] The SFC processing described above can be implemented in many different ways using many different types of circuitry, from highly specialized packet processors to general-purpose central processing units. In one implementation, SFC processing is implemented by the data plane of the network switch. The data plane can include specialized network processors connected to a multigigabit switch fabric.

[0081] With further reference to Fig.In section 5, network-based SFC processing is supported by an overlay topology. The overlay topology implements packet tunnel connections that link the SCPs in each network device (for example, a ToR switch) and each VS in a server rack. The SCPs can be the tunnel endpoints. The overlay topology implements a spoke-connect architecture. In this topology, each network device is connected via overlay tunnels—for example, tunnels from each ToR switch to every other ToR switch—across a defined location, such as a specific data center.

[0082] Accordingly, each network device has a data center tunnel connection to each directly connected host (and VS) for a service network (SF). A service tunnel is defined within the data center tunnel to connect the service control points (SCPs) to the individual SFs and the virtual machines (VMs) hosting the SFs. The data center tunnels support communication between top-of-rack (ToR) switches, each of which can handle packet routing for every part of an SC that can traverse any number of ToR switches and server racks, for example, along the backbone of a data center, connecting multiple server racks within a data center.

[0083] The data center overlay tunnel and the service overlay tunnel form a two-tier forwarding architecture that connects any network device, such as any network switch, to any service file (SF), whether physical or virtual. In one implementation, the outer layer addresses a specific virtual machine (VS), and the inner layer addresses a specific SF hosted by a node connected to that VS. Addressing is not limited to IP or MAC addresses; any addressing scheme can be used. The overlay topology provides logical and physical connections from any top-of-rack (ToR) switch in a server rack to any VS, virtual machine (VM), or SF.

[0084] Fig.Figure 12 shows Logic 1200, which a network node can implement to perform network-based SFC. Logic 1200 receives packets that are part of a network flow (1202). Each logical or physical network node (for example, SCC 410 in SCP 402) can classify the packets, for example, according to application / content and source / subscriber (1204). Logic 1200 includes defining SCs in memory (1206). The SCs can specify sequences of SFs, for example, by using index values ​​that order different service functions in a specific sequence. A function can be assigned to the classification information, for example, SFF 412, which determines which SC, if any, applies to the classification (1208). The function can mark the packets with the appropriate {SCID, SFI} in a packet header (1210).

[0085] The SFF 412 checks the SFIs to determine if more SFs are available to process the packets in the SC (1212). If not, the SFF 412 removes the data center and service overlay tunnel headers from the packets (1214). The packets are then processed normally by the network device. If there are additional SFs available to process the packet, the SFF 412 updates the SFI (1216) and determines network addresses (for example, based on {SCID, SFI}) to reach the next SF. The SFF 412 creates or modifies the data center and service overlay tunnel headers on the packets as needed to route the packets to the next SF (1218).

[0086] The SFF 412 can then forward the packets to the next SF (1220). For example, the SFF 412 can send the packets through the underlay switch, through the overlay topology to a VS and a VM that are connected to the next SF.

[0087] The VS sends the packets processed by the SF back to the SFF 412, for example by swapping SRC and DST information in the data center and service overlay tunnel headers. The SFF 412 receives the processed packets returned by the SF and the VS (1222) and checks whether any subsequent SFs should process the packets (1212).

[0088] The methods, devices, processing, and logic described above can be implemented in many different ways and in many different combinations of hardware and software. For example, all or part of the implementations can be circuitry incorporating an instruction processor, such as a central processing unit (CPU), a microcontroller or microprocessor, an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a field-programmable gate array (FPGA); or circuitry incorporating discrete logic or other circuit components, including analog circuit components, digital circuit components, or both; or any combination thereof.The circuit can have discrete interconnected hardware components and / or can be combined on a single integrated circuit chip, distributed across many integrated circuit chips, or implemented in a Multiple Chip Module (MCM) of several integrated circuit chips in a common package, to name a few examples.

[0089] The circuit may also contain or access instructions for execution by the circuit. These instructions may be stored in a specific storage medium that is different from a transitory signal, for example, flash memory, random access memory (RAM), read-only memory (ROM), or erasable programmable read-only memory (EPROM); or on a magnetic or optical disk, for example, a compact disc read-only memory (CD-ROM), hard disk drive (HDD), or another magnetic or optical disk; or in or on another machine-readable medium.A product, such as a computer program product, may include a storage medium and instructions stored in or on the medium, and the instructions, when executed by the circuit in a device, may cause the device to implement any of the methods described above or shown in the drawings.

[0090] The implementations can be distributed as a circuit across multiple system components, for example, across multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases, and other data structures can be stored and managed separately, can reside in a single memory or database, can be logically and physically organized in many different ways, and can be implemented in many different ways, including as data structures such as linked lists, hash tables, arrays, records, objects, or implicit storage mechanisms.Programs can be parts (for example, subroutines) of a single program, separate programs, distributed across multiple memories and processors, or implemented in many different ways, for example, in a library, or a shared library (for example, a Dynamic Link Library (DLL)). The DLL can, for example, store instructions that perform each of the processes described above or shown in the diagrams when executed by the circuit.

[0091] Several implementations have been described in detail. However, many other implementations are also possible.

Claims

[1] Network switch (400, 400A, 400B) with: a network flow interface (422) for the network switch (400, 400A, 400B), wherein the network flow interface (422) is configured to receive a network flow containing a packet (102, 660); a memory (440) configured to store a network service chain definition (442, 444, 446) that defines a sequence of service functions for packet processing, wherein the network service chain definition (442, 444, 446) includes a service function specification symbol of a service function that is maintained on a server resource separate from the network switch (400, 400A, 400B); and a service chain processing circuit (402) that is connected to the network flow interface (422) and the memory (440), wherein the service chain processing circuit (402) is configured to: Determine that the network service chain definition (442, 444, 446) applies to the network flow; Determine that packet (102, 660) should be processed next by the service function; and Updating a Service Function Index (SFI) pointing to the next service function to be executed on the received packet in order to trace the packet's path (102, 660) through the network service chain definition (442, 444, 446); Forwarding the packet (102, 660) from the network switch (400, 400A, 400B) to the service function on the server resource; where The service chain processing circuit (402) is further configured to: Obtain a flow classification for the packet (102, 660); and map the flow classification to the network service chain definition (442, 444, 446) to determine that the network service chain definition (442, 444, 446) applies to the network flow. [2] Network switch (400, 400A, 400B) according to claim 1, wherein the service chain processing circuit (402) is configured to label the packet (102, 660) with a network address for the service function. [3] Network switch (400, 400A, 400B) according to any one of the preceding claims, wherein: The flow classification includes an application identifier, a participant identifier, or both. [4] Network switch (400, 400A, 400B) according to any one of the preceding claims, wherein: The network service chain definition (442, 444, 446) specifies a sequential order for the execution of the service function in the network service chain definition (442, 444, 446). [5] Network switch (400, 400A, 400B) according to claim 4, wherein the service chain processing circuit (402) is further configured to: Reading a packet header (664, 666) of packet (102, 660) to determine a current index value (1, 2, 3); and Adjusting the current index value (1, 2, 3) to the network service chain definition (442, 444, 446) to determine that the packet (102, 660) should be processed next by the service function. [6] Network switch (400, 400A, 400B) according to claim 5, wherein: The service chain processing circuit (402) is further configured to update the Service Function Index (SFI) to require the forwarding of packet (102, 660) to the service function for processing. [7] Network switch (400, 400A, 400B) according to claim 6, wherein: The service chain processing circuit (402) is further configured to receive the packet (102, 660) from the server resource after processing by the service function; and to determine a subsequent target in the network service chain definition (442, 444, 446) based on the Service Function Index (SFI). [8] Network switch (400, 400A, 400B) according to claim 7, wherein the service chain processing circuit (402) is further configured to: Forwarding packet (102) from the network switch (400, 400A, 400B) to the next destination; where The subsequent target is a different service function that is hosted on a different server resource. [9] Method which includes the following steps: Receiving a network flow containing a packet (102); Storing a network service chain definition (442, 444, 446) that defines a sequence of service functions for packet processing, wherein the network service chain definition (442, 444, 446) includes a service function specification symbol of a service function that is maintained on a server resource separately from a network switch (400, 400A, 400B); Determine that the network service chain definition (442, 444, 446) applies to the network flow; Determine that packet (102) should be processed next by the service function; Updating a Service Function Index (SFI) pointing to the next service function to be executed on the received packet in order to trace the packet's path (102) through the network service chain definition (442, 444, 446); Forwarding the packet (102, 660) from the network switch (400, 400A, 400B) to the service function on the server resource; the procedure further includes: Obtain a river classification for the package (102, 660); and Mapping the flow classification to the network service chain definition (442, 444, 446) to determine that the network service chain definition (442, 444, 446) applies to the network flow.

Images