Methods and Apparatus for Tunneling Legacy Network Management Messages through SNMP (Simple Network Management Protocol)
Claim Score by NHIP
Abstract
Software and/or hardware modules enable secure management of legacy network products. In an illustrated example, if a network device is managed using unsecure SNMPv1 or SNMPv2, the invention acts as an intermediary and applies SNMPv3 security, without the need to migrate the existing network management code to SNMPv3. The invention can be delivered in the form of a stand-alone box, or be integrated into existing products.

Term
Projected expiry 5 January 2027.
- Priority
- Filed
- Published
- Today
- Projected expiry
34 claims: 2 independent, 32 dependent
- 1In a network including a network management station operably coupled to a first intermediate network interface, a network device operably coupled to a second intermediate network interface, and a communication network supporting communication between the first and second intermediate network interfaces, a method for communicating network management messages from the network management station to the network device comprising:at the network management station, generating a first network management message intended for receipt at the network device;receiving the first network management message at the first intermediate network interface;in response to receiving the first network management message, generating a second network management message intended for receipt at the second intermediate network interface, the second network management message encapsulating information contained in the first network management message;and sending the second network management message from the first intermediate network interface to the second intermediate network interface over the communication network, wherein the first network management message comprises a request-type message and the second network management message comprises an SNMP message and the first network management message is encapsulated in at least part of a single variable binding of the SNMP message.
- 33Broadest claimClaim Score 41, average(NHIP)An apparatus for tunneling legacy network management messages from management stations coupled to a first network through SNMP messages to legacy network devices coupled to a second network, said apparatus comprising:a management tunnel endpoint coupled to said first network;a device tunnel endpoint coupled to said second network;a communications network coupled to said management tunnel endpoint and said device tunnel endpoint, said communications network capable of communicating SNMP messages between to said management tunnel endpoint and said device tunnel endpoint;said management tunnel endpoint having means for receiving legacy management messages from the management stations, means for encapsulating legacy management messages in at least a portion of a variable binding of an SNMP message and means for transmitting the SNMP message to the device tunnel endpoint;and said device tunnel endpoint having means for receiving SNMP messages from said management tunnel endpoint, means for decapsulating legacy management messages from a variable binding of an SNMP message, and means for transmitting legacy management messages to the legacy network devices.
Independent claims2
93 paragraphs in 6 sections, as filed
CROSS-REFERENCE TO RELATED APPLICATIONS
0001This application claims benefits from U.S. Provisional Patent Application No. 60/829,962, filed Oct. 18, 2006, the contents of which are hereby incorporated herein by reference.
INCORPORATION BY REFERENCE
0002All of the IETF (internet engineering task force) RFC (request for comments) documents cited in this application are hereby incorporated herein by reference.
BACKGROUND OF THE INVENTION
00031. Field of the Invention
0004This invention relates broadly to computer and communications networks. More particularly, this invention relates to network management messages exchanged between network management stations and managed network devices.
00052. State of the Art
0006Communications and computer networks require a management station to communicate with network devices such as routers, switches, printers, hosts, etc. The management station is responsible for configuring the network devices and determining the status of network devices. Management messages are typically in the form of a request and a response. The management station sends a request to the network device and the device responds to the management station. However, it is also common to provide for unsolicited messages from network devices to the management station. These unsolicited messages, known as trap messages, are used to indicate the occurrence of some undesirable event, e.g. device failure, printer out of paper, etc.
0007Prior to 1988, there existed many different (often proprietary) network management protocols which defined the way in which management stations and managed devices communicated. With the introduction of the internet protocol (IP) came the development of the “simple network management protocol” (SNMP). The Simple Network Management Protocol (SNMP) is an application layer protocol that facilitates the exchange of management information between network devices. It is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth. There are currently four versions of SNMP. SNMPv1 was always considered an interim protocol because, among other reasons, it lacked adequate security. SNMPv1 is defined in IETF RFC 1065-1067. SNMPv2, introduced in 1993, included a controversial security system, better performance and manager to manager communications. SNMPv2 is defined in IETF RFC 1441-1452. The security system was controversial because many thought that it was unduly complex. As a result, it was not widely accepted and a modified version, known as SNMPv2c (IETF RFC 1901-1908), was introduced with a simpler security system. In late 2002, SNMPv3 (IETF RFC 3411-3418) emerged as the current standard. SNMPv3 has a security system similar to SNMPv2 and has other improvements.
0008An SNMP-managed network consists of three key components: managed network devices, agents, and network management systems. A managed network device is a network node that contains an SNMP agent and that resides on a managed network. Managed network devices collect and store management information and make this information available to network management stations using SNMP. Managed network devices, sometimes called network elements, can be routers and access servers, switches and bridges, hubs, computer hosts, or printers. An agent is a network-management software module that resides in a network managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP. A network management station executes applications that monitor and control managed network devices. One or more network management stations must exist on any managed network.
0009Managed network devices are monitored and controlled using four basic SNMP commands: read, write, trap, and traversal operations.
0010Read (or get) commands are used by network management stations to monitor managed network devices whereby a network management station directly examines different variables that are maintained by a managed network device.
0011Write (or set) commands are used by network management stations to control managed network devices whereby a network management station changes the values of variables stored within a managed network device.
0012Trap commands are used by managed network devices to asynchronously report events to network management systems. When certain types of events occur, a managed network device sends a trap command to a network management station.
0013Traversal operations (e.g., get-next commands) are used by network management stations to determine which variables a managed network device supports and to sequentially gather information in variable tables, such as a routing table.
0014SNMP was designed for an expanding network and it adapts to new network equipment through the use of management information bases (MIBs). The MIB is a collection of information that is organized hierarchically. MIBS are comprised of managed objects that are identified by object identifiers. A managed object (sometimes called a MIB object or an object) is one of any number of specific characteristics of a managed network device. Managed objects are comprised of one or more object instances, which are essentially variables. Two types of managed objects exist: scalar and tabular. Scalar objects define a single object instance. Tabular objects define multiple related object instances that are grouped in MIB tables.
0015An object identifier (or object ID) is a numeric identifier, specified as a sequence of integers, that uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations. The top-level MIB object IDs belong to different standards organizations, while lower-level object IDs are allocated by associated organizations. Vendors can define private branches that include managed objects for their own products.
0016SNMP commands utilize variable bindings as part of their message format. A variable binding includes two fields: an object identifier (sometimes referred to as an object name) and an object value. The object identifier refers to a particular managed object stored as a part of a MIB. The object value is the value of the managed object. For any type of get request command, the object value is null (since the get request command is requesting a value).
0017SNMPv1 specified five PDUs (protocol data units): GET REQUEST (aka GET), used to retrieve management information, GET NEXT REQUEST (aka GET NEXT), used to iteratively retrieve information, GET RESPONSE (aka RESPONSE), used by the agent to respond, SET REQUEST (aka SET), used to set a parameter, and TRAP (aka a notification), used by the agent to report an alert. Later versions of SNMP added the PDUs GETBULK REQUEST, a faster iterative retrieval, and INFORM which is like TRAP but requires the manager to reply with a GET RESPONSE.
0018An SNMPv1 message contains two parts: a header and the PDU. The header contains the version number and the community name. The community name defines a group of network managers which exist within the same administrative domain. The GET, GET NEXT, RESPONSE, and SET PDUs all contain the same fields which are illustrated in Table A below.
0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="28pt" align="center" /><colspec colname="4" colwidth="21pt" align="center" /><colspec colname="5" colwidth="35pt" align="center" /><colspec colname="6" colwidth="35pt" align="center" /><colspec colname="7" colwidth="49pt" align="center" /><thead><row><entry namest="1" nameend="7" rowsep="1">TABLE A</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>PDU</entry><entry>Request</entry><entry>Error</entry><entry>Error</entry><entry>Object 1</entry><entry>Object 2</entry><entry>Object x</entry></row><row><entry>Type</entry><entry>ID</entry><entry>Status</entry><entry>Index</entry><entry>Value 1</entry><entry>Value 2</entry><entry>Value x</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0019The “PDU Type” field specifies GET, GET NEXT, RESPONSE, or SET. The “Request ID” field is used to associate responses with requests. The “Error Status” and “Error Index” fields are only used in the RESPONSE PDU. The “Object and Value” fields 1 through x are referred to as “variable bindings” and they serve as the data field of the PDU. Each variable binding associates a particular object with its current value, except in the GET and GET NEXT PDUs where the value is ignored. The TRAP PDU is illustrated in Table B below.
0000<tables id="TABLE-US-00002" num="00002"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="8"><colspec colname="1" colwidth="35pt" align="center" /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="28pt" align="center" /><colspec colname="4" colwidth="28pt" align="center" /><colspec colname="5" colwidth="28pt" align="center" /><colspec colname="6" colwidth="35pt" align="center" /><colspec colname="7" colwidth="35pt" align="center" /><colspec colname="8" colwidth="42pt" align="center" /><thead><row><entry namest="1" nameend="8" rowsep="1">TABLE B</entry></row><row><entry namest="1" nameend="8" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>Enterprise</entry><entry>Agent</entry><entry>Generic</entry><entry>Specific</entry><entry>Time</entry><entry>Object 1</entry><entry>Object 2</entry><entry>Object x</entry></row><row><entry /><entry>Address</entry><entry>Trap</entry><entry>Trap</entry><entry>Stamp</entry><entry>Value 1</entry><entry>Value 2</entry><entry>Value x</entry></row><row><entry /><entry /><entry>Type</entry><entry>Code</entry></row><row><entry namest="1" nameend="8" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0020The “Enterprise” field identifies the type of managed object generating the trap. The “Agent Address” field provides the address of the managed object generating the trap. The “Generic Trap Type” field indicates one of a number of trap types. The “Specific Trap Code” field indicates one of a number of specific trap codes. The “Time Stamp” field indicates the amount of elapsed time between the last network reinitialization and the generation of the trap. The variable bindings field “Object 1 Value 1” through “Object x Value x” each associate a particular object with its current value.
0021An SNMPv2 message also contains two parts: the message header and the PDU. The message header is the same as in SNMPv1. The PDUs for GET, GET NEXT, INFORM, RESPONSE, SET, and TRAP are the same as illustrated above in Table A. The PDU for GETBULK is illustrated in Table C below.
0000<tables id="TABLE-US-00003" num="00003"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="7"><colspec colname="1" colwidth="21pt" align="center" /><colspec colname="2" colwidth="28pt" align="center" /><colspec colname="3" colwidth="35pt" align="center" /><colspec colname="4" colwidth="35pt" align="center" /><colspec colname="5" colwidth="35pt" align="center" /><colspec colname="6" colwidth="35pt" align="center" /><colspec colname="7" colwidth="28pt" align="center" /><thead><row><entry namest="1" nameend="7" rowsep="1">TABLE C</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>PDU</entry><entry>Request</entry><entry>Non-</entry><entry>Max-</entry><entry>Object 1</entry><entry>Object 2</entry><entry>Object</entry></row><row><entry>Type</entry><entry>ID</entry><entry>repeaters</entry><entry>repetitions</entry><entry>Value 1</entry><entry>Value 2</entry><entry>x</entry></row><row><entry /><entry /><entry /><entry /><entry /><entry /><entry>Value x</entry></row><row><entry namest="1" nameend="7" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0022The “PDU Type” field identifies the PDU as a GETBULK operation. The “Request ID” field is used to associate responses with requests. The “Non-repeaters” field specifies the number of object instances in the variable bindings field that should be retrieved no more than once from the beginning of the request. This field is used when some of the instances are scalar objects with only one variable. The “Max-repetitions” field defines the maximum number of times that the variables beyond those specified by the “Non-repeaters” field should be retrieved. The variable bindings field “Object 1 Value 1” through “Object x Value x” each associate a particular object with its current value.
0023While SNMPv1 and SNMPv2 have many similarities, SNMPv3 changes the message format significantly. The format is illustrated in vertical Table D below.
0000<tables id="TABLE-US-00004" num="00004"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="105pt" align="center" /><colspec colname="2" colwidth="112pt" align="left" /><thead><row><entry namest="1" nameend="2" rowsep="1">TABLE D</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row><row><entry>Field Number</entry><entry>Field Definition</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="2"><colspec colname="1" colwidth="105pt" align="char" char="." /><colspec colname="2" colwidth="112pt" align="left" /><tbody valign="top"><row><entry>1</entry><entry>msgVersion</entry></row><row><entry>2</entry><entry>msgID</entry></row><row><entry>3</entry><entry>msgMaxSize</entry></row><row><entry>4</entry><entry>msgFlags</entry></row><row><entry>5</entry><entry>msgSecurityModel</entry></row><row><entry>6</entry><entry>msgAuthoritativeEngineID</entry></row><row><entry>7</entry><entry>msgAuthoritativeEngineBoots</entry></row><row><entry>8</entry><entry>msgAuthoritativeEngineTime</entry></row><row><entry>9</entry><entry>msgUserName</entry></row><row><entry>10</entry><entry>msgAuthenticationParameters</entry></row><row><entry>11</entry><entry>msgPrivacyParameters</entry></row><row><entry>12</entry><entry>contextEngineID</entry></row><row><entry>13</entry><entry>contextName</entry></row><row><entry>14</entry><entry>PDU</entry></row><row><entry namest="1" nameend="2" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0024The “msgVersion” field has the same meaning as the version number in the header of previous versions of SNMP. The “msgID” field is the same as the “Request ID” field in previous versions of SNMP. In SNMPv3 the msgID has a range of 0 through (2<sup>31</sup>−1). The field “msgMaxSize” indicates the maximum size of a message, in octets, supported by the sender of the message, i.e. the maximum size of a message that the sender can accept from another SNMP device. It has a range of 484 through (2<sup>31</sup>−1). The field “msgFlags” is an octet containing three flags in the three least significant bits. The flags are “reportableFlag”, “privFlag”, and “authFlag”. If reportableFlag=1, then a Report PDU must be returned to the sender under those conditions that can cause the generation of a Report PDU; when the flag is zero, a Report PDU may not be sent. The reportableFlag is set to 1 by the sender in all messages containing a request (Get, Set) or an Inform, and set to 0 for messages containing a Response, a Trap, or a Report PDU. The “reportableFlag” field is a secondary aid in determining when to send a Report. The Report PDU is used only in cases in which the PDU portion of the message cannot be decoded (for example, when decryption fails because of an incorrect key). The “privFlag” and “authFlag” fields are set by the sender to indicate the security level that was applied to the message. For privFlag=1, encryption was applied and for privFlag=0, authentication was applied. All combinations are allowed except (privFlag=1 AND authFlag=0); that is, encryption without authentication is not allowed. The field “msgSecurityModel” identifies the security model that was used to prepare the message. It has a range of 0 through (2<sup>31</sup>−1). Reserved values include 1 for SNMPv1, 2 for SNMPv2, and 3 for SNMPv3.
0025SNMPv3 implements the concept of an authoritative engine. In any message transmission, one of the two entities, transmitter or receiver, is designated as the authoritative SNMP engine, according to a set of rules. The field “msgAuthoritativeEngineID” identifies the authoritative SNMP engine. The field “msgAurthoritativeEngineBoots” is an integer in the range 0 through (2<sup>31</sup>−1) that represents the number of times that this SNMP engine has initialized or reinitialized itself since its initial configuration. The field “msgAuthoritativeEngineTime” is an integer in the 0 through (2<sup>31</sup>−1) range that represents the number of seconds since this authoritative SNMP engine last incremented “msgAurthoritativeEngineBoots”. The field “msgUserName” identifies the user on whose behalf the message is being exchanged. The field “msgAuthenticationParameters” is a parameter used in the DES encryption algorithm. The cipher-block-chaining (CBC) mode of DES is used by SNMPv3. This mode requires that an initial value (IV) be used to start the encryption process. The “msgPrivacyParameters” field in the message header contains a value from which the IV can be derived by both sender and receiver. The fields “contextEngineID” and “contextName” are used to limit access to MIBs.
0026The Structure of Management Information (SMI) defines the format for defining MIBS that are accessed via the SNMP protocol, the data types of objects, and the format for defining events (called traps in SMIv1 and notifications in SMIv2). There are currently two versions of the SMI, which are SMIv1 (full) and SMIv2 (draft). SMIv1 is defined by RFC 1155, RFC 1212, and RFC 1215. SMIv2 is defined by RFC 1902, RFC 1903, and RFC 1904.
0027Since the time SNMPv1 was introduced, a very large number of network devices have been developed and deployed in private and public networks. Many of these devices implement obsolete versions of SNMP or non-standard management protocols. Although versions prior to SNMPv3 are considered obsolete, IETF RFC 3584 explains how these different versions can coexist. Although they can coexist, the devices which implement obsolete management protocols can not take advantage of the improved features of the newer protocols, most particularly they cannot provide secure network management as provided in SNMPv3.
0028It would therefore be desirable to provide an inexpensive means by which legacy network devices and management stations can take advantage of the features of the latest version of SNMP (e.g., the security function that is part of SNMPv3) without the need for expensive software upgrading in each device.
SUMMARY OF THE INVENTION
0029It is therefore an object of the invention to provide methods and apparatus by which legacy network equipment can take advantage of the features of a later version of SNMP (e.g., the security function that is part of SNMPv3).
0030It is another object of the invention to provide methods and apparatus by which legacy network equipment can take advantage of more recent versions of SNMP without altering the legacy equipment.
0031In accord with these objects, which will be discussed in detail below, the present invention provides two modules: one for the network management stations and the other for managed network devices. The two modules create an SNMP tunnel through which legacy management messages are sent. At the manager tunnel endpoint (MTE), legacy management messages from one or more network management stations are encapsulated into SNMP messages, which are forwarded to a device tunnel endpoint (DTE). At the device tunnel endpoint (DTE), the legacy management message is decapsulated from the SNMP message, and the legacy management message is forwarded to the recipient managed network device. Legacy response messages from the managed network devices are encapsulated at the DTE into SNMP messages, which are forwarded to the MTE. At the MTE, the legacy response message is decapsulated from the SNMP message and forwarded to the recipient network management station. A single MTE may serve several network management stations and a single DTE may serve several managed network devices. A single MTE may communicate with multiple DTEs. Each MTE is configured with i) the IP addresses of the DTEs it will support and ii) the IP addresses of the devices supported by each DTE it will support. If the MTE is situated on an IP host separate from the network management station(s) that it will support, it is also configured with the IP address of such network management station(s). The DTEs are similarly configured.
0032According to the illustrated embodiment, the MTE and DTE encapsulate SNMPv1 messages into SNMPv3 messages and decapsulate the SNMPv1 messages from such SNMPv3 messages. However, the invention can be applied to encapsulate any legacy management message into any SNMP version message.
0033According to one aspect of the invention, the DTEs each maintain an MIB specifically structured to carry out the tunneling function of the invention. In particular, the MIB includes tunnel objects and tunnel traps. The tunnel objects include a tunnel trap receiver table, a tunnel command table and a tunnel response table. The tunnel command table and the tunnel response table work together to encapsulate requests and responses. The object ID of the tunnel response table is larger than the object ID of the tunnel command table and there is no MIB element between the tunnel command table and the tunnel response table. These two tables are always empty for the purposes of any GET or SET request and are only used for encapsulating and sending requests and responses. The tunnel traps include a tunnel trap receiver table which is used by the DTE to encapsulate traps. It is empty at all other times.
0034According to the illustrated embodiment, when the MTE receives a legacy message from a network management station, the source and destination addresses are extracted from the IP header. Using the MTE configuration, the DTE serving the destination address is determined. If no DTE is found, the packet is quietly dropped, i.e. dropped but no error message is generated. A sequence ID is incremented. An “augmented” PDU is built by concatenating the legacy PDU with the extracted source address and original UDP header. The augmented PDU together with the manager address, device address and sequence ID are encapsulated in the object portion of a single variable binding (with a null value) of an SNMPv3 GET NEXT PDU. The PDU is then given an SNMPv3 header, UDP header and IP header directing it to the DTE determined from the MTE configuration. The DTE receives the SNMPv3 message, extracts the augmented PDU from the object part of the variable binding, rebuilds the legacy message, and adds a UDP header and the IP header from the DTE configuration which sends it to its destination managed network device. The DTE also begins preparing for a response by writing the ultimate source address, ultimate destination address, and sequence ID to the tunnel response table.
0035When the DTE receives a legacy response message from a managed network device, it extracts the manager address (destination) and the device address (source) from the IP header. It extracts the request ID from the PDU. It builds an augmented PDU by concatenating the legacy PDU with the original UDP header and device address. The augmented PDU together with the manager address, device address and sequence ID are encapsulated in the object portion of a single variable binding (with a null value) of an SNMPv3 RESPONSE PDU. The PDU is then given an SNMPv3 header, UDP header and IP header directing it to the MTE determined from information saved in the tunnel response table (in the previous step). The MTE receives the SNMPv3 message, extracts the augmented PDU from the object part of the variable binding, rebuilds the legacy message, and adds a UDP header and the IP header from the MTE configuration which sends it to its destination network management station.
0036When the DTE receives a legacy TRAP message from a managed device, it extracts the manager address (destination) and the device address (source) from the IP header. It finds the MTE address corresponding to the manager address from the DTE configuration and if no MTE is found, the packet is quietly dropped. It builds an augmented PDU by concatenating the legacy PDU with the original UDP header and device address. The trap manager address, Object ID from the tunnel trap receiver table, and the tunnel trap payload are encapsulated in the object portion of a single variable binding of an SNMPv3 TRAP PDU. The augmented PDU is placed in the value portion of the variable binding. The PDU is then given an SNMPv3 header, UDP header and IP header directing it to the MTE determined from the DTE configuration. The MTE receives the SNMPv3 message, extracts the augmented PDU from the value part of the variable binding, rebuilds the legacy message, and adds a UDP header and the IP header from the MTE configuration which sends it to its destination.
0037Additional objects and advantages of the invention will become apparent to those skilled in the art upon reference to the detailed description taken in conjunction with the provided figures.
BRIEF DESCRIPTION OF THE DRAWINGS
0038<figref idref="DRAWINGS">FIG. 1</figref> is a schematic block diagram of two management stations coupled to four network devices through the tunneling apparatus of the invention;
0039<figref idref="DRAWINGS">FIG. 2</figref> is a schematic illustration of the tunneling MIB according to the invention;
0040<figref idref="DRAWINGS">FIG. 3</figref> is a schematic block diagram of the MTE according to the invention;
0041<figref idref="DRAWINGS">FIG. 4</figref> is a schematic block diagram of the DTE according to the invention;
0042<figref idref="DRAWINGS">FIG. 5</figref> is an illustration of how the MTE encapsulates an SNMPv1 request from a management station into an SNMPv3 message for the DTE;
0043<figref idref="DRAWINGS">FIG. 6</figref> is an illustration of how the DTE decapsulates an SNMPv1 message for a network device from an SNMPv3 message;
0044<figref idref="DRAWINGS">FIG. 7</figref> is an illustration of how the DTE encapsulates an SNMPv1 response from a network device into an SNMPv3 response for the MTE;
0045<figref idref="DRAWINGS">FIG. 8</figref> is an illustration of how the MTE decapsulates an SNMPv1 response from a an SNMPv3 response for the management station;
0046<figref idref="DRAWINGS">FIG. 8</figref><i>a </i>is an illustration of how the MTE “to manager packet receptor” handles the packet created in <figref idref="DRAWINGS">FIG. 8</figref>;
0047<figref idref="DRAWINGS">FIG. 9</figref> is an illustration of how the DTE encapsulates an SNMPv1 trap from a network device into an SNMPv3 trap for the MTE;
0048<figref idref="DRAWINGS">FIG. 10</figref> is an illustration of how the MTE decapsulates an SNMPv1 trap from a an SNMPv3 trap for the management station; and
0049<figref idref="DRAWINGS">FIG. 11</figref> is a schematic block diagram of a management station coupled to a network device through the tunneling apparatus according to an alternate embodiment of the invention.
DETAILED DESCRIPTION
0050Turning now to <figref idref="DRAWINGS">FIG. 1</figref>, according to the illustrated embodiment, a pair of network management stations <b>10</b>, <b>12</b> are coupled to a secure (local area) network <b>14</b>, also referred to as a first intermediate network. A manager tunnel endpoint (MTE) <b>16</b>, also referred to as a first intermediate network interface, is coupled to the network <b>14</b> and to a wide area network <b>18</b>, also referred to as a communication network. Two device tunnel endpoints (DTEs) <b>20</b>, <b>22</b> are coupled to the wide area network <b>18</b>. Each DTE <b>20</b>, <b>22</b>, also referred to as a second intermediate network interface, is coupled to a respective secure (local area) network <b>24</b>, <b>26</b>, also referred to as second intermediate networks. Each local area network <b>24</b>, <b>26</b> is respectively coupled to two managed network devices <b>28</b>, <b>30</b>, <b>32</b>, <b>34</b>.
0051The MTE <b>16</b> contains core configuration information about the addresses of the DTEs and the managed network devices. Exemplary MTE core configuration information is shown in Table 1.
0000<tables id="TABLE-US-00005" num="00005"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="56pt" align="left" /><thead><row><entry namest="1" nameend="4" rowsep="1">TABLE 1</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry /><entry /><entry>Device</entry></row><row><entry>Cluster</entry><entry>DTE Address</entry><entry>Device Net</entry><entry>NetMask</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>192.168.12.60</entry><entry>192.168.85.32</entry><entry>255.255.255.240</entry></row><row><entry>2</entry><entry>192.168.12.60</entry><entry>192.168.85.192</entry><entry>255.255.255.240</entry></row><row><entry>3</entry><entry>172.16.1.88</entry><entry>10.5.132.0</entry><entry>255.255.255.0</entry></row><row><entry>4</entry><entry>172.16.1.88</entry><entry>192.168.100.77</entry><entry>255.255.255.255</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0052Table 1 associates the addresses of the managed network devices <b>28</b>, <b>30</b>, <b>32</b>, and <b>34</b> with the addresses of the DTEs <b>20</b>, <b>22</b> that serve them. If the MTE is not on the same IP host as the managers, it is also provided with manager packet receptor information. Table 2 is exemplary of manager packet receptor information.
0000<tables id="TABLE-US-00006" num="00006"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="63pt" align="left" /><colspec colname="4" colwidth="63pt" align="left" /><thead><row><entry namest="1" nameend="4" rowsep="1">TABLE 2</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>Manager</entry><entry /><entry>Device</entry></row><row><entry>Cluster</entry><entry>Address</entry><entry>Device Net</entry><entry>NetMask</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>10.1.1.1</entry><entry>192.168.85.32</entry><entry>255.255.255.240</entry></row><row><entry>2</entry><entry>10.1.1.1</entry><entry>192.168.85.192</entry><entry>255.255.255.240</entry></row><row><entry>3</entry><entry>10.1.1.1</entry><entry>10.5.132.0</entry><entry>255.255.255.0</entry></row><row><entry>4</entry><entry>10.1.1.143</entry><entry>192.168.100.77</entry><entry>255.255.255.255</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0053Table 2 associates the addresses of the managed network devices <b>28</b>, <b>30</b>, <b>32</b>, and <b>34</b> with the address of the network management stations <b>10</b>, <b>12</b> that manage them.
0054The DTEs <b>20</b>, <b>22</b> each contain core configuration information about the addresses of the MTE and the network management stations. Exemplary DTE core configuration information is shown in Table 3.
0000<tables id="TABLE-US-00007" num="00007"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="49pt" align="left" /><colspec colname="4" colwidth="63pt" align="left" /><thead><row><entry namest="1" nameend="4" rowsep="1">TABLE 3</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry /><entry>Manager</entry><entry>Manager</entry></row><row><entry>Cluster</entry><entry>MTE Address</entry><entry>Net</entry><entry>NetMask</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>192.168.12.52</entry><entry>10.1.1.1</entry><entry>255.255.255.255</entry></row><row><entry>2</entry><entry>192.168.12.52</entry><entry>10.1.1.143</entry><entry>255.255.255.255</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0055Table 3 associates the addresses of the network management stations <b>10</b>, <b>12</b> with the address of the MTE <b>16</b> which serves them. If a DTE is not on the same IP host as the managed network devices it serves, it is also provided with device packet receptor information. Table 4 is exemplary of device packet receptor information.
0000<tables id="TABLE-US-00008" num="00008"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="4"><colspec colname="1" colwidth="49pt" align="center" /><colspec colname="2" colwidth="42pt" align="left" /><colspec colname="3" colwidth="63pt" align="left" /><colspec colname="4" colwidth="63pt" align="left" /><thead><row><entry namest="1" nameend="4" rowsep="1">TABLE 4</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row><row><entry /><entry>Manager</entry><entry /><entry>Device</entry></row><row><entry>Cluster</entry><entry>Address</entry><entry>Device Net</entry><entry>NetMask</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>10.1.1.1</entry><entry>192.168.85.32</entry><entry>255.255.255.240</entry></row><row><entry>2</entry><entry>10.1.1.1</entry><entry>192.168.85.192</entry><entry>255.255.255.240</entry></row><row><entry namest="1" nameend="4" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0056Table 4 associates the addresses of managed network devices <b>28</b>, <b>30</b> with the address of the network management station <b>10</b> that manages them.
0057Turning now to <figref idref="DRAWINGS">FIG. 2</figref>, the DTEs each maintain an MIB specifically structured to carry out the tunneling function of the invention and the MTEs are all aware of this MIB. In particular, the MIB includes tunnel objects and tunnel traps. The tunnel objects include a tunnel trap receiver table, a tunnel command table and a tunnel response table. The tunnel command table and the tunnel response table work together to encapsulate requests and responses. The object ID of the tunnel response table is larger than the object ID of the tunnel command table and there is no MIB element between the tunnel command table and the tunnel response table. These two tables (tunnel command and tunnel response) are always empty for the purposes of any GET or SET request and are only used for encapsulating and sending requests and responses. The MIB also includes a tunnel trap receiver table which is used by the DTE to encapsulate traps. It is empty at all other times.
0058An exemplary tunnel command table according to the invention is described in Table 5.
0000<tables id="TABLE-US-00009" num="00009"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="28pt" align="left" /><colspec colname="4" colwidth="42pt" align="left" /><colspec colname="5" colwidth="126pt" align="left" /><thead><row><entry namest="1" nameend="5" rowsep="1">TABLE 5</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>#</entry><entry>Name</entry><entry>Index?</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>managerAddress</entry><entry>yes</entry><entry>ipAddress</entry><entry>Manager that sourced the original</entry></row><row><entry /><entry /><entry /><entry /><entry>SNMPv1 request PDU.</entry></row><row><entry>2</entry><entry>deviceAddress</entry><entry>yes</entry><entry>ipAddress</entry><entry>Device that the SNMPv1 request</entry></row><row><entry /><entry /><entry /><entry /><entry>PDU was directed to.</entry></row><row><entry>3</entry><entry>sequenceID</entry><entry>yes</entry><entry>unsigned32</entry><entry>generated by the MTE to help</entry></row><row><entry /><entry /><entry /><entry /><entry>DTE's response generation.</entry></row><row><entry>4</entry><entry>cmd1</entry><entry>yes</entry><entry>octet-string</entry><entry>The first ‘n1’ octets of ‘augmented’</entry></row><row><entry /><entry /><entry /><entry /><entry>SNMPv1 request PDU.</entry></row><row><entry>5</entry><entry>cmd2</entry><entry>yes</entry><entry>octet-string</entry><entry>The next ‘n2’ octets of</entry></row><row><entry /><entry /><entry /><entry /><entry>‘augmented’ SNMPv1 request</entry></row><row><entry /><entry /><entry /><entry /><entry>PDU.</entry></row><row><entry>6</entry><entry>cmd3</entry><entry>yes</entry><entry>octet-string</entry><entry>The next ‘n3’ octets of</entry></row><row><entry /><entry /><entry /><entry /><entry>‘augmented’ SNMPv1 request</entry></row><row><entry /><entry /><entry /><entry /><entry>PDU.</entry></row><row><entry>7</entry><entry>cmd4</entry><entry>yes</entry><entry>octet-string</entry><entry>The next ‘n4’ octets of</entry></row><row><entry /><entry /><entry /><entry /><entry>‘augmented’ SNMPv1 request</entry></row><row><entry /><entry /><entry /><entry /><entry>PDU.</entry></row><row><entry>8</entry><entry>cmd5</entry><entry>yes</entry><entry>octet-string</entry><entry>The last ‘n5’ octets of</entry></row><row><entry /><entry /><entry /><entry /><entry>‘augmented’ SNMPv1 request</entry></row><row><entry /><entry /><entry /><entry /><entry>PDU.</entry></row><row><entry>9</entry><entry>status</entry><entry>no</entry><entry>integer</entry><entry>Read-only. The only ‘accessible’ element.</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0059The rows of Table 5 describe the columns of the tunnel command table. As stated above, the MIB resides with the DTE and tunnel command table is filled by the DTE with information received from the MTE. The first column of the tunnel command table is the IP address of the network management station that sent the management request. The second column of the tunnel command table is the IP address of the managed network device to which the request is directed. The sequence ID is generated by the MTE. It works like a request ID and is used in the third column of the tunnel command table to match SNMPv3 requests with responses. Columns four through eight of the tunnel command table contain a request PDU segmented into a number of segments. The number of segments and the relative sizes of the segments are arbitrary. In the illustrative embodiment described herein, five segments are used for programming convenience. More particularly, with 5 segments, a 1 Kbyte PDU is split into pieces that are each less than 256 bytes. Management message PDUs are also referred to as application data. The PDU is “augmented” as described below with reference to <figref idref="DRAWINGS">FIGS. 5 and 6</figref>. The last column of the tunnel command table is an SNMP “status integer read only”. Thus, the tunnel command table will look something like table 5A. The column labeled “PDU parts 1-5” is actually five columns. The first eight columns are considered SNMP “indexes”. The ninth column read only status integer is also defined by SNMP.
0000<tables id="TABLE-US-00010" num="00010"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="35pt" align="left" /><colspec colname="2" colwidth="49pt" align="left" /><colspec colname="3" colwidth="56pt" align="left" /><colspec colname="4" colwidth="56pt" align="left" /><colspec colname="5" colwidth="21pt" align="left" /><thead><row><entry namest="1" nameend="5" rowsep="1">TABLE 5A</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>10.1.1.1</entry><entry>192.168.85.32</entry><entry>“32-bit number”</entry><entry>“PDU parts1–5”</entry><entry>RO</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0060A tunnel response table according to the invention is similar to the tunnel command table described above and is described as Table 6 below.
0000<tables id="TABLE-US-00011" num="00011"><table frame="none" colsep="0" rowsep="0" pgwide="1"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="56pt" align="left" /><colspec colname="3" colwidth="28pt" align="left" /><colspec colname="4" colwidth="42pt" align="left" /><colspec colname="5" colwidth="119pt" align="left" /><thead><row><entry namest="1" nameend="5" rowsep="1">TABLE 6</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>#</entry><entry>Name</entry><entry>Index?</entry><entry>Type</entry><entry>Description</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>managerAddress</entry><entry>yes</entry><entry>ipAddress</entry><entry>Manager to which the MTE should</entry></row><row><entry /><entry /><entry /><entry /><entry>send the SNMPv1 response PDU</entry></row><row><entry>2</entry><entry>deviceAddress</entry><entry>yes</entry><entry>ipAddress</entry><entry>Device that sourced the SNMPv1</entry></row><row><entry /><entry /><entry /><entry /><entry>response PDU.</entry></row><row><entry>3</entry><entry>Sequence ID</entry><entry>yes</entry><entry>unsigned32</entry><entry>copied from the SNMPv3 request PDU:</entry></row><row><entry /><entry /><entry /><entry /><entry>vTunnelCmdTable.sequenceID</entry></row><row><entry>4</entry><entry>response</entry><entry>no</entry><entry>octet-string</entry><entry>read-only: ‘augmented’ SNMPv1</entry></row><row><entry /><entry /><entry /><entry /><entry>response PDU.</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0061The first three indexes specify the reverse flow addressing and the sequence ID that was copied from the request sequence ID in the tunnel command table. The last entry is an SNMP RESPONSE, augmented as described below with reference to <figref idref="DRAWINGS">FIGS. 7 and 8</figref>. The tunnel response table is always empty for purposes of direct GET and SET operations. The table is only used by the DTE to encapsulate an SNMPv1 response into an SNMPv3 response.
0062The tunnel objects of the tunnel MIB (<figref idref="DRAWINGS">FIG. 2</figref>) also include a tunnel trap receiver table. An exemplary tunnel trap receiver table according to the invention is described in Table 7.
0000<tables id="TABLE-US-00012" num="00012"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="14pt" align="center" /><colspec colname="2" colwidth="70pt" align="left" /><colspec colname="3" colwidth="28pt" align="left" /><colspec colname="4" colwidth="35pt" align="left" /><colspec colname="5" colwidth="70pt" align="left" /><thead><row><entry namest="1" nameend="5" rowsep="1">TABLE 7</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row><row><entry>#</entry><entry>Name</entry><entry>Index?</entry><entry>Type</entry><entry>description</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>trapManagerAddress</entry><entry>yes</entry><entry>ipAddress</entry><entry>Manager to which the</entry></row><row><entry /><entry /><entry /><entry /><entry>MTE should send this</entry></row><row><entry /><entry /><entry /><entry /><entry>SNMPv1 trap PDU</entry></row><row><entry>2</entry><entry>vTunnelTrapPayload</entry><entry>no</entry><entry>octet-</entry><entry>Accessible-for-notify:</entry></row><row><entry /><entry /><entry /><entry>string</entry><entry>‘augmented’ SNMPv1</entry></row><row><entry /><entry /><entry /><entry /><entry>trap PDU.</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>
0063The tunnel trap receiver table enables a DTE to encapsulate SNMPv1 traps in SNMPv3 traps and send them to the MTE. In the DTE, the table is empty except when generating a trap. When the DTE receives an SNMPv1 trap from a device, it adds a new row in the table, and generates an SNMPv3 trap and sends to the MTE. Immediately following that, the DTE deletes the row from the table.
0064Turning now to <figref idref="DRAWINGS">FIG. 3</figref>, additional details regarding the MTE <b>16</b> are shown. For purposes of illustration the MTE will be shown encapsulating and decapsulating SNMPv1 messages into and out of SNMPv3 messages. However, the invention can be applied to encapsulate any legacy management message into any SNMP version message. According to the illustrated embodiment, the MTE includes an MTE core <b>40</b> and a network subsystem <b>42</b>. The network subsystem <b>42</b> couples the MTE to network <b>14</b> via a network interface <b>44</b> and to network <b>18</b> via a network interface <b>46</b>. The only connection that the network <b>14</b> has to the network <b>18</b> is through the MTE. Therefore, the network subsystem <b>42</b> is designed to allow non-management packets to pass through the MTE unmodified.
0065<figref idref="DRAWINGS">FIG. 3</figref> illustrates the network management station <b>10</b> associated with a network interface <b>13</b> with UDP and IP layers <b>11</b>. Outgoing SNMPv1 packets from the network management station <b>10</b> are intercepted by the network subsystem <b>42</b> via a “from manager packet receptor” <b>48</b> and sent to the MTE core <b>40</b>. The “from manager packet receptor” tests the packet to determine: whether the UDP is addressed to port <b>161</b> (a default SNMP port on IPv4 interfaces), whether the packet contains an SNMPv1 PDU, whether it is a GET, GETNEXT, or SET request, whether its source is a network management station supported by the MTE and whether its destination is a managed network device supported by the MTE. If all of these requirements are met, the packet is sent to the MTE core <b>40</b>. If any one of the requirements is not met, the packet is sent to the network subsystem <b>42</b> without any processing by the MTE core.
0066When the MTE core <b>40</b> receives an SNMPv1 message from the “from manager packet receptor” <b>48</b> it processes it as described below with reference to <figref idref="DRAWINGS">FIG. 5</figref> and uses the API <b>52</b> of SNMPv3 software <b>54</b> to prepare an SNMPv3 message which is passed to the network subsystem for transport to the DTE. The SNMPv3 software intercepts SNMPv3 messages entering the network subsystem <b>42</b> from the network interface <b>46</b>, and passes them to the MTE core <b>40</b> for processing as described below with reference to <figref idref="DRAWINGS">FIGS. 8 and 8</figref><i>a</i>. The result of such processing is an augmented SNMPv1 message which is passed to the network subsystem <b>42</b> via the “to manager packet receptor” <b>50</b> for transport to the manager.
0067Turning now to <figref idref="DRAWINGS">FIG. 4</figref>, the DTE includes a DTE core <b>60</b> and a network subsystem <b>62</b>. The network subsystem <b>62</b> couples the DTE to network <b>24</b> via a network interface <b>64</b> and to network <b>18</b> via a network interface <b>66</b>. The only connection that the network <b>24</b> has to the network <b>18</b> is through the DTE. Therefore, the network subsystem <b>62</b> is designed to allow non-management packets to pass through the DTE unmodified.
0068<figref idref="DRAWINGS">FIG. 4</figref> illustrates the managed network device <b>28</b> associated with a network interface <b>23</b> with UDP and IP layers <b>21</b>. Outgoing SNMPv1 packets from the device <b>28</b> are intercepted by the network subsystem <b>62</b> via a “from device packet receptor” <b>68</b> and sent to the DTE core <b>60</b>. The “from device packet receptor” tests the packet to determine: whether the UDP is addressed to port <b>161</b> or <b>162</b> (default SNMP ports on IPv4 interfaces) whether the packet contains an SNMPv1 PDU, whether it is a RESPONSE or TRAP, whether its source is a managed network device supported by the DTE, and whether its destination is a network management station supported by the DTE. If all of these requirements are met, the packet is sent to the DTE core <b>60</b>. If any one of the requirements is not met, the packet is sent to the network interface <b>66</b> without any processing by the DTE.
0069When the DTE core <b>60</b> receives an SNMPv1 message from the “from device packet receptor” <b>68</b> it processes it as described below with reference to <figref idref="DRAWINGS">FIG. 7</figref> and uses the API <b>72</b> of SNMPv3 software <b>74</b> to prepare an SNMPv3 message which is passed to the network subsystem <b>62</b> for transport to the MTE. The SNMPv3 software intercepts SNMPv3 messages entering the network subsystem from the network interface <b>66</b>, and passes them to the DTE core <b>60</b> for processing as described below with reference to <figref idref="DRAWINGS">FIG. 6</figref>. The result of such processing is an augmented SNMPv1 message which is passed to the network subsystem <b>62</b> via the “to device packet receptor” <b>70</b> for transport to the device.
0070<figref idref="DRAWINGS">FIG. 5</figref> illustrates the processing of an augmented SNMPv1 packet by the MTE core of <figref idref="DRAWINGS">FIG. 3</figref>. The left side of <figref idref="DRAWINGS">FIG. 5</figref> shows the intercepted and validated IP packet <b>80</b> which contains an SNMPv1 PDU, a UDP header, and an IP header which contains the IP address of the source and the IP address of the destination. The MTE core strips off the headers and creates an “augmented” SNMPv1 PDU <b>82</b> by appending the UDP header and the IP address of the source to the end of the of the SNMPv1 PDU. Using the SNMPv3 software (<b>54</b> in <figref idref="DRAWINGS">FIG. 3</figref>), the MTE core creates an SNMPv3 GETNEXT PDU <b>84</b>.
0071The MTE uses information extracted from the IP packet <b>80</b> to fill the object portion of a single variable binding <b>86</b> in the GETNEXT PDU <b>84</b> according to the structure of the tunnel command table (Table 5). This information includes the SNMP object ID of the tunnel command table status element, followed by the IP address of the network management station, the IP address of the managed network device, the sequence ID (which was incremented by the MTE from a global variable), and the augmented SNMPv1 PDU <b>82</b> split into a number of segments. The number of segments and the relative sizes of the segments are arbitrary. In the illustrative embodiment described herein, five segments are used for programming convenience with the SNMPv1 PDU divided into 4 equally sized segments and the fifth segment carrying the augmentation information (UDP header and IP service address). The value portion of the variable binding is set to NULL. The GETNEXT PDU is appended to a UDP header and an IP header which includes the address of the MTE and the address of the DTE (obtained from the MTE core configuration). If the core configuration does not contain an appropriate DTE address, the packet is quietly dropped. When a DTE address is found, the resulting packet <b>88</b> is sent through the network subsystem <b>42</b> (<figref idref="DRAWINGS">FIG. 3</figref>), the network interface <b>46</b>, and out to the network <b>18</b>.
0072Referring now to <figref idref="DRAWINGS">FIGS. 4 and 6</figref>, the SNMPv3 software <b>74</b> intercepts SNMPv3 requests received at network interface <b>66</b> and network subsystem <b>62</b> and forwards the received SNMPv3 requests to the DTE core <b>60</b> via API <b>72</b>. When the DTE core <b>60</b> receives the SNMPv3 request that was sent to it by the MTE, it strips off the headers, and processes the SNMPv3 GETNEXT PDU according to the tunnel command table (Table 5) in the tunnel MIB (<figref idref="DRAWINGS">FIG. 2</figref>). The status object of the SNMPv3 GETNEXT PDU is null and thus is not relevant. The IP address of the network management station, the IP address of the managed network device, and the sequence ID are saved for use in preparing the SNMPv3 response. The augmented SNMPv1 PDU <b>82</b> is extracted from the object identifier of the variable binding <b>86</b> of the SNMPv3 GETNEXT PDU and the request sequence ID is extracted and saved in association with the manager address and device address in the tunnel response table.
0073An SNMPv1 packet is created with the augmented PDU <b>82</b> together with an IP header and a UDP destination port (e.g. 15000). This packet is sent to the network subsystem <b>62</b> where it is intercepted by the “to device packet receptor” <b>70</b> which rebuilds the original SNMPv1 request and sends it to the destination managed network device <b>28</b>.
0074Packets arriving from the managed network device <b>28</b> are intercepted by the “from device packet receptor” <b>68</b> if they meet all of the following requirements: are addressed to UDP port <b>161</b> or <b>162</b>, contain an SNMPv1 PDU, are a RESPONSE or a TRAP, are from a managed network device supported by the DTE and are addressed to a network management station supported by the DTE. If any one of these criteria is not met, the packet is sent to network subsystem <b>62</b>. Otherwise they are sent to the DTE core <b>60</b>.
0075Turning now to <figref idref="DRAWINGS">FIGS. 4 and 7</figref>, when the DTE core <b>60</b> receives an SNMPv1 packet <b>100</b> from a managed network device, it extracts the IP address of the network management station (the destination IP address) and the IP address of the managed network device (the source IP address) from the IP header. It extracts the request ID from the PDU <b>102</b>. It builds an augmented PDU <b>104</b> by concatenating the legacy PDU with the original UDP header and device address. The augmented PDU <b>104</b> including the manager address, device address and sequence ID are encapsulated in the object portion <b>106</b> of a single variable binding <b>108</b> (with a null value) of an SNMPv3 RESPONSE PDU <b>110</b>. The PDU is then given an SNMPv3 header, UDP header and IP header directing it to the MTE determined from the DTE configuration.
0076Referring now to <figref idref="DRAWINGS">FIGS. 3 and 8</figref>, the MTE core receives the SNMPv3 message, extracts the augmented PDU <b>104</b> from the object part of the variable binding <b>108</b>, rebuilds the SNMPv1 message, and adds a UDP header and the IP header from the MTE configuration which sends it to its destination. The “to manager packet receptor” <b>48</b> intercepts the packet if it has the correct UDP port address (e.g., 15000). The “to manager packet receptor” <b>48</b> rebuilds the original SNMPv1 message as shown in <figref idref="DRAWINGS">FIG. 8</figref><i>a </i>by moving the IP header and UDP header from the end of the packet to the beginning of the packet.
0077Turning now to <figref idref="DRAWINGS">FIGS. 4 and 9</figref>, when the “from device packet receptor” <b>68</b> intercepts an SNMPv1 TRAP <b>200</b> it sends it to the DTE core <b>60</b> for processing. When the DTE core receives the TRAP message, it extracts the IP address of the network management station (the destination IP address) and the IP address of the managed network device (the source IP address) from the IP header. It finds the MTE address corresponding to the network management station address from the DTE configuration. If no MTE address is found, the packet is quietly dropped. It builds an augmented SNMPv1 PDU <b>202</b> by concatenating the SNMPv1 PDU with the original UDP header and device address. The Object ID from the tunnel trap receiver table (Table 7), the trap manager address, and the augmented SNMPv1 PDU <b>202</b> are encapsulated into a single variable binding <b>204</b> of an SNMPv3 TRAP PDU <b>206</b>. The augmented SNMPv1 PDU <b>202</b> is placed in the value portion of the variable binding <b>204</b>. The SNMPv3 PDU is then given an SNMPv3 header, UDP header and IP header directing it to the MTE determined from the DTE configuration.
0078Referring now to <figref idref="DRAWINGS">FIGS. 3 and 10</figref>, the MTE core receives the SNMPv3 message, extracts the augmented SNMPv1 PDU <b>208</b> from the value part of the variable binding <b>204</b>, and adds a UDP header and the IP header. The UDP header sends it to the “to manager packet receptor” <b>50</b> which performs the operations described above with reference to <figref idref="DRAWINGS">FIG. 8</figref><i>a </i>and thus reconstructs the original SNMPv1 TRAP PDU.
0079Those skilled in the art will appreciate that the augmentation of the legacy PDUs is needed because of the division between user space and kernel space in the operating system which is running the communications software. It will be thus appreciated that the augmentation of the legacy PDUs can be eliminated if the software is arranged differently.
0080Further, those skilled in the art will appreciate that the port monitoring function of the “packet receptors” as described above can be eliminated if the invention is implemented as a “shim”. <figref idref="DRAWINGS">FIG. 11</figref> shows an alternate embodiment of the invention wherein the functionality of the MTE as described above is realized as a software shim SMTE <b>316</b> and the functionality of the DTE is realized as a software shim SDTE <b>320</b>. Here it can be seen that the network management station <b>310</b> includes SNMPv1 functionality <b>311</b> which would normally communicate directly with TCP/IP functionality <b>317</b>. According to this embodiment of the invention, the Shim MTE (SMTE) <b>316</b> is interposed between the SNMPv1 functionality <b>311</b> and the TCP/IP functionality <b>317</b> and is interfaced to the SNMPv1 functionality in a manner that invokes the SMTE processing without requiring any port monitoring function. Similarly, the managed network device <b>328</b> includes SNMPv1 functionality <b>329</b> which would normally communicate directly with TCP/IP functionality <b>321</b>. According to this embodiment of the invention, the Shim DTE (SDTE) <b>320</b> is interposed between the SNMPv1 functionality <b>329</b> and the TCP/IP functionality <b>321</b> and is interfaced to the SNMPv1 functionality in a manner that invokes the SDTE processing without requiring any port monitoring function. It will be appreciated, however, that the SMTE equipped managers can operate with DTE equipped managed devices and SDTE equipped devices can operate with MTE equipped managers.
0081There have been described and illustrated herein embodiments of methods and apparatus for tunneling legacy network management messages through SNMP. While particular embodiments of the invention have been described, it is not intended that the invention be limited thereto, as it is intended that the invention be as broad in scope as the art will allow and that the specification be read likewise. Thus, while particular IP ports and IP addresses have been disclosed, it will be appreciated that other IP port numbers and IP addresses might be used as well. In addition, while the MTE and DTE have been disclosed in block diagrams of key components, it will be understood the functions of the MTE and DTE could be conceptualized in different blocks so long as the same functions are accomplished. For example, and not by way of limitation, the DTE core function can be implemented as an SNMP subagent, or it could be integrated into a master agent. Also, the MTE could be integrated into a network diagnostic software toolset. Once a DTE has been deployed in the field either in the standalone form or integrated into end devices, there is no reason to restrict MTE usage to specific network manager software. Generic SNMP based tools including the open source Net-SNMP can use an MTE module defined by the invention to access SNMPv1 MIBs securely through the tunnel of the invention. The DTE can also be integrated into NAT/Firewall boxes. The invention enables secure management and provides IP address multiplexing/hiding for SNMP. Integration into NAT/Firewall boxes allows secure management of network devices behind NAT/Firewall boundaries. The invention can also be applied to network request-response applications other than SNMP. The application interface provided by MTE and DTE to the SNMP PDU can be replaced by a layer that understands another request-response application while mapping to and from SNMP GETNEXT will remain unchanged. It will therefore be appreciated by those skilled in the art that yet other modifications could be made to the provided invention without deviating from its spirit and scope as claimed.
Contents6
13 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| US8984145B2 | Cited by | United States of America | Search report |
| CN103401859A | Cited by | China | Search report |
| US8050268B2 | Cited by | United States of America | Search report |
| US8521866B2 | Cited by | United States of America | Search report |
| EP3633923A1 | Cited by | European Patent Office (EPO) | Search report |
| US2009089414A1 | Cited by | United States of America | Pre-grant |
| US2007245011A1 | Cited by | United States of America | Pre-grant |
| US2005097201A1 | Cites | United States of America | Pre-grant |
| US2006026301A1 | Cites | United States of America | Pre-grant |
| US6697845B1 | Cites | United States of America | Pre-grant |
| US7072337B1 | Cites | United States of America | Pre-grant |
| US7401120B2 | Cites | United States of America | Pre-grant |
1 member in 1 office
Priority claims5
| Document | Office | Kind | Date |
|---|---|---|---|
| 82996206 | United States of America | P | |
| 62009907 | United States of America | A | |
| 60829962 | – | – | – |
| US20060829962P | – | – | – |
| US20070620099 | – | – | – |
Members1
| Document | Office | Kind | |
|---|---|---|---|
| US2008098103A1 | United States of America | A1 |
29 transactions on the USPTO file
Abandoned after 1 non-final rejection.
- Non-final rejections
- 1
- Final rejections
- 0
- RCEs
- 0
- Appeals
- 0
Over time
Point at a mark for the transactionTransactions
| Event | Code | |
|---|---|---|
| Mail Abandonment for Failure to Respond to Office ActionAbandonedMABN2 | MABN2 | |
| Aband. for Failure to Respond to O. A.AbandonedABN2 | ABN2 | |
| Examiner Interview Summary Record (PTOL - 413)EXIN | EXIN | |
| Mail Non-Final RejectionNon-final rejectionMCTNF | MCTNF | |
| Non-Final RejectionNon-final rejectionCTNF | CTNF | |
| Date Forwarded to ExaminerFWDX | FWDX | |
| Response to Election / Restriction FiledELC. | ELC. | |
| Mail Restriction RequirementMCTRS | MCTRS | |
| Restriction/Election RequirementCTRS | CTRS | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| PG-Pub Issue NotificationPG-ISSUE | PG-ISSUE | |
| Withdraw Flagged for 5/25W525 | W525 | |
| Flagged for 5/25F525 | F525 | |
| Case Docketed to Examiner in GAUDOCK | DOCK | |
| Information Disclosure Statement consideredIDSC | IDSC | |
| Reference capture on IDSRCAP | RCAP | |
| Information Disclosure Statement (IDS) FiledM844 | M844 | |
| Information Disclosure Statement (IDS) FiledWIDS | WIDS | |
| IFW TSS Processing by Tech Center CompleteTSSCOMP | TSSCOMP | |
| Application Is Now CompleteCOMP | COMP | |
| Application Return from OIPEWROIPE | WROIPE | |
| Application Return TO OIPEROIPE | ROIPE | |
| Application Dispatched from OIPEOIPE | OIPE | |
| Application Is Now CompleteCOMP | COMP | |
| Cleared by OIPE CSRL194 | L194 | |
| IFW Scan & PACR Auto Security ReviewSCAN | SCAN | |
| Initial Exam Team nnIEXX | IEXX |
1 legal event, as the office reported them to INPADOC
Events
| Event | Code | |
|---|---|---|
| Information on status: application discontinuationABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTIONSTCB | STCB |
Numbers
- Publication
- 20080098103
- Publication, DOCDB
- 2008098103
- Publication, EPODOC
- US2008098103
- Application
- 11620099
- Application, DOCDB
- 62009907
- Application, EPODOC
- US20070620099
Titles
- English
- Methods and Apparatus for Tunneling Legacy Network Management Messages through SNMP (Simple Network Management Protocol)
Classification
- CPC, 1
- H04L12/66
- IPC, 1
- G06F15 173
- USPC, 1
- 709223000