Patent Application
20200394169
In modern communications, messages between different devices may be transmitted according to a protocol such that a single message may contain a number of different elements known as Type Length Values (TLVs). A TLV is a particular type of encoding scheme having three fields including a “Type” field, a “Length” field, and a “Value” field. The type field contains a particular number that refers to a specific category of information according to any one of a number of vendor-neutral or vendor-specific registries. The length field designates the size of information within a TLV. The value field contains information of interest of a size expressed by the length field.
Various examples of this disclosure that are proposed as examples will be described in detail with reference to the following figures, wherein like numerals reference like elements, and wherein:
The methods and systems disclosed below may be described generally, as well as described in terms of specific examples. For instances where references are made to detailed examples, it is noted that any of the underlying principles described are not to be limited to a single example but may be expanded for use with any of the other methods and systems described herein as will be understood by one of ordinary skill in the art unless otherwise specifically stated.
For the purposes of this disclosure, the following definitions apply.
The term “process” refers to a set of instructions that may be encoded so as to be implemented on one or more computer-based machines.
The term “message” refers to some form of formatted information that is transmitted by a first communication device (or system) and received by a second communication device (or system).
The term “TLV” (as discussed above) refers to a particular type of encoding scheme having three fields including a “Type” field, a “Length” field, and a “Value” field. When embedded in a message, any number of individual TLV elements can be placed in any order within the body of the message.
The term “standard” as used herein refers to any rule or set of rules used to establish one or more conforming properties of a TLV and that are obligatory to TLV recognition. For example, a “standard” TLV is typically obliged to contains a type field that is a pure binary number of a fixed size. Similarly, it is standard for a length field to be an eight-bit unsigned integer. A failure to conform with a set of TLV standards will typically result in an inoperable TLV that will not be recognized and parsed by devices designed to process TLVs.
The term “custom” as used herein refers to any TLV that is designed to satisfy some utility not met by any known/registered TLV. For example, a number of new, custom TLVs may be deemed appropriate to address a notification process designed to defend against a new form of illicit computer intrusion in a specialized communication system, such as a VLAN (Virtual Local Area Network).
The term “script” as used herein is to be broadly defined as any sequence of information, e.g., commands and/or parameters, provided by a user capable of defining a custom TLV. For example, it is to be appreciated that a “script” may be provided as a stand-alone file/document, or as a part of a larger document. For instance, an individual “script” may take the form as a portion of a document that includes multiple TLV-related scripts or as a document that contains other commands/information not directed to TLVs. Further, it is also to be appreciated that a “script” may take the form of information/commands provided using any number of more interactive approaches, such as information/commands entered by a user via a Command Line Interface (CLI) or entered in appropriately labeled fields provided by a Graphic User Interface (GUI).
The term “structure” as used with respect to TLVs refers to the arrangement, combination and size of data fields/attributes within a TLV. For example, the length of a TLV and the length of a specific portion of a TLV are aspects of a TLV's structure. Similarly, “structure” may refer to the number of different fields i attributes within the TLV, and the relative arrangement of the fields/attributes. “Structure” also refers to the type of data (e.g., binary, decimal, string, MAC (Media Access Control), etc.) within a TLV. That is, while a particular numeric value may not be an issue of structure, whether the particular number is represented by an alphanumeric string, represented by a decimal formatted number or represented by a binary formatted number is an issue of structure.
The term “registry” refers to any formal or informal list of TLVs that are supported by a particular vendor or protocol. Similarly, a “registered” TLV refers to a TLV that is supported by a particular vendor or protocol. For example, a TLV may be considered “registered” if supported by a single vendor. Similarly, a TLV may be considered “registered” if it is supported by any protocol established by industry agreement or by a standards-making body.
Thus, TLVs may be considered as either vendor-specific or vendor-neutral.
Vendor-specific TLVs generally refer to TLVs established to support a specific vendor's product line. Most control plane protocols allow individual vendors to define TLVs according to their own TLV-conforming registries to enable effective communication between compatible devices. However, the idea of “vendor-specific” may be extended to any single manufacturer, group of manufacturers, or similar entities that agree to support a particular product line. An example of a vendor-specific protocol is Hewlett-Packard Enterprises' Aruba operating system (ArubaOS)™, which may be used to define vendor-specific TLVs to detect device types and to communicate the existence of rogue access points (APs) on a network.
Vendor-neutral TLVs refer to TLVs established to support some form of industry-standard protocol. An example of a vendor-neutral protocol that uses TLV technology is the Link Layer Discovery Protocol (LLDP), which is a vendor-neutral Data Link Layer (DLL) protocol used by networked devices to advertise their identity, capabilities, and neighbors on Local Area Networks (LANs).
Most network vendors support vendor-neutral TLVs as part of general protocol compliance but, due to the expense, the same vendors may be reluctant to add even limited support for vendor-specific issues. The problem may be complicated when vendors are asked to support heterogeneous networks that use equipment from multiple vendors.
Supporting a new TLV (vendor-neutral or vendor-defined) typically involves a firmware upgrade to any device intended to use the new TLV. Such firmware upgrades, in turn, can involve a lengthy delay. For example, when a particular vendor needs to add support for LLDP-based TLVs the vendor will likely need to invest considerable time and resources in the firmware code that supports the appropriate LLDP module, which directly affected the time-to-market for the appropriate firmware upgrade release.
To address this time-to-market delay, the disclosed methods and systems use an approach where a user (e.g., network/system administrator) can directly configure a switch (or other communication device) to detect new, custom TLVs using a predefined software-based script that does not require direct vendor support. The disclosed methods and systems also allow the user to define those specific actions a device should take upon receipt of such new TLVs. By allowing system/network administrators to create custom TLVs, any delay for waiting for firmware upgrades may be mitigated. Such an approach provides an on-demand capability for customers to enable specific utility independent of the vendors that supply their equipment by creating their own TLV libraries.
These TLV libraries, which can take the form of any number of database structures: (1) identify the various components of custom TLVs, (2) define the actions to execute on identifying custom TLVs, and (3) define other properties for filtering the custom TLVs, such as the “max occurrences” of a TLV, “on repeat action” for a TLV, etc. Such a library thus eliminates the need for adding detection logic for any new TLV that would otherwise need to be directly supported by vendor-supplied firmware.
The OUI (organizationally unique identifier)/VENDOR_ID attribute in standard TLVs is typically a 24-bit number that uniquely identifies an organization, e.g., a vendor, manufacturer, or other organization. However, as is further discussed below for the example of the present disclosure, the OUI/VENDOR_ID attribute can optionally use a non-standard format, e.g., an alphanumeric string, that will not be processed by devices/systems that are not appropriately modified to recognize such non-standard OUI/VENDOR_ID attributes.
The MAX_OCURANCES attribute defines the maximum number of times that the custom TLV can appear in the same Protocol Data Unit (PDU), and the ON_REPEAT_ACTION attribute defines an action to take when the same attribute of a custom TLV appears more than once in a PDU.
Finally, the FIELD attribute defines a list of individual fields (tokens) which each represent a separate data element within the custom TLV.
Turning to
As with the OUI/VENDOR_ID attribute of
As is demonstrated below, the disclosed methods and systems provide a number of distinct advantages. For instance, the disclosed methods and systems provide a unique platform where TLVs represent a user-configurable attribute that allows users to provide new and useful functionality for networking platforms that, without the disclosed methods and systems, would not allow for customization. That is, the present methods and systems provide an approach that de-couples the data and control planes so as to enable direct user-control of a network's data plane thus making network administration more flexible. Further, the disclosed methods and systems provide for a wide variety of user-friendly and intuitive tools to enable this customization.
Accordingly, the following advantages are provided. First, a user does not have to depend on a switch vendor to support a new TLV, which is a substantial advantage for small network providers that present only a small percentage of a vendor's business.
Second, users can use the disclosed methods and systems to design TLVs across different (otherwise incompatible) switches made by different vendors.
Third, the present methods and systems minimize “code churn.” By way of example, a system “bug” fix may be analyzed and resolved in a matter of hours by a user versus a matter of months by a vendor. Still further, a bug-related software performance regression (i.e., a situation where the software still functions correctly, but performs slowly and/or uses more memory than before due to a system patch caused by bug fixes included in a system firmware patch) may also be resolved in a matter of hours by a user versus a matter of months by a vendor.
As is discussed below, in order to make the disclosed methods and systems more user-friendly, human-readable data serialization languages, such as YAML or JSON, may be used to create the above-described TLV libraries according to a user-friendly grammar. However, any data serialization language capable of converting structured data to a format that allows sharing or storage of the data in a form that allows recovery of its original structure may be equally advantageous, while other languages (although usable) may be less advantageous.
Returning now to the drawings,
The message source 310 and message destination 320 of the example of
In operation, the message source 310 sends a number of messages containing TLV elements to the message destination 320 via the communication conduit 330.
In response, the message destination 330 receives the messages containing the TLV elements, recognizes the individual TLV elements, parses the individual TLV elements, and performs one or more actions (e.g., store a value within a TLV in a database) based upon one or more commands inherent to, or expressly encoded within, the individual TLVs.
However, in addition to recognizing, parsing, and processing known TLV, the custom TLV control system 322 allows the message destination 320 to recognize and parse custom TLVs that are not of a standard format and/or not registered. While it may be inferred from
While explained below in greater detail, the concept used by the custom TLV control system 322 involves receiving a script that includes a plurality of commands that together define both the type of the custom TLV and the structure of the custom TLV, then processing the received script to create a custom TLV configuration database entry. Once the custom TLV database entry is created it may be stored in a TLV configuration database accessible by a message parsing device, which in turn can use the custom TLV database entry to recognize, parse, and otherwise process custom TLVs.
The TLV configuration management device 410 of the example of
In operation the TLV configuration management device 410 allows a user (e.g., a network/system administrator) to “enter” a script (which encompasses entering data into and/or modifying a pre-made script template).
For example, as shown in
A particular advantage of the example script 500 of
Returning to
Again returning to
Although the example TLV configuration management device 700 of
Still further, in other examples, one or more of the various components 710-790 can take form of separate servers coupled together via one or more networks, Additionally, it should be appreciated that each of components 710-790 advantageously can be realized using multiple computing devices employed in a cooperative fashion. For example, by employing two or more separate computing devices, e.g., servers, to provide separate processing and data-handling needs, processing bottlenecks can be reduced/eliminated.
It also should be appreciated that some processing, typically implemented in software/firmware routines residing in program memory 720, alternatively may be implemented using dedicated processing logic. Still further, some processing may be performed by software/firmware processes residing in separate memories in separate servers/computers being executed by different controllers.
In operation, the example TLV configuration management device 700 can first perform a number of setup operations including transferring an operating system and a number of appropriate program(s) (such as the TLV processing program 752 shown in
Subsequent/additional operations of the TLV configuration management device 700 are discussed below with respect to
The method 800 starts in operation 810 where a user designs a new, custom TLV based on a set of one or more requirements not met by any existing TLV. As is discussed above, when designing a TLV one should address the three fields including the “Type” field, the “Length” field, and the “Value” field in a manner that satisfies the particular functionality desired by a new TLV. As is discussed above with respect to
In operation 812, the user may optionally request that the new, custom TLV be registered, either according to a vendor-neutral registry or according to a vendor-specific registry so as to create external support for the new TLV.
In operation 814, the user may design and draft an appropriate TLV configuration script using any number of languages and/or any number of script templates. As is discussed above, any number of data serialization languages may provide an advantage over languages that do not support data serialization. In the example method 800 of
In operation 816 a processing system, such as the example TLV configuration management device 700 of
In operation 820, the custom TLV configuration database entry produced in operation 818 is stored in a database, such as the TLV configuration database 422 shown in
In operation 822, a message parsing device accessing the database of operation 820 uses the custom TLV configuration database entry in response to receiving an appropriately-configured TLV that conforms with the custom TLV so as to recognize, parse, and perform the appropriate actions as defined by the TLV script developed in operations 814-816.
In operation 824, the user may opt to remove the custom TLV configuration database entry in response to receiving a standardized/registered TLV, which may be provided in, for example, an update to the operating system of a communication device/system. The example method 800 then stops at operation 890.
In various examples the above-described systems and/or methods may be implemented using any form of known or later-developed circuitry (e.g., electronic, optical) or programmable device, such as a computer-based system or programmable logic. It should be appreciated that the above-described systems and methods can be implemented using any of various known or later developed programming/scripting languages, such as “YAML,” “JSON,” “Perl,” “Object Pascal,” “Pascal” “SQL,” “C,” “C++,” “FORTRAN,” “Python,” “VHDL” and the like.
Accordingly, various storage media, such as magnetic computer disks, optical disks, electronic memories or any other form of non-transient computer-readable storage memory, can be prepared that can contain information and instructions that can direct a device, such as a computer, to implement the above-described systems and/or methods. Such storage devices can be referred to as “computer program products” for practical purposes. Once an appropriate device has access to the information and programs contained on the storage media/computer program product, the storage media can provide the information and programs to the device, thus enabling the device to perform the above-described systems and/or methods. Unless otherwise expressly stated, “storage medium” is not an electromagnetic wave per se.
For example, if a computer disk containing appropriate materials, such as a source file, an object file, an executable file or the like, were provided to a computer, the computer could receive the information, appropriately configure itself and perform the functions of the various systems and methods outlined in the diagrams and flowcharts above to implement the various functions. That is, the computer could receive various portions of information from the disk relating to different elements of the above-described systems and/or methods, implement the individual systems and/or methods and coordinate the functions of the individual systems and/or methods related to database-related services.
While the methods and systems above are described in conjunction with specific examples, it is evident that many alternatives, modifications, and variations will be apparent to those skilled in the art. Accordingly, the examples above as set forth herein are intended to be illustrative, not limiting. There are changes that may be made without departing from the scope of the present disclosure.
