System for processing encapsulated wireless traffic

Abstract

System comprehensive: a network device; and comprising a wireless access point (WAP): a processor; an antenna; a physical network interface; and a memory comprising a computer-readable program code which, when executed by the processor, causes the WAP to: Receiving a Network Traffic Data Unit (NTDU) from a client device; Identifying a virtual tunnel through which the NTDU is to be transported, based on an NTDU header according to a policy, wherein the policy maps a section of the header to one or a plurality of available virtual tunnels; and Transmitted, via the virtual tunnel, the NTDU to the network device, wherein the header section includes a source IP address, and wherein the policy maps source IP addresses within a first range to a first virtual tunnel of the available virtual tunnels and maps source IP addresses within a second range to a second virtual tunnel of the available virtual tunnels.

Description

BACKGROUND

[0001] Various mechanisms are used to route and / or forward network traffic within a network. Network resources are required to implement these mechanisms. In networks that include both wired and wireless network resources, managing the different types of resources needed to implement these mechanisms is complex.

[0002] Further background information is provided in the following documents.

[0003] US 1,0298,717 B2 discloses a network element configured to: take a data packet originating from a client from an access point, wherein the data packet includes a packet header containing a packet header augmented with context information; decapsulate the packet header to identify the context information; apply a client-specific policy to the packet, at least partially based on the context information; and forward the packet to the next hop in the network. The network element may be part of a network, such as a data center fabric architecture.

[0004] US 9,240,898 B1 discloses methods and apparatus for integrating VLAN-independent devices into VLAN-capable networks. For example, a method for assigning a virtual local area network identifier (VID) to a data unit may involve receiving a data unit encapsulated in a wireless header from a source host via a wireless access point, wherein the data unit is addressed to a destination host. A VID is determined, at least in part, based on a wireless network identifier contained in the wireless header, and the VID is assigned to the data unit.

[0005] US 2017 / 019428 A1 discloses a symmetric return path from an autonomous system (AS) that can be enforced using the same edge gateway for incoming and outgoing communications with an internet source. An asymmetric return path from an AS can be used with different edge gateways for incoming and outgoing communications with an internet source. An anycast IP address can be used to select outgoing edge gateways from an AS. Packets within an AS can be redirected to selected outgoing edge gateways of the AS.

[0006] Arista: “VXLAN Pseudowires”, September 27, 2016, pages 1-4, Santa Clara, USA, reveals “The Arista VXLAN Pseudowire Solution” and outlines benefits that enable organizations to use cost-effective and efficient methods to meet a variety of requirements and modernize their networks. SUMMARY

[0007] A method for processing network traffic data units is provided, as set forth in claim 1.

[0008] A method for processing network traffic data units is also provided, as set forth in claim 10.

[0009] Furthermore, a wireless access point is provided as set out in claim 14. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 shows a system according to one or more embodiments of the invention. Fig. Figure 2 shows a flowchart according to one or more embodiments of the invention. Fig. Figure 3 shows a flowchart according to one or more embodiments of the invention. Fig. Figures 4A-4C show an example according to one or more embodiments of the invention. DETAILED DESCRIPTION

[0010] The following discloses a method for processing network traffic data units (NTDUs). The method comprises receiving an NTDU from a client device via a wireless access point (WAP), identifying a virtual tunnel through which the NTDU is to be transmitted, the virtual tunnel being connected to a network device, and transmitting the NTDU to the network device via the virtual tunnel.

[0011] In general, implementations refer to a procedure for processing network traffic data units (NTDUs). The procedure involves a network device receiving an encapsulated NTDU from a wireless access point (WAP) via a virtual tunnel, retrieving the NTDU from the encapsulated NTDU, and processing the NTDU.

[0012] In general, implementations refer to a wireless access point (WAP) comprising a processor, an antenna, a physical network interface, and memory containing computer-readable program code, wherein, when the computer-readable program code is executed by the processor, the WAP performs a procedure comprising: receiving a network traffic data unit (NTDU) from a client device via the antenna, identifying a virtual tunnel over which the NTDU is to be transmitted, the virtual tunnel being connected to a network device, and transmitting the NTDU over the virtual tunnel and the physical network interface to the network device.

[0013] Specific embodiments are now described with reference to the accompanying figures. Numerous details are given in the following description as examples of the invention. Certain details known to those skilled in the art may be omitted to avoid complicating the description.

[0014] Furthermore, in the following description of the figures, each component described in relation to a figure in different embodiments of the invention may correspond to one or more components of the same name shown and / or described in relation to another figure.

[0015] Throughout the application, ordinal numbers (e.g., first, second, third, etc.) may be used as adjectives for an element (i.e., any noun in the application). The use of ordinal numbers is not intended to imply or create a particular order of elements, nor to restrict an element to a single element unless expressly disclosed, for example, by the use of terms such as "before," "after," "only," and other such terms. Rather, the use of ordinal numbers serves to distinguish between elements. For example, a first element is different from a second element, and the first element may comprise more than one element and follow (or precede) the second element in a sequence of elements.

[0016] In general, embodiments of the invention relate to systems and methods for receiving and processing network traffic data units (NTDUs). Specifically, embodiments of the invention relate to the processing of NTDUs received from wireless access points (WAPs) and then the transmission of the received NTDUs via a virtual tunnel to a network device in a network. The network devices can then decapsulate and process the NTDUs, the processing of which may further include encapsulating the NTDUs within the network to send the NTDU to the appropriate virtual endpoint (VEP). Depending on the network configuration, the VEP may be in the same domain (e.g., the same Layer 2 domain) or in a different domain than the network device that received the NTDU from the WAP. Embodiments allow NTDUs to be sent from WAPs to a network (e.g.,(a network edge) without the WAP having to participate in any learning about the location of targets within the network. In this way, various embodiments of the invention can utilize the encapsulation from the WAP to the final target of the NTDU without the WAP experiencing any overhead associated with "learning" about the network.

[0017] In one or more embodiments of the invention, an NTDU is any relevant data transmitted in a format specified by one or more network protocols or standards over a wired or wireless transmission medium (or a combination thereof). Examples of such protocols or standards include, but are not limited to, Internet Protocol (IP), Media Access Control (MAC), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), InfiniBand, Hypertext Transfer Protocol (HTTP), the IEEE 802.11 protocol family, etc. In one or more embodiments of the invention, the relevant data is at least one segment of the payload of an NTDU in any format.

[0018] Fig. Figure 1 shows a system according to one or more embodiments of the invention. As in Fig. As shown in Figure 1, the system comprises one or more client devices (100A, 100N), one or more network devices (e.g., Network Device A (106), Network Device B (108), Network Device C (110), and Network Device D (112)), a WAP (102), and one or more local devices (e.g., Local Device (104)). Each of these components is described below.

[0019] In one or more embodiments of the invention, one or more client devices (100A, 100N) can be implemented as computing devices. In one or more embodiments of the invention, a computing device is any device or set of devices capable of processing instructions electronically and comprising at least one or more processors, memory, input and output device(s), and operational network connectivity to one or more network devices or one or more WAPs. Examples of computing devices include, but are not limited to, a server (e.g., a blade server in a blade server enclosure, a shelf server in a shelf, etc.), a virtual machine (VM), a desktop computer, a mobile device (e.g., laptop computer, smartphone, personal digital assistant, tablet computer, and / or any other mobile computing device), a network device (e.g.,Switches, routers, multi-layer switches, etc.) and / or any other type of computing equipment meeting the aforementioned requirements.

[0020] In one embodiment of the technology, one or more client devices (100A, 100N) include functionality for communicating with one or more WAPs (e.g., 102). Communicating with the WAPs can include functionality for sending NTDUs to the resource WAP (102) and for receiving NTDUs from the WAP (102).

[0021] In one or more embodiments of the invention, a network device (e.g., 106, 108, 110, 112) can be a physical device comprising all or any subset of the following, but not limited to: a persistent memory (not shown), a memory (e.g., random access memory (RAM)) (not shown), one or more processors (not shown), one or more network chips, one or more circuit components (e.g., wire, resistors, capacitors, transistors, inductors, integrated circuit packages, printed circuit boards, diodes, comparators, etc.), one or more field-programmable gate arrays (FPGAs), one or more application-specific integrated circuits (ASICs), one or more complex programmable logic devices (CPLDs), and / or two or more physical network interfaces (which may also be referred to as ports).A network device can be connected to other devices via wired (e.g., using the ports) and / or wireless connections.

[0022] In one or more embodiments of the invention, the one or more network devices (106, 108, 110, 112) comprise functionality for receiving NTDUs at one of the physical network interfaces (i.e., ports) of the network device and for subsequently transmitting NTDUs from one of the physical network interfaces of the network device. The NTDU can be transmitted to other network devices and / or to client devices (not shown) connected to the network device. In one embodiment of the invention, the network device comprises functionality for processing NTDUs according to the Fig. 2-3.

[0023] Network devices may also include functionality to inspect all or certain sections of an NTDU to determine whether: (i) the NTDU is dropped; (ii) the NTDU is processed (which may include encapsulation); and / or (iii) the NTDU is transmitted, based on processing by the network device, where processing may be performed by a hardware component in the network device, by software running on the network device, or by any combination thereof.

[0024] In one or more embodiments of the invention, the network device includes functionality for storing (e.g., in persistent memory, in a memory, in a register, etc.) any number of data structures (e.g., filter information, buffer information, routing information base (RIB), queued and timestamped NTDU, etc., forwarding information base (FIB), connection state database, counters, etc.) to facilitate the operation of at least some aspects of the network device.

[0025] Such structures can be stored in a data storage device (not shown) that is contained in and / or operationally connected to a network device. In one or more embodiments of the invention, a data storage device is any type of storage unit(s) and / or device(s) (e.g., a file system, a database, a collection of tables, or any other storage mechanism) for storing data. Furthermore, the data storage device can comprise several different storage units and / or devices. The several different storage units and / or devices can be of the same type or not, or they can be located at the same physical location. In one or more embodiments of the invention, the network device data storage device comprises all or any portion of the persistent and / or non-persistent storage of the network device, as described above.

[0026] Examples of network devices include, but are not limited to, a Layer 2 network switch, a router, a multilayer switch, a fiber optic conduit device, an InfiniBand® device, etc.

[0027] The local devices (e.g., 104) can be implemented as network devices (described above) and / or computing devices (described above). The local devices include functionality for receiving NTDUs with or without virtual local area network (VLAN) tags from the WAP (102).

[0028] The WAP (102) can be implemented as a network device with one or more antennas. The antennas enable the WAP to receive NTDUs via a wireless transmission medium and transmit them to one or more client devices (100A, 100N). When NTDUs are sent and received via the wireless transmission medium, they can be transmitted according to a wireless communication standard such as the IEEE 802.11 protocol family. Other wireless communication standards and / or protocols can be used without deviating from the invention.

[0029] The WAP transmits NTDUs to and receives NTDUs from one or more local devices via one or more physical network interfaces (not shown) on the WAP. Furthermore, the WAP transmits NTDUs to and receives NTDUs from one or more network devices (e.g., 106, 108, 110, 112).

[0030] The WAP (102) uses a virtual tunnel to transmit NTDUs (and receive NTDUs from) network devices (106, 108, 110, 112). For example, a virtual endpoint (114) running an encapsulation protocol (e.g., Virtual Extendable Local Area Network (VXLAN), Generic Routing Encapsulation (GRE), Multiprotocol Label Switching (MPLS), etc.) (or otherwise implemented on the WAP) can encapsulate the NTDU using an encapsulation protocol and then transmit the encapsulated NTDU to a network device. Unlike standard encapsulation, which requires the encapsulated NTDU to be transmitted to a network device locally connected to the NTDU's destination, the encapsulation and transmission by the WAP transmit the NTDU to a preconfigured destination (i.e., a specific network device) regardless of the NTDU's actual destination.

[0031] The network device, as described below in Fig. As described in section 3, the NTDU can then be further processed for transmission to its final destination (which may or may not include encapsulation). In one embodiment of the invention, the network device (e.g., 106) that received the encapsulated NTDU from the WAP includes a VEP (e.g., 116) that decapsulates the encapsulated NTDU received via the virtual tunnel. Unlike the VEP running on the WAP, the VEP running on the network devices (e.g., 116, 118) includes functionality for "learning" destinations connected to the operationally linked network devices (e.g., 106, 108, 110, 112). In one embodiment of the invention, the VEPs running on the network devices (e.g., 116, 118) are virtual tunnel endpoints (VTEPs) that implement the VXLAN protocol. The VEPs can implement other encapsulation protocols (e.g., GRE, MPLS) without deviating from the invention.Additional details on the functionality of the various VEPs can be found in the . Fig. 2 and Fig. 3 provided.

[0032] In one embodiment of the invention, the network devices (e.g., 106, 108, 110, 112) can be located in the same domain (e.g., Layer 2 domains; domain X in Fig. 1) are located in different domains (not shown) or a combination thereof (not shown). The way in which NTDUs are transferred between the different network devices depends on the domain(s) in which the network device is located and how the network devices are connected. For example, the NTDUs transferred between the network devices can be encapsulated or unencapsulated, even if the network devices are in the same domain. If the network devices (e.g., 106, 110) are locally connected (e.g., there is a direct physical connection between the network devices), then the NTDUs can be transferred without encapsulation. However, if the network devices (e.g., 106, 108) are not locally connected but are within the same domain, then the NTDUs are transferred as encapsulated NTDUs according to one or more embodiments of the invention.Additional details are provided below regarding . Fig. 3 provided.

[0033] Each of the system components described above may also include software and / or firmware stored in any data storage device (not shown) and / or memory (not shown) (i.e., non-transient, computer-readable media). Such software and / or firmware may include instructions which, when executed by one or more processors (not shown) contained in and / or operationally connected to the component, cause the one or more processors to perform all or a portion of the methods / functionalities described in this application according to one or more embodiments of the invention.

[0034] The instructions can be in the form of computer-readable program code for carrying out embodiments of the invention and can be stored wholly or partially, temporarily or permanently, on a non-transitory computer-readable medium such as a CD, DVD, storage device, floppy disk, tape, flash memory, physical memory, or other computer-readable storage medium. In particular, the software instructions can correspond to computer-readable program code which, when executed by one or more processors, is configured to perform functions relating to embodiments of the invention.

[0035] While Fig. Figure 1 shows one configuration of components; other configurations can be used without deviating from the scope of the invention. For example, there can be any number of client devices, WAPs, network devices, local devices, etc., which can be arranged in any way. Accordingly, the embodiments disclosed herein should not be limited to those shown in Figure 1. Fig. The configuration of components shown may be limited to 1.

[0036] Fig. Figures 2-3 show flowcharts according to one or more embodiments of the invention. While the various steps in the flowcharts are presented and described sequentially, a person skilled in the art will recognize that some or all of the steps can be performed in different orders, combined, or omitted, and that some or all of the steps can be performed in parallel. In one embodiment of the invention, the steps shown in Fig. 2-3 shown steps parallel to any other in Fig. The steps shown in 2-3 can be carried out without deviating from the scope of the invention.

[0037] Fig. Figure 2 shows a method for transferring NTDUs according to one or more embodiments of the invention. The Fig. The two procedures shown can, for example, be performed by a WAP.

[0038] With reference to Fig. In step 200, an NTDU is received from a WAP by a client device. The client device can receive the NTDU via an antenna on the WAP.

[0039] In step 202, the NTDU is analyzed to determine whether: (i) the transfer of the NTDU to a local device (see e.g. Fig. 1, Fig. 104) or (ii) the transmission of the NTDU to a network device via a virtual tunnel. The analysis to determine whether option (i) or (ii) is selected can be performed using at least one section of the contents of an NTDU header. For example, the WAP can use the source Internet Protocol (IP) address, the destination IP address, a tag within the NTDU header, any other section of the NTDU header, or any combination thereof to make the aforementioned determination.

[0040] Continuing the discussion from Step 202, the analysis can use the aforementioned content of the NTDU header to determine: (a) that the NTDU should be sent to a local device via a physical network interface; (b) that the NTDU should be tagged with a suitable VLAN tag and then sent to a local device via a physical network interface; or (c) that the NTDU should be sent to a network device via a virtual tunnel.

[0041] With regard to (c), as explained above, the WAP can encapsulate the NTDU and transmit it to a network device via a virtual tunnel. The virtual tunnel used to transmit the encapsulated NTDU to the network device is a point-to-point virtual tunnel. In other words, the virtual tunnel between the WAP and a specific network device is preconfigured such that all encapsulated NTDUs transmitted in the tunnel reach the specific network device, regardless of the contents of the NTDU header. In one embodiment of the invention, the virtual tunnel between the WAP and the specific network device can be implemented as a VXLAN pseudowire. The aforementioned virtual tunnel can be implemented using other protocols without deviating from the invention.

[0042] If, based on the above analysis, the NTDU is to be transmitted to the network device via a virtual tunnel, the system determines which virtual tunnel should be used for the NTDU transmission; in other words, the virtual tunnel is identified. If only one virtual tunnel is configured, the NTDU is transmitted via that virtual tunnel. However, if multiple virtual tunnels exist, the WAP can implement a policy to select one virtual tunnel from the set of virtual tunnels to use for the NTDU transmission.

[0043] In this scenario, the WAP can select a specific virtual tunnel from the set of available virtual tunnels based on a policy, using the NTDU header (or a portion thereof). In one embodiment of the invention, the policy can be implemented as a lookup table, where the policy maps sections of the NTDU header to a given virtual tunnel. For example, NTDUs with source IP addresses within a first range can be transmitted to a first network device over a first virtual wire, while NTDUs with source IP addresses within a second range can be transmitted to a second network device over a second virtual wire. The invention is not limited to the aforementioned policy; rather, any policy can be used to select a virtual wire over which the NTDU is to be transmitted.Furthermore, there can be any number of pre-configured virtual tunnels connecting the WAP to one or more network devices, which can be in the same or different domains. The virtual tunnel is identified using metadata associated with the NTDU to be transmitted over the virtual tunnel. The metadata includes at least one of: (i) the wireless frequency (also referred to as wireless frequency band) (e.g., 2.4 GHz, 5 GHz, etc.) over which the NTDU was transmitted from the client to the WAP; (ii) the wireless channel (i.e., the portion of the wireless frequency band) over which the NTDU was transmitted from the client to the WAP; (iii) the wireless frequency (also referred to as wireless frequency band, e.g., 4 GHz, 5 GHz, etc.) over which the NTDU was transmitted from the client to the WAP; (ii) the wireless channel (i.e.,(iii) the portion of the wireless frequency band over which the NTDU was transmitted from the client to the WAP; and (iii) a service set identifier (SSID) of the wireless network over which the NTDU was transmitted from the client to the WAP. The metadata may include, but is not limited to, (iv) client vendor / brand, (v) client device type, (vi) current operating system version running on the client, (vii) authentication state (e.g., authenticated or unauthenticated) of the client, and / or (viii) authentication method implemented on the client.

[0044] Continuation of the explanation of Fig. 2: In step 204, if the NTDU is to be transmitted to a network device via a virtual tunnel, the NTDU is encapsulated and transmitted from the WAP's VEP to a VEP of the network device via the identified virtual tunnel. Although in Fig. If 2 is not shown, the NTDU will be transferred to a local device (with or without VLAN tag) if it is to be transferred to the local device.

[0045] Fig. Figure 3 shows a method for processing NTDUs by a network device according to one or more embodiments of the invention. The Fig. The 3 methods shown can be performed by any network device upon receiving an encapsulated NTDU via a virtual tunnel originating from a WAP.

[0046] With reference to Fig. In step 300, the encapsulated NTDU is received by the network device via the virtual tunnel from the WAP.

[0047] In step 302, the encapsulated NTDU will be decapsulated to obtain the NTDU.

[0048] Step 304 determines whether the NTDU should be routed or bridged. This determination can be made based on the content of at least one section of the NTDU header. For example, if the NTDU is a frame, the determination in step 304 can be based on an analysis of the NTDU's destination media access control (MAC) address. If, based on the analysis, the NTDU must be routed (e.g., because the NTDU's destination is in a different L2 domain than the L2 domain of the network device that received the NTDU), the process proceeds to step 310; otherwise, the NTDU must be bridged (e.g., because the NTDU's destination is in the same L2 domain as the network device that received the NTDU), and the process proceeds to step 306.

[0049] While the NTDU is being bridged, the NTDU target can be connected to a locally connected network device or a remotely connected network device that is in the same domain. Accordingly, step 306 determines whether the NTDU target is reachable via a locally connected network device. If the NTDU target is reachable via a locally connected network device, the process proceeds to step 308; otherwise, the process proceeds to step 310.

[0050] In one or more embodiments, the aforementioned provision must be made for bridging scenarios because the network device receiving the NTDU from the WAP may not be locally connected to the NTDU destination. In other words, while the WAP uses encapsulation to transmit the NTDU to the network device, it does so using a virtual tunnel preconfigured to deliver the NTDU to a preconfigured network device, regardless of the NTDU's destination. As a result, and unlike other encapsulation schemes (e.g., VXLAN, GRE), the NTDU does not reach the network device that is locally connected to the NTDU destination. Consequently, and again unlike other encapsulation schemes (e.g., VXLAN, GRE), the network device may need to re-encapsulate the NTDU for transmission within the same Layer 2 domain.

[0051] In step 308, the network device bridges the NTDU towards the NTDU destination. In one embodiment of the invention, the NTDU is bridged to a locally connected network device without a VLAN tag. In another embodiment of the invention, the NTDU is bridged to a locally connected computing device as soon as a VLAN tag is added to the NTDU.

[0052] Returning to step 304: If the NTDU needs to be routed or bridged to a non-locally connected network device, step 310 processes the NTDU to obtain an encapsulated NTDU. However, the processing and encapsulation of the NTDU varies depending on whether the NTDU is to be routed or bridged.

[0053] If the NTDU is to be routed, its header is used to route it to the appropriate domain. For example, the destination IP address in the NTDU is used to determine where the NTDU should be routed. The contents of the encapsulated NTDU are then generated based on this route. For instance, if the encapsulation is performed according to the VXLAN protocol, the encapsulated NTDU header might include a VNI for the domain where the NTDU destination resides, as well as the VTEP IP address of a VTEP within that Layer 2 domain.

[0054] However, if the NTDU is to be bridged, a lookup is performed to identify the destination VEP (e.g., a destination VTEP) on a network device from which the NTDU can be bridged locally to the NTDU destination. Unlike the routing scenario, the destination VEP is in the same Layer 2 domain as the source VEP (i.e., the VEP on the network device that initially received the NTDU from the WAP). Based on the result of the lookup, the contents of the encapsulated NTDU are then generated. For example, if the encapsulation is performed according to the VXLAN protocol, the header of the encapsulated NTDU might include a VNI of the current Layer 2 domain as well as the VTEP IP address of the aforementioned destination VTEP.

[0055] In step 312, the encapsulated NTDU created in step 310 is transferred towards the NTDU target. Example

[0056] Fig. Figures 4A-4C show an example according to one or more embodiments of the invention.

[0057] With reference to Fig. 4A We consider a scenario for processing NTDUs in which a client device (400) communicates with a WAP (402) via a wireless transmission medium. The WAP (402) is functionally connected to a network device A (406) and a local device (404). The network device A (406) is functionally connected to a network device C (410).

[0058] The following describes a scenario for the transmission and processing of NTDUs in the aforementioned system.

[0059] Referring to the example, (1) the WAP (402) receives the NTDU from a client device (400).

[0060] (2) According to Fig. 2. The WAP (402) identifies the virtual tunnel for processing the NTDU using at least one section of the NTDU header.

[0061] (3) The NTDU will be encapsulated and the encapsulated NTDU will be sent via the virtual tunnel to VEP A of the network device A (406).

[0062] (4) According to Fig. 3. Network device A (406) receives the encapsulated NTDU and decapsulates it to obtain the NTDU. The NTDU header is then parsed to determine the NTDU's destination. Network device A (406) determines that the NTDU's destination can be reached by locally bridging the NTDU.

[0063] (5) Network device A (406) bridges the unencapsulated NTDU to network device C (410).

[0064] (6) Network device C (410) bridges the non-encapsulated NTDU to computing device A (412), which in this scenario is the NTDU destination.

[0065] With reference to Fig. Section 4B describes another scenario for the transmission and processing of NTDUs in the aforementioned system.

[0066] (7) The WAP (402) receives the NTDU from a client device (400).

[0067] (8) According to Fig. 2. The WAP (402) identifies the virtual tunnel for processing the NTDU using at least one section of the NTDU header.

[0068] (9) The NTDU will be encapsulated and the encapsulated NTDU will be sent via the virtual tunnel VEP A of the network device A (406).

[0069] (10) According to Fig. 3. Network device A (406) receives the encapsulated NTDU and decapsulates it to obtain the NTDU. The NTDU header is then parsed to determine the NTDU's destination. Network device A (406) determines that the NTDU's destination can be reached by bridging the NTDU. However, the NTDU's destination cannot be reached by local bridging, and therefore the NTDU must be encapsulated and bridged to another network device in the same Layer 2 domain (e.g., network device B (408) in this scenario).

[0070] (11) Network device A (406) transmits the encapsulated NTDU from VEP A to VEP B of network device B (408).

[0071] (12) Network device B (408) decapsulated the encapsulated NTDU to obtain the NTDU.

[0072] (14) The unencapsulated NTDU is then bridged to the NTDU destination, which in this example is the computing device B (414).

[0073] With reference to Fig. Section 4C below describes another scenario for the transmission and processing of NTDUs in the aforementioned system.

[0074] (14) The WAP (402) receives the NTDU from a client device (400).

[0075] (15) The WAP (402) determines, based on an analysis of the NTDU header, that the NTDU target can be accessed from the WAP via a local bridge.

[0076] (16) The WAP (402) transmits the NTDU to the local device (404). End of example

[0077] While various embodiments of the invention have been described relating to NTDUs originating from the client device and being transmitted to an NTDU destination, embodiments of the invention can also be used to transmit NTDUs originating from a computing device (which may be a local device) to the client devices. In the latter scenario, the NTDU originating from the computing device would travel along the same path (but in reverse order) as the NTDU originating from the client device that was destined for the computing device. For example, with reference to Fig.4A An NTDU originating from client device A (412) is transferred (without encapsulation) to network device C (410) and then to network device A (406). Network device A (406) would analyze at least one section of the NTDU header and, based on this analysis, select a virtual tunnel, the virtual tunnel target being preconfigured to WAP (402). Network device A (406) would then encapsulate the NTDU and transfer the encapsulated NTDU to WAP (402). WAP (402) would decapsulate the encapsulated NTDU and then transmit the NTDU to client (400) via the wireless transmission medium and a suitable wireless transmission protocol. The scope of the invention is limited only by the appended claims. QUOTES INCLUDED IN THE DESCRIPTION

[0000] This list of documents cited by the applicant was automatically generated and is included solely for the reader's convenience. The list is not part of the German patent or utility model application. The DPMA accepts no liability for any errors or omissions. Cited patent literature

[0000] US 1,0298,717 B2

[0003] US 9,240,898 B1

[0004] US 2017 / 019428 A1

[0005] Cited non-patent literature

[0000] VXLAN Pseudowires”, September 27, 2016, pages 1-4, Santa Clara, USA, reveals “The Arista VXLAN Pseudowire Solution

[0006]

Claims

[1] System encompassing: a network device; and comprising a wireless access point (WAP): a processor; an antenna; a physical network interface; and a memory comprising a computer-readable program code which, when executed by the processor, causes the WAP to: Receiving a Network Traffic Data Unit (NTDU) from a client device; Identifying a virtual tunnel through which the NTDU is to be transported, based on an NTDU header according to a policy, wherein the policy maps a section of the header to one or a plurality of available virtual tunnels; and Transmitted, via the virtual tunnel, the NTDU to the network device, wherein the header section includes a source IP address, and wherein the policy maps source IP addresses within a first range to a first virtual tunnel of the available virtual tunnels and maps source IP addresses within a second range to a second virtual tunnel of the available virtual tunnels. [2] System according to claim 1, wherein the guideline is implemented using a lookup table. [3] System according to claim 1, wherein the computer-readable program code further causes the WAP to: Establishing a second virtual tunnel between the WAP and a second network device, wherein the network device is associated with a layer 2 domain, wherein the second network device is associated with a second layer 2 domain, and wherein the established second virtual tunnel is one of the plurality of available virtual tunnels. [4] System according to claim 1, wherein the virtual tunnel is implemented as a virtual expandable local area network (VXLAN) pseudowire. [5] System according to claim 1, wherein the virtual tunnel is a virtual extensible local area network (VXLAN) tunnel. [6] System according to claim 1, wherein the plurality of available virtual tunnels comprises one or more preconfigured virtual tunnels that connect the WAP to a plurality of network devices. [7] Wireless Access Point (WAP) encompassing: a processor; an antenna; a physical network interface; and a memory containing computer-readable program code which, when executed by the processor, causes the WAP to: Receiving a Network Traffic Data Unit (NTDU) from a client device; Identifying a virtual tunnel through which the NTDU is to be transported, based on an NTDU header according to a policy, wherein the policy maps a section of the header to one or a plurality of available virtual tunnels; and Transmitted, via the virtual tunnel, the NTDU to a network device, wherein the header section includes a source IP address, and wherein the policy maps source IP addresses within a first range to a first virtual tunnel of the available virtual tunnels and maps source IP addresses within a second range to a second virtual tunnel of the available virtual tunnels. [8] WAP according to claim 7, wherein the guideline is implemented using a lookup table. [9] WAP according to claim 7, wherein the computer-readable program code further causes the WAP to: Establishing a second virtual tunnel between the WAP and a second network device, wherein the network device is associated with a layer 2 domain, wherein the second network device is associated with a second layer 2 domain, and wherein the established second virtual tunnel is one of the plurality of available virtual tunnels. [10] WAP according to claim 7, wherein the virtual tunnel is implemented as a virtual expandable local area network (VXLAN) pseudowire. [11] WAP according to claim 7, wherein the virtual tunnel is a virtual extensible local area network (VXLAN) tunnel. [12] WAP according to claim 7, wherein the plurality of available virtual tunnels comprises one or more preconfigured virtual tunnels that connect the WAP to a plurality of network devices. [13] System encompassing: a network device; and comprising a wireless access point (WAP): a processor; an antenna; a physical network interface; and a memory comprising a computer-readable program code which, when executed by the processor, causes the WAP to: Receiving a Network Traffic Data Unit (NTDU) from a client device; Identifying a virtual tunnel through which the NTDU is to be transported, based on an NTDU header according to a policy, wherein the virtual tunnel is associated with the network device; and Transmitted, via the virtual tunnel, the NTDU to the network device, comprising identifying the virtual tunnel, using metadata associated with the NTDU, and comprising at least one of a client vendor / brand, a client device type, a current operating system version running on the client device, a client device authentication state status, and an authentication method implemented on the client device. [14] System according to claim 13, wherein the policy is implemented using a lookup table stored in the memory. [15] System according to claim 13, wherein the policy assigns a section of the header to the plurality of available virtual tunnels, the section of the header comprising a source IP address, and wherein the policy assigns source IP addresses within a first range to a first virtual tunnel of the available virtual tunnels and assigns source IP addresses within a second range to a second virtual tunnel of the available virtual tunnels. [16] System according to claim 13, further comprising a second network device, wherein the computer-readable program code further causes the WAP to: Establishing a second virtual tunnel between the WAP and the second network device, wherein the network device is associated with a layer 2 domain, wherein the second network device is associated with a second layer 2 domain, and wherein the established second virtual tunnel is one of the plurality of available virtual tunnels. [17] System according to claim 13, wherein the virtual tunnel is a virtual extensible local area network (VXLAN) tunnel [18] System according to claim 13, wherein the virtual tunnel is implemented as a virtual expandable local area network (VXLAN) pseudowire. [19] System according to claim 13, wherein identifying a virtual tunnel over which the NTDU is to be transmitted comprises: Selecting a virtual tunnel from a variety of pre-configured virtual tunnels that connect the WAP to a variety of network devices. [20] System according to claim 13, wherein the computer-readable program code further causes the WAP to: Encapsulation of the NTDU using an encapsulation protocol. [21] Wireless Access Point (WAP) comprising: a processor; an antenna; a physical network interface; and a memory containing computer-readable program code which, when executed by the processor, causes the WAP to: Receiving a Network Traffic Data Unit (NTDU) from a client device; Identifying a virtual tunnel through which the NTDU is to be transported, based on an NTDU header according to a policy, wherein the virtual tunnel is associated with a network device; and Transmitted, via the virtual tunnel, the NTDU to a network device, comprising identifying the virtual tunnel, using metadata associated with the NTDU, and comprising at least one of a client vendor / brand, a client device type, a current operating system version running on the client device, a client device authentication state status, and an authentication method implemented on the client device. [22] WAP according to claim 21, wherein the policy is implemented using a lookup table stored in the memory. [23] WAP according to claim 21, wherein the policy assigns a section of the header to the plurality of available virtual tunnels, the section of the header comprising a source IP address, and wherein the policy assigns source IP addresses within a first range to a first virtual tunnel of the available virtual tunnels and assigns source IP addresses within a second range to a second virtual tunnel of the available virtual tunnels. [24] WAP according to claim 21, wherein the computer-readable program code further causes the WAP to: Establishing a second virtual tunnel between the WAP and a second network device, wherein the network device is associated with a layer 2 domain, wherein the second network device is associated with a second layer 2 domain, and wherein the established second virtual tunnel is one of the plurality of available virtual tunnels. [25] WAP according to claim 21, wherein the virtual tunnel is a virtual extensible local area network (VXLAN) tunnel [26] WAP according to claim 21, wherein the virtual tunnel is implemented as a virtual expandable local area network (VXLAN) pseudowire. [27] WAP according to claim 21, wherein identifying a virtual tunnel over which the NTDU is to be transmitted comprises: Selecting a virtual tunnel from a variety of pre-configured virtual tunnels that connect the WAP to a variety of network devices. [28] WAP according to claim 21, wherein the computer-readable program code further causes the WAP to: Encapsulation of the NTDU using an encapsulation protocol.

Images