Cisco Technology, Inc.

Sridar Kandaswamy

Sebastian Jeuk

Bob Melander

Gonzalo A Salgueiro

Rajasekhar Manam

Ralf Rantzau

Khalil A Jabr

Sudhakar Shenoy

Ramesh V N Ponnapalli

Abhijit V Warkhedi

Venkata Naga Ramesh Ponnapalli

Rajath Agasthya

Praveenkumar Reguraman

Madhusudanan Manohar

Sandeep Hebbani

Techniques are described herein for generating network topologies based on models, and deploying the network topologies across hybrid clouds and other computing environments that include multiple workload resource domains. A topology deployment system may receive data representing a logical topology model, and may generate a network topology for deployment based on the logical model. The network topology may include various services and/or other resources provided by different tenants in the computing environment, and tenant may be associated with different set of resources and deployment constraints. The topology deployment system may determine and generate the network topology to use the various resources and comply with various deployment constraints of the different tenants providing the services, and the tenants consuming the network topology.

Multi-domain and multi-tenant network topology model generation and deployment

Techniques are described herein for generating and deploying network topologies to implement machine learning systems. A topology deployment system may receive data representing a logical model corresponding to a machine learning system, and may analyze the machine learning system to determine various components and attributes of the machine learning system to be deployed. Based on the components and attributes of the machine learning system, the topology deployment system may select target resources and determine constraints for the deployment of the machine learning system. A corresponding network topology may be generated and deployed across one or a combination of workload resource domains. The topology deployment system also may monitor and update the deployed network topology, based on performance metrics of the machine learning system and/or the current status of the system in a machine learning pipeline.

Network topology model generation and deployment for machine learning systems

Techniques for deploying, monitoring, and modifying network topologies operating across multi-domain environments using formal models and weighting factors assigned to computing elements in the network topologies. The weighting factors restrict or allow the movement of various computing elements and/or element groupings to prevent undesirable disruptions or outages in the network topologies. Generally, the weighting factors may be determined based on an amount of disruption experienced in the network topologies if the corresponding computing element or grouping was migrated. As the amount of disruption caused by modifying a particular computing element increases, the weighting factor represents a greater measure of resistivity for migrating the computing element. In this way, topology deployment systems may allow, or disallow, the modification of particular computing elements based on weighting factors. Thus, the amount of disruption in the functioning of network topologies may be considered when optimizing the allocation of computing elements across multi-domain environments.

Determining formal models using weighting factors for computing elements in multi-domain environments

Techniques are described herein for deploying, monitoring, and modifying network topologies comprising various computing and network nodes deployed across multiple workload resource domains. A deployment system may receive operational data from a network topology deployed across multiple workload resource domains, such as public or private cloud computing environments, on-premise data centers, and the like. The operational data may be provided to a trained machine-learning model, and output from the trained model may be used, along with constraint inputs and resource inventories of the workload resource domains, to determine updated topology models which may be deployed within the workload resource domains.

Machine-learning infused network topology generation and deployment

A deployment system may generate and deploy network topology models within one or more workload resource domains. In some examples, the deployment system may implement a hierarchical data structure to store and manage multiple variations of a network topology models, in which network topology definitions and other characteristics may be inherited between related elements in the data structure. Data structures storing network topology models may be implemented as hierarchical levels of elements storing related, overlapping, and/or alternative portions of network topologies. A network topology model may be generated for deployment by combining the portions of network topologies stored within a branch of elements in the hierarchy, and the model may be deployed across one or more workload resource domains. Modifications to network topology models may be applied to individual elements and/or propagated to related elements based on the relationships and metadata defined for the in the hierarchical structure.

Generation and deployment of inherited network topology models

Techniques for edge cloud identification. An indication of edge clouds is received. Each edge cloud is uniquely identifiable via an associated edge cloud identifier. A characteristic is received from each of the edge clouds. An edge cloud for communication is determined based on the characteristic. The edge cloud is communicated with using its associated edge cloud identifier.

Identifying edge clouds within networks

Techniques are described herein for generating and modifying formal network topology models, and deploying network topologies based on the formal models across multiple workload resource domains. A topology deployment system may receive modification data for a deployed network topology, and analyze the modification data to determine whether the associated formal network topology model is to be recomputed. In some examples, modifications to a deployed network topology that do not impact operational performance or compromise functional equivalence with the underlying logical model, need not trigger a recomputation of the network topology model immediately and could be delayed. Modifications to deployed network topologies that do not trigger recomputations of the formal network topology model may be stored and tracked, so that subsequent recomputations of the model may incorporate the pending modifications.

Delayed recomputation of formal network topology models based on modifications to deployed network topologies

In an embodiment, a computer-implemented method comprises receiving logical model input that specifies a logical topology model of networking elements and/or computing elements for deployment at least partially in a private cloud computing infrastructure and at least partially in a public cloud computing infrastructure; receiving resource input specifying an inventory of computing elements that are available at least partially in the private cloud computing infrastructure and at least partially in the public cloud computing infrastructure; automatically generating an intermediate topology comprising a set of deployment instructions that are capable of execution at least partially in the private cloud computing infrastructure and at least partially in the public cloud computing infrastructure to cause physical realization of a network deployment corresponding to the logical topology model; determining whether the intermediate topology is functionally equivalent to the logical topology model; in response to determining that the intermediate topology is functionally equivalent to the logical topology model, transmitting the deployment instructions at least partially to the private cloud computing infrastructure and at least partially to the public cloud computing infrastructure.

Formal model checking based approaches to optimized realizations of network functions in multi-cloud environments

Determining formal models using weighting factors for computing elements in multi-cloud environments

Certain aspects of the present disclosure provide a method for managing network operations. The method generally includes selecting an edge cloud of a plurality of edge clouds to be used for performing one or more network operations for at least one endpoint device. In certain aspects, the selection may be based on an indication of at least one of an amount of available resources or capabilities associated with each of the plurality of edge clouds. In certain aspects, the method also includes configuring the edge cloud to perform the one or more network operations based on the selection.

A method and apparatus for dynamic integration of a covert namespace are provided. A Software-Defined Networking (SDN) controller is configured to send a request for workload transfer to an endpoint where the endpoint is connected to a virtual switch. The SDN controller determines that a connection between the endpoint and the virtual switch is secure based on a tenant-specific policy associated with the endpoint. A first covert namespace is configured to be connected between the endpoint and the virtual switch to communicate to the endpoint and the virtual switch directly. The operations of the virtual switch are executed using the first covert namespace according to the tenant-specific policy. A workload is caused to be transmitted to the endpoint through the first covert namespace.

Enforcing network endpoint policies in a cloud-based environment using a covert namespace

Embodiments generally provide techniques for mapping service modules on a network device. Embodiments identify a plurality of service modules, each configured to perform a respective service. A first one of the plurality of service modules is mapped to a first one of a plurality of virtual switches on the network device. Service policy information for a plurality of virtual switches is retrieved. The service policy information is indicative of service requirements for each of the plurality of virtual switches. Upon detecting an occurrence of a predefined event, embodiments determine a second one of the plurality of virtual switches to map the first service module to, based on the service policy information. The first service module is then mapped to the second virtual switch.

Dynamic re-assignment of service ports to active virtual network switch based on service policy

A method is provided in one example and includes receiving a first packet of a connection between a client and a server. The first packet is tagged with a tag comprising a member id of a service node in a service cluster that includes a plurality of nodes having distinct member ids. The method can also include mapping the member id to the service node in a tag-to-node map; receiving a second packet of the connection, where the second packet is tagged with the tag comprising the member id; determining the service node from the tag-to-node map; and forwarding the second packet to the service node.

Growing community of inventors

San Jose, CA, United States of America

Sridar Kandaswamy