Patent Grant
11695615
Configuring a network has often required a network administrator to manually configure network components to create a desired network. For example, the network administrator would often have to manually configure each of many network switches, servers, storage, and other network devices to create a desired network configuration. Although partial automation solutions have been introduced by specific vendors to integrate devices of a single vendor together, these solutions often lock a user entity into only utilizing devices and solutions of a single vendor. However, it is often desirable to utilize devices and solutions from various multiple vendors to take advantage of technological advantages of different devices and solutions as well as to optimize costs. Configuration and management of the integration and use of various network devices and solutions from multiple vendors typically require a user to manually perform integration and configuration. When new devices and solutions are added, removed or modified, modification of the entire integration and configuration may need to be performed again. Manually monitoring this type of network also adds to the complexity and inefficiencies. Therefore, there exists a need for a generalized configuration, management, and monitoring solution for network devices and solutions.
Various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.
The invention can be implemented in numerous ways, including as a process; an apparatus; a system; a composition of matter; a computer program product embodied on a computer readable storage medium; and/or a processor, such as a processor configured to execute instructions stored on and/or provided by a memory coupled to the processor. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention. Unless stated otherwise, a component such as a processor or a memory described as being configured to perform a task may be implemented as a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. As used herein, the term ‘processor’ refers to one or more devices, circuits, and/or processing cores configured to process data, such as computer program instructions.
A detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment. The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.
Configuring a network is disclosed. The network may be a collection of one or more devices that are able to be connected together. In some embodiments, at least three components work together to manage, configure, and/or monitor a network. For example, an interaction agent interacts with a user to receive and provide desired requirements, specification, and status updates; an application agent implements and manages the desired requirements and status updates across various network devices; and a proxy agent of each network component implements and manages device specific configurations and status updates of its network device. A set of network requirements is received at an interaction agent. For example, desired requirements of a network configuration are received from a user via the interaction agent. At least a portion of the network requirements are published to a system data store. For example, rather than maintaining state information and managing communication between agent components directly at each agent component, the system data store is utilized to track and provide state and communications of agent components. The published network requirements are received at an application agent. For example, the application agent has subscribed to the network requirements stored in the system data store and is notified when the set of network requirements is stored in the system data store. Device requirements are published by the application agent to the system data store for a plurality of devices. For example, the application agent has identified the plurality of devices to be utilized to implement the published network requirements and has generated specific device requirements for the each of the plurality of identified devices. The applicable device requirements are received at a proxy agent of a network device. For example, each proxy agent of each of the identified devices has subscribed to and receives the corresponding device requirements of its network device. Native hardware instructions are generated by the proxy agent to configure an individual network device. For example, the proxy agent translates the received device requirements to generate the hardware instructions to implement the received device requirements.
Interaction agent 112 facilitates interaction with users to receive and provide desired requirements, specification, and status updates. For example, a user accesses interaction agent 112 via a user interface (e.g., web interface, application interface, command line interface, application programming interface (API), configuration file interface, etc.) provided directly and/or remotely (e.g., via display, wired connection, network, etc.). Using the user interface, a user may provide high level requirements that specify a desired configuration of a desired network/device and/or receive information regarding status of devices/components of the desired network and/or an implementation status regarding the desired configuration requirements. Interaction agent 112 may manage a plurality of application agents. For example, interaction agent 112 selects an application agent among a plurality of applications to achieve/complete a desired network requirement.
Application agent 114 implements and manages the desired network requirements, configurations and status updates across various network devices. In some embodiments, application agent 114 provides device requirement instructions to and receives status information from various devices of a network being managed. For example, using desired network requirements, application agent 114 determines individual device requirements to implement the desired network requirements. The device requirements determined by application agent 114 may be declarative device requirements such that the device requirements may be translated to any of a number of different native device instructions (e.g., native instruction of devices of different vendors, device versions, device operating systems, programming interfaces, etc.) to implement the device requirements. In the example shown, application agent 114 has selected network devices 106 and 108 to implement the desired network requirements and generates unique device requirements for each network device 106 and network device 108. Proxy agent 116 receives its device requirements for network device 106 and proxy agent 118 receives its device requirements for network device 108. Each proxy agent may generate native hardware instructions implementing its device requirements to configure its associated individual network device.
In some embodiments, each proxy agent reports information about a status, an operation, and/or other information of its associated device(s). Application agent 114 may then collect and process the reported information to report the information and/or perform a responsive action. For example, when a proxy agent provides a status update that its associated device is overloaded, the application agent may add a new device to a network to offload processing and/or move a processing task of the overloaded device to another network device. The collected status information may be provided by application agent 114 to interaction agent 112 as a report and/or a request for action.
Communication between interaction agent 112, application agent 114, and proxy agents 116 and 118 are facilitated via data store 104. In some embodiments, interaction agent 112, application agent 114, and proxy agents 116 and 118 do not directly communicate with each other. For example, rather than maintaining state information and managing communication between agent components directly at each agent component, the data store 104 is utilized to track and provide state information and communications of agent components. All state information (e.g., state of device, requirements, configurations, etc.) of the agents may be stored in data store 104 rather than storing state information in the agents. When data is to be communicated between the agents, a sending agent publishes/stores the data to be communicated to data store 104. The agent receiving the data may read the data from data store 104 and/or may be pushed the data. For example, an agent subscribes to be notified when a certain type of data is stored in data store 104 and the agent is notified when a new or a modification to the certain type of data is received at storage 104. In some embodiments, an agent periodically polls/checks data store 104 for data. Data store 104 may be included in a networked storage service. In the example shown, the agents access data store 104 via network 110. In some embodiments, data store 104 is directly connected to management server 102 via a non-shared connection. In various embodiments, data store 104 is included in any of the components shown in
Network device 106 and network device 108 may be any type of device connected to network 110. Examples of network device 106 and network device 108 include a server, a network switch, a network router, a cache server, a storage device, a hypervisor switch, virtual router, a load balancer, a firewall, a network fabric device, a virtual network device, a software device, a software component or any type of computer or networking device that may be physical or virtual. Proxy agent 116 is a software and/or hardware component included in network device 106. Proxy agent 116 manages network device 106. Proxy agent 118 is a software and/or hardware component included in network device 108. Proxy agent 118 manages network device 108. Examples of network 110 include one or more of the following: a direct or indirect physical communication connection, a mobile communication network, Internet, intranet, Local Area Network, Wide Area Network, Storage Area Network, and any other form of connecting two or more systems, components, or storage devices together. Other communication paths may exist and the example of
Although single instances of many of the components shown in
At 202, a set of network requirements is received at an interaction agent. In some embodiments, the interaction agent is an interaction agent such as interaction agent 112 of
In some embodiments, the set of network requirements includes a specification of a desired configuration, setting, topology, and/or other specification of a network/service and/or one or more devices connected or able to be connected to the network. In some embodiments, the set of network requirements includes a set of declarative requirements. For example, declarative requirements express a desired configuration of network components without specifying an exact native device configuration and control flow. By utilizing declarative requirements, what should be accomplished may be specified rather than how it should be accomplished. Declarative requirements may be contrasted with imperative instructions that describe the exact device configuration syntax and control flow to achieve the configuration. By utilizing declarative requirements rather than imperative instructions, a user and/or user system is relieved of the burden of determining the exact device configurations required to achieve a desired result of the user/system. For example, it is often difficult and burdensome to specify and manage exact imperative instructions to configure each device of a network when various different types of devices from different vendors are utilized. The types and kinds of devices of the network may dynamically change as new devices are added and device failures occur. Managing various different types of devices from different vendors with different configuration protocols, syntax and software versions to configure a cohesive network of devices is often difficult to achieve. Thus, by only requiring a user/system to specify declarative requirements that specify a desired result applicable across various different types of devices, management and configuration of the network devices becomes more efficient.
In various embodiments, the set of network requirements specify a desired configuration, a desired action, a command, or any other instruction or desired result of one or more devices. One example of the set of network requirements is a set of requirements to establish a network topology. For example, a mesh network (e.g., Layer 3 Clos Network) is desired to be established and the set of network requirements specify desired parameters of the desired mesh network. In a Clos Network, every lower-tier switch (e.g., leaves) is connected to each of the top-tier switches (e.g., spines) in a full-mesh topology. A portion of an example set of requirements that specify an instruction to establish an L3 Clos network configuration received via a received requirements file is below:
In some embodiments, the set of requirements is verified for validity and correctness. For example, it is verified that the set of network requirements has been received from an authorized and validated source, the provided requirement specification syntax is correct, valid requirements have been provided, all required parameters for a desired result have been specified, and provided requirements are able to be achieved via available hardware/software resources/devices.
At 204, at least a portion of the set of network requirements is published to a system data store. For example, the set of network requirements are published to data store 104 of
In some embodiments, publishing the set of network requirements includes storing the set of network requirements in the system data store to allow an application agent to read and access the published set of requirements. Thus rather than directly communicating the set of network requirements to the application agent, the interaction agent publishes the set of requirements to the storage to communicate the information to the application agent. In some embodiments, publishing the set of requirements includes selecting one or more application agents that are to receive appropriate network requirements. For example, there exists a plurality of different application agents and each application agent performs a different type of processing and/or processing for a different set of one or more network devices. In order to achieve/complete the set of network requirements, the set of network requirements may need to be routed to the appropriate application agent for further processing. In some embodiments, the set of network requirements are processed to identify which application agent should receive which portion (or all) of the set of requirements and the requirement(s) to be received by each appropriate application agent is published to a different storage location or identified by a different identifier of the system data store corresponding to the appropriate application agent. For example, the data store includes different data records corresponding to each different application agent and requirement(s) may be communicated to an application agent by publishing requirements to the corresponding data record of the desired application agent. In another example, an identifier included in the published data identifies which application agent should receive the published data.
In some embodiments, the received set of requirements is modified prior to being published. For example, the received set of network requirements is translated into a form that can be published to a data store. In another example, additional requirements determined to be required to achieve the received set of requirements are added. In another example, one or more requirements determined to be not required to achieve the received set of requirements are removed. In another example, one or more requirements of the received set of requirements are modified.
In some embodiments, publishing the set of requirements includes storing/creating an identifier in the system data store that identifies the status of one or more requirements of the set of network requirements. For example, an identifier is stored in the system data store that identifies that the set of network requirements have been published in the system data store and is ready to be processed by one or more application agents. As the set of network requirements are processed by an application agent and other agents, the status identifier may be updated by an application agent or other agents to provide an update of the status of achieving/completing the corresponding requirements.
At 302, a set of network requirements is received at an application agent. In some embodiments, the application agent is application agent 114 of
In some embodiments, the received set of requirements is the set of requirements published in 204 of
In some embodiments, by subscribing to a data record, the application agent may be provided a notification by the data storage in the event data is published to a subscribed data record and/or includes a subscribed data identifier. In some embodiments, by subscribing to a data record and/or a data identifier, the application agent may be automatically provided/sent any data published to the subscribed data record and/or identified by the data identifier. In some embodiments, the receiving the set of network requirements includes receiving an indication that the set of network requirements of interest have been stored in the data store and the application agent requests and obtains the set of network requirements of interest. In some embodiments, the receiving the set of network requirements includes automatically receiving content of the set of network requirements subscribed by the application agent. In some embodiments, receiving the set of requirements includes directly receiving the set of requirements from an interaction agent.
At 304, device requirements corresponding to the received requirements are published to a system data store. In some embodiments, the network requirements received by the application agent are processed by the application agent to determine the appropriate device requirements for one or more devices that are to be configured to implement the received network requirements. For example, the application agent analyzes the received network requirements and determines one or more devices (e.g., devices determined and selected by device type, capability, quantity required, processing capability, etc. required to implement received requirements) that will be utilized to implement the received network requirements. For each of the one or more devices that are to be configured, the application agent determines its individual device requirements.
In some embodiments, the device requirements for each individual device are declarative requirements. For example, the device requirements include a specification of a desired configuration, setting, and/or other specification of a network device. The declarative requirements express a desired configuration of a network device without specifying an exact native device configuration and control flow instructions. By utilizing declarative requirements, what should be accomplished in the network device is specified rather than exact native hardware instructions. By utilizing declarative requirements rather than imperative instructions, the application agent is relieved of the burden of determining the exact device programming and configuration syntax required to achieve a desired result. For example, it is often difficult and burdensome for a single component to be configured and updated to know exact imperative syntax and configuration paradigm to configure each device of a network when various different types of devices from different vendors may utilized and interchanged dynamically on the network.
In some embodiments, publishing the device requirements includes storing the device requirements in a system data store (e.g., data store 104 of
In one example, the set of requirements to establish the L3 Clos network configuration described previously is received at the application agent and the application agent analyzes the received requirements and determines and identifies devices that will be utilized to implement the desired network configuration of the received network requirements. The example L3 Clos network requirements specify the number of spine network switch devices to be 16 and the number of leaf network switch devices to be 128. In total, the application agent will determine and identify 144 devices that will need to be configured to implement the desired Clos network. For each of the devices that are to be utilized, the application agent determines the individual device requirements in implementing the desired Clos network. The individual device requirements may be stored in a corresponding system data store entry for each device. For example, the application agent publishes the individual device requirements in 144 different data entries of the data store and each proxy agent of each device accesses these data entries to receive the corresponding device requirements. In the L3 Clos network example, below is one example of device requirements for one of the 144 different device requirements.
In some embodiments, publishing the device requirements includes storing/creating an identifier in the system data store for each device requirement of devices to be utilized to implement the received network requirements. The published “Status” device requirement in the previous Clos network example specifies a status of achieving the device requirement. This status identifier may be updated by a proxy agent of the network switch device as the device requirements are achieved/completed. For example, an identifier is stored in the system data store that identifies that the device requirements for a device have been published in the system data store and are ready to be processed by an appropriate proxy agent (e.g., set in “defined” state). As the device requirements are processed by the proxy agent, the status identifier may be updated by the proxy agent to provide an update of the status of achieving the device requirements.
At 402, device requirements are received at a proxy agent. In some embodiments, the proxy agent is proxy agent 116 or 118 of
In some embodiments, the received device requirements are the device requirements published in 304 of
At 404, native hardware instructions are generated at the proxy agent to configure a device of the proxy agent. In some embodiments, the device requirements received by the proxy agent are processed by the proxy agent to generate the native hardware instructions implementing the received device requirements. For example, received declarative instructions are converted to imperative instructions. In some embodiments, the native hardware instructions are in the native programming/configuration syntax of the device. For example, the native hardware instructions are generated in a format native to a configuration software interface of the device. In some embodiments, the native hardware instructions are instructions that can be understood/processed by a software component of the device to configure the device. In some embodiments, the native hardware instructions are in a form that can be directly utilized by the device to configure the device. In some embodiments, the native hardware instructions are executed by the device. For example, the generated native hardware instructions are issued for execution on the device.
In one example, the device requirements to become a spine switch of the L3 Clos network configuration described previously in the specification are received at the proxy agent and the proxy agent analyzes the received device requirements and generates native network switch device instructions to configure the network switch device to become a spine switch of a Clos network with the specified IP address and specified neighbors.
At 406, a status of the device is provided. In some embodiments, step 406 is optional and may not be performed. In some embodiments, providing the status includes publishing an identifier of the status to a system data store (e.g., data store 104 of
In some embodiments, the status of the device indicates a status of implementing device requirements on the device. For example, the status may be one of six states. The initial first example state is a “defined” state that indicates that the device requirement has been successfully published to a system data store by an application agent. A second example state is a “staged” state that is indicated by a receiving proxy agent that the proxy agent has received the device requirements and has allocated resources to implement the device requirements. A third example state is a “rendered” state that indicates that the proxy agent has generated native hardware instructions corresponding to the device requirements. A fourth example state is a “deployed” state that indicates the proxy agent has issued the generated native hardware instruction for execution on the device. A fifth example state is an operational state that indicates that the generated native hardware instructions are successfully executed on the device. However, when an error is encountered, a sixth example “error” state may be indicated to indicate that an error has been encountered.
In some embodiments, the status of the device indicates a health state of the device. For example, indication of information such as processing load, CPU utilization, storage utilization, memory utilization, version identification, errors encountered, network status, network bandwidth, network latency, etc. may be provided. In some embodiments, the status of the device indicates a packet drop rate. For example, an indication of a Ternary Content Addressable Memory (i.e., TCAM) utilization of the device is provided by the proxy agent. In another example, an indication is provided when a TCAM table is overflowed.
At 502, a status of a device is received. In some embodiments, the status of the device is a status of a resource of the device. In some embodiments, the status of the device is a status of device requirements being implemented by the device. In some embodiments, the status of the device is a status of any errors of the device. In some embodiments, the status of the device is the status provided in 406 of
In some embodiments, the status is received via a system data store such as data store 104 of
At 504, an expectation associated with the received status is verified. For example, one or more rules or tests are performed to verify that the status is as expected, specified, and/or within a range. In some embodiments, the expectation includes one or more tests to be performed to verify that a set of requirements provided by an interaction agent (e.g., published in 204 of
At 506, an action, if applicable, is performed based on the verification of the expectation. In some embodiments, no action is performed if the received status is as expected, specified, and/or within a range. In some embodiments, the expectation identifies the responsive action to be performed based on the received status. In some embodiments, performing the action includes reporting the received status. For example, a result of a test of the expectation and/or the received status is reported (e.g., report that a test to verify that the set of network requirements have been successfully achieved has passed to indicate that the set of network requirements have been achieved). In some embodiments, reporting the received status includes summarizing a plurality of received statuses. Reporting the status may include providing the report/status to an interaction agent (e.g., the interaction agent may provide the report/status to a user). In some embodiments, reporting the status includes publishing/updating a data record of a system data store such as data store 104 of
In some embodiments, performing the action includes configuring, moving, removing, and/or adding a device of a network and/or a process/program of a device of the network. For example, the application agent generates instructions (e.g., publishes device requirements to a system data store for a proxy agent to implement on a device) to automatically mitigate/fix an error indicated by the status (e.g., repair/replace device that has encountered an error). In one example, when a proxy agent provides a status update that its associated device is overloaded, the application agent may add a new device to a network to offload processing and/or move a processing task of the overloaded device to another network device. The collected status information may be provided by an application agent to an interaction agent as a report and/or a request for action.
In some embodiments, performing the action includes allowing another application agent that is configured to perform the action to perform the action. For example, an application agent that has determined that the received status indicates that the action should be performed informs another application agent (e.g., by publishing to a data store subscribed by the second application agent) to perform the action. In some embodiments, an interaction agent manages which application agent is to perform the action. For example, the interaction agent is informed of the status and instructs (e.g., by publishing requirements to a data store) an application agent that is able to perform responsive action to perform the responsive action. In some embodiments, performing the responsive action includes providing responsive requirements in response to the status that is received in 302 of
Although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
This application is a continuation of U.S. patent application Ser. No. 16/452,412, filed Jun. 25, 2019, which is a continuation of U.S. patent application Ser. No. 14/542,463, filed Nov. 14, 2014 (now U.S. Pat. No. 10,389,573, issued Aug. 20, 2019), which are incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 7636771 | Torii | Dec 2009 | B2 |
| 7870238 | Pusateri | Jan 2011 | B2 |
| 8156207 | Wood et al. | Apr 2012 | B2 |
| 8386593 | Gao et al. | Feb 2013 | B1 |
| 8737993 | Alves et al. | May 2014 | B2 |
| 8782182 | Chaturvedi et al. | Jul 2014 | B2 |
| 8819202 | Carolan et al. | Aug 2014 | B1 |
| 8849973 | Leib et al. | Sep 2014 | B2 |
| 8869236 | Tonogai | Oct 2014 | B1 |
| 9037969 | Wolff-Petersen et al. | May 2015 | B2 |
| 10063428 | Karam et al. | Aug 2018 | B1 |
| 10277461 | A et al. | Apr 2019 | B1 |
| 10313206 | Karam et al. | Jun 2019 | B1 |
| 10333776 | Karam et al. | Jun 2019 | B2 |
| 10374872 | Ratkovic et al. | Aug 2019 | B2 |
| 10389573 | Karam et al. | Aug 2019 | B2 |
| 10516761 | A et al. | Dec 2019 | B1 |
| 10558542 | A et al. | Feb 2020 | B1 |
| 10630540 | Karam et al. | Apr 2020 | B2 |
| 10698714 | Krishnamurthy et al. | Jun 2020 | B2 |
| 10756983 | Ratkovic et al. | Aug 2020 | B2 |
| 20020112053 | Christensen et al. | Aug 2002 | A1 |
| 20020178380 | Wolf et al. | Nov 2002 | A1 |
| 20040059812 | Assa | Mar 2004 | A1 |
| 20050091068 | Ramamoorthy | Apr 2005 | A1 |
| 20060080425 | Wood et al. | Apr 2006 | A1 |
| 20060129670 | Mayer | Jun 2006 | A1 |
| 20060241931 | Abu el Ata et al. | Oct 2006 | A1 |
| 20070130192 | Bolder et al. | Jun 2007 | A1 |
| 20070150561 | Courtney | Jun 2007 | A1 |
| 20080162609 | Bigian | Jul 2008 | A1 |
| 20090059814 | Nixon et al. | Mar 2009 | A1 |
| 20090198797 | Wang et al. | Aug 2009 | A1 |
| 20090216867 | Pusateri et al. | Aug 2009 | A1 |
| 20090282129 | Tindal | Nov 2009 | A9 |
| 20100202450 | Ansari | Aug 2010 | A1 |
| 20100293364 | Maini | Nov 2010 | A1 |
| 20100306275 | Maheshwari et al. | Dec 2010 | A1 |
| 20130060929 | Koponen et al. | Mar 2013 | A1 |
| 20140096249 | Dupont et al. | Apr 2014 | A1 |
| 20140136685 | Chan et al. | May 2014 | A1 |
| 20140200858 | Chatow et al. | Jul 2014 | A1 |
| 20150015376 | Jenkins | Jan 2015 | A1 |
| 20150188774 | Nadaf et al. | Jul 2015 | A1 |
| 20150248487 | Baranowski et al. | Sep 2015 | A1 |
| 20150379409 | Hu et al. | Dec 2015 | A1 |
| 20160188767 | Razin | Jun 2016 | A1 |
| 20160342510 | Pani | Nov 2016 | A1 |
| 20160344772 | Monahan et al. | Nov 2016 | A1 |
| 20170109907 | Hamedani | Apr 2017 | A1 |
| 20170250881 | Kellicker | Aug 2017 | A1 |
| 20170331828 | Caldera et al. | Nov 2017 | A1 |
| 20180137155 | Majumdar | May 2018 | A1 |
| 20180210927 | Karam et al. | Jul 2018 | A1 |
| 20180316576 | Kang et al. | Nov 2018 | A1 |
| 20190173805 | Balan et al. | Jun 2019 | A1 |
| 20190238423 | Karam et al. | Aug 2019 | A1 |
| 20190306015 | Ratkovic et al. | Oct 2019 | A1 |
| 20190319830 | Karam et al. | Oct 2019 | A1 |
| 20200007495 | Balamurugan et al. | Jan 2020 | A1 |
| 20200136917 | Kang et al. | Apr 2020 | A1 |
| 20200213189 | Karam et al. | Jul 2020 | A1 |
| 20200274772 | A et al. | Aug 2020 | A1 |
| 20200313957 | A et al. | Oct 2020 | A1 |
| 20200313980 | A et al. | Oct 2020 | A1 |
| 20200326924 | A et al. | Oct 2020 | A1 |
| 20200328949 | Ratkovic et al. | Oct 2020 | A1 |
| 20200344171 | Sharma et al. | Oct 2020 | A1 |
| Number | Date | Country |
|---|---|---|
| 101310263 | Nov 2008 | CN |
| 101582794 | Nov 2009 | CN |
| 103051481 | Apr 2013 | CN |
| 2007030305 | Mar 2007 | WO |
| 2007140337 | Dec 2007 | WO |
| Entry |
|---|
| U.S. Appl. No. 16/400,936, filed May 1, 2019, naming inventors Ratkovic et al. |
| Bjorklund, “YANG—A Data Modeling Language for the Network Configuration Protocol (NETCONF),” Internet Engineering Task Force (IETF), RFC 6020, Oct. 2010, 174 pp. |
| Enns et al., “Network Configuration Protocol (NETCONF),” Internet Engineering Task Force (IETF),RFC 6241, Jun. 2011, 114 pp. |
| Enns, “NETCONF Configuration Protocol,” Network Working Group, RFC 4741, Dec. 2006, 96 pp. |
| Examination Report from counterpart European Application No. 15858564.6, dated Feb. 7, 2019, 4 pp. |
| Extended Search Report from counterpart European Application No. 15858564.6, dated Mar. 29, 2018, 8 pp. |
| First Office Action and Search Report, and translation thereof, from counterpart Chinese Application No. 201580055839.8, dated Mar. 12, 2020, 29 pp. |
| Harrington et al., “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” Network Working Group, RFC 3411, Dec. 2002, 65 pp. |
| International Preliminary Report on Patentability from International Application No. PCT/US2015/059083, dated May 26, 2017, 7 pp. |
| International Search Report and Written Opinion of International Application No. PCT/US2015/059083, dated Mar. 2, 2016, 8 pp. |
| Notice of Intent to Grant and Text Intended to Grant from counterpart European Application No. 15858564.6, dated Feb. 4, 2020, 36 pp. |
| Prakash et al., “PGA: Using Graphs to Express and Automatically Reconcile Network Policies,” SIGCOMM '15: Proceedings of the 2015 ACM Conference on Special Interest Group on Data Communication, Aug. 2015, pp. 29-42, https://doi.org/10.1145/2785956.2787506, 14 pp. |
| Prosecution History from U.S. Appl. No. 14/542,463, dated Aug. 26, 2016 through Jul. 15, 2019, 147 pp. |
| Response to Examination Report dated Feb. 7, 2019 from counterpart European Application No. 15858564.6, filed Jun. 3, 2019, 18 pp. |
| Response to Extended Search Report dated Mar. 29, 2018 from counterpart European Application No. 15858564.6, filed Oct. 15, 2018, 13 pp. |
| Second Office Action and Search Report, and translation thereof, from counterpart Chinese Application No. 201580055839.8, dated Sep. 2, 2020, 8 pp. |
| U.S. Appl. No. 16/360,660, filed Mar. 21, 2019, naming inventors Rachamadugu et al. |
| U.S. Appl. No. 17/104,804, filed Nov. 25, 2020, naming inventors Hafeez et al. |
| Prosecution History from U.S. Appl. No. 16/452,412, dated Aug. 21, 2020 through Nov. 19, 2021, 87 pp. |
| First Office Action and Search Report from counterpart Chinese Application No. 202110186643.X dated Jan. 20, 2023, 7 pp. |
| Number | Date | Country | |
|---|---|---|---|
| 20220086033 A1 | Mar 2022 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 16452412 | Jun 2019 | US |
| Child | 17532855 | US | |
| Parent | 14542463 | Nov 2014 | US |
| Child | 16452412 | US |
