Packet handling in software-defined net working (SDN) environments

Example methods and systems for packet handling in a software-defined networking (SDN) environment are disclosed. One example method may comprise detecting an egress application-layer message from a first logical endpoint supported by a first host; and identifying a second logical endpoint supported by the second host for which the egress application-layer message is destined. The method may also comprise generating an egress packet that includes the egress application-layer message and metadata associated with the second logical endpoint, but omits one or more headers that are addressed from the first logical endpoint to the second logical endpoint. The method may further comprise sending the egress packet to the second host to cause the second host to identify the second logical endpoint based on the metadata, and to send the egress application-layer message to the second logical endpoint.

CROSS-REFERENCE TO RELATED APPLICATION

The present application U.S. Patent application Ser. No. 16/538,855) claims the benefit under 35 U.S.C. § 119(a) of Patent Cooperation Treaty (PCT) Application No. PCT/CN2019/090578, filed Jun. 10, 2019, which is incorporated herein by reference.

BACKGROUND

Virtualization allows the abstraction and pooling of hardware resources to support virtual machines in a software-defined networking (SDN) environment, such as a software-defined data center (SDDC). For example, through server virtualization, virtual machines (VMs) running different operating systems may be supported by the same physical machine (also referred to as a “host”). Each virtual machine is generally provisioned with virtual resources to run an operating system and applications. The virtual resources may include central processing unit (CPU) resources, memory resources, storage resources, network resources, etc. In practice, multiple protocol layers are implemented in the SDN environment to facilitate packet communication among logical endpoints such as VMs. However, as network protocol stacks become thicker and more complicated, the additional complexity may affect performance.

DETAILED DESCRIPTION

Challenges relating to packet handling will now be explained in more detail usingFIG.1, which is a schematic diagram illustrating example software-defined networking (SDN) environment100in which packet handling may be performed. It should be understood that, depending on the desired implementation, SDN environment100may include additional and/or alternative components than that shown inFIG.1. SDN environment100includes multiple hosts110A-C that are inter-connected via physical network104. In practice, SDN environment100may include any number of hosts (also known as a “host computers”, “host devices”, “physical servers”, “server systems”, “transport nodes,” etc.), where each host may be supporting tens or hundreds of virtual machines (VMs).

Each host110A/110B/110C may include suitable hardware112A/112B/112C and virtualization software (e.g., hypervisor-A114A, hypervisor-B114B, hypervisor-C114C) to support various VMs131-136. The term “hypervisor” may refer generally to a software layer or component that supports the execution of multiple virtualized computing instances, including system-level software in guest VMs that supports namespace containers such as Docker, etc. Hypervisors114A-C may each implement any suitable virtualization technology, such as VMware ESX® or ESXi™ (available from VMware, Inc.), Kernel-based Virtual Machine (KVM), etc. Hypervisor114A/114B/114C maintains a mapping between underlying hardware112A/112B/112C and virtual resources allocated to respective VMs131-136.

Hardware112A/112B/112C includes suitable physical components, such as central processing unit(s) (CPU(s)) or processor(s)120A/120B/120C; memory122A/122B/122C; physical network interface controllers (NICs)124A/124B/124C; and storage disk(s)126A/126B/126C, etc. Virtual resources are allocated to respective VMs131-136to support respective guest operating systems (OS)151-156and applications141-146(e.g., containerized applications to be discussed below). The virtual resources may include virtual CPU, guest physical memory, virtual disk, virtual network interface controller (VNIC), etc. Hardware resources may be emulated using virtual machine monitors (VMMs). VNICs for VMs131-136may be emulated by corresponding VMMs instantiated by their respective hypervisor at respective hosts110A-C.

Although examples of the present disclosure refer to VMs, it should be understood that a “virtual machine” running on a host is merely one example of a “logical endpoint,” “virtualized computing instance” or “workload.” A virtualized computing instance may represent an addressable data compute node (DCN) or isolated user space instance. In practice, any suitable technology may be used to provide isolated user space instances, not just hardware virtualization. Other virtualized computing instances may include containers (e.g., running within a VM or on top of a host operating system without the need for a hypervisor or separate operating system or implemented as an operating system level virtualization), virtual private servers, client computers, etc. Such container technology is available from, among others, Docker, Inc. The VMs may also be complete computational environments, containing virtual equivalents of the hardware and software components of a physical computing system.

For example, container technologies may be used to run various containers141-146(labelled “C1” to “C6”) inside respective VMs131-136. As used herein, the term “container” (also known as “container instance”) is used generally to describe an application that is encapsulated with all its dependencies (e.g., binaries, libraries, etc.). Containers141-146may be implemented using any suitable container technology, such as Docker (www.docker.com), Linux (http://linuxcontainers.org), etc. Unlike VMs, containers141-146are “OS-less”, meaning that they do not include any OS that could weigh 10s of Gigabytes (GB). This makes containers141-146more lightweight, portable, efficient and suitable for delivery into an isolated OS environment. Running containers inside a VM (known as “containers-on-virtual-machine” approach) not only leverages the benefits of container technologies but also that of virtualization technologies. A particular VM may support multiple containers.

Hypervisor114A/114B/114C further implements virtual switch115A/115B/115C to handle egress packets from, and ingress packets to, corresponding VMs131-136. Packets may be received from, or sent to, each VM via an associated logical port. For example, logical switch ports161-166(see “LP1” to “LP6”) are associated with respective VMs131-136. Here, 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. The term “logical port” or “logical switch port” may refer generally to a port on a logical switch to which a virtualized computing instance is connected. A “logical switch” may refer generally to a software-defined networking (SDN) construct that is collectively implemented by virtual switches115A-C inFIG.1, whereas a “virtual switch” may refer generally to a software switch or software implementation of a physical switch. Logical switches providing logical layer-2 connectivity and logical distributed routers (DRs) providing logical layer-3 connectivity may be implemented in a distributed manner and span multiple hypervisors114A-C on respective hosts110A-C.

Through virtualization of networking services, logical networks (also referred to as overlay networks or logical overlay networks) may be provisioned, changed, stored, deleted and restored programmatically without having to reconfigure the underlying physical hardware architecture. A logical network may be formed using any suitable tunneling protocol, such as Virtual eXtensible Local Area Network (VXLAN), Stateless Transport Tunneling (STT), Generic Network Virtualization Encapsulation (GENEVE), etc. For example, VXLAN is a layer-2 overlay scheme on a layer-3 network that uses tunnel encapsulation to extend layer-2 segments across multiple hosts which may reside on different layer 2 physical networks.

SDN manager180and SDN controller184are example network management entities in SDN environment100. One example of an SDN controller is the NSX controller component of VMware NSX® (available from VMware, Inc.) that operates on a central control plane. SDN controller184may be a member of a controller cluster (not shown for simplicity) that is configurable using SDN manager180operating on a management plane. To send or receive control information, a local control plane (LCP) agent (not shown for simplicity) on host110A/110B/110C may interact with central control plane (CCP) module186at SDN controller184via control-plane channel101/102/103. CCP module186may interact with management plane module182supported by SDN manager182. Network management entity184/180may be implemented using physical machine(s), VM(s), or both.

Hosts110A-C may maintain data-plane connectivity among themselves via physical network104to facilitate communication among VMs located on the same logical overlay network. Hypervisor114A/114B/114C may implement a virtual tunnel endpoint (VTEP) (not shown) to encapsulate and decapsulate packets with an outer header (also known as a tunnel header) identifying the relevant logical overlay network (e.g., using a VXLAN or “virtual” network identifier (VNI) added to a header field). For example inFIG.1, hypervisor-A114A implements a first VTEP associated with (IP address=IP-A, MAC address=MAC-A, VTEP label=VTEP-A), hypervisor-B114B implements a second VTEP with (IP-B, MAC-B, VTEP-B), hypervisor-C114C implements a third VTEP with (IP-C, MAC-C, VTEP-C), etc.

To facilitate data-plane communication among VMs131-136that are connected via logical networks in SDN environment100, packets are generally encapsulated with multiple layers of header information. For example, a hypertext transfer protocol (HTTP) request from VM1131on host-A110A to VM2132on host-B110B may be encapsulated with an inner header and an outer header. To facilitate routing within a logical network domain, the inner header may be addressed from source VM1131and destination VM2132, and include an inner layer-4 header, an inner layer-3 header and an inner layer-2 header. Here, the term “layer-2” or “L2” may refer generally to a link layer or media access control (MAC) layer; “layer-3” or “L3” to a network or Internet Protocol (IP) layer; and “layer-4” or “L4” to a transport layer (e.g., using Transmission Control Protocol (TCP), User Datagram Protocol (UDP), etc.) in the TCP/IP model, although the concepts described herein may be used with other networking models (e.g., Open System Interconnection (OSI) model).

To facilitate routing within a physical network domain, the outer header may be addressed from source host-A110A to destination host-B110B. Depending on the desired implementation, the outer header may include a GENEVE header, an outer UDP header, an outer IP header and an outer MAC header. Using the “multi-layer routing” approach, the HTTP request may be transmitted from host-A110A to host-B110B based on the outer header, and subsequently to VM2132based on the inner and GENEVE headers. As a network stack or protocol suite becomes more complicated, additional protocol layers are built on top of existing ones. In SDN environment100, the implementation of new paradigms, policies or services may require additional protocol layer(s), which potentially increases the size of packet header information and/or packet header processing operations. In various scenarios, the additional complexity may affect performance due to increased resource consumption, such as in terms of CPU, memory and network resources. This may also increase complexity in the management domain and data-plane domain.

Packet Handling Based on Metadata

According to examples of the present disclosure, the complexity associated with thick network protocol stacks may be reduced by omitting some protocol layer(s) and associated header(s) from packets that are transported among hosts. For example inFIG.1, to facilitate packet transmission from a first logical endpoint (e.g., VM1131or C1141) to a second logical endpoint (e.g., VM2132or C2142) within a logical network domain, metadata that identifies the second logical endpoint may be included in packets that are transmitted from a first host (e.g.,110A) to a second host (e.g.,110B). Using metadata that is more compact than the omitted header(s), the processing burden relating to header information processing may be reduced, thereby reducing resource consumption and improving performance. As used herein, the term “logical endpoint” may refer generally to an element that is connected to a logical network, such as a VM, a VNIC, a container or application running inside a VM, etc.

In more detail,FIG.2is a flowchart of example process200for a first host to perform packet handling in SDN environment100. Example process200may include one or more operations, functions, or actions illustrated by one or more blocks, such as210to240. The various blocks may be combined into fewer blocks, divided into additional blocks, and/or eliminated depending on the desired implementation. In the following, an example will be described using host-A110A as a “first host,” host-B110B as a “second host,” VM1131as a “first logical endpoint,” and VM2132as “second logical endpoint.” Although the terms “first” and “second” are used to describe various elements, these elements should not be limited by these terms. These terms are used to distinguish one element from another. For example, a first element may be referred to as a second element, and vice versa. Any logical endpoint may each perform the role of a “first logical endpoint” or a “second logical endpoint.”

At210and220inFIG.2, in response to detecting an egress application-layer message from C1141running inside VM1131(“first logical endpoint”), host-A110A identifies that the egress application-layer message is destined for C2142running inside VM2132(“second logical endpoint”) supported by host-B110B. Block220may be performed based on control information that associates C2142with at least one attribute (e.g., domain name=bookstore-A, logical IP address=9.1.1.1, etc.) specified by the egress application-layer message (e.g., HTTP request). As will be discussed further usingFIG.4, the control information may be obtained from management entity180/184via control-plane channel101/102/103.

As used herein, the term “application-layer message” may refer generally to any suitable information generated by a logical endpoint according to an application-layer protocol. The “application-layer protocol” may be defined according to OSI model, Internet Protocol (IP) suite, etc. Examples of an “application-layer protocol” include, but not limited to, HTTP, HTTP secure (HTTPS), file transfer protocol (FTP), Simple Mail Transfer Protocol (SMTP), etc. In the following, various examples will be discussed using application-layer messages in the form of HTTP requests. In practice, any alternative and/or additional application-layer protocols may be used.

At230and240inFIG.2, host-A110A generates and sends an egress packet (see192inFIG.1) to host-B110B. Egress packet192includes the egress application-layer message (e.g., HTTP request) and metadata associated with C2142, but omits header(s) addressed from C1141to C2142. Egress packet192may be sent to host-B110B to cause host-B110B to identify C2142based on the metadata, and to send the egress application-layer message to C2142(see193inFIG.1). In practice, the “metadata” in block230may include any suitable information based on which C2142may be uniquely identified by second host-B110B. As will be described usingFIGS.3-6, the metadata may include a logical domain ID (e.g., domain=D1 inFIG.4), an application-layer attribute (e.g., domain name=bookstore-a2.com), etc. In some cases, a physical address (e.g., RDMA address) in egress packet192may be used as the metadata, provided the physical address is uniquely mapped to C2142.

In a first example inFIG.5, the application-layer message (e.g., HTTP request) detected at block210may be encapsulated with various headers, such as a layer-4 (“L4”) TCP header, layer-3 (“L3”) IP header and layer-2 (“L2”) MAC header. In this case, block230may involve host-A110A omitting the L2-L4 headers in the egress packet sent to destination host-B110B. Depending on the desired implementation, the omitted L2-L4 headers may be reconstructed at host-B110B based on the metadata. In a second example inFIG.6, the application-layer message (e.g., HTTP request) may be detected at block210via application programming interface (API) invocation, in which case packet header trimming and reconstruction is not necessary.

Examples of the present disclosure may be implemented to support service-to-service communication (e.g., using a service mesh inFIG.4), VM networking, container networking, application networking, etc. By reducing the size of packet header information and associated processing burden, examples of the present disclosure may be implemented to reduce routing complexity and improve network performance. As will be discussed further below, examples of the present disclosure may be implemented by any suitable host110A/110B/110C and more specifically virtual switch115A/115B/115C, such as using logical packet adapter(s)116A/116B/116C, service module117A/117B/117C, routing module118A/118B/118C and physical packet adapter(s)119A/119B/119C. In practice, service modules117A-C and routing module118A-C may be designed to be orthogonal to (i.e., independent from) respective logical packet adapters116A-C (e.g.,501-502inFIGS.5and601-602inFIG.6) and physical packet adapters119A-C. In this case, service modules117A-C and routing module118A-C may be configured to interact with different packet adapters116A-C/119A-C,

Service Mesh Implementation

In the following, various examples will be described with reference to a microservice architecture. Unlike a conventional monolithic application that is self-contained and independent from other applications, a microservice architecture splits a single application into a set of modular components called “microservices.” By designing microservices to be independently deployable and configurable, applications are simpler to build and maintained using the microservice architecture. Also, developers may isolate software functionality into independent microservices that are each responsible for performing specific tasks.

To support the microservice architecture, a service mesh may be implemented to facilitate service-to-service communication in a reliable manner. The term “service mesh” may refer generally to a group of microservices that make up an application, and the interactions among them. Depending on the desired implementation, the service mesh may facilitate load balancing, service discovery, authentication, support for circuit breaker pattern and other capabilities. Any suitable approach may be used for the service mesh, such as Istio™, Kong™ (available from Kong Inc.), Linkerd® and Envoy™ (available from The Linux Foundation®), NGINX™ (available from Nginx, Inc.), etc. For example, a mircoservice running on Istio may be packaged in a container and deployed using a container management system, such as Kubernetes® from The Linux Foundation®, etc.

In more detail,FIG.3is a flowchart of example detailed process300of packet handling in SDN environment100. Example process300may include one or more operations, functions, or actions illustrated at305to390. The various operations, functions or actions may be combined into fewer blocks, divided into additional blocks, and/or eliminated depending on the desired implementation. Example process300may be performed by any suitable computer system capable of acting as host110A/110B/110C/110D. The example inFIG.3will be explained usingFIG.4, which is a schematic diagram illustrating example dissemination300of control information to facilitate packet handling in SDN environment100.

At305inFIG.3, host110A/110B/110C/110D may obtain, from management entity180/184, control information401/402/403/404to facilitate service-to-service communication. The control information may include load balancing information410, logical endpoint information420and logical endpoint placement information430. Block310may be initiated by a host or management entity180/184, and the term “obtain” may refer generally to a host retrieving or receiving the information from management entity180/184.

In the example inFIG.4, microservices that support an online bookstore may be implemented using respective C1141inside VM1131on host-A110A, C2142running inside VM2132on host-B110B, C3143running inside VM3133on host-C110C, and C7147running inside VM7137on host-D110D. For example, to search for book(s) matching a particular title in an inventory, C1141may generate and send a query (e.g., HTTP request) to virtual domain name=bookstore-A. Based on load balancing information410, the HTTP request may be addressed to virtual domain name=bookstore-A, which may be mapped to bookstore-a1.com, bookstore-a2.com or bookstore-a3.com defined in routing domain=D1.

Logical endpoint information420specifies logical address information associated with each domain name. Referring to421, domain name=“bookstore-A” is associated with (logical IP address=9.1.1.1, logical MAC address=MAC-A). Within a particular routing domain or routing scope (e.g., D1), a logical IP address must be unique. Referring to422-424, domain name=“bookstore-a1.com” is associated with (2.1.1.1, MAC-a1); “bookstore-a2.com” with (2.1.1.2, MAC-a2) and “bookstore-a3.com” with (2.1.1.3, MAC-a3), respectively.

Logical endpoint placement information430identifies the physical placement associated with each domain name. At431inFIG.4, C7147running inside VM7137implements a first microservice associated with domain name=“bookstore-a1.com,” which is mapped to host ID=host-D110D, physical endpoint address=RDMA(k1, a1) and endpoint ID=(port-2, vlan-1). At432inFIG.4, C2142running inside VM2132implements a second micro service application associated with domain name=“bookstore-a2.com,” which is mapped to host-B110B, RDMA(k2, a2) and (port-5, vlan-2). At433inFIG.4, C3143running inside VM3133implements a third micro service application associated with domain name=“bookstore-a3.com,” which is mapped to host-C110C, RDMA(k3, a3) and (port-3, vlan-1).

In practice, the “endpoint ID” may include multiple layers of identification information, such as a port ID identifying a particular VM supported by a host, and a virtual local area network (VLAN) ID identifying a container running inside the VM. Using (port-3, vlan-1) as an example, port ID=port-3 may be used to identify VM3133on host-C110C, and VLAN ID=vlan-1 to identify container C3143. In practice, any alternative format for the endpoint ID may be used. Physical address such as RDMA(k3, a3) refers to an address of physical host-C110C on physical network104. In practice, the “physical address” may refer generally to an address seen by a physical entity (e.g., physical NIC), and the “logical address” to an address seen by a logical endpoint (e.g., VM, container, etc.).

At310inFIG.3, a host may establish a communication session with another host to facilitate service mesh implementation. In the example inFIG.4, logical endpoint placement information430may be used to establish a communication session between a pair of hosts, such as an RDMA-based connection. For example, host-A110A may establish a first RDMA-based connection with host-D110D using physical endpoint address=RDMA(k1, a1). A second RDMA-based connection may be established with host-B110B using RDMA(k2, a2), and a third RDMA-based connection with host-C110C using RDMA(k3, a3). The actual format for the physical address (e.g., RDMA(k1, a1)) may vary for different RDMA protocols.

As used herein, the term “RDMA” may refer to an approach that enables direct memory access from the memory of one computer system to the memory of another computer system via an interconnected network. Any suitable RDMA protocol may be used to establish RDMA-based connections, such as RDMA over converged Ethernet (RoCE) version 1, 2 or any other version, InfiniBand® (IB, a trademark of the InfiniBand Trade Association), RDMA over TCP/IP (iWARP), Virtual Interface Architecture (VIA), Omni-Path (a trademark of the Intel Corporation), etc. IB is a computer networking communications standard used in high-performance computing that features relatively high throughput and low latency. RoCE is a networking protocol that allows RDMA over an Ethernet network. RoCE version 1 (RoCEv1) is an Ethernet link layer protocol that allows communication between any two hosts on the same Ethernet broadcast domain. RoCE version 2 (RoCEv2) is an IP-based protocol that allows communication via a layer-3 network. An “RDMA-capable NIC” (e.g.,124A/124B/124C inFIG.1) may refer generally to any suitable network adapter that is capable of sending or receiving traffic via the RDMA-based connection.

In practice, an RDMA-based connection may be established using any suitable library calls (known as “verbs” library calls). These library calls provide semantic description of a required behavior, and are used for managing control path objects by creating and destroying objects such as send and receive work queue pairs, completion queues and memory regions. For example, host-A110A may use library call=rdma_connect( ) to initiate a connection request with host-B110B. In response, host-B110B may accept the connection request using rdma_bind( ), rdma_listen( ) rdma_accept( ) etc.

First Example: Packet Header Trimming and Reconstruction

A first example based on packet header trimming and reconstruction will be exampled usingFIG.3andFIG.5. In particular,FIG.5is a schematic diagram illustrating first example500of packet handling in SDN environment100. Here, consider a scenario where microservice supported by container C1141on host-A110A issues an application-layer message specifying an “attribute” in the form of virtual domain name=bookstore-A. For example, the application-layer message may be a representational state transfer (RESTful) request=“GET http://bookstore-A/book?title=SDN” (see510) to search for books with string=“SDN” in their title. Any alternative HTTP request may be issued, such as HEAD, PUT, POST, DELETE, etc. In the example inFIG.5, logical packet adapter116A/116B inFIG.1may be in the form of layer-7 packet adapter501/502to handle header removal and/or reconstruction.

At315and320inFIG.3, virtual switch115A may provide a domain name system (DNS) service to translate domain name=“bookstore-A” to logical IP address=9.1.1.1 based on load balancing information410and logical endpoint information420. To provide the DNS service, virtual switch115A may implement a meta packet service to act as a DNS server (not shown for simplicity). The DNS server may be configured by management entity180/184and deployed on a logical network to which C1141is connected. The DNS server may determine that it is backed by a pool of micro service applications, and respond with logical IP address=9.1.1.1, which is a special IP address assigned to virtual domain name=bookstore-A. Note that it is not necessary to translate the domain name to the logical IP address when native API invocation (to be discussed usingFIG.6) is used.

At325inFIG.3, VM1131generates and sends a packet (see510-520) that is addressed to logical IP address=9.1.1.1 associated with virtual domain name=“bookstore-A”. In the example inFIG.5, packet520includes HTTP request510that is encapsulated with logical network header information521-523. Logical TCP header521specifies any suitable information to establish a TCP connection with IP address=9.1.1.1. Logical IP header522identifies (source IP address=IP-1, destination IP address=9.1.1.1), while logical MAC header523identifies (source MAC address=MAC-1, destination MAC address=MAC-G). In this example, IP-1 is in a different subnet compared to 9.1.1.1, in which case “MAC-G” represents a destination MAC address associated with a gateway (e.g., edge) capable of forwarding the packet to the destination. Note that (IP-1, MAC-1) are associated with VM1131, or more particularly C1141running inside VM1131.

At330inFIG.3, virtual switch115A determines that load balancing is required because (domain name=bookstore-A, IP address=9.1.1.1) may be mapped to (bookstore-a1.com, 2.1.1.1) associated with C7147, (bookstore-a2.com, 2.1.1.2) associated with C2142and (bookstore-a3.com, 2.1.1.3) associated with C3143. At335, virtual switch115A (e.g., using service module117A and/or routing module118A) performs load balancing by selecting (bookstore-a2.com, 2.1.1.2) to handle the HTTP request.

In other words, destination C2142is selected from a group of logical endpoints that are capable of processing the HTTP request. The request to establish a TCP connection is terminated locally on a proxy running on hypervisor-A114A. As will be described below, destination hypervisor-B114B may run a similar proxy. In practice, any suitable load balancing approach may be used, such as round robin, historical connection information, a hash function based on source IP address, etc. Further, liveness detection may be performed periodically (e.g., using a meta packet service) to determine whether “bookstore-a1.com,” “bookstore-a2.com,” and “bookstore-a3.com” are running.

At340(yes) and345inFIG.3, virtual switch115A performs packet header trimming to reduce the amount of header information in packet520from VM1131. Depending on the desired implementation, logical packet adapter116A may be configured to process packet520to remove any “unnecessary” header information that may be reconstructed at the destination based on control information410-430inFIG.4. For example, packet header trimming may be performed to remove logical TCP header521, logical IP header522, logical MAC header523, or any combination thereof.

At350inFIG.3, virtual switch115A generates metadata based on which C2142may be identified at the destination host. In the example inFIG.5, the metadata (see531) may include (domain=D1, domain name=“bookstore-a2.com”), which uniquely identifies C2142having endpoint ID=(port-5, vlan-2) within domain=D1. In practice, any alternative and/or additional metadata may be used. For example, since physical address=RDMA(k2, a2) is uniquely associated with endpoint ID=(port-5, vlan-2) within domain=D1, the physical address may be used as the metadata, In this case, it is not necessary to include domain=D1 and domain name=“bookstore-a2.com” in the metadata. In another example, group or context information associated with firewall rule(s) may be included in the metadata. Further, the metadata may include any information (e.g., endpoint ID) that identifies source C1141to facilitate header reconstruction at the destination.

At355inFIG.3, virtual switch115A identifies physical address=RDMA(k2, a2) associated with host-B110B based on logical endpoint placement information432. At360and365, virtual switch115A generates and sends egress packet530to host-B110B. Egress packet530includes physical address header532(labelled “PHY”) specifying source=RDMA(k0, a0) and destination=RDMA(k2, a2), metadata531specifying (domain=D1, domain name=“bookstore-a2.com”) and HTTP request510. Physical packet adapter119A may interface with source RDMA-capable physical NIC124A on host-A110A to transmit egress packet530to destination RDMA-capable physical NIC124B on host-B110B via physical network104. From a logical network perspective, egress packet530be forwarded via logical router(s) and logical switch(es).

At370and375inFIG.3, in response to detecting packet530, virtual switch115B identifies destination C2142based on metadata531and logical endpoint placement information432. In particular, based on (domain=D1, domain name=“bookstore-a2.com”) specified by metadata531and associated with endpoint ID=(port-5, vlan-2), destination=C2142running inside VM2132may be identified.

At380(yes) and385, virtual switch115B performs packet header reconstruction to by generating a logical TCP header (L4*), a logical IP header (L3*) and a logical MAC header (L2*) for HTTP request510. The packet header reconstruction is based on metadata531specifying (domain=D1, domain name=“bookstore-a2.com”), which may be mapped to (logical IP address=2.1.1.2, logical MAC address=MAC-a2) associated with C2142. Physical address532and metadata531will be discarded. Depending on the desired implementation, virtual switch115B may act as a TCP proxy to establish a TCP connection with logical IP address=2.1.1.2 and (port-5, vlan-2) associated with C2142.

In practice, any suitable approach may be used to generate the source IP/MAC address information of C1141. In one example, logical endpoint information430inFIG.4may further include (host ID=host-A, physical address=RDMA(k0, a0), endpoint ID=(port-4, vlan-3) for C1141). In this case, virtual switch115B may identify C1141based on source physical address=RDMA(k0, a0) in packet530. In another example, additional metadata531identifying the source (e.g., “src=C1” or “src=(port-4, vlan-3)”) may be added to packet530. In a further example, a HTTP header (e.g., “X-Forwarded-For: C1”) may be appended at the source.

At390inFIG.3, virtual switch115B sends the HTTP request (see540inFIG.5) with reconstructed logical header(s) to VM2132. The reconstructed headers are removed by a protocol stack of guest OS152of VM2132before HTTP request510/550is sent to C2142for processing. When responding to the HTTP request, host-B110B may act as a “first host” and host-A110B as a “second host” using the example inFIG.3to facilitate the communication between source C2142and destination C1141.

Second Example: Native Network API

A second example based on API invocation will be explained usingFIG.3andFIG.6. In particular,FIG.6is a schematic diagram illustrating second example500of packet handling in SDN environment100. Using a native network API approach, applications or microservices (e.g., C1147) may be connected to a logical network directly without VNIC or port construction. For example inFIG.6, logical packet adapter116A/116B inFIG.1may be in the form of native API adapter601/602to handle API calls. Compared to the example inFIG.5, it is not necessary to perform packet header trimming and reconstruction, and to terminate any TCP connection.

At610inFIG.6, virtual switch115A may detect a HTTP request via an API invocation, such as in the form of send(destination=bookstore-A, HTTP request). After examining load balancing information410and logical endpoint information420, it is determined that load balancing is required. This is based on (bookstore-A, 9.1.1.1), which may be mapped to (bookstore-a1.com, 2.1.1.1) associated with C7147, (bookstore-a2.com, 2.1.1.2) associated with C2142and (bookstore-a3.com, 2.1.1.3) associated with C3143. In this case, virtual switch115A (e.g., using service module117A) performs load balancing by selecting (bookstore-a3.com, 2.1.1.3) associated with C3143. See corresponding325-335inFIG.3. Note that block320inFIG.3is not necessary in the example inFIG.6.

Next, egress packet620that includes physical address622, metadata621and HTTP request610is sent to host-C110C. For example, based on logical endpoint information423, metadata621specifying (domain=D1, domain name=“bookstore-a3.com”) may be generated. Based on logical endpoint placement information433, RDMA(k3, a3) associated with host-C110C may be identified to be destination physical address622. See corresponding340(no),350-365inFIG.3.

At destination host-C110C, virtual switch115B may identify C3143associated with endpoint ID=(port-3, vlan-1) based on metadata621specifying (domain=D1, domain name=bookstore-a3.com). As such, HTTP request630may be sent to C3143directly, such as through an API invocation by API adapter602. Unlike the example inFIG.5, L2-L4 packet header reconstruction is not necessary. See corresponding370-375,380(no) and395inFIG.3. Other implementation details explained usingFIG.5are also applicable in the example inFIG.6and will not be repeated for brevity.

In the examples inFIG.5andFIG.6, egress packet530/620includes RDMA header532/622, metadata531/621and application-layer message510/610. In these examples, one layer of routing (i.e., application-based routing) may be implemented in a more efficient manner compared to conventional multi-layer routing that relies on logical network domain headers (e.g., inner TCP header, inner IP header, inner MAC header) and physical network domain headers (e.g., outer TCP header, outer IP header, outer MAC header). Using control information410-430inFIG.3, routing decisions based on metadata may be configured in a centralized manner instead of a distributed manner.

Although described using RDMA, it should be understood that any alternative communication session may be established between first host110A and second host110B/110C/110D, such as via a TCP connection. In this case, metadata531/621and application-layer message510/610may be encapsulated with header(s) specifying physical address information of host110A/110B/110C/110D. In the example inFIG.5, physical IP/MAC header532may be addressed from (source physical IP address=IP-A of host-A110A, source MAC address=MAC-G of a gateway) to (destination physical IP address=IP-B, MAC address=MAC-B) of host-B110B. In the example inFIG.6, physical IP/MAC header632may be addressed from (IP-A, MAC-G) to host-C110C (e.g., destination physical IP address=IP-C, MAC address=MAC-C).

Unicast and/or Multicast Packet Handling

It should be understood that examples of the present disclosure may be implemented for unicast and/or multicast packet handling in various scenarios where load balancing is used (as explained usingFIGS.4-6) or otherwise. For example, C4144on host-A110A may communicate with C5145on host-B110B in a unicast manner. In this case, logical endpoint information420inFIG.4may specify (domain=D2, domain name=“xyz.com,”logical IP=IP-5, logical MAC=MAC-5) associated with C5145. Logical placement endpoint information430may specify domain name=“xyz.com,” host ID=host-B, RDMA(k2, a2) and endpoint ID=(port-1, vlan-1) associated with C5145. This way, any unicast packet from source=C4144may include metadata identifying destination=C5145. Based on domain=D2 and domain name=“xyz.com,” C5145may be identified at host-B110B. Alternatively, if a particular physical address is able to uniquely identify the destination endpoint, metadata specifying the domain and domain name may be omitted.

In another example, C4144on host-A110A may communicate with both C3143and C7147in a multicast manner. In this case, one approach is to send two packets to respective destinations. A first packet that includes metadata associated with C3143may be sent to host-C110C in a unicast manner. A second packet that includes metadata associated with C7147may be sent to host-D110D in a unicast manner. Similarly, logical L2-L4 headers may be omitted according to the examples of the present disclosure. Depending on the desired implementation, a multicast address may be configured, such as “group.bookstore-N” that is mapped to multiple domain names associated with respective logical endpoints (i.e., group members). A packet that is addressed to the multicast address will be forwarded to its group members. Each packet includes any suitable metadata for identifying the destination endpoint.

Computer System

The above examples can be implemented by hardware (including hardware logic circuitry), software or firmware or a combination thereof. The above examples may be implemented by any suitable computing device, computer system, etc. The computer system may include processor(s), memory unit(s) and physical NIC(s) that may communicate with each other via a communication bus, etc. The computer system may include a non-transitory computer-readable medium having stored thereon instructions or program code that, when executed by the processor, cause the processor to perform processes described herein with reference toFIG.1toFIG.6. For example, a computer system capable of acting as a first host or a second host may be deployed in SDN environment100.

Those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computing systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure.Software and/or other instructions to implement the techniques introduced here may be stored on a non-transitory computer-readable storage medium and may be executed by one or more general-purpose or special-purpose programmable microprocessors. A “computer-readable storage medium”, as the term is used herein, includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, personal digital assistant (PDA), mobile device, manufacturing tool, any device with a set of one or more processors, etc.). A computer-readable storage medium may include recordable/non recordable media (e.g., read-only memory (ROM), random access memory (RAM), magnetic disk or optical storage media, flash memory devices, etc.).