Network technology interworking via user programmable event-action profiles
US-9893937-B2 · Feb 13, 2018 · US
US12237975B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-12237975-B2 |
| Application number | US-202318469168-A |
| Country | US |
| Kind code | B2 |
| Filing date | Sep 18, 2023 |
| Priority date | Dec 20, 2022 |
| Publication date | Feb 25, 2025 |
| Grant date | Feb 25, 2025 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
A method, implemented by a controller, includes steps of: subsequent to converting a bespoke model to Open Application Programming Interface (API) Schema that is Custom Resource Definition (CRD), receiving the CRD; receiving a target that is a data record that represents a network entity; receiving a configuration model instance for the target, wherein the configuration model instance includes one or more values that are compliant to the CRD and the one or more values represent a desired state of the network entity; receiving an observed state of the network entity; and determining drift between the observed state and the desired state.
Opening claim text (preview).
The invention claimed is: 1. A method comprising steps of: subsequent to converting a bespoke model to Open Application Programming Interface (API) Schema that is a Custom Resource Definition (CRD), receiving the CRD; receiving a target that is a data record that represents a network entity; receiving a configuration model instance for the target, wherein the configuration model instance includes one or more values that are compliant to the CRD and the one or more values represent a desired state of the network entity; receiving an observed state of the network entity; and determining drift between the observed and desired states, wherein the drift includes (1) static drift where the desired state differs from the observed state based on configuration and is determined/calculated based on a comparison therebetween, and (2) constraint drift where the desired state differs from the observed state based on characteristics of the network entity and is calculated by comparing observed telemetry that determines the observed state to the desired state. 2. The method of claim 1 , wherein the steps include based on one of a range and a threshold, and responsive to determined drift being in violation for some predetermined time, triggering reconciliation to achieve the desired state. 3. The method of claim 1 , wherein the network entity is one of a server, a network element, an application, a virtualized instance of the server or the network element, and an endpoint in a network that utilizes YANG (Yet Another Next Generation). 4. The method of claim 1 , wherein the receiving an observed state is based on one or more of a change notification from and a periodic poll to the network entity. 5. The method of claim 1 , wherein the network entity has multiple bespoke models each being converted to a corresponding CRD. 6. The method of claim 1 , wherein the bespoke model utilizes YANG (Yet Another Next Generation). 7. The method of claim 1 , wherein the bespoke model is one of locally stored schema files and schema directly queried from the network entity. 8. The method of claim 1 , wherein the states are one of a configuration and a characteristic. 9. A controller comprising: one or more processors and memory storing instructions that are configured to program the one or more processors to subsequent to converting a bespoke model to Open Application Programming Interface (API) Schema that is a Custom Resource Definition (CRD), receive the CRD, receive a target that is a data record that represents a network entity, receive a configuration model instance for the target, wherein the configuration model instance includes one or more values that are compliant to the CRD and the one or more values represent a desired state of the network entity, receive an observed state of the network entity; and determine drift between the observed and desired states, wherein the drift includes (1) static drift where the desired state differs from the observed state based on configuration and is determined/calculated based on a comparison therebetween, and (2) constraint drift where the desired state differs from the observed state based on characteristics of the network entity and is calculated by comparing observed telemetry that determines the observed state to the desired state. 10. The controller of claim 9 , wherein the instructions are further configured to program the one or more processors to based on one of a range and a threshold, and responsive to determined drift being in violation for some predetermined time, trigger reconciliation to achieve the desired state. 11. The controller of claim 9 , wherein the network entity is one of a server, a network element, an application, a virtualized instance of the server or the network element, and an endpoint in a network that utilizes YANG (Yet Another Next Generation). 12. A non-transitory computer-readable medium comprising instructions for programming one or more processors to implement steps of: subsequent to converting a bespoke model to Open Application Programming Interface (API) Schema that is a Custom Resource Definition (CRD), receiving the CRD; receiving a target that is a data record that represents a network entity; receiving a configuration model instance for the target, wherein the configuration model instance includes one or more values that are compliant to the CRD and the one or more values represent a desired state of the network entity; receiving an observed state of the network entity; and determining drift between the observed and desired states, wherein the drift includes (1) static drift where the desired state differs from the observed state based on configuration and is determined/calculated based on a comparison therebetween, and (2) constraint drift where the desired state differs from the observed state based on characteristics of the network entity and is calculated by comparing observed telemetry that determines the observed state to the desired state. 13. The non-transitory computer-readable medium of claim 12 , wherein the steps include based on one of a range and a threshold, and responsive to determined drift being in violation for some predetermined time, triggering reconciliation to achieve the desired state. 14. The non-transitory computer-readable medium of claim 12 , wherein the network entity is one of a server, a network element, an application, a virtualized instance of the server or the network element, and an endpoint in a network that utilizes YANG (Yet Another Next Generation). 15. The non-transitory computer-readable medium of claim 12 , wherein the receiving an observed state is based on one or more of a change notification from and a periodic poll to the network entity. 16. The non-transitory computer-readable medium of claim 12 , wherein the network entity has multiple bespoke models each being converted to a corresponding CRD. 17. The non-transitory computer-readable medium of claim 12 , wherein the bespoke model utilizes YANG (Yet Another Next Generation). 18. The non-transitory computer-readable medium of claim 12 , wherein the bespoke model is one of locally stored schema files and schema directly queried from the network entity. 19. The non-transitory computer-readable medium of claim 12 , wherein the observed telemetry includes one or more of Performance Monitoring (PM) data and Key Performance Indicators (KPIs). 20. The non-transitory computer-readable medium of claim 19 , wherein the characteristics are a quantifiable measurement that includes one of latency, jitter, bandwidth, and any Key Performance Indicator (KPI).
Configuration setting · CPC title
Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF] · CPC title
Interprogram communication · CPC title
Event management; Broadcasting; Multicasting; Notifications · CPC title
via adapters, e.g. between incompatible applications · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.