Group-based policy coding for network virtualization coverage

Abstract

Embodiments of the present disclosure provide group-based policy coding for network virtualization coverage. A first network device of a first data center may encode a source tenant system interface (TSI) group identifier into a tag protocol identifier and a group-based policy identifier, and may encode the tag protocol identifier and the group-based policy identifier into a virtual extensible local area network (VXLAN) packet having a source TSI group identifier, wherein the source TSI group identifier is included in a header of the VXLAN packet. The first network device may provide the VXLAN packet with the source TSI group identifier to a second network device of the second data center via an Ethernet virtual private network (EVPN) multi-protocol label switching (MPLS) network.

Description

[0001] Cross - Reference to Related Applications

[0002] This patent application claims priority to a U.S. Provisional Patent Application filed on December 29, 2023, with Serial No. 63 / 616,394 and entitled "GROUP-BASED POLICY ENCODING FOR NETWORK VIRTUALIZATION OVERLAYS", and assigns it to the assignee. The disclosure of the prior application is considered to be part of this patent application, and its entire content is incorporated herein by reference. Technical Field

[0003] Embodiments of the present disclosure relate to the field of communications, and more particularly, to group-based policy encoding for network virtualization overlays. Background Art

[0004] A group-based policy (GBP) model can define an application-centric or service-function-centric policy model in a Virtual eXtensible Local Area Network (VXLAN) deployment, where endpoint (e.g., endpoint device) or application network access policies are independent of the underlying network topology. This helps achieve macro-segmentation and micro-segmentation behavior consistency across large-scale networks and with minimal policies. Summary of the Invention

[0005] Some implementations described herein relate to a method. The method may include encoding, by a first network device in a first data center, a source tenant system interface (TSI) group identifier into a label protocol identifier and a group-based policy identifier, and encoding the label protocol identifier and the group-based policy identifier into a VXLAN packet having the source TSI group identifier, wherein the source TSI group identifier is not included in the header of the VXLAN packet. The method may include providing, via an Ethernet Virtual Private Network (EVPN) Multi-Protocol Label Switching (MPLS) network, the VXLAN packet having the source TSI group identifier to a second network device in a second data center.

[0006] Some implementations described herein relate to a first network device in a first data center. The first network device may include one or more memories and one or more processors. The one or more processors may be configured to encode a source TSI group identifier as a label protocol identifier and a group-based policy identifier, and encode the label protocol identifier and the group-based policy identifier into a VXLAN packet having the source TSI group identifier, where the source TSI group identifier is not included in the header of the VXLAN packet. The one or more processors may be configured to provide the VXLAN packet having the source TSI group identifier to a second network device in a second data center via an EVPN MPLS network, where the second network device is to apply a policy associated with the source TSI group identifier of the VXLAN packet.

[0007] Some implementations described herein relate to a non-transitory computer-readable medium storing an instruction set. When executed by one or more processors of a first network device in a first data center, the instruction set may cause the first network device to encode a source TSI group identifier as a label protocol identifier and a group-based policy identifier, and encode the label protocol identifier and the group-based policy identifier into a VXLAN packet having the source TSI group identifier, where the source TSI group identifier is included in the payload of the VXLAN packet. When executed by one or more processors of the first network device, the instruction set may cause the first network device to provide the VXLAN packet having the source TSI group identifier to a second network device in a second data center via an EVPN MPLS network. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figures 1A - 1F is a diagram of an example associated with providing group-based policy encoding for network virtualization overlays.

[0009] Figure 2 is a diagram of an example environment in which the systems and / or methods described herein may be implemented.

[0010] Figure 3 and Figure 4 is Figure 2 a diagram of example components of one or more devices of

[0011] Figure 5 is a flowchart of an example process for providing group-based policy encoding for network virtualization overlays. DETAILED DESCRIPTION

[0012] The following detailed description of example implementations refers to the accompanying drawings. The same reference numerals in different drawings may identify the same or similar elements.

[0013] The GBP model enables policies to be applied among groups of network endpoints. When a user looks beyond basic connectivity, richer network services with different implementations and network attributes (e.g., service chaining, quality of service (QoS) of services, path attributes, access control, etc.) can be expressed via these policies. In the GBP model, tenant system interfaces (TSIs) can be assigned to TSI groups. Each TSI group can include TSIs that share the same network policies and requirements. Network policies can be defined between a TSI group of a service source and a TSI group of a service destination. When a TSI is attached to a network, these policies can be deployed.

[0014] In many cases, the mapping of a TSI to a TSI group may only be known at the network virtualization edge (NVE) to which the TSI is attached. Thus, the TSI group of a packet destination may not be known until the packet reaches the egress NVE to which the packet destination is attached. However, since the source TSI group identifier is removed from the packet during transmission, the policy cannot be applied at the egress NVE. For example, a data center interconnection topology may include a first data center and a second data center that perform EVPN VXLAN. The first data center and the second data center may be interconnected via a wide area network (WAN) that performs EVPN MPLS. However, there is no mechanism for transporting the TSI group identifier (e.g., in a packet) from a leaf device in the first data center to a leaf device in the second data center.

[0015] Thus, current techniques for preserving group-based policies for network virtualization overlays consume computing resources (e.g., processing resources, memory resources, communication resources, etc.), network resources, etc., associated with not being able to retain the TSI group identifier provided in a packet, not being able to apply the policy associated with the TSI group identifier, providing a poor user experience based on not being able to apply the policy associated with the TSI group identifier, handling complaints associated with the poor user experience, etc.

[0016] Some implementations described herein relate to network devices that provide group-based policy encoding for network virtualization overlays. For example, a first network device in a first data center can encode a source TSI group identifier as a label protocol identifier and a group-based policy identifier, and can encode the label protocol identifier and the group-based policy identifier into a VXLAN packet with the source TSI group identifier. The source TSI group identifier may not be included in the header of the VXLAN packet. The first network device can provide the VXLAN packet with the source TSI group identifier to a second network device in a second data center via an EVPN MPLS network.

[0017] In this manner, network devices provide group-based policy encoding for network virtualization overlay. For example, a network device in a first data center can generate a packet that includes a TSI group identifier (e.g., but not provided in the header of the packet). The network device can provide the packet to a gateway in the first data center, and the gateway can de-encapsulate the packet to generate an EVPN MPLS packet with the TSI group identifier. The gateway can provide the EVPN MPLS packet to the EVPN MPLS network, and the EVPN MPLS network can provide the EVPN MPLS packet to a gateway in the second data center. The gateway in the second data center can de-encapsulate the EVPN MPLS packet to generate a packet with the TSI group identifier, and can provide the packet to a network device in the second data center. The network device can apply the policy associated with the TSI group identifier. This provides a way to seamlessly preserve the TSI group identifier in packets transmitted between data centers, and can be utilized with MPLS, VXLAN, Generic Routing Encapsulation (GRE). Thus, network devices save computing resources, network resources, etc., which would otherwise be severely affected by not being able to preserve the TSI group identifier provided in the packet, not being able to apply the policy associated with the TSI group identifier, providing a poor user experience based on not being able to apply the policy associated with the TSI group identifier, handling complaints associated with the poor user experience, etc.

[0018] Figures 1A - 1F is a diagram of Example 100 associated with providing group-based policy encoding for network virtualization overlay. As shown in Figures 1A - 1F Example 100 includes endpoint devices associated with a first data center (DC1), server devices associated with a second data center (DC2), and a wide area network (WAN) (e.g., an EVPN VXLAN fabric). The first data center can include leaf network devices (e.g., Leaf 11, Leaf 12, and Leaf 13), spine network devices (e.g., Spine 11 and Spine 12), and gateway network devices (e.g., GW 11 and GW 12). The second data center can include leaf network devices (e.g., Leaf 21, Leaf 22, and Leaf 23), spine network devices (e.g., Spine 21 and Spine 22), and gateway network devices (e.g., GW21 and GW 22). Further details of the endpoint devices, server devices, first data center, second data center, WAN, and network devices are provided elsewhere in this document.

[0019] As shown in Figure 1AAs shown in, and by reference numeral 105, a first network device of a first data center may generate a VXLAN packet having a source TSI group identifier. For example, the first network device of the first data center may correspond to leaf 11. In some implementations, the first network device may generate a VXLAN packet based on traffic received from an endpoint device. For example, the endpoint device may wish to communicate with a server device associated with a second data center. The endpoint device may generate traffic and may provide the traffic to the first data center. The first network device may receive the traffic from the endpoint device and may generate a VXLAN packet based on the traffic received from the endpoint device. In some implementations, the VXLAN packet may include a source TSI group identifier. The source TSI group identifier may identify the source TSI group using TSIs that share the same network policy and requirements. The network policy may be defined between the source TSI group of the VXLAN packet (e.g., a second network device (leaf 21) of the second data center) and the destination.

[0020] In some implementations, the first network device may generate the VXLAN packet by encoding the source TSI group identifier as a label protocol identifier and a group-based policy identifier and encoding the label protocol identifier and the group-based policy identifier as a VXLAN packet payload (e.g., not in the header) or another type of packet payload (e.g., a Multiprotocol Label Switching (MPLS) packet payload).

[0021] Figure 1B An example source TSI group identifier and an example VXLAN packet having the example source TSI group identifier are described. As in Figure 1B shown, and by reference numeral 110, the source TSI group identifier may include a group-based policy (GPB) label format having a label protocol identifier (TPID) and a group-based policy identifier (GPB-Id). For example, the TPID (e.g., 16 bits in length) may be dedicated to indicating the presence of the GPB-Id (e.g., 24 bits in length).

[0022] As in Figure 1BAs further shown in, and by reference numeral 115, a VXLAN packet may include an outer Ethernet header, an outer Internet Protocol (IP) header, an outer User Datagram Protocol (UDP) header, an outer VXLAN header, an inner destination Media Access Control (MAC) address, an inner source MAC address, a Virtual Local Area Network (VLAN) tag, a TPID, a GPB-Id, and an inner payload. The outer Ethernet header may include a source Ethernet address and a destination Ethernet address, and the outer IP header may include a source IP address and a destination IP address. The outer UDP header may include a default VXLAN destination UDP port number. The outer VXLAN header may include VXLAN information for the VXLAN packet. The inner destination MAC address may include the MAC address of the destination of the VXLAN packet. The inner source MAC address may include the MAC address of the source of the VXLAN packet. The VLAN tag may indicate that the VXLAN packet needs to access several networks simultaneously using the same interface. As in Figure 1B As further shown in, the GPB tags (e.g., TPID and GPB-Id) are not part of the VXLAN header, but rather part of the inner payload of the VXLAN packet. The inner payload may include data to be transmitted from the source to the destination.

[0023] As in Figure 1C As shown in, and by reference numeral 120, a first network device may provide a VXLAN packet to a first gateway of a first data center. For example, the first network device may forward the VXLAN packet to the destination of the VXLAN packet (e.g., a second network device (Leaf 21) of a second data center). Accordingly, the first network device may provide the VXLAN packet to a spine network device of the first data center (e.g., Spine 11). The spine network device may provide the VXLAN packet to a first gateway of the first data center (e.g., GW 11). The first gateway may receive the VXLAN packet from the spine network device.

[0024] As in Figure 1CAs further shown in, and by reference numeral 125, the first gateway may de-encapsulate the VXLAN packet and may encapsulate the packet as an EVPN MPLS packet. For example, the first gateway may de-encapsulate the VXLAN packet by removing the header information from the VXLAN packet. In some implementations, the first gateway may remove the outer Ethernet header, the outer IP header, the outer UDP header, and the outer VXLAN header from the VXLAN packet. The first gateway may not remove the inner destination MAC address, the inner source MAC address, the VLAN tag, the TPID, the GPB-Id, and the inner payload from the VXLAN packet. The first gateway may encapsulate the inner destination MAC address, the inner source MAC address, the VLAN tag, the TPID, the GPB-Id, and the inner payload with an EVPN MPLS header (e.g., including an outer Ethernet header, an outer IP header, and an MPLS header) to generate an EVPN MPLS packet.

[0025] As shown in Figure 1C As further shown in, and by reference numeral 130, the first gateway may provide the EVPN MPLS packet to a WAN (e.g., an EVPN MPLS network). For example, the first gateway of the first data center may provide the EVPN MPLS packet to the EVPN MPLS network, and the EVPN MPLS network may receive and route the EVPN MPLS packet to the second data center (e.g., via an EVPN MPLS tunnel provided in the WAN).

[0026] As shown in Figure 1D As shown in, and by reference numeral 135, the second gateway of the second data center may receive the EVPN MPLS packet from a WAN (e.g., an EVPN MPLS network). For example, the EVPN MPLS network may route the EVPN MPLS packet to the second gateway of the second data center (e.g., GW21) since the second gateway is associated with a second network device (e.g., leaf 21). The second gateway of the second data center may receive the EVPN MPLS packet from the EVPN MPLS network.

[0027] As shown in Figure 1DAs further shown in and by reference numeral 140, the second gateway may de-encapsulate the EVPN MPLS packet and may encapsulate the packet as a VXLAN packet. For example, the second gateway may de-encapsulate the EVPN MPLS packet by removing the EVPN MPLS header information from the EVPN MPLS packet. The second gateway may not remove the internal destination MAC address, internal source MAC address, VLAN tag, TPID, GPB-Id, and internal payload from the EVPN MPLS packet. The second gateway may encapsulate the internal destination MAC address, internal source MAC address, VLAN tag, TPID, GPB-Id, and internal payload with an external Ethernet header, external IP header, external UDP header, and external VXLAN header to generate a VXLAN packet.

[0028] As shown in Figure 1E and by reference numeral 145, a second network device in the second data center may receive a VXLAN packet with a source TSI group identifier preserved. For example, the second gateway may forward the VXLAN packet to the destination of the VXLAN packet (e.g., a second network device (leaf 21) in the second data center). Accordingly, the second gateway may provide the VXLAN packet to a spine network device in the second data center (e.g., spine 21). The spine network device may provide the VXLAN packet to a second network device in the second data center (e.g., leaf 21). The second network device may receive the VXLAN packet from the spine network device. The VXLAN packet may include a TPID and GPB-Id and may thus preserve the source TSI group identifier of the VXLAN packet.

[0029] As shown in Figure 1F and by reference numeral 150, the second network device may apply a policy associated with the source TSI group identifier of the VXLAN packet. For example, the second network device (e.g., leaf 21) may apply a policy associated with the TPID and GPB-Id (e.g., TSI group identifier) of the VXLAN packet. In some implementations, the policy may be associated with service chaining, quality of service, path attributes, access control, etc. In some implementations, the policy may include a tenant system security policy that defines what traffic may pass through the second network device and what actions need to be taken on the traffic when the traffic passes through the second network device. The tenant security policy may enable the second network device to control the traffic flow from zone to zone by defining the types of traffic that are allowed to be passed from a source to a destination. Traffic may enter one security zone and may leave through another security zone.

[0030] In this manner, network devices provide group-based policy encoding for network virtualization overlays. For example, a network device in a first data center can generate a packet that includes a TSI group identifier (e.g., but not provided in the header of the packet). The network device can provide the packet to a gateway in the first data center, and the gateway can de-encapsulate the packet to generate an EVPN MPLS packet with the TSI group identifier. The gateway can provide the EVPN MPLS packet to an EVPN MPLS network, and the EVPN MPLS network can provide the EVPN MPLS packet to a gateway in a second data center. The gateway in the second data center can de-encapsulate the EVPN MPLS packet to generate a packet with the TSI group identifier, and can provide the packet to a network device in the second data center. The network device can apply the policy associated with the TSI group identifier. This provides a way to seamlessly preserve the TSI group identifier in packets transmitted between data centers, and can be utilized with MPLS, VXLAN, GRE, etc. Thus, network devices save computing resources, network resources, etc., which would otherwise be severely affected by not being able to preserve the TSI group identifier provided in the packet, not being able to apply the policy associated with the TSI group identifier, providing a poor user experience based on not being able to apply the policy associated with the TSI group identifier, handling complaints associated with the poor user experience, etc.

[0031] As shown above, Figures 1A - 1F is provided as an example. Other examples may be different from those described with respect to Figures 1A - 1F The number and arrangement of the devices shown in Figures 1A - 1F are provided as an example. In practice, there may be additional devices, fewer devices, different devices, or differently arranged devices compared to those shown in Figures 1A - 1F In addition, two or more of the devices shown in Figures 1A - 1F can be implemented within a single device, or a single device shown in Figures 1A - 1F can be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) shown in Figures 1A - 1F can perform one or more of the functions described as being performed by another set of devices shown in Figures 1A - 1F

[0032] Figure 2 Figure 2 is a diagram of an example environment 200 in which the systems and / or methods described herein can be implemented. As shown in Figure 2 environment 200 can include endpoint devices 210, a set of network devices 220 (shown as network devices 220-1 through network devices 220-N), server devices 230, and a network 240. The devices of environment 200 can be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections.

[0033] The endpoint device 210 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information such as the information described herein. For example, the endpoint device 210 may include a mobile phone (e.g., a smart phone or a wireless phone), a laptop computer, a tablet computer, a desktop computer, a handheld computer, a gaming device, a wearable communication device (e.g., a smart watch, smart glasses, a heart rate monitor, a fitness tracker, smart clothing, smart jewelry, or a head-mounted display), a network device, a server device, a group of server devices, or a similar type of device. In some implementations, the endpoint device 210 may receive network traffic from other endpoint devices 210 and / or server devices 230 via the network 240 and / or may provide network traffic to other endpoint devices 210 and / or server devices 230 (e.g., by using the network device 220 as an intermediate device to route packets).

[0034] The network device 220 includes one or more devices capable of receiving, processing, storing, routing, and / or providing traffic (e.g., packets or other information or metadata) in the manner described herein. For example, the network device 220 may include a router, such as a label switching router (LSR), a label edge router (LER), an ingress router, an egress router, a provider router (e.g., a provider edge router or a provider core router), a virtual router, a route reflector, an area border router, or another type of router. Additionally or alternatively, the network device 220 may include a gateway, a switch, a firewall, a hub, a bridge, a reverse proxy, a server (e.g., a proxy server, a cloud server, or a data center server), a payload balancer, and / or a similar device. In some implementations, the network device 220 may be a physical device implemented within an enclosure such as a chassis. In some implementations, the network device 220 may be a virtual device implemented by one or more computer devices in a cloud computing environment or a data center. In some implementations, a group of network devices 220 may be a group of data center nodes used to route traffic flows through the network 240.

[0035] As described elsewhere herein, the server device 230 may include one or more devices capable of receiving, generating, storing, processing, providing, and / or routing information. The server device 230 may include communication devices and / or computing devices. For example, the server device 230 may include a server, such as an application server, a client server, a web server, a database server, a host server, a proxy server, a virtual server (e.g., executed on computing hardware), or a server in a cloud computing system. In some implementations, the server device 230 may include computing hardware used in a cloud computing environment.

[0036] Network 240 includes one or more wired and / or wireless networks. For example, network 240 may include a packet-switched network, a cellular network (e.g., a fifth-generation (5G) network, a fourth-generation (4G) network such as a Long-Term Evolution (LTE) network, a third-generation (3G) network, a Code Division Multiple Access (CDMA) network, a Public Land Mobile Network (PLMN), a Local Area Network (LAN), a Wide Area Network (WAN), a Metropolitan Area Network (MAN), a telephone network (e.g., a Public Switched Telephone Network (PSTN)), a private network, a mobile ad hoc network, an intranet, the Internet, a fiber-based network, a cloud computing network, etc., and / or a combination of these or other types of networks.

[0037] In Figure 2 the number and arrangement of the devices and networks shown are provided as an example. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or differently arranged devices and / or networks compared to those shown in Figure 2 In addition, two or more of the devices shown in Figure 2 may be implemented within a single device, or a single device shown in Figure 2 may be implemented as multiple distributed devices. Additionally or alternatively, a set of devices (e.g., one or more devices) of environment 200 may perform one or more of the functions described as being performed by another set of devices of environment 200.

[0038] Figure 3 is Figure 2 a diagram of example components of one or more devices of Figure 3 Example components may be included in device 300, which may correspond to endpoint device 210, network device 220, and / or server device 230. In some implementations, endpoint device 210, network device 220, and / or server device 230 may include one or more devices 300 and / or one or more components of device 300. As shown in

[0039] Bus 310 includes one or more components that implement wired or wireless communication among the components of device 300. Bus 310 may couple Figure 3Two or more components are coupled together, such as via operational coupling, communication coupling, electrical coupling, and / or electro - coupling. Processor 320 includes a central processing unit, a graphics processing unit, a microprocessor, a controller, a microcontroller, a digital signal processor, a field - programmable gate array, an application - specific integrated circuit, and / or another type of processing component. Processor 320 is implemented in hardware, firmware, or a combination of software and hardware. In some implementations, processor 320 includes one or more processors that can be programmed to perform one or more operations or processes described elsewhere herein.

[0040] Memory 330 includes volatile and / or non - volatile memory. For example, memory 330 can include random access memory (RAM), read - only memory (ROM), a hard disk drive, and / or another type of memory (e.g., flash memory, magnetic memory, and / or optical memory). Memory 330 can include internal memory (e.g., RAM, ROM, or hard disk drive) and / or removable memory (e.g., removable via a universal serial bus connection). Memory 330 can be a non - transient computer - readable medium. Memory 330 stores information, instructions, and / or software (e.g., one or more software applications) regarding the operation of device 300. In some implementations, memory 330 includes one or more memories coupled to one or more processors (e.g., processor 320), such as via bus 310.

[0041] Input component 340 enables device 300 to receive input, such as user input and / or sensed input. For example, input component 340 can include a touch screen, a keyboard, a keypad, a mouse, buttons, a microphone, switches, sensors, a global positioning system sensor, an accelerometer, a gyroscope, and / or actuators. Output component 350 enables device 300 to provide output, such as via a display, a speaker, and / or a light - emitting diode. Communication interface 360 enables device 300 to communicate with other devices via a wired connection and / or a wireless connection. For example, communication interface 360 can include a receiver, a transmitter, a transceiver, a modem, a network interface card, and / or an antenna.

[0042] Device 300 may perform one or more operations or processes described herein. For example, a non-transitory computer-readable medium (e.g., memory 330) may store a set of instructions (e.g., one or more instructions or code) for execution by processor 320. Processor 320 may execute the set of instructions to perform one or more operations or processes described herein. In some implementations, the set of instructions executed by one or more processors 320 causes one or more processors 320 and / or device 300 to perform one or more operations or processes described herein. In some implementations, hardwired circuitry may be used in place of or in combination with the instructions to perform one or more operations or processes described herein. Additionally or alternatively, processor 320 may be configured to perform one or more operations or processes described herein. Accordingly, the implementations described herein are not limited to any particular combination of hardware circuitry and software.

[0043] The Figure 3 number and arrangement of components shown in Figure 3 are provided as an example. Compared to the components shown in

[0044] Figure 4 , device 300 may include additional components, fewer components, different components, or components arranged differently. Additionally or alternatively, a set of components (e.g., one or more components) of device 300 may perform one or more of the functions described as being performed by another set of components of device 300. Figure 2 FIG. Figure 4 is a diagram of example components of one or more devices. The example components may be included in device 400. Device 400 may correspond to network device 220. In some implementations, network device 220 may include one or more devices 400 and / or one or more components of device 400. As shown in

[0045] The input component 410 can be one or more points in an attachment for a physical link and can be one or more points for an ingress of incoming traffic such as packets. The input component 410 can process incoming traffic, such as by performing data link layer encapsulation or decapsulation. In some implementations, the input component 410 can send and / or receive packets. In some implementations, the input component 410 can include an input line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more interface cards (IFCs), packet forwarding components, line card controller components, input ports, processors, memories, and / or input queues. In some implementations, the device 400 can include one or more input components 410.

[0046] The switching component 420 can interconnect the input component 410 and the output component 430. In some implementations, the switching component 420 can be implemented via one or more crossbars, via a bus, and / or with a shared memory. The shared memory can act as a temporary buffer to store packets from the input component 410 before the packets are ultimately destined for delivery to the output component 430. In some implementations, the switching component 420 can enable the input component 410, the output component 430, and / or the controller 440 to communicate with each other.

[0047] The output component 430 can store packets and can schedule packets for transmission on an output physical link. The output component 430 can support data link layer encapsulation or decapsulation, and / or various high-level protocols. In some implementations, the output component 430 can send and / or receive packets. In some implementations, the output component 430 can include an output line card that includes one or more packet processing components (e.g., in the form of integrated circuits), such as one or more IFCs, packet forwarding components, line card controller components, output ports, processors, memories, and / or output queues. In some implementations, the device 400 can include one or more output components 430. In some implementations, the input component 410 and the output component 430 can be implemented by the same set of components (e.g., and the input / output component can be a combination of the input component 410 and the output component 430).

[0048] The controller 440 includes a processor in the form of, for example, a CPU, GPU, APU, microprocessor, microcontroller, DSP, FPGA, ASIC, and / or another type of processor. The processor is implemented in hardware, firmware, or a combination of hardware and software. In some implementations, the controller 440 can include one or more processors that can be programmed to perform functions.

[0049] In some implementations, the controller 440 may include a RAM, a ROM, and / or another type of dynamic or static storage device (e.g., flash memory, magnetic memory, optical memory, etc.) that stores information and / or instructions used by the controller 440.

[0050] In some implementations, the controller 440 may communicate with other devices, networks, and / or systems connected to the device 400 to exchange information about the network topology. The controller 440 may create a routing table based on the network topology information, may create a forwarding table based on the routing table, and may forward the forwarding table to the input component 410 and / or the output component 430. The input component 410 and / or the output component 430 may use the forwarding table to perform a route lookup for incoming and / or outgoing packets.

[0051] The controller 440 may execute one or more of the processes described herein. The controller 440 may execute these processes in response to executing software instructions stored by a non-transitory computer-readable medium. A computer-readable medium is defined herein as a non-transitory memory device. The memory device includes a memory space within a single physical storage device or a memory space distributed across multiple physical storage devices.

[0052] The software instructions may be read via a communication interface from another computer-readable medium or from another device into the memory and / or storage component associated with the controller 440. When executed, the software instructions stored in the memory and / or storage component associated with the controller 440 may cause the controller 440 to execute one or more of the processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with the software instructions to execute one or more of the processes described herein. Thus, the implementations described herein are not limited to any particular combination of hardware circuitry and software.

[0053] In Figure 4 The number and arrangement of the components shown are provided as an example. In practice, compared to those shown in Figure 4 The device 400 may include additional components, fewer components, different components, or components arranged differently. Additionally or alternatively, a set of components (e.g., one or more components) of the device 400 may perform one or more of the functions described as being performed by another set of components of the device 400.

[0054] Figure 5 Is a flowchart of an example process 500 for providing group-based policy encoding for network virtualization overlay. In some implementations, Figure 5 One or more of the process blocks of Figure 5One or more process blocks of can be performed by another device or group of devices independent of or including the network device, such as an endpoint device (e.g., endpoint device 210) and / or a server device (e.g., server device 230). Additionally or alternatively, Figure 5 One or more process blocks of can be performed by one or more components of device 300, such as processor 320, memory 330, input component 340, output component 350, and / or communication interface 360. Additionally or alternatively, Figure 5 One or more process blocks of can be performed by one or more components of device 400, such as input component 410, switching component 420, output component 430, and / or controller 440.

[0055] As shown in Figure 5 Process 500 can include encoding a source TSI group identifier as a label protocol identifier and a group-based policy identifier (block 510). For example, a first network device can encode a source TSI group identifier as a label protocol identifier and a group-based policy identifier as described above. In some implementations, the source TSI group identifier includes a label protocol identifier and a group-based policy identifier. In some implementations, the source TSI group identifier includes a group-based policy label format.

[0056] As further shown in Figure 5 Process 500 can include encoding the label protocol identifier and the group-based policy identifier as a VXLAN packet with a source TSI group identifier, where the source TSI group identifier is not included in the header of the VXLAN packet (block 520). For example, a first network device can encode the label protocol identifier and the group-based policy identifier as a VXLAN packet with a source TSI group identifier as described above. In some implementations, the source TSI group identifier is not included in the header of the VXLAN packet. In some implementations, the VXLAN packet includes an outer Ethernet header, an outer Internet Protocol header, an outer User Datagram Protocol header, an outer VXLAN header, an inner destination MAC address, an inner source MAC address, a VLAN tag, a source TSI group identifier, and / or an inner payload. In some implementations, the source TSI group identifier is included in the payload of the VXLAN packet.

[0057] As shown in Figure 5As further shown, process 500 may include providing a VXLAN packet with a source TSI group identifier to a second network device in a second data center via an EVPN MPLS network (block 530). For example, a first network device may provide a VXLAN packet with a source TSI group identifier to a second network device in a second data center via an EVPN MPLS network, as described above. In some implementations, providing the VXLAN packet to the second network device includes providing the VXLAN packet to a first gateway in a first data center, causing the first gateway to de-encapsulate the VXLAN packet to generate a de-encapsulated packet, encapsulating the de-encapsulated packet as an EVPN MPLS packet, and providing the EVPN MPLS packet to the EVPN MPLS network. In some implementations, the second network device is to apply a policy associated with the source TSI group identifier of the VXLAN packet. In some implementations, the policy is associated with one or more of service chaining, quality of service, path attributes, or access control. In some implementations, the first network device is a leaf network device in a first data center, and the second network device is a leaf network device in a second data center. In some implementations, the EVPN MPLS network is an EVPN MPLS tunnel provided in a wide area network.

[0058] In some implementations, the EVPN MPLS network is to provide an EVPN MPLS packet to a second gateway in a second data center. In some implementations, the second gateway is to de-encapsulate the EVPN MPLS packet to generate another de-encapsulated packet, and encapsulate the another de-encapsulated packet as a VXLAN packet. In some implementations, the second gateway is to provide a VXLAN packet with a source TSI group identifier to the second network device.

[0059] Although Figure 5 illustrative blocks of process 500 are shown, in some implementations, process 500 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks compared to those shown in Figure 5 . Additionally or alternatively, two or more of the blocks of process 500 may be executed in parallel.

[0060] The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit the implementations to the precise forms disclosed. Modifications may be made in light of the above disclosure, or modifications may be obtained from the practice of implementations.

[0061] As used herein, the term "component" is intended to be broadly construed as hardware, firmware, or a combination of hardware and software. It is evident that the systems and / or methods described herein can be implemented in different forms of hardware, firmware, and / or a combination of hardware and software. The use of actual dedicated control hardware or software code to implement these systems and / or methods is not a limitation of the implementation. Thus, the operation and behavior of the systems and / or methods described herein are not referenced to specific software code - it is to be understood that, based on the description herein, software and hardware can be used to implement the systems and / or methods.

[0062] Although specific combinations of features are recited in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of various implementations. In fact, many of these features can be combined in ways not specifically recited in the claims and / or disclosed in the specification. Although each of the dependent claims listed below may directly depend on only one claim, the disclosure of various implementations includes each dependent claim in combination with every other claim in the claim set.

[0063] Unless so explicitly described, no element, act, or instruction used herein should be construed as critical or essential. Additionally, as used herein, the articles "a" and "an" are intended to include one or more items and can be used interchangeably with "one or more." Additionally, as used herein, the article "the" is intended to include one or more items related to the reference associated with the article "the" and can be used interchangeably with "one or more." Additionally, as used herein, the term "set" is intended to include one or more items (e.g., related items, unrelated items, combinations of related and unrelated items, etc.) and can be used interchangeably with "one or more." If only one item is intended, the phrase "only one" or similar language is used. Additionally, as used herein, the terms "has," "have," "is having," or similar terms are intended to be open-ended terms. Additionally, the phrase "based on" is intended to mean "at least partially based on" unless otherwise explicitly stated. Additionally, as used herein, the term "or" is intended to be inclusive when used in a series and can be used interchangeably with "and / or" unless otherwise explicitly stated (e.g., if used in combination with "one of" or "only one of").

[0064] In the foregoing specification, various example embodiments have been described with reference to the accompanying drawings. However, it will be apparent that various modifications and changes can be made thereto, and additional embodiments can be implemented, without departing from the broader scope of the invention as set forth in the following claims. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method comprising: encoding, by a first network device in a first data center, a source tenant system interface TSI group identifier into a tag protocol identifier and a group-based policy identifier; encoding, by the first network device, the tag protocol identifier and the group-based policy identifier into a virtual extensible local area network (VXLAN) packet having the source TSI group identifier, wherein the source TSI group identifier is not included in a header of the VXLAN packet; as well as The first network device provides the VXLAN packet with the source TSI group identifier to a second network device in a second data center via an Ethernet Virtual Private Network (EVPN) Multi-Protocol Label Switching (MPLS) network.

2. The method of claim 1 , wherein providing the VXLAN packet to the second network device comprises: The VXLAN packet is provided to a first gateway of the first data center so that the first gateway decapsulates the VXLAN packet to generate a decapsulated packet, encapsulates the decapsulated packet into an EVPN MPLS packet, and provides the EVPN MPLS packet to the EVPN MPLS network.

3. The method of claim 2, wherein the EVPN MPLS network is to provide the EVPN MPLS packets to a second gateway of the second data center. 4 . The method of claim 3 , wherein the second gateway is to decapsulate the EVPN MPLS packet to generate another decapsulated packet, and to encapsulate the another decapsulated packet as the VXLAN packet.

5. The method of claim 4, wherein the second gateway is to provide the VXLAN packet with the source TSI group identifier to the second network device.

6. The method of claim 1, wherein the second network device is to apply a policy associated with the source TSI group identifier of the VXLAN packet.

7. The method of claim 6, wherein the policy is associated with one or more of service chaining, quality of service, path attributes, or access control.

8. A first network device of a first data center, the first network device comprising: one or more memories; as well as One or more processors to: Encode the source tenant system interface TSI group identifier into a label protocol identifier and a group-based policy identifier; encoding the tag protocol identifier and the group-based policy identifier into a Virtual Extensible Local Area Network (VXLAN) packet with the source TSI group identifier, wherein the source TSI group identifier is not included in a header of the VXLAN packet; as well as providing the VXLAN packet with the source TSI group identifier to a second network device of a second data center via an Ethernet virtual private network (EVPN) multiprotocol label switching (MPLS) network, Wherein the second network device is to apply a policy associated with the source TSI group identifier of the VXLAN packet.

9. The first network device of claim 8, wherein the source TSI group identifier comprises the label protocol identifier and the group-based policy identifier.

10. The first network device of claim 8, wherein the source TSI group identifier comprises a group-based policy tag format.

11. The first network device of claim 8, wherein the VXLAN packet comprises an outer Ethernet header, an outer Internet Protocol header, an outer User Datagram Protocol header, an outer VXLAN header, an inner destination Media Access Control MAC address, an inner source MAC address, a VLAN tag, the source TSI group identifier, and / or an inner payload.

12. The first network device of claim 8, wherein the first network device is a leaf network device of the first data center, and the second network device is a leaf network device of the second data center.

13. The first network device of claim 8, wherein the source TSI group identifier is included in a payload of the VXLAN packet.

14. The first network device according to claim 8, wherein the EVPN MPLS network is an EVPN MPLS tunnel provided in a wide area network.

15. A non-transitory computer-readable medium storing a set of instructions, the set of instructions comprising: One or more instructions that, when executed by one or more processors of a first network device in a first data center, cause the first network device to: Encode the source tenant system interface TSI group identifier into a label protocol identifier and a group-based policy identifier; encoding the tag protocol identifier and the group-based policy identifier into a Virtual Extensible Local Area Network (VXLAN) packet with the source TSI group identifier, wherein the source TSI group identifier is included in a payload of the VXLAN packet; as well as The VXLAN packet with the source TSI group identifier is provided to a second network device of a second data center via an Ethernet virtual private network (EVPN) multi-protocol label switching (MPLS) network.

16. The non-transitory computer-readable medium of claim 15, wherein the one or more instructions that cause the first network device to provide the VXLAN packet to the second network device cause the first network device to: The VXLAN packet is provided to a first gateway of the first data center so that the first gateway decapsulates the VXLAN packet to generate a decapsulated packet, encapsulates the decapsulated packet into an EVPN MPLS packet, and provides the EVPN MPLS packet to the EVPN MPLS network.

17. The non-transitory computer-readable medium of claim 15, wherein a second gateway of the second data center is to provide the VXLAN packet with the source TSI group identifier to the second network device.

18. The non-transitory computer-readable medium of claim 17, wherein the second network device is to apply a policy associated with the source TSI group identifier of the VXLAN packet, The policy is associated with one or more of a service chain, quality of service, path attributes, or access control.

19. The non-transitory computer-readable medium of claim 15, wherein the source TSI group identifier comprises the tag protocol identifier and the group-based policy identifier.

20. The non-transitory computer-readable medium of claim 15, wherein the VXLAN packet comprises an outer Ethernet header, an outer Internet Protocol header, an outer User Datagram Protocol header, an outer VXLAN header, an inner destination Media Access Control MAC address, an inner source MAC address, a VLAN tag, the source TSI group identifier, and / or an inner payload.

Images