DTN Research Group G. Clark Internet-Draft G. Campbell Expires: August 13, 2010 H. Kruse S. Ostermann Ohio University IRG February 9, 2010 DING Protocol -- A Protocol For Network Management draft-irtf-dtnrg-ding-network-management-02 Abstract This memo describes the Diagnostic Interplanetary Network Gateway protocol (DING). DING is a subscription-based network management protocol designed specifically for use in situations where SNMP's request / response model does not perform well, e.g. in heavily delayed and / or disrupted networks. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 13, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Clark, et al. Expires August 13, 2010 [Page 1] Internet-Draft DING Network Management February 2010 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Clark, et al. Expires August 13, 2010 [Page 2] Internet-Draft DING Network Management February 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 3. Service Definitions . . . . . . . . . . . . . . . . . . . . . 6 4. Subscription Requests . . . . . . . . . . . . . . . . . . . . 8 4.1. Subscription Request Overview . . . . . . . . . . . . . . 8 4.2. Schema Section . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Schema Format . . . . . . . . . . . . . . . . . . . . 10 4.2.2. Schema / SNMP Compatibility Note . . . . . . . . . . . 11 4.2.3. OID Compression . . . . . . . . . . . . . . . . . . . 11 4.3. Schedule Section . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. Schedule Overview . . . . . . . . . . . . . . . . . . 11 4.4. Example Subscription Request . . . . . . . . . . . . . . . 12 5. Scheduled Frames . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Scheduled Frame Container Overview . . . . . . . . . . . . 14 5.2. Scheduled Frame Entries . . . . . . . . . . . . . . . . . 15 5.3. Scheduled Frame Entry Example . . . . . . . . . . . . . . 15 6. Removal Requests . . . . . . . . . . . . . . . . . . . . . . . 17 7. Status Requests . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Clark, et al. Expires August 13, 2010 [Page 3] Internet-Draft DING Network Management February 2010 1. Introduction Over the past 20 years, SNMP has firmly established itself as the de facto standard protocol for network management. There are SNMP agents available for everything from network switches to supercomputers. Further, the protocol works extremely well on most (if not all) terrestrial networks. In delay tolerant networks (DTNs), however, SNMP tends to perform poorly. The request / response mechanism SNMP uses does not seem practical in environments where transmission delays can range from minutes to days; by the time a query has made it to a remote host and back again, the information contained in the response is often too old to be relevant to the device's status at the current point in time. Furthermore, in many delay-tolerant networks, there are often severe restrictions in place on the amount of bandwidth available to a given device. While SNMP is not an inefficient protocol, there are areas where existing knowledge about a device could be utilized to drastically reduce the size of SNMP requests and replies. The Diagnostic Interplanetary Network Gateway (DING) protocol described in this document has been designed to address these issues. Rather than use the request / reply paradigm employed by SNMP, DING relies on a subscription model. When a host wishes to receive information about a remote node, the host (called a "subscriber") sends that node (called a "provider") a "subscription request". This request consists of two parts: a "schema" and a "schedule". The "schema" is a static data model definition that defines exactly which data the subscriber wishes to receive from the provider. This schema consists solely of a list of object identifiers (OIDs). The provider, upon examining the schema, parses this list of OIDs and compares each OID to a list of known OIDs it has. If the OID matches a piece of information it knows how to provide, the provider will transmit that information as instructed by the schedule included with the subscription request. If the provider does not know how to translate a given OID into data, the provider will assign 0 to any field where that OID is requested. The "schedule" contains two things: a time interval and a set of conditions. The conditions determine when a provider sends a scheduled frame: the provider will only send a scheduled frame if all conditions are met (the expression provided in the schedule frame evaluates to true). If no conditions are specified, then the Clark, et al. Expires August 13, 2010 [Page 4] Internet-Draft DING Network Management February 2010 provider assumes that there are no conditions to meet and will transmit scheduled frames as determined by the time interval. The time interval itself (specified in seconds) determines how often to transmit "scheduled frames" (sets of data encoded using a given schema). As soon as the conditions in a schedule are met, a single scheduled frame is transmitted, and then an additional scheduled frame is transmitted every time_interval seconds. If the time interval is set to be zero, then the scheduled frame is sent only when the specified conditions are met and is never repeated. When a provider sends a scheduled frame to a subscriber as described by a schema, the scheduled frame includes a "Schema ID" which can be used by the subscriber to uniquely identify the schema associated with that scheduled frame. It also includes a "Schedule ID" which can be used to identify the schedule that triggered the frame. Assuming Schema IDs are used and agreed upon by both the provider and the subscriber, data can be encoded far more efficiently than it would be if encoded in the standard BER and DER formats used by SNMP. If further compression is desired, DING supports specifying that data has been compressed; see sections 4.3 and 4.4 of this document for details. DING is designed to operate in conjunction with a gateway. This gateway is designed to act as a kind of SNMP proxy for DTN nodes. To do this, the gateway subscribes to a number of DING providers running on a DTN and caches scheduled frames received from each provider. The gateway also runs an SNMP agent which uses this cached information to respond to SNMP GET messages and generate SNMP TRAP messages. The motivation for and operation of this gateway will be explored further in a separate draft (currently a work in progress). Clark, et al. Expires August 13, 2010 [Page 5] Internet-Draft DING Network Management February 2010 2. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Clark, et al. Expires August 13, 2010 [Page 6] Internet-Draft DING Network Management February 2010 3. Service Definitions Frame - A collection of consecutive bytes organized into a single logical unit. Provider - A machine that provides a service which processes subscription requests from and sends scheduled frames to subscribers. Registration - The act of sending a subscription request to a provider. Removal Request - Request to remove a certain schema from a provider (so that the provider will quit using that schema along with any associated schedules to send scheduled frames to a subscriber) and / or remove a certain schedule from a provider. Schedule - Links a schema with a time interval and a set of conditions. Assuming that all conditions described in a schedule are met, the provider is expected to send a scheduled frame every [time interval] seconds. Scheduled Frame - A frame sent by a provider to a subscriber as directed by the "schedule" portion of a subscription request. The content of this data is described by the "schema" portion of a subscription request. A scheduled frame may be associated with a corresponding schema and / or subscription request through the use of a schema ID. Scheduled Frame Container - A container meant to transport one or more scheduled frames from a provider to a subscriber. Scheduled Frame Entry - A single scheduled frame contained within a "Scheduled Frame Container". Schema - A static data model which is included in a subscription request and defines exactly which pieces of data the subscriber is requesting from the provider. Schema ID - A sequence of bytes which can be used to uniquely identify a given schema. This documents suggests computing an SHA-1 hash of the schema to compute this value, although the particular method is not as important as is A) ensuring that both subscriber and provider agree on an ID and B) ensuring ID is as unique as possible. Self-Delimiting Numeric Value (SDNV) - Encoding for a positive integer. Supports numbers of any size through the use of a scheme similar to that used within BER to encode OIDs into numeric values. See RFC 5050 for a complete explanation of SDNVs and their usage. Clark, et al. Expires August 13, 2010 [Page 7] Internet-Draft DING Network Management February 2010 Subscriber - A machine which has sent a subscription request to a provider. Unsubscribe - Sending a "removal request" to a provider so that provider will quit sending certain scheduled frames to a given subscriber. Clark, et al. Expires August 13, 2010 [Page 8] Internet-Draft DING Network Management February 2010 4. Subscription Requests 4.1. Subscription Request Overview A subscription request is composed of the following fields: o Type -- Four bit field consisting of the value '0110'. o Options -- Set of options applying to every field contained within this subscription request. 4-bit field. The following options are supported: 0 1 2 3 +-+-+-+-+ |C|H|S|E| |M|S|C|X| |P|H|A|T| +-+-+-+-+ Figure 1: Options * CMP -- Compression bit. If set, the schema is compressed. The format is encoded as a one-byte number in the options data. The following options must be supported: + 0 -- No compression. + 1 -- GZIP format. Additional options may be supported assuming both subscriber and provider agree on a common association between number and compression scheme. * HSH -- Hash bit. If set, the provider should run a specified hash algorithm on each included schema and verify that the resulting hash matches the specified schema's ID. This is designed to be used as a simple data integrity check, and could perhaps be used as a part of a simple authentication scheme as well. The algorithm to use is specified by the first byte of the options data section (HSHDATA). The following options must be supported: + 0 -- No hash; IDs of all included schemas are assumed to be 0. Using this option is not recommended, but may be necessary for some devices depending on hardware specifications and / or bandwidth requirements. Clark, et al. Expires August 13, 2010 [Page 9] Internet-Draft DING Network Management February 2010 + 1 -- CRC; 16 bit. Using this option is not recommended, but may be necessary for some devices depending on hardware specifications and / or bandwidth requirements. + 2 -- MD5; 128 bit digest. + 3 -- SHA-1; 160 bit digest. When the hash option is specified, the size of the schema ID field must be the same size as the size of the digest produced. When the hash bit is not specified, the schema ID field must have a size of 20 bytes. * SCA -- Scaling bit. If this bit is set, NSC and NSM will both be multiplied by an SDNV provided in the option data. * EXT -- Extension bit. If this bit is set, then the option data contains an SDNV integer of value X (after the hash byte and compression byte, if either and / or both are present), followed by X bytes of data. This is to allow the inclusion of additional options, should the need arise. o Option Data -- Data necessary to support any option bits set in the Options field. Up to three bytes in length unless EXT bit is set, at which point the size of this field is unknown. o Number of Schemas (NSM) -- 4 bits encoding number of schemas included with this request. Up to 16 * SCA. o Number of Schedules (NSC) -- 4 bits encoding number of schedules included with this request. Up to 16 * SCA. o Schema X (SMX) -- schema number X in a sequence of NSM consecutive schema fields. Unknown total length, but there can be no more than NSchma schemas included with a single subscription request. o Schedule X (SCX) -- schedule number X in a sequence of NSC consecutive schedule fields. Unknown total length, but there can be no more than NSched schedules included with a single subscription request. Clark, et al. Expires August 13, 2010 [Page 10] Internet-Draft DING Network Management February 2010 Example schedule request header format (assuming CMP = 1, HSH = 1, SCA = 0, EXT = 0): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | OPTN | HSHDATA | CMPDATA | NSM | NSC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SMX [NSM variable-length schemas] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCX [NSC variable-length schedules | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Subscription Request Overview 4.2. Schema Section 4.2.1. Schema Format A schema is composed of an X-bit ID unique ID, followed by a list of SDNV / OID pairs. Each SDNV specifies the depth of a particular OID from the root of the OID tree (.1 = 1, .3.2.4 = 3, .6.1.4.7.24 = 5, etc), and each OID is encoded in standard DER format. The last entry in a schema must consist of a single "OID_DEPTH" field with a value of 0. +-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+ ~ +-+-+ | SCHEMA_ID | | OID_DEPTH | | OID | | OID_DEPTH | | OID | | 0 | +-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+-+ ~ +-+-+-+-+-+-+-+ ~ +-+-+-+ ~ +-+-+ Figure 3: Schema Format Given the nature of DTN, it is a distinct possibility that a request to remove a schema from a system may arrive before the schema itself. Thus, requests for the removal of a schema that does not yet exist should be held for some time, where the exact definition of "some time" is left up to the system implementing this protocol. If a schema is received with a Schema ID that matches the Schema ID of a schema already stored, the newest schema may be either stored (while waiting for a removal request) or silently discarded. Note that if a schema arrives with a Schema ID and length that matches any removal request currently queued by the system, that schema should be immediately discarded. Clark, et al. Expires August 13, 2010 [Page 11] Internet-Draft DING Network Management February 2010 4.2.2. Schema / SNMP Compatibility Note In an effort to provide some compatibility between DING and SNMP, a schema may be stored locally on a host as a MIB encoded in standard ASN.1/SMIng format. To convert a MIB into a schema, a provider or subscriber should extract each leaf OID defined within the MIB. Once the provider or subscriber has done this, they may simply use this list of OIDs as a schema. Note that the order these OIDs appear in the schema must match the order in which they were defined in the corresponding MIB. 4.2.3. OID Compression [Need to do literature review here; found draft on SNMP Payload Compression by Schoenwaelder et. al.] [How do OID compression algorithms compare to "standard" compression algorithms e.g. GZIP / BZIP2?] 4.3. Schedule Section 4.3.1. Schedule Overview A schedule is composed of an X-bit schema ID, an SDNV-encoded schedule ID, an SDNV-encoded interval value, and a set of conditions (an expression). +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+-+ | SCHEMA_ID | | SCHED_ID | | INTERVAL | | EXPR | +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+-+ Figure 4: Schedule Format The SCHEMA_ID must refer to an existing schema (which may be defined by the current subscription request or exist previously); if this field refers to an unknown schema, the provider may choose to A) ignore the schedule request or B) hold the schedule request for an unknown time in the hopes of receiving a relevant schema. The SCHED_ID is an SDNV which can be used, in conjunction with the schema ID, to uniquely reference this schedule. The INTERVAL is a time interval, specified in seconds and encoded as an SDNV. Assuming all conditions are met, this value specifies the amount of time the provider should wait between each scheduled frame it transmits. Clark, et al. Expires August 13, 2010 [Page 12] Internet-Draft DING Network Management February 2010 EXPR is an expression (a set of conditions) that determine whether or not a scheduled frame should be transmitted. Each condition is composed of a single operator (<, >, <=, >=, ==, !=, &&, ||) and two operands, where an operand can be an OID, a constant, or a condition. o If an operand is an OID, the value of any sensors associated with that OID should be inserted into the expression when the expression is evaluated. If a provider does not have a sensor associated with a given OID, the OID should be treated as the integer '0'. o An expression must evaluate to be either TRUE or FALSE. o If the value of an expression changes from FALSE to TRUE, a scheduled frame should be immediately sent unless a scheduled frame has already been sent within the last INTERVAL seconds. o Example: .3.2.7.4 <= 4 && .3.2.7.5 > .3.2.7.4 o [*** TODO *** : Specify how EXPR is encoded in schedule data (e.g. NOT plaintext). Specify BNF. Perhaps move conditions to its own section?] 4.4. Example Subscription Request NOTE: This is a contrived example; the OIDs used here are not valid, and are used for the sole purpose of saving space. Also, the schema ID here is not necessarily valid. Assume a satellite (the provider) knows that OID .92.2.3.1 corresponds to a thermal sensor and that OID .92.2.3.2 corresponds to a battery charge sensor. A subscriber sends a subscription request to this satellite, with the following OIDs listed in the schema portion of the subscription request: +-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+ ~ +-+-+ | 0xf73492aaecb | | 4 | .92.2.3.1 | | 4 | .92.2.3.2 | | 0 | +-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+ ~ +-+-+ Figure 5: Example Schema Section This schema says every scheduled frame that the satellite sends with a Schema ID corresponding to that of this schema (0xf73492aaecb) will contain two data values: the data from the thermal sensor and the data from the battery charge sensor. The schedule part of the subscription request looks like: Clark, et al. Expires August 13, 2010 [Page 13] Internet-Draft DING Network Management February 2010 +-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xf73492aaecb | | 108000 | .92.2.3.1 > 120 | +-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Example Schedule Section The schedule says that scheduled frames with a format corresponding to this schema with ID 0xf73492aaecb will be sent every 30 minutes (108000 seconds) ONLY IF the value corresponding to .92.2.3.1 (in this case, the reading from the thermal sensor) is greater than 120. Clark, et al. Expires August 13, 2010 [Page 14] Internet-Draft DING Network Management February 2010 5. Scheduled Frames 5.1. Scheduled Frame Container Overview A scheduled frame container is composed of the following fields: o Type -- Four bit field consisting of the value '0111'. o Options -- Set of options applying to every field contained within this scheduled frame. 4 bit field. The following options are supported: 0 1 2 3 +-+-+-+-+ |C|U|S|E| |M|N|C|X| |P|U|A|T| +-+-+-+-+ Figure 7: Options * CMP -- Compression bit. If set, all data within the scheduled frame is compressed. The format is encoded as a one-byte number in the options data. The following options must be supported: + 0 -- No compression. + 1 -- GZIP format. Additional options may be supported assuming both subscriber and provider agree on a common association between number and compression scheme. * UNU -- Unused bit. The value of this bit must be ignored. * SCA -- Scaling bit. If this bit is set, NSF will be multiplied by an SDNV provided in the option data. * EXT -- Extension bit. If this bit is set, then the option data contains an SDNV integer of value X (after the hash byte and compression bytes, if either and / or both are present), followed by X bytes of data. This is to allow the inclusion of additional options, should the need arise. Clark, et al. Expires August 13, 2010 [Page 15] Internet-Draft DING Network Management February 2010 o Option Data -- Data necessary to support any option bits set in the Options field. Up to two bytes in length unless EXT bit is set, at which point the size of this field is unknown. o Number of Scheduled Frames (NSF) -- 8 bits encoding number of entries included within this scheduled frame. Up to 256. o Scheduled Frame X (SFX) -- scheduled frame number X in a sequence of NSF consecutive scheduled frame fields. Example scheduled frame container header (assuming CMP = 0, SCA = 0, EXT = 0): 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TYPE | OPTN | NSF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SFX [NSF entries] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Scheduled Frame Container Overview 5.2. Scheduled Frame Entries Each individual scheduled frame entry within a scheduled frame container consists of the following fields: Schema ID -- ID of the schema that should be used to parse this data. Variable length field. Sched ID -- ID of the schedule that generated this scheduled frame. Data -- Data which corresponds to a schema. Each 'Data' field in the schema corresponds to the value mapped from a single OID. +-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+ | SCHEMA_ID | | SCHED_ID | | DATA | | DATA | | ... | +-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+ Figure 9: Scheduled Frame Entry Format 5.3. Scheduled Frame Entry Example Assuming a subscriber has registered with the provider described in the "Subscription Request Example" section, then an entry in the scheduled frame container originating from the provider (the Clark, et al. Expires August 13, 2010 [Page 16] Internet-Draft DING Network Management February 2010 satellite, in this case) might look like: +-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0xf73492aaecb | | 170 | 252 | +-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Satellite's Scheduled Frame Entry assuming that the thermal and charge sensors reported values of 170 and 252, respectively. Clark, et al. Expires August 13, 2010 [Page 17] Internet-Draft DING Network Management February 2010 6. Removal Requests Sent by a subscriber to unsubscribe (quit receiving scheduled frames from a provider) or to remove a schedule associated with a given schema (referenced by schema ID and schedule ID). *** TODO *** Clark, et al. Expires August 13, 2010 [Page 18] Internet-Draft DING Network Management February 2010 7. Status Requests Clark, et al. Expires August 13, 2010 [Page 19] Internet-Draft DING Network Management February 2010 Authors' Addresses Gilbert Clark Ohio University Internetworking Research Group 301 Stocker Center Ohio University Athens, OH 45701 US Email: gc355804@ohio.edu URI: http://irg.cs.ohiou.edu/ Greg Campbell Ohio University Internetworking Research Group 301 Stocker Center Ohio University Athens, OH 45701 US URI: http://irg.cs.ohiou.edu/ Hans Kruse Ohio University Internetworking Research Group 292 Lindley Hall Ohio University Athens, OH 45701 US URI: http://irg.cs.ohiou.edu/ Shawn Ostermann Ohio University Internetworking Research Group 322b Stocker Center Ohio University Athens, OH 45701 US URI: http://irg.cs.ohiou.edu/ Clark, et al. Expires August 13, 2010 [Page 20]