Patent Application
20170131980
Field
Embodiments of the systems and methods described herein are generally related to data network management.
Background
In recent years, there has been a push to drive the configuration and runtime management of networking applications from a conceptual data model. However, the internal data structures used by the networking applications may not conform to the defined data model. A network management system may communicate with network device elements and external systems in a data network via a network management protocol. Messages sent and received via the network management protocol may conform to the conceptual data model, but networking applications may require a translation to be applied to map the messages to the internal data structures of the networking applications.
This approach is inefficient and may require significant processing power. Further, network management systems may include network management software written in multiple languages, requiring multiple translations for each received network management protocol message. A solution is needed that synchronizes the internal data structures of networking applications with the conceptual data model and enables efficient communication between network management components.
The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the present disclosure and, together with the description, further serve to explain the principles of the disclosure and to enable a person skilled in the relevant art to make and use the disclosure.
The drawing in which an element first appears is typically indicated by the leftmost digit or digits in the corresponding reference number. In the drawings, like reference numbers may indicate identical or functionally similar elements.
In the detailed description that follows, references to “one embodiment”, “an embodiment”, “an example embodiment”, etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
As networks become more complex and heterogeneity increases among network device elements, network data modeling languages have simplified development of networking applications. Network data modeling languages, for example YANG, enable defining of a schema to represent network configuration and operational state data. Application developers may then use the defined data schema to implement networking applications in various languages that monitor and manipulate network configuration and state data. However, the internal data structures used in management software 102 may not emulate this data schema. For example, data from network device elements 110 or external systems may be received by management agent 104 and conform to an employed network management protocol. In order for management software 102 to consume this data, a translation may need to be applied to convert the received data to the internal data structures of the software. This translation adds latency and may require significant processing power.
In order to simplify this translation, management software 102 may implement internal data structures to mirror the defined data schema. While this reduces the complexity of mappings between external and internal data structures, a large amount of data must still be transferred between network management components, and parsing this data may be inefficient. For example, messages received via the NETCONF protocol may be in the form of an extensible markup language (XML) encoded document. These XML encoded documents may be large in size and inefficient to parse. Furthermore, any changes to the data schema require that the translation mappings and/or internal data structures be updated. If manual updating is required, this may add significant complexity to large network management systems.
In an embodiment, schema translator 206 enables automatic generation of internal data structures within management software 202 from a data schema. The data schema may be defined in a network data modeling language such as, but not limited to, YANG. In an embodiment, schema translator 206 may first translate the data schema to a data definition for a serializable data structure such as, but not limited to, a GOOGLE Protocol Buffer data definition, used for inter-process communication within management software 202. A serializable data structure may be used for efficient communication between components. Management software 202 may include multiple components defined in various programming languages. Schema translator 206 may then use the data definition to generate internal object definitions for each of the programming languages and language-specific bindings for accessing the serializable data structure, as will be discussed in more detail below. For example, schema translator 206 may generate internal data structures and language-specific bindings for a networking application written in the C programming language that mirror the data schema defined by the network data modeling language. This may allow separate network management components to read data from and write data to serializable data structures.
In an embodiment, data converter 208 enables conversion of data external to the system to a serializable data structure, and vice versa. Data received by network management system 200 may conform to a format specified by a particular network management protocol. For example, a NETCONF message received from a network device element 210 or an external system may be in the form of a NETCONF-compatible XML encoded document. Data converter 208 may convert this document into a serializable data structure, which in turn is automatically accessible via language bindings in management software 202 previously generated by schema translator 206. In this manner, no translation mappings between external data and internal software data structures may be needed.
Likewise, data converter 208 may convert a serializable data structure written by management software 202 to a network management protocol-compatible format, such as a NETCONF-compatible XML encoded document. This document may then be sent by management agent 204 to one or more network device elements 210, to an external system or application, or any combination thereof. In an embodiment, data converter 208 may validate both external data and internal serializable data structures for compliance with the defined data schema.
In an embodiment, data schema 302, once defined, is passed to schema translator 304. Schema translator 304 may then translate data schema 302 to a data definition for a serializable data structure 306. In an embodiment, data definition 306 may be constructed for a data serialization framework such as, but not limited to, GOOGLE Protocol Buffers, APACHE THRIFT, or APACHE AVRO.
In an embodiment, data schema 302 may include a plurality of extensions that direct the translation to data definition 306. Example extensions may include, according to an embodiment:
A data-new extension that specifies a particular data node of data schema 302 should be included at the top-level scope within data definition 306.
A field-name extension that specifies a field name to be used within data definition 306 for a particular data node of data schema 302.
A field-type extension that specifies a type to be used within data definition 306 for a particular data node of data schema 302.
A field-tag extension that specifies a tag number or column number for a field within data definition 306 corresponding to a particular data node of data schema 302.
In an embodiment, schema translator 304 may compile data definition 306 into internal object definitions for one or more programming languages. Each programming language may be used to develop various network management components or applications within a network management system. In the example illustrated in
In an embodiment, data schema 302 may include a plurality of extensions that direct the compilation of data definition 306 to internal object definitions for the one or more programming languages. These extensions may be passed from schema object 302 to data definition 306. Example extensions may include, according to an embodiment:
A data-flat extension that specifies memory be explicitly allocated for each internal object definition and contained fields/attributes. For example, when compiling data definition 306 into C object definitions, this extension may specify to allocate memory for each defined structure, variable, and function.
A field-inline extension that specifies explicit memory be allocated for a particular field. For example, when compiling data definition 306 into C object definitions, this extension will prevent a particular variable from being defined as a pointer.
A field-inline-max extension that specifies the maximum size of a particular repeated field, for example an array.
A field-string-max extension that specifies the maximum size of a particular text field, for example a character array.
In an embodiment, schema translator 304 may also generate one or more interface definition language (IDL) files 308 that define an interface based on the data schema. In a further embodiment, one or more IDL files 308 may be compiled into a binary library, and cross-language bindings for each programming language (e.g., Python, C, and Lua) may be generated to enable communication via the binary library. Rather than communicate between components written in different languages via a serializable data structure, the generated cross-language bindings and binary library may enable a management component or application to directly invoke functionality of another component or application. For example, a core management application may be developed in C, and a testing framework may be developed in Python. Using the generated cross-language bindings, the testing framework may be able to directly invoke methods and other subroutines of the core management application defined in the binary library for testing purposes. In an embodiment, the binary library may be dynamically linked at runtime of a management application.
An example of middleware that provides cross-language bindings between multiple programming languages is GObject Introspection maintained by THE GNOME PROJECT. In this example, one or more IDL files may be generated that reflect functionality defined in C object definitions 312. The IDL files may be compiled into a GObject binary library, and cross-language bindings may be generated for Python and Lua that may be used to make calls to the GObject library. One of skill in the art will recognize that GObject Introspection is used by way of example, and other frameworks and software components may be used in addition or as alternatives.
Data schema 302 may be updated periodically to reflect changes within a network. In an embodiment, schema translator 304 may detect updates to data schema 302 and automatically retranslate data schema 302 to a new data definition for a serializable data structure. In an embodiment, schema translator 304 may retranslate data schema 302 to a new data definition in response to manual input, for example by a network administrator. Schema translator 304 may then compile the new data definition into a new object definitions for each of the programming languages that include new bindings for accessing data within a serializable data structure. In this manner, data schema 302 may be updated without requiring manual updates to other components of a network management system. Additionally, in the case that one or more management components are not properly updated, schema translator 302 may ensure backward compatibility of software versions, according to an embodiment. For example, in an embodiment, each field may have a default value, and extra fields defined in schema translator 302 may be ignored during translation.
In an embodiment, serializable data structure 402 may contain data fields defined by a data definition, such as data definition 306 of
In an embodiment, applications 404-408 may also communicate via cross-language bindings 418 and application library 416. Application library 416 and cross-language bindings 418 may be generated by compiling one or more IDL files, such as IDL file 308 of
In an embodiment, management agent 414 sends and receives data external to network management system 400. For example, management agent 414 may send data to and receive data from other network device elements. Data may be communicated over one or more network management protocols such as, but not limited to, NETCONF and SNMP. In the example illustrated in
When an XML encoded document 412 is received by management agent 414, data converter 410 may convert XML document 412 to a serializable data structure 402 accessible by applications 404-408 via language-specific bindings. For example, XML document 412 may contain configuration data and status information for a plurality of routers within a data network. Data converter 410 may validate XML document 412 for compliance with a defined data schema, such as data schema 302 of
Applications 404-408 may also create or write to a serializable data structure 402. For example, C application 406 may define configuration data to be deployed on one or more network device elements in a data network, and this data may be written to a serializable data structure 402. Data converter 410 may then validate data structure 402 for compliance with a defined data schema, such as data schema 302 of
In an embodiment, data converter 410 may convert a plurality of received messages encoded in XML documents 412 to a single serializable data structure 402. For example, a request may be submitted from network management system 400 to retrieve configuration data for all routers within a data network. In this example, management agent 414 may receive an XML encoded response from each router in the network. Data converter 410 may merge the plurality of XML encoded documents into a single XML tree and validate the tree for compliance with a defined data schema. If the tree is determined to be valid, data converter 410 may then convert the XML tree to a corresponding serializable data structure 402. In this manner, configuration data from each router within the network may be analyzed by applications 404-408 as a single collection of data.
In an embodiment, XML document 412 may be saved by network management system 400 and written to a management database. Management database may be a part of or external to network management system 400. This may be useful to save or back up configuration information internal to network management system 400.
At stage 504, the data schema may be automatically translated to a data definition for a serializable data structure. In an embodiment, the data definition may be constructed for a data serialization framework such as, but not limited to, GOOGLE Protocol Buffers, APACHE THRIFT, or APACHE AVRO. The serializable data structure may provide and efficient means for exchanging data on the wire among network management components and applications.
At stage 506, the data definition may be compiled into a first binding for a first programming language. At stage 508, the data definition may then be compiled into a second binding for a second programming language. Each programming language may be used to develop various network management components and applications within a network management system. In an embodiment, the generated bindings may include getter and setter methods for accessing fields of a serializable data structure defined in the data definition. This may allow separate network management components to read data from and write data to serializable data structures.
At stage 604, the received data structure may be converted to an XML encoded document for use with an employed network management protocol. For example, the received data structure may be parsed and converted to a NETCONF-compatible XML encoded document to be sent as a NETCONF message. At step 606, the XML encoded document may be distributed to one or more network device elements via the employed network management protocol. XML encoded documents are used by way of example, but the received data structure may similarly be converted to other network management protocol-compatible formats for encoding messages.
At stage 704, the plurality of received XML encoded documents may be merged into a single XML tree. At stage 706, it is determined whether the XML tree is valid based on a defined data schema, such as data schema 302 of
Computer system 800 includes one or more processors (also called central processing units, or CPUs), such as a processor 804. Processor 804 may be connected to a communication infrastructure or bus 806.
One or more processors 804 may each be a graphics processing unit (GPU). In an embodiment, a GPU is a processor that is a specialized electronic circuit designed to rapidly process mathematically intensive applications on electronic devices. The GPU may have a highly parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images and videos.
Computer system 800 also includes user input/output device(s) 803, such as monitors, keyboards, pointing devices, etc., which communicate with communication infrastructure 806 through user input/output interface(s) 802.
Computer system 800 also includes a main or primary memory 808, such as random access memory (RAM). Main memory 808 may include one or more levels of cache. Main memory 808 has stored therein control logic (i.e., computer software) and/or data.
Computer system 800 may also include one or more secondary storage devices or memory 810. Secondary memory 810 may include, for example, a hard disk drive 812 and/or a removable storage device or drive 814. Removable storage drive 814 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.
Removable storage drive 814 may interact with a removable storage unit 818. Removable storage unit 818 includes a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 818 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/or any other computer data storage device. Removable storage drive 814 reads from and/or writes to removable storage unit 818 in a well-known manner.
According to an exemplary embodiment, secondary memory 810 may include other means, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 800. Such means, instrumentalities or other approaches may include, for example, a removable storage unit 822 and an interface 820. Examples of the removable storage unit 822 and the interface 820 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.
Computer system 800 may further include a communication or network interface 824. Communication interface 824 enables computer system 800 to communicate and interact with any combination of remote devices, remote networks, remote entities, etc. (individually and collectively referenced by reference number 828). For example, communication interface 824 may allow computer system 800 to communicate with remote devices 828 over communications path 826, which may be wired and/or wireless, and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 800 via communication path 826.
In an embodiment, a tangible apparatus or article of manufacture comprising a tangible computer useable or readable medium having control logic (software) stored thereon is also referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 800, main memory 808, secondary memory 810, and removable storage units 818 and 822, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 800), causes such data processing devices to operate as described herein.
Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use the inventions using data processing devices, computer systems and/or computer architectures other than that shown in
Identifiers, such as “(a),” “(b),” “(i),” “(ii),” etc., are sometimes used for different elements or steps. These identifiers are used for clarity and do not necessarily designate an order for the elements or steps.
Embodiments of the present inventions have been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.
The foregoing description of specific embodiments will so fully reveal the general nature of the inventions that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present inventions. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.
The breadth and scope of the present inventions should not be limited by any of the above-described embodiments, but should be defined only in accordance with the following claims and their equivalents.
