An SNMP Gateway for Delay/Disruption Tolerant Network Management GREGORY L. CAMPBELL. Ohio University 08/22/10

Transcription

1 An SNMP Gateway for Delay/Disruption Tolerant Network Management by GREGORY L. CAMPBELL McClure School of Information and Telecommunication Systems Ohio University 08/22/10

2 2 ABSTRACT The SNMP Gateway is used in Delay Tolerant Network (DTN) management to translate between terrestrial and DTN network management protocols. This project proposes a generic DTN topology in which a DTN network that runs ION or DTN2 implementations of Bundle Protocol is monitored by an adjacent terrestrial TCP/IP network. At the threshold of the two, the SNMP Gateway provides a proxy service for terrestrial SNMP get-requests by accessing a local SQLite3 database to retrieve stored information about managed nodes on the DTN. According to the proposed management scheme, this database is populated by a DTN network management protocol called the Diagnostic Interplanetary Network Gateway (DING) protocol which is being developed by my colleague, Gilbert Clark. The SNMP Gateway also provides appropriate timestamp information for terrestrial managers and SNMP trap configuration and notification sending services. An implementation of the SNMP Gateway is tested by creating a sample terrestrial management system and by mimicking interaction with the DING protocol. The results prove that a push-based data collection method that populates a shared database can be successful employed by an SNMP Gateway to perform DTN network monitoring from a terrestrial manager. 2

3 3 TABLE OF CONTENTS Page List of Diagrams...4 1) Background and Literature Review...5 2) Project Definition and Scope...7 3) Methodology ) Basic Proxy Function ) Timestamp Mechanism ) SNMP Notifications ) Project MIB ) Results ) Basic Proxy Function ) Timestamp Mechanism ) SNMP Notifications ) Conclusions ) Further Research ) References ) Glossary Appendix 1: SQL Table Schemas Appendix 2: MIB Print-out

4 4 LIST OF DIAGRAMS Page Figure 1: Generic DTN Network Management Model... 7 Figure 2: Basic Components of the Management Gateway... 9 Figure 3: SNMP Agent Interaction Inside The SNMP Gateway Figure 4: Example of Relevant Timestamp OID Figure 5: Sending Notifications in Normal SNMP Figure 6: Sending Notifications in DTN Network Management Figure 7: Configuring Traps in DTN Network Management Figure 8: Trap Configuration Step Figure 9: Trap Configuration Step Figure 10: Trap Configuration Step Figure 11: Trap Configuration Step Figure 12: Notification Sending Step Figure 13: Notification Sending Step Figure 14: Notification Sending Step Figure 15: Notification Sending Step Figure 16: stattrackermib Figure 17: 24 Hours of Bundlessent (Graphed Tue. 16:07) Figure 18: 24 Hours of Bundlesreceived (Graphed Tue. 16:07) Figure 19: 24 Hours of Bundlesdropped (Graphed Tue. 16:07)

5 5 1) BACKGROUND AND LITERATURE REVIEW Network management is a crucial part of maintaining modern information systems. Security, monitoring, centralized trending or analysis, and node configuration are all components of a well managed data network. The most common networking protocol used to retrieve management data is Simple Network Management Protocol, or SNMP. SNMP is typically implemented by collecting data at a central management station which queries other SNMP-enabled network nodes (Case, et al. 1990). Management information is defined by globally unique Object Identifiers (OID) and organized into hierarchical data structure known as Management Information Bases (MIB). SNMP works on a polling system, which works well on terrestrial networks where transmission delays are negligible, but not as well on a delayed/disrupted network where round trips must be kept to a minimum. A Delay/Disruption Tolerant Network is a number of interconnected machines that experience either large transmission delays or periods of intermittent disruption of communication. Protocols that work in common terrestrial networks such as TCP/IP often can't cope with the harsh conditions of DTNs. RFC 5050 is an experimental document which defines a networking protocol called Bundle Protocol for communication in a delayed/disrupted network (Scott and Burleigh, 2007). Two implementations of RFC 5050 have emerged: DTN2 and ION. The functionality of each code base is currently at the point where basic operations can be done (such as sending/receiving data) but debugging and optimizations are still taking place. One such optimization where DTN is lacking is network management. 5

6 6 Just like other networks, DTNs seek the benefits of a network management arrangement. But unlike other networks, proven protocols such as SNMP do not work well because they are based on polling. To illustrate this, consider communications between Earth and Mars where propagation delays can exceed 20 minutes. It takes a full round trip time plus processing delays (at least 40 minutes in this scenario) to collect Martian data on Earth using a polling, or pull, data-collection method. This is hardly acceptable considering real-time polling expectations associated with terrestrial based networks. In order to make the best of a highly delayed environment, this research adopts a telemetry-based, or push, data collection method. In this method, data is collected on a scheduled interval, without the need to ask for it. The telemetry-based model reduces the overall latency compared to a polling model by eliminating the propagation delay of the query (cutting the 40 minutes to 20 minutes in the Martian example). The next section describes how telemetry-based data collection and SNMP are implemented by this project to create a network management scheme that is designed for DTNs. 6

7 7 2) PROJECT DEFINITION AND SCOPE This project proposes a generic DTN network management topology (figure 1), which can be exemplified in the following scenario: a DTN management node collects data from one or many managed nodes over Bundle Protocol. This management node is also connected to a terrestrial TCP/IP network, and thus it is called the Gateway. There is a management station on the terrestrial network which is interested in collecting, monitoring, and trending data from the DTN notes. The network management protocol used on the terrestrial side is SNMP, and on the DTN side is DING a flexible, subscription-based data collection protocol developed by my colleague (Clark, 2010). The job of the Gateway is to handle SNMP requests on the terrestrial side and return the appropriate monitoring information collected from the DTN nodes. Figure 1: Generic DTN Network Management Model This DTN management scheme has been divided into two major components, each of which has become a topic for Master s research at OU. The first component is the scheduled data-collection over bundle protocol, called DING. This protocol has been 7

8 8 designed by Gilbert Clark of the Ohio University EE/CS program to be a lightweight and modular scheme for transporting management information in telemetry format over the rigors of a DTN. The second component of this management scheme is the Gateway seen in the middle of Diagram 1, which is the specific topic of this project. The primary responsibility of the Gateway is the handling and interpreting of SNMP requests from the TCP/IP network. It is also responsible for providing a method of retrieving relevant timestamps and supporting SNMP traps, both of which will be described in more detail in later sections. The Gateway also houses a database which stores management information gathered from the DTN nodes (seen in figure 2). The database used in this project is SQLite, version , and it acts as a logical dividing point between the SNMP handling component of this management scheme and the DTN data collection component. The latter fills the database with management information from the DTN nodes. The former pulls information from the database to satisfy SNMP requests. As will be described later in this paper, the database will also be used as a means of communication between the two components in order to accommodate some of the more complicated interactions in this management scheme. Either way, it acts as a convenient logical separator for the different components of this management scheme. 8

9 9 Figure 2: Basic Components of the Management Gateway Shared DB DTN Node SNMP Queries SNMP Agent(s) DING Agent DTN Node DTN Node Gateway Because of the overlap of this project with my colleague s research, special care was taken to make the SNMP Gateway component individually testable. The intrinsic dependencies built into the parts of the management scheme create a situation where this project becomes reliant on the work of others, which is very undesirable for scheduling and managing workload. In order to mitigate the risk of relying on other work, all interaction between this project and the DING component were designed to be replicated. This way, each portion of the overall management scheme can progress individually and the two projects can be completed without relying on each other for basic interaction and communication. It will become clearer what replication is necessary when the operational details of this project are described in the following sections. 9

10 10 3) METHODOLOGY The SNMP Gateway has three functions which contribute to the operation of the proposed DTN network management scheme. Its primary function is to respond to SNMP queries by retrieving appropriate network management information, which is described in section 3.1. In sections 3.2 and 3.3, the SNMP Gateway s secondary functions are described: a relative timestamp mechanism and SNMP trap support. 3.1) MAIN PROXY FUNCTION The main function of the SNMP gateway is to interpret SNMP queries and respond with the associated DTN management information. To achieve this, the Gateway must have a process that listens and responds to queries (SNMP Agent), as well as an intimate knowledge of the local database which stores management information. It must maintain a mapping between SNMP data structures (MIBs) and the data structures within the shared database. There is only one interface to accept SNMP queries, while there are potentially many DTN nodes being managed, so the SNMP queries must identify the target DTN node within the request itself so that the Gateway can retrieve information for the correct node. The finished product will allow management stations to use basic SNMP requests directed towards the Gateway to collect information about remote DTN nodes. The SNMP agent used by this project is called Net-SNMP, which runs a background process called snmpd (Net-SNMP, 2007). This daemon listens on UDP 10

11 11 port 161 by default for SNMP messages. The content of the message depends on the version of SNMP. Earlier version (1 and 2) headers simply include the version, an authentication mechanism, and the body of the message (i.e. get, set, notification, etc). This project focuses on version 3 of the protocol, whose message header includes: a version, a unique transaction identifier, a more sophisticated security model which supports multiple authentication and encryption mechanisms, unique identifiers for both the recipient and sending physical devices (called contextengineids), a unique identifier for the logical recipient (called contextname), and finally the body of the message (i.e. get, set, notification, etc). When the SNMP message is constructed, lots of these details are defined by command-line options, so that the sender can uniquely tailor the SNMP message depending on his/her management needs. This project utilizes the contextname feature of SNMPv3 to identify which DTN node is being questioned. The contextname is an ASCII text string designed to identify the logical recipient of the SNMP message, and is defined in most SNMP applications using the command line option: -n [contextname]. In the DTN network management scheme, this allows the management station to tell the Gateway which node the request is polling. It is the job of the Gateway to interpret the contextname, discover which DTN node is being polled, and retrieve the requested information. It does this by utilizing the proxy feature of Net-SNMP. The proxy feature of Net-SNMP allows the agent to forward SNMP messages to a separate management entity based upon the requested OID and the contextname of the message. A proxy rule is configured in the SNMP agent using the following syntax: proxy Cn [contextname] [SNMP options] [destination] [OID], where [contextname] 11

12 12 is the ASCII-text string to match against incoming contextnames, [SNMP options] are the command line options used to forward the message, [destination] is where the message is forwarded, and [OID] is the location in the MIB hierarchy under which the requested OID must fall. Consider an example where an SNMP agent is configured with the following 3 proxy functions: proxy Cn node1 -v 3 l noauthnopriv : proxy Cn node2 -v 3 l noauthnopriv : proxy Cn node3 -v 3 l noauthnopriv : If this agent receives an SNMP message for OID (or any OIDs contained within the branch) that also has a contextname of node1, then the SNMP message is forwarded to :161 using the SNMP options -v 3 l noauthnopriv. Likewise, if the contextname of the request was node2, then the message would have been forwarded to :161, and similarly for node3. Because all of the proxy functions in this example use the same OID, the deciding proxy factor becomes the context name. The DTN network management scheme uses the same concept, but with a slightly different application. The Net-SNMP agent on the SNMP Gateway is configured with syntax similar to the following proxy functions: proxy -Cn "node1" l authnopriv -v2c -c public : proxy -Cn "node2" -l authnopriv -v2c -c public : proxy -Cn "node3" -l authnopriv -v2c -c public :

13 13 These proxy functions allow the Net-SNMP agent to forward messages that are asking for an OID under based on the contextnames of node1, node2, and node3. This OID identifies the MIB that is used by this project (which will be explained in greater detail in section 3.4). Again, because the same OIDs are used, only the context name is used for selecting a forwarding address, so that these proxy functions allow the SNMP agent to take separate actions depending on which DTN agent is being targeted. The destination address is the loop back address of the local machine at an arbitrary high port (the rationale of which will be explained shortly). The SNMP options are simple and minimal to allow for basic SNMP version 2 communications. The SNMP Gateway has a proxy function for each managed DTN node, and each function forwards to a different arbitrary high port on the loopback address. For each of these high ports, there is another SNMP agent listening for forwarded messages. These agents are called secondary agents because they only receive forwarded messages. This second layer of agents is necessary in order to de-multiplex the incoming single stream of SNMP requests. There is a secondary agent for each managed DTN node, each listening on a separate high port, resulting in a 1:1 mapping between contextnames and secondary agents. Each secondary agent has the necessary logic to respond to the request with information specific to that DTN node. This logic is contained within the passthrough SNMP agent feature. The pass-through feature allows an SNMP agent to forego the logic of responding to requests and passing that logic to an external script. The purpose of the pass-through script is to allow extended user customizability to the functioning of the 13

14 14 agent. Its configuration syntax is: pass [OID] [program] [path to script], where [OID] defines which OID(s) are applicable, [program] indicates the program with which to run the script (typically bash or Perl), and [path to script] identifies the location of the external script to be run. When the script is called, it is given the following arguments: [ - g, -n, or -s ] and [OID], where the first argument specifies whether the command is a get getnext or set command, and the second argument specifies the OID being requested. In the case of get and getnext, the script returns the value by echoing three values to stdout: the OID being requested, the data type of the value, and value itself. In the current DTN network management scheme, set commands are not implemented and this is an area in need of further research. The SNMP Gateway utilizes the pass-through feature by configuring each of the secondary agents to pass its logic to a script that performs an appropriate database lookup. These scripts are written in the bash scripting language, and they are where the translation between the SNMP data structure (MIB) and the database data structure takes place (the database used by the SNMP Gateway is sqlite3--a MySQL variant). In the pass-through scripts, each OID has a mapping to a particular SQL command. When handed a get-request (specified by the -g argument), the scripts match up the given OID to the proper SQL command to retrieve the associated data. When passed a get-next command ( -n is provided as an argument), the script must respond with the database value associated with the next OID in the MIB. This means that the script must have an intimate knowledge of the MIB so that it knows that, for example, follows (which may seem simple but can get complicated with the use of variable length tables). In both cases of get-request and get-next, once the pass-through script retrieves the data 14

15 15 from the SQL database, it returns the value to the secondary agent, which creates and sends the response to the primary SNMP agent, which returns its response to the originating management station. The process is illustrated in Figure 3: Figure 3: SNMP Agent Interaction Inside The SNMP Gateway Figure 3 shows how the SNMP Gateway performs its primary function of responding to SNMP queries. First, the name of the DTN node is encapsulated in a SNMPv3 message using the contextname option, -n, and sent to the main agent. The main agent is configured with proxy functions which forward the request to subagents based upon the contextname. The subagents pass on the logic of retrieving a response to a pass-through script, which pulls the appropriate information from the SQL database. This process allows the Gateway to perform its primary function sets the groundwork for its other functions of appropriate timestamps and SNMP traps. 15

16 16 3.2) TIMESTAMP MECHANISM One of the challenges facing a DTN network management application is to pair retrieved management data with a relevant and accurate time stamp. In the scheme presented by this project, information retrieved from the SNMP Gateway is old because of high DTN transmission delays, even though the SNMP response is performed at terrestrial speeds. This dichotomy between the time that the data is retrieved and the time that the data is recorded is confusing to terrestrial network management stations. In a terrestrial environment, there is no motivation or necessity to differentiate between time retrieved and time recorded due to fast polling times. Because management stations are not accustomed to this concept, this project provides a unique mechanism to pair management information with a relevant time stamp. Two solutions were investigated by this project: imbedding the correct timestamp within the SNMP response itself and requiring a second OID request which contains the correct timestamp. Imbedding the correct timestamp in the SNMP getresponse would be the most elegant way to solve the problem because it would require minimal extra overhead. The best way to achieve this would be to simply add the extra varbind to the getresponse PDU within the SNMP message. However, the SNMP application at the receiving end (i.e. snmpget) would have no way of interpreting the extra information. While not actually prohibited in the SNMP protocol (Case et al., 1990), the added varbind would not be recognized by the SNMP application, so this approach was abandoned. Instead, this project provides a method of retrieving a timestamp using a second OID request. The MIB supports this by containing an OID called getlasttimestamp. 16

17 17 When the management station asks for the value of this OID, the SNMP Gateway returns the timestamp associated with the most recently requested OID. This functionality is built into the pass-through scripts which use simple file I/O as data storage. This timestamp solution is convenient for the management station because it only has to know a single OID for retrieving timestamps. It also simplifies the MIB (described in greater detail in section 3.4), because there is only one OID necessary for representing the entire MIBs worth of timestamps. The following example shows that the getlasttimestamp solution retrieves separate values even though only one OID is used. Figure 4: Example of Relevant Timestamp OID The timestamp mechanism created by this project is limited in a few ways. First, using a temporary file as a data storage mechanism is not the most efficient or secure solution. Future research may want to expand upon the getlasttimestamp storage mechanism and possibly support the ability to retrieve more than one or older 17

18 18 timestamps. Another problem with the single OID timestamp solution is the potential for incoming SNMP messages to arrive at the SNMP Gateway out of order due to inconsistent IP packet delivery. To avoid this situation, the application used at the management station should use a single SNMP message to request multiple OIDs, either using get-request or getbulkrequest PDUs. This is necessary to avoid the case where multiple managers compete for the same timestamp mechanism, which could potentially result in inconsistent timestamp delivery. Both snmpget or snmpbulkget Net-SNMP applications can be used to perform multiple OID requests on a single SNMP message. The relevant timestamp solution is predicated on the fact that the management station is able to interpret the timestamp in a meaningful way. While this is an implementation-specific issue, it highlights a potential problem with the proposed DTN network management scheme: off-the-shelf network management systems have difficulty with the concept of relevant timestamps. The tool investigated by this research is a popular enterprise-level, java-based, open-sourced network management suite called OpenNMS. OpenNMS, like other similar software tools, has no feature to configure the way that timestamps are recorded. Ideally, we d like to associate our own custom timestamp with a set of data, but this is simply not configurable without editing source code, which is out of the scope of this project. Section 4.2 will explain the use of a custom made management system and show that relative timestamps can be interpreted correctly by using the getlasttimestamp method. 18

19 19 3.3) SNMP NOTIFICATIONS In typical operation, SNMP uses solicitations to retrieve management information. However, there is a feature where the user can set a condition, or trap, that allows the managed entity to send an unsolicited notification upon reaching the condition. SNMP Traps are often used as a form of alarm that alerts the management station when an unfavorable or dangerous situation has been reached. In these dire management situations, time is of the essence, so it is appropriate that an unsolicited alert be sent the moment the condition is reached, rather than waiting for the management station to find out in regular polling. In the SNMP notification design, the managed node is configured to send a notification under certain circumstances and the management station is configured to listen for notifications. This design becomes more complicated in the DTN network management scheme, where a 3 rd element is added: the SNMP Gateway. In this design, the managed node is configured to send a notification over the DTN to the Gateway, the SNMP Gateway is configured to receive the notification on the DTN and immediately forward the notification on the terrestrial network, and the terrestrial management station is configured to listen for notifications. Figures 5 and 6 show the difference between normal SNMP trap operation and DTN trap operation: Figure 5: Sending Notifications in Normal SNMP SNMP Notification Management Station Managed Node 19

20 20 Figure 6: Sending Notifications in DTN Network Management Management Station SNMP Notification SNMP Gateway DING Frame DTN Node The ability to identify when a trap has sprung is part of the DING protocol. The DING agent on the DTN node must have the capability to retrieve relevant hardware information and compare it against the condition of the trap. SNMP traps support several different logical operations, including threshold, boolean, and existence. Most traps are threshold expressions, i.e. send a notification if OID x > 100. In this example, the DING agent would regularly (every 10 mins by default in SNMP) retrieve the data point associated with OID x and check to see if it is greater than 100. If it is, then the DING agent informs the SNMP Gateway that a trap has been sprung by sending a DING frame. When the SNMP Gateway receives the DING frame, it must make and send a SNMP Notification to the management station on the terrestrial network. The following sections will describe in detail the processes for configuring and sending DTN notifications ) CONFIGURING NOTIFICATIONS Establishing and configuring a trap is an entirely separate process from the operation of sending a notification. In the terrestrial world, creating a Net-SNMP trap consists of modifying the agent configuration file. Instead, in the DTN network management scheme, the user calls a program which prompts the user for the necessary information to create a trap. This information is stored in the shared database on the 20

21 21 SNMP Gateway and passed on to the DING agent, which passes on the configuration details to the DTN Node in the form of a subscription request (see figure 7). When it is all said and done, the DTN Node has the necessary information to check for the trap condition and the DING agent is listening for notifications. The process of configuring a trap can be broken down into four major steps. The remainder of this section will describe each of these steps in detail including graphical representations. Figure 7: Configuring Traps in DTN Network Management Management Station User Input SNMP Gateway DING Subscription DTN Node 1) In the first major step of trap configuration, the user calls a program on the SNMP Gateway called snmpgate with the arguments trap add. This begins the ION SNMP Gateway Trap Configuration Utility. The output shown below is a sample of the command line trap configuration utility. The bold lines denote user input. 21

22 22 Example Output: ION SNMP Gateway Trap Configuration Management Utility trap add ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Welcome to the ION SNMP Gateway trap configuration management utility! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ You will now be prompted for your trap configuration information Please enter the IP that will receive notifications. > Please specify ALL standard SNMP options to be attached to notifications. > -l authnopriv -v 3 -u ion -a MD5 -A asdfasdf Please enter the notification-type object identifier. > Please enter the type of trap condition: "THRESHOLD", "BOOLEAN", or "EXISTENCE". > Currently only THRESHOLD tests are supported. Skipping... Threshold expressions are defined by the following syntax: [OID] [OPERATOR] [VALUE]. [OID] is the object identifier to be monitored. [VALUE] is an integer to be compared against. [OPERATOR] uses Bash syntax (i.e. "-eq", "-ne", "-lt", "-le", "-gt" or "-ge". Please enter a value for [OID]. > Please enter a value for [OPERATOR]. > -gt Please enter a value for [VALUE]. > 100 Checking for errors... No errors found. Populating database... insert into traps (Trapid,Sendto,Options,Oid) values (NULL," ","-l authnopriv -v 3 -u ion -a MD5 -A asdfasdf n laren"," "); insert into snmptoding ("Type","Oid","Operator","Value","TrapKey","Index") values ("THRESHOLD"," ","-gt","100",1, NULL); Done. Figure 8: Trap Configuration Step 1 Management Station User Input At CL ION SNMP Gateway Trap Configuration Utility Shared DB DING Agent DTN Node Gateway 22

23 23 2) The SQL command syntax that populates the database can be seen in the example output, after Populating Database. There are, in fact, two rows written one each into two separate tables of the same database. The first is titled traps and holds a record of all SNMP-related trap information. The fields of this table are: an integer that is the incremental index of the table entry (called the TrapKey), the IP address of the management station, the SNMP options to be used in the notification, and the OID of the notification-type object identifier. For reference, appendix 1 contains a print-out of the database schemas used in this project. Figure 9 shows this database row entry in the stepby-step topology: Figure 9: Trap Configuration Step 2 Management Station ION SNMP Gateway Trap Configuration Utility Shared DB SQL Transaction DING Agent DTN Node Gateway 3) The second table populated using the SNMP Gateway Trap Configuration Utility is called snmptoding. Its fields contain all of the information that is necessary to create a trap condition in DING: the type of trap expression (i.e. Threshold, Boolean, or Existence. Note: only threshold type traps are supported right now and these database fields are tailored specifically for threshold expressions), the OID to be monitored, the logical operator (in bash shell string notation, i.e. -eq, -ne, etc.), the integral value to 23

24 24 be compared against, and the index value of the trap table entry (TrapKey). It is important that DING is passed the TrapKey because DING will store this integer and associate it with a particular trap. Later, when a trap is triggered and a notification needs to be sent, DING returns the TrapKey of the sprung trap so that the correct SNMP information can be retrieved from the trap SQL table. The snmptoding SQL table is called such because it is a means for the SNMP components of the management scheme to communicate with the DING components using the shared database. The DING agent on the Gateway reads the snmptoding table on a regular basis. If it finds an entry, then it digests the contents of the table row and deletes it. Likewise, there is a dingtosnmp table that performs the same communication in the opposite direction, which will be described later. These tables are a form of oneway information sharing using the SQL database that is essential to the operation of the SNMP Gateway. Figure 10 shows the snmptoding SQL table entry in the step-by-step illustration of DTN network management trap configuration (notice that the arrow goes through the DB, symbolizing its use as a communication mechanism). Figure 10: Trap Configuration Step 3 Management Station ION SNMP Gateway Trap Configuration Utility Shared DB SQL Transactions DING Agent DTN Node Gateway 24

25 25 4) After the Trap Configuration Utility communicates the trap information to the DING agent on the Gateway, the data is passed to the DTN Node in the form of a Template. A Template is a DING term which defines a list of values to be sent at a certain interval for network monitoring. When the manager sends the Template to the managed node, it is within what is called a Subscription Request. In this case, the Template contained within the Subscription identifies a condition, much like an SNMP Trap, on which to send a notification. Once the DTN Node receives the Subscription, it is then responsible for alerting the SNMP Gateway if the condition is met. While the DING protocol is out of the scope of this project, this step is critical to the DTN Network Management Scheme s implementation of Traps/Notifications so it cannot be ignored in the context of the SNMP Gateway. Figure 11 shows the Subscription Request as the last step in the DTN trap configuration process: Figure 11: Trap Configuration Step 4 Management Station ION SNMP Gateway Trap Configuration Utility Shared DB DING Agent DING Subscription DTN Node Gateway 3.3.2) SENDING NOTIFICATIONS The previous four diagrams and accompanying text have described the process for configuring a DTN trap in detail. There is an entirely separate process for executing a 25

26 26 notification. The following four steps identify how a trap is triggered and a following notification is sent to the proper recipient. Figures 12, 13, 14, and 15 graphically represent the process for sending notifications. 1) The DTN Node sends a DING Frame to the Gateway DING Agent alerting that a trap has sprung. A Frame is a DING term that identifies a chunk of management information. Although DING is not the focus of this project, this step is a critical piece in the SNMP Trap functionality. Realizing that a trap has been sprung is the initial step that will eventually end in an SNMP notification being sent. Figure 12: Notification Sending Step 1 Management Station Notification Sender SNMPTrigger Shared DB DING Agent DING Frame DTN Node Gateway 2) The SNMP Gateway employs two separate programs which dictate the manner in which a notification is sent. The first one, SNMPTrigger, is responsible for communicating with the DING agent. Where trap configuration used the snmptoding SQL table to communicate between the two, here the dingtosnmp SQL table is used. The SNMPTrigger daemon reads the shared database at a regular, predetermined interval to listen for dingtosnmp table entries. The table contains the following data points: the OID of the sprung trap, the data type of the associated value, the value of the sprung 26

27 27 trap, and the TrapKey that references a trap table entry discusses in trap configuration. Figure 12 shows the step involving the SNMPTrigger daemon: Figure 12: Notification Sending Step 2 Management Station Notification Sender SNMPTrigger Shared DB SQL Transactions DING Agent DTN Node Gateway 3) Once the DING to SNMP handoff has occurred using the shared database as a communications tool and SNMPTrigger as a daemon process, the SNMP notification must be created and sent. In order to collect all of the information necessary to send the notification, the program snmpgate is called with the arguments trap send, which invokes the ION SNMP Gateway Notification Sender. As additional command line arguments, SNMPTrigger passes on the information that it received from DING via dingtosnmp : OID, data type, and value. SNMPTrigger also passes along the TrapKey value that it got from DING so that the Notification Sender can retrieve the trap table information in the shared database that is associated with the sprung trap: IP of the management station, SNMP options, and the notification-type OID. The ION SNMP Gateway Notification Sender now has all of the information it needs to send a notification. Figure 13 shows a graphical representation of SNMPTrigger and the ION SNMP Gateway Notification Sender: 27

28 28 Figure 13: Notification Sending Step 3 Management Station Notification Sender SNMPTrigger Shared DB SQL Transaction DING Agent DTN Node Gateway 4) Lastly, the data supplied from the DING agent and the data stored in the trap database table must be combined to create the notification. The tool used for this is an SNMP application called snmptrap, which creates and sends notification messages to a network manager. The following syntax shows the arguments required to call the snmptrap program in the ION SNMP Gateway Notification Sender implementation: snmptrap [Options] [Host] [Trap-OID] [OID TYPE VALUE] The Options, Host, and Trap-OID fields are taken from the trap database table. The is an artifact of the snmptrap syntax and is simply a required placeholder for the program to operate properly. The varbind of the notification itself is defined by three values: a numerical OID, a single character representing data type ( s, i, u, etc.), and value associated with the OID. When given the correct command line parameters, the snmptrap program creates a TRAP-PDU, encapsulates it within a SNMPv1, v2, or v3 message as defined, and sends the datagram via UDP or TCP to the specified host. 28

29 29 Figure 14: Notification Sending Step 4 Management Station SNMP Notification Notification Sender SNMPTrigger Shared DB DING Agent DTN Node Gateway 3.4) PROJECT MIB The Management Information Base is an important concept in the DTN Network Management Scheme. The term MIB is used relatively loosely and can refer to two things: the overall organization scheme or a file which defines a small portion of the overall structure. The overall scheme is a hierarchal organization structure (envision an upside-down tree) often represented in numerical notation separated by periods. Where 1 represents the root, 1.1 represents a branch under that root and represents another smaller branch. This pattern continues to branch outwards until a globally unique identifier is reached that is associated to a particular object (OID). Alternatively, a MIB file is written in ASN.1 and it defines a branch of OIDS that can be categorized under a single organization or otherwise logically grouped together. In this fashion, the MIB hierarchy is made up of many MIB files. Together, they are a way of logically organizing a multitude of globally-unique variables into a commonly-understood, standardized hierarchy. This project has created and gone through a few different MIB files in its progression. Initially, there was a simplistic MIB that was used to merely test ASN.1 syntax. Afterwards, in coordination with my colleague at Ohio University who created 29

30 30 the DING protocol, the STATTRACKER-MIB was created which was a rough-draft of an ION MIB. The idea was that it would contain OIDS useful for ION node management, including bundle statistics, endpoints, ION memory usage, etc. This MIB was used as a proof-of-concept to test the SNMP Gateway and the first version of the DING protocol. SATTARCKER-MIB has a numerical representation of and the following figure identifies the values associated with each level of the hierarchy: Figure 15: stattrackermib Root Identification 1 ISO assigned OIDs.3 ISO Identified Organization.6 US Department of Defense.1 Internet.4 Private.1 Enterprises Ohio University.42 College of Communications.3 DTN.1 stattrackermib The STATTRACKER-MIB turned out to be an inadequate representation of an ION MIB. DING has since progressed to a new version and has slightly different OID requirements. In order for this research to stay independent of my colleague s work, this project has adopted a simple test MIB for the purpose of finalizing the SNMP Gateway at a proof-of-concept level. Called the SNMPGATE-TEST-MIB, it is smaller and simpler than the STATTRACKER-MIB, but it does not rely on constant upkeep and coordination with different DING versions and implementations. SNMPGATE-TEST-MIB is also found within Ohio University/College of Communications/DTN, but at.2 instead of.1. The Gateway maintains the functionality to retrieve OIDS on both MIBS, but the STATTRACKER-MIB will become out of sync and eventually entirely obsolete as DING 30

31 31 continues to progress. For this project, all tests and proof-of-concept operations are performed using the SNMPGATE-TEST-MIB, which is can be seen in appendix 2. The contents of SNMPGATE-TEST-MIB are few. There are three subsets which are separated by function: bundlestats, notifications, and utilities (.1,.2, and.3 respectively). Bundlestats contains three example OIDs that may be found in a full fledged ION MIB: bundlessent, bundlesreceived, and bundlesdropped. They are 32 bit counters and are used by this project as examples of OIDs that may filled by DING. The notifications section contains a single NOTIFICATION-TYPE object which is used in Trap configuration and will be described in more detail in the results section. Finally, utilities contains the getlasttimestamp OID which was described in section 3.2 and will be referenced again in section 4.2. While the SNMPGATE-TEST-MIB is rather simplistic compared to the larger STATTRACKER-MIB, it has all of the necessary features to test the SNMP Gateway and it does not require upkeep to stay compatible with DING versions. 31

32 32 4) RESULTS The easiest way to see the results of the SNMP Gateway implementation is do perform a series of tests that mimic the conditions that the Gateway would see in actual use. Because the scope of this project is limited to the Gateway itself, it has been thoroughly tested and troubleshot using imitations of both a management station and a DING agent. As long as the mimicked inputs to the Gateway remain consistent with the expected behavior of these outside elements, the output of the Gateway can be tested for correctness and overall performance. The following examples test the various functions of the SNMP Gateway by replicating appropriate input. 4.1) BASIC PROXY FUNCTION RESULTS The first function of the SNMP Gateway is the main proxy function. To test the main proxy function, a management station on the terrestrial network must monitor a DTN node by querying the SNMP Gateway. In this example, the management station is an Ubuntu distribution Linux system which will use the SNMP application: snmpget. The following excerpt shows all of the appropriate command line parameters for the snmpget program: snmpget -l authnopriv -v 3 -u ion -a MD5 -A asdfasdf -n laren nerys.its.ohiou.edu The l, -u, -a, and A options specify the authentication method and 32

33 33 credentials. v defines the SNMP protocol version and n specifies the context name. In this example, nerys.its.ohiou.edu is the SNMP Gateway and the OID being requested is The snmpget program will construct a GetRequest-PDU, apply the appropriate authentication algorithm, and send the request to nerys.its.ohiou.edu UDP port 161. Nerys.its.ohiou.edu is an Ubuntu linux workstation configured as an SNMP Gateway described in section 3.1. This machine is a part of a testbed at Ohio University created for developing and testing Delay Tolerant Networking. The main SNMP Agent on nerys is configured to accept SNMP messages using the credentials of the aforementioned snmpget command (version 3, ion user, MD5 authentication algorithm, and asdfasdf as the passkey). It is also configured with two proxy commands using the following syntax: proxy -Cn "nerys" l authnopriv -v2c -c public : proxy -Cn "laren" -l authnopriv -v2c -c public : When the agent on the Gateway receives the SNMP message sent by the snmpget command, it compares the requested OID and context name against the two proxy functions. Because the context names match and the OID of the request falls within the OID in the configuration, the agent forwards the packet based upon the second proxy statement. The SNMP request is sent to :16200 using the options -l authnopriv -v2c -c public. In addition to the main Net-SNMP agent, the Gateway has several other agents acting as secondary agents. One such agent was initiated with the following syntax sudo /usr/sbin/snmpd -f -C -Ls4d -Lf /dev/null -c /etc/snmp/dtn/snmpd_node2.conf udp:16200 & 33

34 34 The f, -C, -Ls4d, and Lf /dev/null options specify various logging, display, and behavior options that allow the agent to run transparently. The syntax at the end, udp:16200, defines which port that the agent listens to for SNMP messages. In this case, the secondary agent is listening on the port that the main agent forwarded our snmpget command to. For each proxy command in the main agent s configuration file, there is a secondary agent listening at the specified port. Lastly, the -c /etc/snmp/dtn/snmpd_node2.conf option defines which configuration file the agent loads at start up. Each secondary agent has a separate, unique configuration file. Among other security and authentication controls, the /etc/snmp/dtn/snmpd_node2.conf configuration file contains the following line: pass /bin/bash /etc/snmp/dtn/pass_laren.sh This line defines an extended functionality of the snmpd agent where instead of the agent itself performing the SNMP command, the agent passes the functionality to an external script. In this case, /etc/snmp/dtn/pass_laren.sh is a bash script which has the logic for retrieving DTN information about the DTN node laren. As described in the methodology section, the pass-through script is run with two command line arguments: the type of SNMP command and the target OID. Our snmpget command executes /etc/snmp/dtn/pass_laren.sh with the following options: -g /etc/snmp/dtn/pass_laren.sh is actually a one line bash script that simply calls another bash script called /etc/snmp/dtn/pass_master.sh using the same options with the addition of the name of the node (i.e. -g laren ). This 34

35 35 allows for easier scalability because only one master script needs to be maintained and each additional node added to the scheme would require a simple one-line script. Pass_master.sh is a lengthy script that contains all of the logic necessary to parse the snmp command and respond accordingly. It supports SNMP get-request and get-next PDUs (SNMP set-requests are NOT currently implemented). The pass_master script retrieves the management information requested in our sample snmpget command using the following pseudo code: If -g PDU { If the requested OID is in the branch { Determine specific object requested in the branch // this case:.1 Retrieve the relevant data for this node from the SQL database Parse the database response for the specific object // This is the mapping between OIDs and database objects Write the timestamp associated with the retrieved OID to $TIMESTAMPFILE // This will be explained in the section on relative timestamps. Print the data type to stdout // in this case: counter Print the value to stdout // in this case: } } /* The script also contains actions for n and s PDUs. In the g section, there is separate logic for each branch of the MIB, and in the n section there is even more logic necessary to parse table rows to retrieve the next OID. This script is probably the most sensitive and complicated piece of the project and it needs to be updated if either the MIB or the database structure changes. */ 35

36 36 The secondary Net-SNMP agent captures the values printed to standard out: counter and It then produces an SNMP response PDU and sends the message back to the main agent. The main agent re-packages the message in order to send to the management station. When the SNMP agent receives the message at the management station and confirms its authenticity, it passes the contents to the SNMP application which made the original request. In this example, the snmpget application processes the contents and prints the results to stdout: SNMPv2-SMI::enterprises = Counter32: In normal operation of the DTN network management scheme, the OID values would be incremental counters that DING would update in the SQL database. However, because this is a test MIB that does not actively use DING, another script is necessary to reproduce this behavior. This script runs in the background and regularly populates an SQL database with random incremental values for bundlessent (2.1.1), bundlesreceived (2.1.2), and bundlesdropped (2.1.3). Along with each data entry, an associated timestamp field is also populated which equals the current time in UTC seconds minus 10,000 seconds, to represent delay associated with an DTN. Also, to reproduce the concept of varying DING schedules, the rows are updated at different intervals: bundlessent every 300 seconds, bundlesreceived every 600 seconds, and bundlesdropped every 900 seconds. Each managed node has its own table in the example database (see appendix 1 for reference). The pass_master.sh script points SNMP get-requests to this SQL database, so that the latest values produced by the script are retrieved when the associated OID is requested. When running, this script reproduces the behavior of DING for testing the 36

37 37 various SNMP Gateway functions. This example has shown how the SNMP Gateway provides the means to monitor DTN nodes using SNMP. Also, a DING-imitation script is run which populates an SQL database with pseudo random DTN information. It is now up to the management station to interpret this data in a meaningful way. This is an implementation specific issue; however, there is one challenge to interpretation that the Gateway can help with: retrieving a relevant timestamp associated with the data. The following section shows how this is done using an example. 4.2) TIMESTAMP MECHANISM RESULTS This example uses the same machines in the prior example: an Ubuntu workstation as a management station and nerys.its.ohiou.edu as the SNMP Gateway. Previously, the snmpget application was used to retrieve management information about DTN node called laren. This section will demonstrate how the management station can retrieve a timestamp of when that DTN information was created. Like the previous example, the snmpget application will be used by the management station. However, it requests a special OID called getlasttimestamp, which is.3.1 in the SNMPGATE-TEST- MIB. A management station implements getlasttimesamp by requesting a bundle statistic plus timestamp pair. One SNMP message must contain the request for both OIDs: snmpget -l authnopriv -v 3 -u ion -a MD5 -A asdfasdf -n laren nerys.its.ohiou.edu

38 38 This SNMP message is forwarded to the secondary agent just like the basic proxy function example. The first OID requested (bundlesent in this example) will be treated by the secondary agents as described in the previous section. The second OID requested (getlasttimesamp), however, will be treated by the pass-through script in a specific fashion. Below is the pseudo code: If -g PDU { If the requested OID is in the branch { If the specific object requested in the branch is.1 { Retrieve contents of $TIMESTAMPFILE via file i/o Print the data type of stdout // in this case: counter Print the value to stdout // in this case: the contents of $TIMESTAMPEFILE } } } $TIMESTAMPFILE is a local file named after the given DTN node. It contains the value of the timestamp associated with the last piece of information retrieved from the shared database. In this example, the timestamp is associated with bundlesent (.1.1) which was requested in the same SNMP message. Because a single process is not maintained between different SNMP requests, the timestamp value is not kept in persistent memory. To avoid delay associated with another database call, file i/o is used to store the timestamp value. Despite the different method of retrieving a value, the getlasttimestamp OID is treated like any other object by the SNMP Agents. Just like the previous example, the data type and value are returned to the main agent and finally sent 38

39 39 to the management station. The snmpget application returns with the values for both OIDs: SNMPv2-SMI::enterprises = Counter32: SNMPv2- SMI::enterprises = Counter32: While the main scope of this project is to create the SNMP Gateway and provide the mechanism to retrieve relative timestamps, this research has also created an example of a simple manager application which retrieves, stores, and displays management data using the DTN network management scheme. While it is not a sophisticated application, it still accomplishes the same purpose as a management station by trending and averaging data that is old when it is received by the manager. This is a useful tool for testing the ability of relative timestamps to be interpreted meaningfully. The application itself is simply a bash script that runs continuously and a database(s) to store the gathered information. The script follows this pseudo-code: While [1] { Use an SNMP application to retrieve the desired OID and getlasttimestamp pair in a single SNMP message. Populate the database using the getlasttimestamp value as the time. Repeat for all desired OID/timestamp pairs. } Wait a while // 300 seconds (5 mins) is a typical sleep time. 39

40 40 The database utility used by this manager is an application called RRDtool, which not only creates and populates databases, but graphs them as well (Van Den Bogaerdt, 2010). RRDtool is open-source and is used by popular networking applications such as multi-router traffic grapher (MRTG). In fact, MRTG is simply a Perl script wrapper around RRDtool; much like this research s bash script. Similarly, OpenNMS uses a javabased implementation of RRDtool to store management information. The type of database that RRDtool creates is called a round robin database, and they are ideal for network management applications because they are designed for long-term data storage. The size of the database is determined when it is created as well as the update interval and any trending/averaging that it will perform over time. The database is populated in a cyclical nature, such that if the database reaches the end, then it will begin populating the beginning again. They are therefore capable of storing a known amount of historical information, which is exactly what is required for network management data storage and why they are used in OpenNMS, MRTG, and other similar tools. The manager script from this project polls for three bundle statistic and timestamp pairs: bundlesreceived (.2.1.1), bundlessent (.2.1.2), and bundlesdropped (.2.1.3) of a particular node (again, laren). Part of each RRD is called the Round Robin Archive (RRA) which defines, among other things, the total duration of stored data. The RRAs defined in this simple manager script collect data every 300 seconds, and hold a 24 hour period worth of data. Bundlssent is rate-calculated every 300 second (once per interval), bundlesreceived is rate-calculated every 600 seconds (two intervals per data point), and bundlesdropped is rate-calculated every 900 seconds (three intervals per consolidated data point) in order to reflect the rate at which the SQL database is updated. Using the 40

41 41 RRDtool to graph these databases results in the following images: Figure 17: 24 Hours of Bundlessent (Graphed Tue. 16:07) Figure 18: 24 Hours of Bundlesreceived (Graphed Tue. 16:07) Figure 19: 24 Hours of Bundlesdropped (Graphed Tue. 16:07) The discrepancy between the latest time on the graph (13:20) and the actual time recorded (16:07) represents the time it took for the information to travel over the DTN. 41