CROSS-DOMANIC DISTRIBUTED NETWORK FUNCTION

Abstract

A cross-domain distributed network function can be constructed by instantiating a local domain endpoint for a first application component. Here, the local domain endpoint resides in a first network domain that contains the first application component. A connection can then be established to an external domain endpoint. Here, the external domain endpoint resides in a second network domain that does not contain the first network domain, and this second network domain contains a second application component. The local domain endpoint can then provide a network service to a third network domain that contains the application. The first application component can then use this network service to connect to the second application component.

Description

BACKGROUND

[0001] Computer networking is a term that refers to the various systems, devices, or protocols that connect computing devices. A computer network is often described in layers, with a physical layer typically defining or describing the physical media (e.g., radio frequency transmission, fiber optics, copper wiring, etc.) and protocols for those media, and an application layer typically defining or describing software that directs communications. A variety of layers, such as a media access layer, may be included between the physical layer and the application layer.

[0002] In address-based networking, such as in Internet Protocol (IP) networks, devices are typically assigned a unique address within an address space, or domain. A gateway is typically used to communicate outside a domain. Gateways generally bridge domains with one interface in a first domain (e.g., a local domain) and another interface in a second domain (e.g., a remote domain or an additional domain). Within a domain, a variety of communication techniques can be used, such as unicast (where there is a single destination address for the data), multicast (where there are multiple destinations for the data), or broadcast (where the data is addressed to all addresses in the domain). Switches are network devices that route packets from a sender to a receiver within a domain based on the addressing of the data.Thus, in a unicast transmission, a switch forwards the packet directly to an interface of the receiving device. In the case of a broadcast transmission, the switch forwards the data to each connected device (e.g., copies it). BRIEF DESCRIPTION OF THE DRAWINGS

[0003] In the drawings, which are not necessarily drawn to scale, like reference numerals may describe similar components in different views. Like reference numerals with different letter suffixes may represent different instances of similar components. The drawings generally illustrate, by way of example but not limitation, various embodiments discussed in this document. Fig. 1 is an example of an environment including a system for a cross-domain distributed network function, according to one embodiment. Fig. 2 illustrates an example of a unified architecture using a cross-domain switch according to one embodiment. Fig. Figure 3 illustrates an example of interactions between client, edge, and cloud components according to one embodiment. Fig. 4 illustrates an example of domain interactions according to one embodiment. Fig. 5A-5B illustrate an example of signaling between components according to one embodiment. Fig. 6 illustrates a flow diagram of an example method for a cross-domain distributed network function according to one embodiment. Fig. 7 is a block diagram illustrating an example of a machine on which one or more embodiments may be implemented. DETAILED DESCRIPTION

[0004] Address-based networking has long provided reliable communication between computers. While domains ease some administrative problems, such as address management (e.g., there is generally no need to coordinate addresses around the world), including finite address spaces, there are some problems when communicating across domains. Generally, an address in a first domain cannot be used in a second domain. As noted above, a gateway can operate to forward such requests. Network address translation (NAT) is one technique that allows a gateway to accomplish this task. With NAT, the local request is traced at the gateway. The gateway replaces the source address with one that the gateway in the remote domain controls and sends the packet, for example.When a response is received, the original request is located and the original requestor address is written as the destination in the response packet. The response packet can then be sent to the original requestor in the local domain.

[0005] Some applications rely on intra-domain communications, such as multicast or broadcast messages. Examples of such systems might include augmented reality (AR) or virtual reality (VR), industrial security (e.g., machine tolerance monitoring, roller coaster safety monitoring, etc.), or other applications that use these intra-domain techniques to perform, for example, resource discovery or management (e.g., device heartbeats). A problem can arise when distributed computing, such as vehicle edge cloud architectures, is used to deploy such applications. In general, operations without NAT to ensure bidirectional connection initiation make support for discovery or management based on a broadcast and multicast traffic domain difficult.Furthermore, NAT is difficult to use because, in dynamic environments, a given endpoint device may involve multiple gateways during operation. This results in complex translation table and packet management across gateways. Furthermore, a virtual private network (VPN) overlay may face similar overhead in connection dynamics that is not scalable.

[0006] To address the problems mentioned above, a cross-domain distributed network function can be used. The cross-domain distributed network function is an overlay network with single-domain semantics that operates across multiple domains. The components of the distributed network function include endpoints in the multiple domains and a backplane connecting these endpoints. The endpoints exist within multiple domains and act as network interfaces, similar to a typical physical switch. An edge application connects to the endpoint using local hardware semantics and receives, for example, an IP address and DNS configuration from the overlay network. Thus, the application is able to communicate with other components in the overlay network using local domain semantics, even though the components are physically distributed in different network domains.

[0007] In one example, the network endpoint is a proxy application that connects to the overlay network functions (e.g., Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), etc.) at the application layer of the underlying networks. In an example where application components are deployed as containers, the proxy can be part of the container or adjacent to the container, such as a sidecar. This arrangement reduces most additional administrative overhead, as the proxy applications only need to connect to stable cloud endpoints to construct the backplane of the distributed network function. By using the cross-domain distributed network function, an application developer can continue to use proven local domain messaging while also benefiting from distributed cloud edge architectures. Additional details and examples are provided below.

[0008] Fig. 1 is an example of an environment including a system for cross-domain distributed networking, according to one embodiment. The illustrated scenario includes an application that extends across an edge, the vehicle 105, to a cloud, the server 145. For example, a passenger of the vehicle 105 may use a VR application to participate in a conference while driving. The vehicle 105 has a local network or local domain 110 in which the vehicle 105 operates. The local domain 110 is a local network for vehicle components, such as a display terminal, engine diagnostics, etc. The vehicle 105 includes a device 115 that operates in the local domain 110. The device 115 includes processing circuitry 120, memory 125, and a set of network interfaces, which may include a radio 130 for high-frequency physical layer communication.

[0009] Other vehicles, such as vehicle 160 and vehicle 170, also have local domains, such as local domain 165 for vehicle 160 and local domain 175 for vehicle 170. Furthermore, server 145 operates in its own local domain 150. For the various components, the corresponding local domain is the component's underlying network environment. However, application network 155 is a network enabled by the cross-domain distributed networking functionality. Application network 155 is a type of overlay network in which the transport mechanisms of the local domains are used, but the network semantics are consistent for any component of the application, regardless of which local domain may host that component.

[0010] The cross-domain distributed network function is enabled by the operation of local endpoints (e.g., offered local services and inter-domain connections). Since locality can be considered relative, for the following discussion, local domain 110 is "local" and local domain 150 is "external." Accordingly, the endpoint for local domain 110 is local-domain endpoint 135, and the endpoint for local domain 150 is external-domain endpoint 140. The structure and operations of the cross-domain distributed network function are described from the perspective of local-domain endpoint 135, which is implemented by processing circuitry 120, which can be configured by instructions residing in memory 125.

[0011] The local domain endpoint 135 functions similarly to a switch port connected to a network device and forming a termination point of a switch backplane. To achieve this arrangement, the processing circuitry 120 is configured to instantiate (e.g., install, execute, perform, launch, etc.) the local domain endpoint 135 for a first application component. Again, the local domain endpoint 135 is located in the local domain 110 (e.g., a first network domain). The local domain 110 also includes the first application component, which is only one part of a multi-component application. In one example, the local domain endpoint 135 operates in a networking application layer. Although there are several network models that have layers, the application layer is the layer furthest removed from the physical layer, as illustrated in the OSI (Open Systems Interconnection) model.This example illustrates that the local domain endpoint 135 does not modify the operation of the lower network layers, such as the media access layer. Instead, the local domain endpoint 135 uses these facilities without modification.

[0012] In one example, the application is a virtual reality (VR) or augmented reality (AR) application. In one example, the application is an industrial monitoring or control application. These example applications tend to use multicast or broadcast communications for component discovery or to request responses from components, such as reporting a current value for a sensor monitoring a machine.

[0013] In one example, the first application component is a microservice implemented in a virtual environment, such as a virtual machine. In one example, the first application component is located in a container. The container's environment may be virtual or may be implemented in whole or in part by configurable hardware. Containers are often hosted such that multiple containers in a host use (e.g., share) a single operating system (OS) kernel. Some hosting platforms allow encapsulated modifications to containers called sidecars. A sidecar is deployed with a container to modify an aspect of the container related to a specific deployment. In one example, the local domain endpoint 135 is a container sidecar. In one example, the container is hosted by a multi-access edge computing (MEC) host.In this example, device 115 is the MEC host. In one example, external domain endpoint 140 is hosted in a cloud. In one example, local domain endpoint 135 is a proxy container in a service mesh for the container. Fig. 3 and Fig. 4 illustrate some of these examples.

[0014] Processing circuitry 120 is configured to establish a connection to the external domain endpoint 140. Again, the external domain endpoint 140 is located in a second network domain (the local domain 150) that does not include the first network domain, the local domain 110. The second network domain also includes a second application component for the application. In one example, if the first application component is a container, establishing the connection to the external domain endpoint includes using an ingress gateway of a service mesh control plane hosting the container. Fig. 3 and Fig. 4 illustrate exemplary aspects of this arrangement. Once the connection is established, bidirectional communications on the link enable the backplane of the cross-domain distributed function, such as a cross-domain distributed switch, with respect to the two ports represented by the local domain endpoint 135 and the external domain endpoint 140.

[0015] Processing circuitry 120 is configured to provide a network service for a third network domain (the application network 155) to the first application component. The third network domain is the application network domain. Because local domain endpoint 135 operates similarly to a port on a switch, local domain endpoint 135 operates to provide the network to the first application component. Accordingly, in one example, the network service is one of a plurality of network services provided by local domain endpoint 135. In one example, the plurality of network services includes DHCP. In one example, DHCP provides a configuration for the third network domain. In one example, processing circuitry 120 is configured to receive a DHCP request from the first application component and provide a configuration to the first application component.In one example, the configuration includes an IP address, a default gateway IP address, or a DNS server IP address.

[0016] Processing circuitry 120 is configured to forward traffic from the first application component to the second application component across the connection in response to an invocation of the network service by the first application component. This traffic forwarding completes the switch analogy by using the established connection as the backplane to connect the two ports of the local domain endpoint 135 and the external domain endpoint 140. In one example, forwarding traffic from the first application component to the second application component includes performing a unicast broadcast, an any-cast broadcast, a multi-cast broadcast, or a broadcast broadcast. Thus, true local network operations are enabled across a variety of network domains.

[0017] Fig. Figure 2 illustrates an example of a unified architecture using a cross-domain switch according to one embodiment. The components of the architecture, as illustrated, are self-explanatory. Note that DHCP for the application-specific unified domain is extended across the various domains spanning different layers in local edge-cloud architectures. The application-specific unified domain is beneficial for applications that typically run locally with possible connections to a cloud. For example, applications—such as AR / VR, remote gaming, and web3—typically benefit from users and edge or cloud applications being in the same IP domain to support multicast or broadcast communications.In general, web3 applications—such as game consoles—and content for AR / VR devices are typically hosted on local computing, such as on the same local area network (LAN) within a shared Wi-Fi access point (AP) gateway. Often, this network architecture cannot be extended to seamlessly serve edge computing services—for example, cellular or fixed wireless ISPs—due to multi-level NAT complications that still do not allow broadcast traffic between application domains. NAT complications can require a client (e.g., a local application) to initiate connections (e.g., to the cloud), resulting in the use of techniques such as Transmission Control Protocol (TCP) keep-alive overhead. These techniques tend to consume network resources, including bandwidth and performance, with little other benefit.

[0018] The illustrated architecture uses cloud-native principles, such as service mesh architecture, for easy integration across client cloud and edge domains. The architecture is NAT-free in the local domain, employing a cross-domain setup derived from a client-first approach. This also leads to secondary benefits such as performance and operational efficiencies. By using a common IP domain, the application-specific unified domain, the architecture enables new use cases through seamless migration of client-side applications to the edge and cloud. Applications such as automotive, robotics, remote control (such as closed-loop control systems), or other highly interactive industrial systems do not need to change local network paradigms, while utilizing flexible and dynamic deployments of application components from local computing to edge computing or cloud computing.Furthermore, different application flows can be separated into different unified domains. Consider using a different flow for each of the illustrated IP domains (e.g., client_app :: edge_app :: cloud_app). Thus, for example, a flow can be specified by the following quintuple (e.g., five-tuple): {source IP, destination IP, source port, destination port, and IP type [UDP or TCP]}. Accordingly, each application and flow can have a separate IP domain. This arrangement can address scalability issues inherent in some other interconnection approaches.

[0019] Fig. Figure 3 illustrates an example of interactions between client, edge, and cloud components according to one embodiment. The illustrated interactions operate within a service mesh architecture. From a client networking perspective, it is typical for the client to initiate the first connection to the server using a DNS lookup for the server. Generally, this process creates NAT rules at the client-side NAT table for the returned traffic. Unlike traditional operations, the application component or workload within a container is assigned an application domain IP address by the client-side DHCP server (e.g., from the local domain). If the local domain is a cellular network, the cellular network DHCP server (e.g., from the core network) coordinates with the client-side DHCP server to receive the IP addresses.In this case, the core network function can be run as a container coordinated by the service mesh controller and service mesh proxies.

[0020] For control plane traffic, client-side DHCP communicates with the service mesh controllers at the edge and cloud, establishing all necessary interconnections for the data plane. Data plane traffic passes through the DHCP gateway on the client side to the service mesh proxy container, which provides the same domain IPs retrieved by the client side, maintaining the same broadcast and multicast domain.

[0021] Fig. Figure 4 illustrates an example of domain interactions according to one embodiment. As illustrated, the service mesh control plane connects to the client DHCP service to set up the proxy configuration for the client-local IP domain. This is then used by the service mesh proxy container (e.g., sidecar) to provide the client-local IP domain configuration of the DHCP service to the workload container. Thus, the server application operates in the client-local IP domain. This client-centric networking also enables client-local DNS to the edge or cloud, for example, when a mobile client extends a DNS lookup using the access edge. This example can enable mobility by allowing a component to move to different network domains while maintaining a consistent DNS setup for connecting to other components or services.

[0022] In one example, the service mesh extends (e.g., with a sidecar proxy) to the MEC edge to ensure communication with the DHCP service on the client side. In one example, this can be implemented in a multi-cluster-based universal service mesh that extends the mesh control and management plane at the MEC edge while maintaining a universal management plane at different MEC edges. In one example, in accordance with ETSI MEC standards, state management and locality management are coordinated by edge DNS servers across distributed edge locations. Service mesh-based sidecar proxies can be extended across these distributed edge DNS servers to provide NAT facilities without affecting (e.g., modifying) client operations.

[0023] For edge or cloud networking, service mesh benefits—such as privacy, security, network policies, or traffic distribution—can be enforced at the server while extending the networking from the client. This creates a tight coupling between the client application and the edge or cloud application. In one example, the access gateway can be the DNS-resolved address of an application (e.g., someapplication.app.server.com), which sends the request from the client to the service mesh control plane and is redirected to the proxy within the service mesh to provide networking for the container and application. This eliminates NAT issues in traditional arrangements, such as nested NATs or double-sided NATs.

[0024] Because the service mesh domain controls the proxies used for the shared IP domain, network routing consistently follows the traditional routing mechanism and therefore does not need to be changed. Regarding the actual IP addressing to the endpoints, they follow normal procedures and therefore do not require any changes.

[0025] For the purpose of actually implementing the service mesh-based shared IP domains, IP addressing is derived from the client application domain and applied to the edge and cloud domains.

[0026] Fig. 5A-5B illustrate an example of inter-component signaling according to one embodiment. When the application component starts at an edge or cloud server, the application component may register with a service mesh controller for a managed connection (operation 505). The service mesh controller requests an initial container network setup from the service mesh proxy container (operation 510). The proxy container communicates with the workload container to establish a connection with the access gateway DHCP (operation 515). The service mesh controller then makes a DHCP request (operation 520) to the proxy container, where the service request is communicated to the access gateway DHCP (operation 525).

[0027] The access gateway DHCP can set up one or more NAT rules in a local table to enable connections between the server and the client (operation 530). The proxy mesh can also complete the IP configuration from the access gateway DHCP response for the workload container (operation 535). Upon completion, the access gateway DHCP can signal the service mesh controller that the client configuration is complete (operation 540), which prompts the service mesh controller to signal the proxy container that the network configuration is complete (operation 545). At this point, the proxy container signals the server that the managed connection is ready (operation 550). At this point, communications from the server operate in the same IP domain as the application.

[0028] When either party initiates a termination (operation 555), the access gateway DHCP signals the service mesh controller that the managed connection is terminated (operation 560). The access gateway DHCP requests that the NAT policy be revoked (operation 565). The service mesh controller requests a DHCP release from the proxy container (operation 570). The proxy container then signals the access gateway DHCP that the release is complete (operation 575). The NAT facility also signals the access gateway DHCP that the NAT policy revocation is complete, terminating the managed connection.

[0029] A service mesh is an overlay network that operates at the application layer and is typically managed by a centralized entity contained within a container domain. Because the service mesh operates at the application layers, it allows the use of an application's entire underlying network infrastructure as is. Accordingly, there are generally no modifications to the application or network layers. The service mesh proxies that exist as part of container networking are designed to emulate the networking for the application, enabling communications as if all application components were located on a single LAN segment with a single IP domain.

[0030] Fig. Figure 6 illustrates a flowchart of an example method 600 for a cross-domain distributed network function according to one embodiment. The method 600 is performed by computing hardware, such as that described above or below (e.g., processing circuitry).

[0031] At operation 605, a local domain endpoint for a first application component is instantiated (e.g., installed, started, executed, etc.). This local domain endpoint is located in a first network domain that includes the first application component, where the first application component is part of an application. In one example, the local domain endpoint operates in a networking application layer. In one example, the application is a virtual reality (VR) or augmented reality (AR) application.

[0032] In one example, the first application component is located in a container. In one example, the container is hosted by a multi-access edge computing (MEC) host. In one example, the external domain endpoint is hosted in a cloud. In one example, the local domain endpoint is a container sidecar. In one example, the local domain endpoint is a proxy container in a service mesh for the container.

[0033] At operation 610, the local domain endpoint connects to an external domain endpoint. This external domain endpoint is located in a second network domain that does not include the first network domain. The second network also includes a second application component for the application. In one example, if the first application component is a container, establishing the connection to the external domain endpoint includes using an ingress gateway of a service mesh control plane hosting the container.

[0034] At operation 615, a network service for a third network domain is provided to the first application component. The third network domain includes the application. In other words, the third network domain is the network domain of the application. In one example, the network service is one of a plurality of network services provided by the local domain endpoint to the first application component. In one example, the plurality of network services includes Dynamic Host Configuration Protocol (DHCP). In one example, the DHCP provides a configuration for the third network domain. In one example, method 600 includes the additional operations of receiving a DHCP request from the first application component and providing a configuration to the first application component.In one example, the configuration includes an Internet Protocol (IP) address, a default gateway IP address, or a Domain Name System (DNS) server IP address.

[0035] At operation 620, traffic is forwarded from the first application component to the second application component over the connection in response to a call to the network service by the first application component. In one example, forwarding traffic from the first application component to the second application component includes performing a unicast broadcast, an any-cast broadcast, a multi-cast broadcast, or a broadcast broadcast.

[0036] Fig.7 illustrates a block diagram of an example machine 700 on which one or more of the techniques (e.g., methodologies) discussed herein may be performed. Examples as described herein may include logic or a number of components or mechanisms within or operating through machine 700. Circuitry (e.g., processing circuitry) is a collection of circuits implemented in tangible entities of machine 700 that include hardware (e.g., simple circuits, gates, logic, etc.). The composition of the circuitry may be flexible over time. Circuitry includes elements that, in operation, can perform specified operations alone or in combination. In one example, hardware of the circuitry may be invariably configured (e.g., hard-wired) to perform a specific operation.In one example, the circuitry hardware may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.), including a machine-readable medium that is physically modified (e.g., with magnetic, electrical, movable placement of invariant mass particles, etc.) to encode instructions of the specific operation. Upon connecting the physical components, the underlying electrical properties of a hardware component are changed, for example, from an insulator to a conductor or vice versa. The instructions enable embedded hardware (e.g., the execution units or a loading mechanism) to create elements of the circuitry in hardware via the variable connections to, in operation, perform portions of the specific operation.Accordingly, in one example, the machine-readable media elements are part of the circuitry or are communicatively coupled to the other components of the circuitry when the device is in operation. In one example, any of the physical components may be used in more than one element of more than one circuitry. For example, execution units in operation may be used in a first circuit of a first circuitry at one time and reused by a second circuit in the first circuitry or by a third circuit in a second circuitry at another time. Additional examples of these components with respect to machine 700 follow.

[0037] In alternative embodiments, machine 700 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, machine 700 may operate in the capacity of a server machine, a client machine, or both in server-client network environments. In one example, machine 700 may function as a peer machine in a peer-to-peer (P2P) network environment (or other distributed network environment). Machine 700 may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile phone, a web device, a network router, a switch or bridge, or any machine capable of executing instructions (sequentially or otherwise) that specify actions to be taken by that machine.Furthermore, while only a single machine is illustrated, the term “machine” is intended to include any collection of machines that individually or collectively execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein, such as cloud computing, software-as-a-service (SaaS), or other computer cluster configurations.

[0038] The machine (e.g., the computer system) 700 may include a hardware processor 702 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), main memory 704, static memory (e.g., memory or storage for firmware, microcode, a basic input / output (BIOS), a unified extensible firmware interface (UEFI), etc.) 706, and mass storage 708 (e.g., hard drives, tape drives, flash memory, or other block devices), some or all of which may communicate with each other via an interconnect (e.g., a bus) 730. The machine 700 may further include a display unit 710, an alphanumeric input device 712 (e.g., a keyboard), and a user interface (UI) navigation device 714 (e.g., a mouse).In one example, the display unit 710, the input unit 712, and the UI navigation device 714 may be a touchscreen display. The machine 700 may additionally include a storage device (e.g., a drive unit) 708, a signal generator 718 (e.g., a speaker), a network interface device 720, and one or more sensors 716, such as a global positioning system (GPS) sensor, a compass, an accelerometer, or another sensor. The machine 700 may include an output controller 728, such as a serial (e.g., a Universal Serial Bus (USB)), a parallel, or other wired or wireless (e.g., infrared (IR), near-field communication (NFC), etc.) connection, to interface with or communicate with one or more peripheral devices (e.g., a printer, card reader, etc.).

[0039] Registers of the processor 702, the main memory 704, the static memory 706, or the mass storage 708 may be or include a machine-readable medium 722 on which one or more sets of data structures or instructions 724 (e.g., software) are stored that perform or are employed by one or more of the techniques or functions described herein. The instructions 724 may also reside, during their execution by the machine 700, in whole or in part, within any of the registers of the processor 702, the main memory 704, the static memory 706, or the mass storage 708. In one example, one or any combination of the hardware processor 702, the main memory 704, the static memory 706, or the mass storage 708 may constitute the machine-readable media 722.While the machine-readable medium 722 is illustrated as a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) configured to store the one or more instructions 724.

[0040] The term "machine-readable medium" may include any medium capable of storing, encoding, or executing instructions for execution by machine 700 that cause machine 700 to perform one or more of the techniques of the present disclosure, or capable of storing, encoding, or carrying data structures used by or associated with such instructions. Non-limiting example machine-readable media may include solid-state storage, optical media, magnetic media, and signals (e.g., radio frequency signals, other photon-based signals, acoustic signals, etc.). In one example, a non-transitory machine-readable medium includes a machine-readable medium having a plurality of particles with invariant (e.g., rest) mass and are thus compositions of material.Accordingly, non-transitory machine-readable media are machine-readable media that do not contain transitory propagating signals. Specific examples of non-transitory machine-readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM)), and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

[0041] In one example, information stored or otherwise provided on the machine-readable medium 722 may represent the instructions 724, such as the instructions 724 themselves or a format from which the instructions 724 may be derived. This format from which the instructions 724 may be derived may include source code, encoded instructions (e.g., in compressed or encrypted form), packaged instructions (e.g., divided into multiple packages), or the like. The information representing the instructions 724 in the machine-readable medium 722 may be processed by processing circuitry into the instructions to implement any of the operations discussed herein. For example, deriving the instructions 724 from the information (e.g., processing by the processing circuitry) may include: compiling (e.g., from source code, object code, etc.)), interpreting, loading, organizing (e.g., dynamic or static linking), encoding, decoding, encrypting, decrypting, packaging, unpacking, or otherwise manipulating the information into the instructions 724.

[0042] In one example, deriving the instructions 724 may include assembling, compiling, or interpreting the information (e.g., by the processing circuitry) to generate the instructions 724 from any intermediate or preprocessed format provided by the machine-readable medium 722. The information, if provided in multiple pieces, may be combined, unpacked, and modified to create the instructions 724. For example, the information may be located in multiple compressed source code packages (or object code, or binary executable code, etc.) on one or more remote servers. The source code packages may be encrypted as they move across a network and decrypted, decompressed, reassembled (e.g., linked) on demand, and compiled or interpreted (e.g., into a library, standalone executable, etc.) on a local machine.) and run from the local machine.

[0043] The instructions 724 may further be sent or received over a communications network 726 using a transmission medium via the network interface device 720 using any of a number of transfer protocols (e.g., Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), etc.). Example communications networks may include, but are not limited to, a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), LoRa / LoRaWAN or satellite communications networks, cellular telephone networks (e.g., cellular networks such as those that meet 3G, 4G LTE / LTE-A, or 5G standards), analog telephone networks (POTS), and wireless data networks (e.g., the Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi®, the IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks).In one example, network interface device 720 may include one or more physical jacks (e.g., Ethernet, coaxial, or telephone jacks) or one or more antennas for connecting to communications network 726. In one example, network interface device 720 may include a plurality of antennas to communicate wirelessly using at least one of single input multiple output (SIMO), multiple input multiple output (MIMO), or multiple inputs and one output techniques. The term "transmission medium" is intended to include any intangible medium capable of storing, encoding, or carrying instructions for execution by machine 700, and includes digital or analog communication signals or other intangible medium to enable communication of such software. A transmission medium is a machine-readable medium. Additional notes and examples

[0044] Example 1 is an apparatus for a cross-domain distributed network function, the apparatus comprising: a memory containing instructions; and processing circuitry configured by the instructions to: instantiate a local domain endpoint for a first application component, wherein the local domain endpoint is located in a first network domain that includes the first application component, the first application component being part of an application; establish, by the local domain endpoint, a connection to an external domain endpoint, the external domain endpoint is located in a second network domain that does not include the first network domain, the second network domain including a second application component for the application; provide, to the first application component, a network service for a third network domain, the third network domain including the application;and forwarding traffic from the first application component to the second application component over the connection in response to a call to the network service by the first application component;

[0045] In Example 2, the subject matter of Example 1, wherein the first application component is located in a container.

[0046] In Example 3, the subject matter of Example 2, wherein the local domain endpoint is a container sidecar.

[0047] In Example 4, the subject matter of any of Examples 2-3, wherein the local domain endpoint is a proxy container in a service mesh for the container.

[0048] In Example 5, the subject matter of any of Examples 2-4, wherein the instructions to establish the connection to the external domain endpoint configure the processing circuitry to use an ingress gateway of a service mesh control plane hosting the container.

[0049] In Example 6, the subject matter of any of Examples 2-5, wherein the container is hosted by a multiple access edge computing (MEC) host and wherein the external domain endpoint is hosted in a cloud.

[0050] In Example 7, the subject matter of any of Examples 1-6, wherein the network service is one of a plurality of network services provided by the local domain endpoint to the first application component.

[0051] In Example 8, the subject matter of Example 7, wherein the plurality of network services include Dynamic Host Configuration Protocol (DHCP).

[0052] In Example 9, the subject matter of Example 8, wherein the DHCP provides a configuration for the third network domain.

[0053] In Example 10, the subject matter of any of Examples 8-9, wherein the instructions configure the processing circuitry to: receive a DHCP request from the first application component; and provide a configuration to the first application component.

[0054] In Example 11, the subject matter of any of Examples 9-10, wherein the configuration includes an Internet Protocol (IP) address, a default gateway IP address, or a Domain Name System (DNS) server IP address.

[0055] In Example 12, the subject matter of any of Examples 1-11, wherein the instructions configure the processing circuitry to forward traffic from the first application component to the second application component to perform a unicast broadcast, an any-cast broadcast, a multi-cast broadcast, or a broadcast broadcast.

[0056] In Example 13, the subject matter of any of Examples 1-12, wherein the local domain endpoint operates in a networking application layer.

[0057] In Example 14, the subject matter of any of Examples 1-13, wherein the application is a virtual reality (VR) or augmented reality (AR) application.

[0058] In Example 15, the subject matter of any of Examples 1-14, wherein the first application component is a microservice.

[0059] In Example 16, the subject matter of any of Examples 1-15, wherein the processing circuitry for establishing the connection to the external domain endpoint does not use or employ a network address translation (NAT) service or a NAT protocol.

[0060] Example 17 is a method for a cross-domain distributed network function, the method comprising: instantiating a local domain endpoint for a first application component, wherein the local domain endpoint is located in a first network domain that includes the first application component, the first application component being part of an application; establishing, by the local domain endpoint, a connection to an external domain endpoint, wherein the external domain endpoint is located in a second network domain that does not include the first network domain, the second network domain including a second application component for the application; providing, to the first application component, a network service for a third network domain, the third network domain including the application;and forwarding traffic from the first application component to the second application component over the connection in response to a call to the network service by the first application component;

[0061] In Example 18, the subject matter of Example 17, wherein the first application component is in a container.

[0062] In Example 19, the subject matter of Example 18, wherein the local domain endpoint is a container sidecar.

[0063] In Example 20, the subject matter of any of Examples 18-19, wherein the local domain endpoint is a proxy container in a service mesh for the container.

[0064] In Example 21, the subject matter of any of Examples 18-20, wherein establishing the connection to the external domain endpoint includes using an ingress gateway of a service mesh control plane hosting the container.

[0065] In Example 22, the subject matter of any of Examples 18-21, wherein the container is hosted by a multiple access edge computing (MEC) host and wherein the external domain endpoint is hosted in a cloud.

[0066] In Example 23, the subject matter of any of Examples 17-22, wherein the network service is one of a plurality of network services provided by the local domain endpoint to the first application component.

[0067] In Example 24, the subject matter of Example 23, wherein the plurality of network services include Dynamic Host Configuration Protocol (DHCP).

[0068] In Example 25, the subject matter of Example 24, wherein the DHCP provides a configuration for the third network domain.

[0069] In Example 26, the subject matter of any of Examples 24-25, comprising: receiving a DHCP request from the first application component; and providing a configuration to the first application component.

[0070] In Example 27, the subject matter of any of Examples 25-26, wherein the configuration includes an Internet Protocol (IP) address, a default gateway IP address, or a Domain Name System (DNS) server IP address.

[0071] In Example 28, the subject matter of any of Examples 17-27, wherein forwarding traffic from the first application component to the second application component includes performing a unicast broadcast, an any-cast broadcast, a multi-cast broadcast, or a broadcast broadcast.

[0072] In Example 29, the subject matter of any of Examples 17-28, wherein the local domain endpoint operates in a networking application layer.

[0073] In Example 30, the subject matter of any of Examples 17-29, wherein the application is a virtual reality (VR) or augmented reality (AR) application.

[0074] In Example 31, the subject matter of any of Examples 17-30, wherein the first application component is a microservice.

[0075] In Example 32, the subject matter of any of Examples 17-31, wherein establishing the connection to the external domain endpoint does not use or employ a network address translation (NAT) service or a NAT protocol.

[0076] Example 33 is at least one machine-readable medium including instructions for a cross-domain distributed network function, the instructions, when executed by processing circuitry of a device, causing the device to perform operations comprising: instantiating a local-domain endpoint for a first application component, wherein the local-domain endpoint is located in a first network domain that includes the first application component, the first application component being part of an application; establishing, by the local-domain endpoint, a connection to an external-domain endpoint, the external-domain endpoint is located in a second network domain that does not include the first network domain, the second network domain including a second application component for the application;Providing, to the first application component, a network service for a third network domain, wherein the third network domain includes the application; and forwarding traffic from the first application component to the second application component over the connection in response to a call to the network service by the first application component;

[0077] In Example 34, the subject matter of Example 33, wherein the first application component is in a container.

[0078] In Example 35, the subject matter of Example 34, wherein the local domain endpoint is a container sidecar.

[0079] In Example 36, the subject matter of any of Examples 34-35, wherein the local domain endpoint is a proxy container in a service mesh for the container.

[0080] In Example 37, the subject matter of any of Examples 34-36, wherein connecting to the external domain endpoint includes using an ingress gateway of a service mesh control plane hosting the container.

[0081] In Example 38, the subject matter of any of Examples 34-37, wherein the container is hosted by a multiple access edge computing (MEC) host and wherein the external domain endpoint is hosted in a cloud.

[0082] In Example 39, the subject matter of any of Examples 33-38, wherein the network service is one of a plurality of network services provided by the local domain endpoint to the first application component.

[0083] In Example 40, the subject matter of Example 39, wherein the plurality of network services include Dynamic Host Configuration Protocol (DHCP).

[0084] In Example 41, the subject matter of Example 40, wherein the DHCP provides a configuration for the third network domain.

[0085] In Example 42, the subject matter of any of Examples 40-41, wherein the operations comprise: receiving a DHCP request from the first application component; and providing a configuration to the first application component.

[0086] In Example 43, the subject matter of any of Examples 41-42, wherein the configuration includes an Internet Protocol (IP) address, a default gateway IP address, or a Domain Name System (DNS) server IP address.

[0087] In Example 44, the subject matter of any of Examples 33-43, wherein forwarding traffic from the first application component to the second application component includes performing a unicast broadcast, an any-cast broadcast, a multi-cast broadcast, or a broadcast broadcast.

[0088] In Example 45, the subject matter of any of Examples 33-44, wherein the local domain endpoint operates in a networking application layer.

[0089] In Example 46, the subject matter of any of Examples 33-45, wherein the application is a virtual reality (VR) or augmented reality (AR) application.

[0090] In Example 47, the subject matter of any of Examples 33-46, wherein the first application component is a microservice.

[0091] In Example 48, the subject matter of any of Examples 33-47, wherein establishing the connection to the external domain endpoint does not use or employ a network address translation (NAT) service or a NAT protocol.

[0092] Example 49 is a system for a cross-domain distributed network function, the system comprising: means for instantiating a local domain endpoint for a first application component, the local domain endpoint located in a first network domain that includes the first application component, the first application component being part of an application; means for establishing, by the local domain endpoint, a connection to an external domain endpoint, the external domain endpoint located in a second network domain that does not include the first network domain, the second network domain including a second application component for the application;Means for establishing, by the local domain endpoint, a connection to an external domain endpoint, the external domain endpoint being located in a second network domain that does not include the first network domain, the second network domain including a second application component for the application; means for providing, to the first application component, a network service for a third network domain, the third network domain including the application; and means for forwarding traffic from the first application component to the second application component over the connection in response to an invocation of the network service by the first application component.

[0093] In Example 50, the subject matter of Example 49, wherein the first application component is in a container.

[0094] In Example 51, the subject matter of Example 50, wherein the local domain endpoint is a container sidecar.

[0095] In Example 52, the subject matter of any of Examples 50-51, wherein the local domain endpoint is a proxy container in a service mesh for the container.

[0096] In Example 53, the subject matter of any of Examples 50-52, wherein the means for establishing the connection to the external domain endpoint includes means for using an ingress gateway of a service mesh control plane hosting the container.

[0097] In Example 54, the subject matter of any of Examples 50-53, wherein the container is hosted by a multiple access edge computing (MEC) host and wherein the external domain endpoint is hosted in a cloud.

[0098] In Example 55, the subject matter of any of Examples 49-54, wherein the network service is one of a plurality of network services provided by the local domain endpoint to the first application component.

[0099] In Example 56, the subject matter of Example 55, wherein the plurality of network services include Dynamic Host Configuration Protocol (DHCP).

[0100] In Example 57, the subject matter of Example 56, wherein the DHCP provides a configuration for the third network domain.

[0101] In Example 58, the subject matter of any of Examples 56-57, comprising: means for receiving a DHCP request from the first application component; and means for providing a configuration to the first application component.

[0102] In Example 59, the subject matter of any of Examples 57-58, wherein the configuration includes an Internet Protocol (IP) address, a default gateway IP address, or a Domain Name System (DNS) server IP address.

[0103] In Example 60, the subject matter of any of Examples 49-59, wherein the means for forwarding traffic from the first application component to the second application component includes means for performing a unicast broadcast, an any-cast broadcast, a multi-cast broadcast, or a broadcast broadcast.

[0104] In Example 61, the subject matter of any of Examples 49-60, wherein the local domain endpoint operates in a networking application layer.

[0105] In Example 62, the subject matter of any of Examples 49-61, wherein the application is a virtual reality (VR) or augmented reality (AR) application.

[0106] Example 63 is at least one machine-readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform operations to implement any of Examples 1-62.

[0107] Example 64 is an apparatus comprising means for implementing any of Examples 1-62.

[0108] Example 65 is a system for implementing any of Examples 1-62.

[0109] Example 66 is a method for implementing any of Examples 1-62.

[0110] The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show specific illustrative embodiments that may be practiced. These embodiments are also referred to herein as "examples." Such examples may include additional elements to those shown or described. However, the present inventors also contemplate examples in which only the elements shown or described are provided. Furthermore, the present inventors also contemplate examples using any combination or permutation of the elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof) or with respect to other examples (or one or more aspects thereof) shown or described herein.

[0111] All publications, patents, and patent documents referenced in this document are incorporated herein by reference in their entirety, as if individually incorporated by reference. In the event of any conflicting usages between this document and the documents so incorporated by reference, the usage in the one or more incorporated references should be considered supplemental to that of this document; in the event of irreconcilable conflicts, the usage in this document shall prevail.

[0112] Throughout this document, the terms "a," "an," or "an" are used as is customary in patent documents to include one or more than one, regardless of any other instances or uses of "at least one" or "one or more." Throughout this document, the term "or" is used to refer to non-exclusives, or such that "A or B" includes "A but not B," "B but not A," and "A and B," unless otherwise noted. In the appended claims, the terms "including" and "in which" are used as the plain English equivalents of the respective terms "comprising" and "wherein." Furthermore, the terms "including" and "comprising" in the following claims are open-ended; that is, a system, apparatus, article, or process that includes elements additional to those listed after such a term is still considered within the scope of that claim.Furthermore, in the following claims, the terms “first”, “second”, and “third”, etc., are used only as labels and are not intended to impose numerical requirements on their objects.

[0113] The above description is intended to be illustrative and not restrictive. The examples described above (or one or more aspects thereof) may, for example, be used in combination with one another. Other embodiments may be used, for example, by those of ordinary skill in the art after reviewing the above description. The abstract is intended to enable the reader to quickly ascertain the essence of the technical disclosure and is submitted with the understanding that it is not used to interpret or limit the scope or meaning of the claims. In the above detailed description, various features may also be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim.Rather, the inventive subject matter may lie in fewer than all features of a particular disclosed embodiment. Therefore, the following claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate embodiment. The scope of the embodiments should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

[1] A method for a cross-domain distributed network function, the method comprising: Instantiating a local domain endpoint for a first application component, wherein the local domain endpoint is located in a first network domain that includes the first application component, wherein the first application component is part of an application; Establishing, by the local domain endpoint, a connection to an external domain endpoint, wherein the external domain endpoint is located in a second network domain that does not include the first network domain, wherein the second network domain includes a second application component for the application; Providing, to the first application component, a network service for a third network domain, wherein the third network domain includes the application; and Forwarding traffic from the first application component to the second application component over the connection in response to a call to the network service by the first application component. [2] The method of claim 1, wherein the first application component is located in a container. [3] The method of claim 2, wherein the local domain endpoint is a container sidecar. [4] The method of any of claims 2-3, wherein the local domain endpoint is a proxy container in a service mesh for the container. [5] The method of any of claims 2-4, wherein establishing the connection to the external domain endpoint includes using an ingress gateway of a service mesh control plane hosting the container. [6] The method of any of claims 2-5, wherein the container is hosted by a multiple access edge computing (MEC) host and wherein the external domain endpoint is hosted in a cloud. [7] The method of any of claims 1-6, wherein the network service is one of a plurality of network services provided by the local domain endpoint to the first application component. [8] The method of claim 7, wherein the plurality of network services include Dynamic Host Configuration Protocol (DHCP). [9] The method of claim 8, wherein the DHCP provides a configuration for the third network domain. [10] A method according to any one of claims 8-9, comprising: Receiving a DHCP request from the first application component; and Deploy a configuration for the first application component. [11] The method of any of claims 9-10, wherein the configuration includes an Internet Protocol (IP) address, a default gateway IP address, or a Domain Name System (DNS) server IP address. [12] The method of any of claims 1-11, wherein forwarding traffic from the first application component to the second application component includes performing a unicast transmission, an any-cast transmission, a multi-cast transmission, or a broadcast transmission. [13] The method of any of claims 1-12, wherein the local domain endpoint operates in a networking application layer. [14] The method of any of claims 1-13, wherein the application is a virtual reality (VR) or augmented reality (AR) application. [15] The method of any of claims 1-14, wherein the first application component is a microservice. [16] The method of any of claims 1-15, wherein establishing the connection to the external domain endpoint does not use or employ a network address translation (NAT) service or a NAT protocol. [17] A system comprising means for performing a method according to any one of claims 1-13. [18] At least one machine-readable medium containing instructions that, when executed by processing circuitry, cause the processing circuitry to perform a method according to any one of claims 1-13. [19] Apparatus for a cross-domain distributed network function, the apparatus comprising: a memory containing instructions; and processing circuitry configured by the instructions to: Instantiating a local domain endpoint for a first application component, wherein the local domain endpoint is located in a first network domain that includes the first application component, wherein the first application component is part of an application; Establishing, by the local domain endpoint, a connection to an external domain endpoint, wherein the external domain endpoint is located in a second network domain that does not include the first network domain, wherein the second network domain includes a second application component for the application; Providing, to the first application component, a network service for a third network domain, wherein the third network domain includes the application; and Forwarding traffic from the first application component to the second application component over the connection in response to a call to the network service by the first application component. [20] The apparatus of claim 19, wherein the network service is one of a plurality of network services provided by the local domain endpoint to the first application component. [21] The apparatus of claim 20, wherein the plurality of network services include Dynamic Host Configuration Protocol (DHCP). [22] The apparatus of claim 21, wherein the DHCP provides a configuration for the third network domain. [23] Apparatus according to any one of claims 21-22, wherein the instructions configure the processing circuitry to: Receiving a DHCP request from the first application component; and Deploy a configuration for the first application component. [24] The apparatus of any of claims 22-23, wherein the configuration includes an Internet Protocol (IP) address, a default gateway IP address, or a Domain Name System (DNS) server IP address. [25] The apparatus of any of claims 19-24, wherein the processing circuitry for establishing the connection to the external domain endpoint does not use or employ a network address translation (NAT) service or a NAT protocol.

Images