Multicast Domain Name System (mDNS)-based pull registration systems and methods facilitate discovery in communication networks, such as Storage Area Networks (SANs) that operate in non-volatile memory express over Fabric (NVMe-oF) environments. In various embodiments, this is accomplished by allowing a network entity (e.g., a Centralized Discovery Controller (CDC)) to use a pull registration to exchange discovery information with a storage subsystem (e.g., a storage array), advantageously, without requiring storage subsystem to possess complex functionalities present in existing designs.

Multicast Domain Name System (mDNS)-based pull registration systems and methods facilitate discovery in communication networks, such as Storage Area Networks (SANs) that operate in non-volatile memory express over Fabric (NVMe-oF) environments. In various embodiments, this is accomplished by allowing a network entity (e.g., a Centralized Discovery Controller (CDC)) to use a pull registration to exchange discovery information with a storage subsystem (e.g., a storage array), advantageously, without requiring storage subsystem to possess complex functionalities present in existing designs.

Techniques for providing more efficient onboarding traffic protocols in a standalone non-public network architecture are provided. A network entity includes processing circuitry and at least one memory including computer program code. The at least one memory and the computer program code configured to, with the processing circuitry, cause the network entity at least to generate one or more traffic filter rules for a traffic filter set. The one or more traffic filter rules or traffic detection rules are generated based at least in part on domain name service query response information related to one or more user device originated domain name service queries. The network entity may further be configured to cause a user plane function to be provided with the one or more traffic filter rules.

A method for providing for optimized service based interface (SBI) communications by performing network function (NF) fully qualified domain name (FQDN) resolution at an NF repository function (NRF) includes, at an NRF including at least one processor, receiving NF register requests including NF profiles and/or NF service profiles, at least some of which include FQDNs and do not include Internet protocol (IP) addresses. The method further includes storing the NF profiles and/or NF service profiles in an NF profiles database. The method further includes resolving the FQDNs in NF profiles and/or NF service profiles into IP addresses. The method further includes receiving NF discovery requests. The method further includes generating lists of NF profiles and/or NF service profiles that match query parameters in the NF discovery requests. The method further includes providing the lists of NF profiles and/or NF service profiles including the IP addresses to consumer NFs in NF discovery responses.

A network edge computing method includes receiving, by an edge data node, a service request at least processed by network edge computation scheduling; and routing, according to a service port involved in the service request, the service request to a container of the edge data node, to be processed by the container.

A device estimating apparatus acquires one or more DNS queries transmitted from each device connected to a network and generates comparison source data in which each content of the acquired DNS queries is associated with one or more pieces of attribute information of each of the one or more devices that have transmitted the DNS queries having the content. Thereafter, when one or more DNS queries are acquired from an estimation target device, the device estimating apparatus reads, for each DNS query, attribute information of one or more devices associated with a content of the DNS query from the comparison source data and estimates an attribute of the estimation target device using the read attribute information.

A device estimating apparatus acquires one or more DNS queries transmitted from each device connected to a network and generates comparison source data in which each content of the acquired DNS queries is associated with one or more pieces of attribute information of each of the one or more devices that have transmitted the DNS queries having the content. Thereafter, when one or more DNS queries are acquired from an estimation target device, the device estimating apparatus reads, for each DNS query, attribute information of one or more devices associated with a content of the DNS query from the comparison source data and estimates an attribute of the estimation target device using the read attribute information.

A tenant management system includes an application management portion and a tenant management portion. The application management portion terminates a request from a user at a tenant specific application that is an application prepared for a tenant in a solution that is built on a public cloud. The tenant management portion manages a subdomain as identification information of the tenant. Upon receiving, from the user, a query including FQDN of a server name of the tenant, the tenant management portion calls the tenant specific application for the tenant that is identified by the subdomain in the FQDN.

In an approach, a processor creates a local first Pod API object in a first lower Kubernetes cluster based on a first Pod API object in an upper Kubernetes cluster, where: the local first Pod API object includes internal and external network descriptions for a Pod described in the local first Pod API object, and the upper cluster manages the first and second lower Kubernetes cluster. A processor adds an annotation for the Pod to the local first Pod API object and the first Pod API object. A processor creates a local endpoint API object in the first lower cluster based on an endpoint API object in the upper cluster and annotations of Pods in the upper cluster. A processor redirects the first request to the endpoint of the second Pod described in the local endpoint API object.

Some embodiments establish for an entity a virtual network over several public clouds of several public cloud providers and/or in several regions. In some embodiments, the virtual network is an overlay network that spans across several public clouds to interconnect one or more private networks (e.g., networks within branches, divisions, departments of the entity or their associated datacenters), mobile users, and SaaS (Software as a Service) provider machines, and other web applications of the entity. The virtual network in some embodiments can be configured to optimize the routing of the entity's data messages to their destinations for best end-to-end performance, reliability and security, while trying to minimize the routing of this traffic through the Internet. Also, the virtual network in some embodiments can be configured to optimize the layer 4 processing of the data message flows passing through the network.