Media access control address learning for packets

Certain embodiments described herein are generally directed to media access control (MAC) address learning for packets sent between end points (EPs) in a network (e.g., overlay network). For example, in some embodiments, VTEPs may be used to provide packet forwarding services, load balancing services, gateway services, etc., to EPs in the network. In certain embodiments, the VTEPs may be assigned unique labels, which are used by the VTEPs to map MAC addresses of packets to destination addresses for the packets.

BACKGROUND

In some aspects, physical machines may be connected into an overlay network (e.g., logical network). For example, a data center operator may run certain services (e.g., file server, database server, etc.) on a specific physical machine (e.g., physical servers) instead of in a virtual machine (VM) that is part of the overlay network, but still want to connect the physical machine into the overlay network to gain the benefits of a software defined networking (SDN) solution. In order to couple the physical machines to the overlay network, specialized hardware switches may be implemented in the network to bridge packets between the physical machine's network and the overlay network. These hardware switches, in some embodiments, may be referred to as hardware VTEPs, which stands for “VXLAN tunnel endpoints.” It should be noted, though, that the term “VTEP” is now used regardless of the tunneling protocol and sometimes as a backronym of “virtual tunnel endpoint,” which can be confusing because the tunnel is not actually “virtual.”

SUMMARY

Herein described are one or more embodiments of a method for performing media access control learning. The method includes receiving, at a destination VTEP, an encapsulated packet. The encapsulated packet includes a source address associated with an intermediate VTEP, a destination address associated with the destination VTEP, and a first label associated with a source VTEP. The encapsulated packet further includes an inner packet. The inner packet includes a source media access control address of a source endpoint. The method further includes receiving, at the destination VTEP, information indicative of a plurality of labels and associated addresses of VTEPs. The method further includes determining, by the destination VTEP, a first address associated with the source VTEP based on the first label and the information indicative of the plurality of labels and associated addresses of VTEPs. The method further includes mapping the first address of the source VTEP to the source media access control address of the source endpoint.

Also described herein are embodiments of a non-transitory computer readable medium comprising instructions to be executed in a computer system, wherein the instructions when executed in the computer system perform a method described above for performing media access control learning.

Also described herein are embodiments of a computer system, wherein software for the computer system is programmed to execute the method described above for performing media access control learning.

DETAILED DESCRIPTION

Embodiments presented herein relate to media access control (MAC) address learning for packets sent between end points in a network (e.g., overlay network). For example, in some embodiments, VTEP services may be implemented at an edge or at a gateway. Edge VTEPs are generally connected to virtual switches implemented by the hypervisor for VMs on the same physical host. Hardware VTEPs are often integrated into top-of-rack (TOR) switches, but could be provided as a stand-alone appliance for bridging logical overlay networks with physical networks. In certain embodiments, the edge VTEPs may be assigned unique labels, which may be used by the VTEPs to map MAC addresses of packets to destination IP addresses for the packets as further described below.

FIG. 1is a block diagram of a network100in which one or more embodiments of the present invention may be implemented. It should be understood that network100may include additional and/or alternative components than that shown, depending on the desired implementation. Network100includes one or more end points (EPs)102. An EP (e.g., EP102) may refer generally to an originating node (“source endpoint”) or terminating node (“destination endpoint”) of a flow of network packets, which can comprise one or more network packets being passed from the source to the destination endpoint. In practice, an endpoint may be a physical computing device (e.g., physical server, physical host), virtualized computing instance (e.g., virtual machine, container, data compute node, isolated user space instance) supported by a physical computing device, etc. For example, EP102ais a physical computing device. Further, each of EPs102b-102dis a virtualized computing instance, i.e., a virtual machine, container (such as a Docker container), or other logical compute node.

Network100further includes one or more VTEPs104that provide one or more of packet forwarding services, load balancing services, gateway services, etc., to EPs102. VTEPs104may be implemented by or executed on physical devices. For example, VTEP104amay be a hardware VTEP (e.g., integrated with a hardware switch such as a top-of-rack (ToR) switch). Further, VTEPs104b-104dmay be implemented by a hypervisor (e.g., a virtual switch of the hypervisor) running on a host, which is a physical computing device that supports execution of virtual machines or other virtualized computing instances. One or more VTEPs104b-104dand EPs102b-102dmay reside on the same physical computing device, or on different computing devices.

As discussed, VTEPs104may provide connectivity between associated EPs102. For example, as shown, VTEPs104a-104dare associated with EPs102a-102d,respectively. VTEPs104may provide connectivity between each other, to provide connectivity between associated EPs102. To provide connectivity between VTEPs104, a “tunnel” (not shown for simplicity) may be established between the pair of VTEPs using a suitable protocol (e.g., Stateless Transport Tunneling (STT), Virtual eXtension Local Area Network (VXLAN), Network Virtualization Generic Routing Protocol (NVGRE), Geneve, etc.). The term “tunnel” may generally refer to encapsulated communication between a pair of VTEPs. For example, before forwarding data packets from EP102b,VTEP104bperforms encapsulation to generate encapsulated packets. The original data packet in the encapsulated packet may be referred to as the inner packet. Encapsulating the packet may include adding certain header information to the packet, such as addresses of the source VTEP and destination VTEP for the encapsulated packet. The originating VTEP (e.g., associated with the source EP) that sends a packet may be referred to as a source VTEP. The terminating VTEP (e.g., associated with the destination endpoint) that receives the packet may be referred to as the destination VTEP.

The term “layer-2” generally refers to a data link layer (e.g., Media Access Control (MAC) or Ethernet layer), “layer-3” to a network layer (e.g., Internet Protocol (IP) layer), and “layer-4” to a transport layer (e.g., Transmission Control Protocol (TCP) layer) in the Open System Interconnection (OSI) model, although the concepts described herein and referred to simply as “MAC” and “IP” may be applicable to corresponding layers in other networking models. The term “packet” may refer generally to a group of bits that can be transported together, and may be in another form, such as “frame”, “message”, “segment”, etc. In some embodiments, the packet may include a payload (e.g., data) and header information, such as a source MAC address corresponding to the MAC address of the EP that generated the packet, a source port corresponding to the port of the EP that generated the packet, a destination MAC address corresponding to the MAC address of the destination EP, a destination port corresponding to the port of the destination EP, and/or a protocol used for the packet.

Hardware VTEP104amay forward data packets from EP102ato another VTEP104. For example, hardware VTEP104amay send a layer-2 packet received from physical endpoint102athrough a tunnel (e.g., VXLAN tunnel) to VTEP104bbased on the destination MAC address in the packet corresponding to EP102b,which is associated with VTEP104b.

In particular, EP102amay generate a packet (e.g., unicast packet) to send to EP102b(e.g., an application running on EP102b). The packet may include a source MAC address corresponding to the MAC address of EP102a,and a destination MAC address corresponding to the MAC address of EP102b.For example, the packet may include a destination MAC address corresponding to the MAC address of EP102bwhen both EP102aand EP102bare connected to the same logical switch. However, in some embodiments, there may be a logical router interposed between the endpoints, and the destination MAC address may then correspond with the logical router rather than EP102b.The destination layer 3 (IP) address of the packet may still correspond to the destination EP102b.EP102a,which is a physical system, may send the packet to the top-of-rack switch which may act as or include VTEP104a.VTEP104atherefore acts as a source VTEP for the packet sent from EP102a.VTEP104athen determines if it has (e.g., stored in local memory accessible by the VTEP) a mapping of the destination MAC address indicated in the packet to a destination layer-3 address (i.e., an IP address) of a destination VTEP104. If VTEP104ahas the mapping of the destination MAC address of EP102bto the destination IP address of VTEP104b,VTEP104aencapsulates the packet with an outer packet header (e.g., according to VXLAN tunneling protocol) and sets a destination IP address of the outer header in the encapsulated packet to the IP address of the VTEP104b,and the source IP address in the outer header of the packet as that of VTEP104a.VTEP104athen sends the encapsulated packet to VTEP104b.

If VTEP104acannot map the destination MAC address of the packet received from endpoint102ato a destination VTEP or the packet is not a unicast packet (i.e., if the packet is a broadcast, unknown unicast, or multicast (BUM) packet), VTEP104aencapsulates the packet and sets a destination IP address of the encapsulated packet as that of intermediate VTEP106, and the source address in the encapsulated packet as that of VTEP104a.In particular, VTEP104amay not have the capability to determine the mapping of a destination MAC address to a destination VTEP that it does not already have the mapping for, and further may not have the capability to directly forward broadcast and multicast packets to the appropriate destination.

Intermediate VTEP106is a specialized VTEP, which may be implemented as a virtual appliance, i.e., as a service implemented on a virtual machine. In one embodiment, intermediate VTEP106may be configured to receive encapsulated BUM packets from a source VTEP such as hardware VTEP104aand process BUM packets to identify the appropriate destination VTEP. For example, the VTEP106may be configured to extract the inner packet (original packet) from the encapsulated packet and determine the destination MAC address for the inner packet. The VTEP106then determines if it has a mapping of the destination MAC address indicated in the inner packet to destination IP address of the destination VTEP associated with destination MAC address. For any destination MAC address that intermediate VTEP106does have a mapping, VTEP106encapsulates the packet (e.g., VxSTT packet, Geneve packet, VXLAN packet, etc.) and sets a destination IP address in the outer header of the encapsulated packet as that of the destination VTEP, and the source IP address in the outer header of the encapsulated packet as the IP address of intermediate VTEP106. Intermediate VTEP106then sends the encapsulated packet to the destination VTEP.

For any destination MAC address that intermediate VTEP106does not have a mapping, the VTEP106may query such information from one or more other devices such as a central control plane of the network100, which may also be referred to as an SDN controller cluster as described in more detail below with reference toFIG. 2. Alternatively, intermediate VTEP106may perform a flooding procedure, whereby the VTEP106replicates the packet and sends it to a set of destinations (e.g., all VTEPs that participate in the logical layer-2 network of endpoint102a,as indicated in a flood list, etc.). In this case, intermediate VTEP106encapsulates each of the replicated inner packets so that the outer packet header includes a source IP address of intermediate VTEP106. Further, each encapsulated packet includes a destination IP address of the VTEP the encapsulated replicated packet is sent to. The receiving VTEPs may determine if the destination MAC address of the inner packet is associated with that VTEP. In other words, if the VTEP receiving a replicated packet from intermediate VTEP106is associated with an endpoint that matches the destination MAC address of the inner packet, then it forwards the inner packet to the destination endpoint. Otherwise, the VTEP simply drops the received replicated packet.

In some embodiments, VTEPs104and106may be configured to learn mappings between inner packet source MAC addresses of a received encapsulated packet and the IP address of the associated source VTEP in the outer header of the received encapsulated packet and store the mappings (e.g., in local memory accessible by the VTEP) based on received packets by a process referred to as “MAC learning.” The VTEP may utilize this information for forwarding future packets in the network100. By performing such MAC learning, the VTEPs can save on processing time and network bandwidth needed for querying necessary information or performing the flooding procedure.

However, if a destination VTEP receives a packet from an intermediate VTEP it may not be able to perform the typical MAC learning procedure. In particular, when the intermediate VTEP re-encapsulates the inner packet, it uses its own IP address as the source IP address in the outer header instead of the IP address of the source VTEP. However, the inner header of the encapsulated packet still includes the source MAC address corresponding to the source endpoint. Accordingly, a destination VTEP trying to perform MAC learning on such a packet would associate the wrong IP address—the IP address of the intermediate VTEP106with the MAC address of the source EP instead of the source VTEP which is associated with the source EP. In some embodiments, to prevent a destination VTEP from learning such an incorrect mapping, the intermediate VTEP includes a flag in the outer packet header sent to a destination VTEP104athat instructs the destination VTEP not to perform MAC learning for that packet.

Accordingly, embodiments herein provide techniques for performing MAC learning even for packets sent via an intermediate VTEP. For example, such techniques may be used for performing MAC learning for networks including VTEPs (e.g., hardware VTEPs) that do not support advanced and extensible protocols. Accordingly, such VTEPs in the network can learn associations between source MAC addresses of an inner packet and the IP address of its associated VTEP, which can save on processing time and network bandwidth needed for querying necessary information or performing a flooding procedure, as previously described.

In some embodiments, each VTEP is assigned a unique identifier, which may be referred to as a VTEP label. In one embodiment, the VTEP label may be a 24-bit unsigned number. Each VTEP, whether it is a hardware VTEP or a hypervisor-based VTEP, is assigned a VTEP label. The VTEPs may then receive information mapping VTEP labels to corresponding IP addresses of the VTEPs.

An intermediate VTEP may be configured to include the VTEP label of the source VTEP in an encapsulated packet sent to a destination VTEP. The destination VTEP can utilize the VTEP label of the source VTEP to identify the IP address of the source VTEP and map that IP address to the source MAC address in the packet. Accordingly, the destination VTEP can perform MAC learning even on a packet received from an intermediate VTEP.

FIG. 2is a block diagram of a network control system200for the network100ofFIG. 1. Specifically, as shown, the network control system200includes a management plane205, a central control plane210, and a data plane220. The EPs102and VTEPs104and106of the network100, as shown, are implemented as part of the data plane220.

Though shown as single entities, it should be understood that both the management plane205and central control plane210may be implemented as distributed or clustered systems. That is, management plane205may include multiple computers that implement management plane functions, and central control plane210may include multiple controller computers or virtual machines or containers (or other logical compute instances) that implement central control plane functions. In some embodiments, each such controller includes both management plane and central control plane functions (e.g., as separate applications or functions). Further, the management plane functions and control plane functions may be implemented on the same or different computers as VTEPs104b-104dand EPs102b-102d.

In some embodiments, management plane205receives logical network configuration inputs through an application programming interface (API). Users may further input logical network configuration data through an interface, e.g., a command-line interface, a graphical user interface, etc. Further, in some embodiments, management plane205assigns and manages VTEP labels for VTEPs (e.g., VTEPs104and106) in the network100. As previously described, management plane205may generate a unique VTEP label for each VTEP. The management plane205further associates the VTEP label with the IP address of the corresponding VTEP, and optionally, an indication (referred to as a VTEP type) of the types of communication protocols supported by the VTEP (e.g., VXLAN, Geneve, STT, etc.). Management plane205provides the information of the VTEP label, IP address, and VTEP type for each VTEP of network100to control plane210.

Control plane210pushes the information of the VTEP label, IP address, and VTEP type for each VTEP of the network100to each of VTEPs104and106in network100that are not hardware VTEPs. In particular, hardware VTEPs may not be configured to receive, store, or manage such information. It should be noted, in some embodiments, some hardware VTEPs may be configured to receive, store, or manage such information and may receive such information from control plane210and work similar to non-hardware VTEPs discussed herein.

Accordingly, in some embodiments, control plane210includes one or more ToR agents230, that serve as an “adapter” between hardware VTEPs (e.g., hardware VTEP104a) and control plane210. For example, control plane210controllers may communicate utilizing a proprietary protocol, while hardware VTEPs may communication using another protocol (e.g., Open vSwitch database (OVSDB)). ToR agent230may be configured to understand both protocols, and further facilitate control of the hardware VTEPs. Accordingly, for hardware VTEPs controlled by a ToR agent, control plane210pushes the information of the VTEP label, IP address, and VTEP type for each hardware VTEP of the network100to the ToR agent(s)230.

In some embodiments, if a hardware VTEP joins a particular logical switch, ToR agent230maps the hardware VTEP to the assigned VTEP label for the hardware VTEP and reports the VTEP label, IP address, and VTEP type to control plane210. Control plane210may then push updated information of the VTEP label, IP address, and VTEP type for the hardware VTEP to each of VTEPs104and106and/or other ToR agents230in network100. In some embodiments, if a new hypervisor-based VTEP is created, or parameters of a hypervisor-based VTEP change, control plane210may push updated information of the VTEP label, IP address, and VTEP type for each new/updated hypervisor-based VTEP to each of the VTEPs104and106and/or ToR agents230in network100.

In some embodiments, based on the VTEP label, IP address, and VTEP type information shared between the VTEPs, MAC learning is enabled for packets sent via intermediate VTEPs as follows. In some embodiments, when hardware VTEP104ahas a BUM packet to send to EP102b,the hardware VTEP encapsulates the packet into an encapsulated packet (e.g., VXLAN packet) and sets a destination address in the encapsulated packet (i.e., outer packet header) as that of intermediate VTEP106, and the source address in outer packet header as that of the hardware VTEP. The inner packet includes a source MAC address of the EP102a,and a destination MAC address of the destination EP102b.

Upon receiving the encapsulated packet, the intermediate VTEP106determines the source IP address of the encapsulated packet, that being the IP address of the hardware VTEP104a.The VTEP106then determines the VTEP label associated with the source VTEP104a,based on the source IP address included in the outer header. Intermediate VTEP106uses mapping information associating VTEP label, IP address, and VTEP type for each VTEP of the network100previously received from the control plane210to determine the VTEP label. Intermediate VTEP106then extracts and re-encapsulates the inner packet, possibly using a different tunneling protocol (e.g., STT or Geneve), which may not be supported by hardware VTEP104a.Intermediate VTEP106includes in the outer header of the re-encapsulated packet the source IP address of intermediate VTEP106and the destination IP address of the destination VTEP104bbased on the destination MAC address of EP102bin the inner packet. In addition, the intermediate VTEP106includes the VTEP label for the VTEP104ain the encapsulated packet as corresponding to the actual source IP of the original outer header of the received packet.

Destination VTEP104bthen receives the re-encapsulated packet from the intermediate VTEP106. Since the outer packet header includes the VTEP label for the source VTEP104a,the VTEP104bcan determine the IP address of the hardware VTEP104aby mapping the source VTEP's label to its IP address. The destination VTEP104bmay then perform MAC learning by associating the source MAC address of the inner packet to the IP address of the source VTEP104aand recording this association in its table so that when endpoint102bsends a packet back to endpoint102a,VTEP104bcan use that recorded association to immediately encapsulate that packet with an outer header directed to VTEP104awithout querying control plane210or utilizing intermediate VTEP106. More particularly, VTEP104bmay store a mapping (e.g., in a local memory accessible by VTEP104b) of the source MAC address to the IP address of the source VTEP. VTEP104bmay further utilize the stored mapping to directly send packets for the EP102ato hardware VTEP104a,without having to query the control plane210or perform a flooding procedure. Accordingly, based on the VTEP label information included in the encapsulated packet by an intermediate VTEP, a destination VTEP can perform MAC learning of packets sent by a source VTEP.

FIG. 3is an example of a signal flow diagram300for performing MAC learning for BUM packets from hardware VTEPs. At305, control plane210sends information of the VTEP label, IP address, and VTEP type for each VTEP of the network100to ToR Agent230, intermediate VTEP106, and VTEP104b.

Hardware VTEP104a,acting as a source VTEP, receives a BUM packet to send (e.g., from EP102ashown inFIG. 2). The BUM packet may include a source MAC address of the source EP (e.g., EP102a), the source port, the destination MAC address of the destination EP (e.g., EP102b), and a protocol type. Hardware VTEP104a,at310, encapsulates the BUM packet and sends the encapsulated packet to intermediate VTEP106. Hardware VTEP104aincludes in the outer header of the encapsulated packet a source address corresponding to the IP address of hardware VTEP104a,and a destination address corresponding to the IP address of intermediate VTEP106because, for example, hardware VTEP104ais programmed to send BUM packets by default to intermediate VTEP106.

Intermediate VTEP106receives the encapsulated packet and determines the IP address of the source VTEP, i.e., the IP address of hardware VTEP104a,for the encapsulated packet based on the outer header information of the encapsulated packet. Intermediate VTEP106further identifies the VTEP label associated with the source VTEP for the encapsulated packet by matching the determined IP address of the hardware VTEP104ato the corresponding VTEP label based on the information received from the control plane210in operation305. Intermediate VTEP106further determines a destination VTEP for the encapsulated packet based on the destination MAC address included in the inner packet header. For example, intermediate VTEP106may already have stored a mapping of the destination MAC address included in the inner packet to an IP address of an associated VTEP. Otherwise, for example, at315, intermediate VTEP106may send a message to query control plane210(or performs a flooding procedure (not shown)) for the VTEP associated with the destination MAC address of EP102b.At320, control plane210may send a message to intermediate VTEP106indicating that VTEP104bis associated with the destination MAC address of EP102band including the IP address of the VTEP104b.

At325, intermediate VTEP106extracts and re-encapsulates the inner packet from the encapsulated packet received at310, and sends the encapsulated packet to VTEP104b.Intermediate VTEP106includes in the outer header of the re-encapsulated packet a source address corresponding to the IP address of the intermediate VTEP106, a destination address corresponding to the IP address of destination VTEP104b,and a label associated with source hardware VTEP104a.

VTEP104breceives the re-encapsulated packet from intermediate VTEP106and performs MAC learning by associating the source MAC address of EP102aincluded in the header of the inner packet to the VTEP label of hardware VTEP104aincluded in the outer header of the encapsulated packet. VTEP104bmay store the mapping of the source MAC address to the IP address of source VTEP104ato directly send packets for EP102ato hardware VTEP104a.

For example, VTEP104bacting as a source VTEP, receives a packet from EP102b(shown inFIG. 2). The packet may include a source MAC address of EP102b,the source port, the destination MAC address of EP102a,and a protocol type. VTEP104bdetermines it has a mapping of the MAC address of EP102ato the VTEP label or IP address of VTEP104a.VTEP104bmay match the VTEP label of VTEP104ato the IP address of VTEP104abased on the information received from the control plane210in operation305. This step is unnecessary if the VTEP stores a mapping of the source MAC address of the EP to the IP address of the corresponding VTEP instead of to the VTEP label of the corresponding VTEP.

VTEP104b,at330, encapsulates the packet and sends the encapsulated packet to the hardware VTEP104a.The VTEP104bincludes in the outer header of the encapsulated packet a source address corresponding to the IP address of the VTEP104b,and a destination address corresponding to the IP address of the hardware VTEP104a.

FIG. 4illustrates example operations for performing MAC learning for BUM packets from hardware VTEP.

At410, a destination VTEP receives an encapsulated packet. The encapsulated packet includes a source IP address associated with an intermediate VTEP, a destination IP address associated with the destination VTEP, and a first label associated with a source VTEP. The encapsulated packet further includes an inner packet. The inner packet includes a source media access control address of a source endpoint.

At420, the destination VTEP receives information indicative of a plurality of labels and associated addresses of VTEPs. The destination VTEP may receive this information from the control plane. It should be noted that this operation may precede operation410, or it may query the control plane in response to receiving the encapsulated packet with an unknown source VTEP label.

At430, the destination VTEP determines a first address associated with the source VTEP based on the first label and the information indicative of the plurality of labels and associated addresses of VTEPs.

At440, the destination VTEP maps the first address of the source VTEP to the source media access control address of the source endpoint. Accordingly, the destination VTEP performs MAC learning for the encapsulated packet received from the intermediate VTEP.

FIG. 5illustrates an example of an electronic system500with which some embodiments of the invention are implemented. The electronic system500can be used to execute any of the control, virtualization, or operating system applications described above. The electronic system500may be a computer (e.g., a desktop computer, personal computer, tablet computer, server computer, mainframe, a blade computer etc.), phone, PDA, or any other sort of electronic device. Such an electronic system includes various types of computer readable media and interfaces for various other types of computer readable media. Electronic system500includes a bus505, processing unit(s)510, a system memory525, a read-only memory530, a permanent storage device535, input devices540, and output devices545.

The bus505collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system500. For instance, the bus505communicatively connects the processing unit(s)510with the read-only memory530, the system memory525, and the permanent storage device535.

The read-only-memory (ROM)530stores static data and instructions that are needed by the processing unit(s)510and other modules of the electronic system. The permanent storage device535, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system500is off. Some embodiments of the invention use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as the permanent storage device535.

Other embodiments use a removable storage device (such as a floppy disk, flash drive, etc.) as the permanent storage device. Like the permanent storage device535, the system memory525is a read-and-write memory device. However, unlike storage device535, the system memory is a volatile read-and-write memory, such a random access memory. The system memory stores some of the instructions and data that the processor needs at runtime. In some embodiments, the invention's processes are stored in the system memory525, the permanent storage device535, and/or the read-only memory530. From these various memory units, the processing unit(s)510retrieve instructions to execute and data to process in order to execute the processes of some embodiments.

The bus505also connects to the input and output devices540and545. The input devices enable the user to communicate information and select commands to the electronic system. The input devices540include alphanumeric keyboards and pointing devices (also called “cursor control devices”). The output devices545display images generated by the electronic system. The output devices include printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some embodiments include devices such as a touchscreen that function as both input and output devices.

Finally, as shown inFIG. 5, bus505also couples electronic system500to a network565through a network adapter (not shown). In this manner, the computer can be a part of a network of computers (such as a local area network (“LAN”), a wide area network (“WAN”), or an Intranet, or a network of networks, such as the Internet. Any or all components of electronic system500may be used in conjunction with the invention.