DTN Research Group G. Clark Internet-Draft G. Campbell Expires: August 1, 2010 H. Kruse S. Ostermann Ohio University IRG January 28, 2010 DING Protocol -- A Protocol For Network Management draft-irtf-dtnrg-ding-network-management-00 Abstract This memo describes the DING (Diagnostic Interplanetary Network Gateway) protocol, which is a network management protocol designed for use in delay and disruption tolerant networks (DTNs). The protocol is designed to eliminate some of the overhead involved with using SNMP to manage hosts on a DTN. 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 1, 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 1, 2010 [Page 1] Internet-Draft DING Network Management January 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 1, 2010 [Page 2] Internet-Draft DING Network Management January 2010 1. Introduction This document describes the first version of the Diagnostic Interplanetary Network Gateway (DING) communication protocol. DING is a protocol designed to be used for network management in delay and/or disruption tolerant networks. The protocol has been designed as a lower-bandwidth alternative to SNMP for use in delay / disruption tolerant networks. DING can be broken down into a number of subsections: o Schemas -- Specified in standard ASN.1 format. Used to describe which data to transmit when an update is sent. o Data -- Data sent from one host to another. Packed as described by an associated schema. A related RFC describes a gateway that provides SNMP access to terrestrial hosts; this RFC only describes the protocol spoken in the delayed / disrupted network. This is an experimental protocol. If this protocol is used on the Internet, IETF standard protocols for security and congestion control should be used. Clark, et al. Expires August 1, 2010 [Page 3] Internet-Draft DING Network Management January 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 1, 2010 [Page 4] Internet-Draft DING Network Management January 2010 3. Service Definitions Frame - A chunk of data. Schema - Definition of frame fields and types. ASN.1 representation on a host, and a binary-encoded sequence of OIDs when being transmitted on the wire. Slot - Since this protocol is designed to operate between space objects with limited resources, there's the chance that the machine might not support an unlimited number of different schemas. Thus, we assign each schema to a "slot". Each of these slots are spaces meant to hold a schema, so by assigning a schema definition to a slot, we effectively limit the number of schemas a host will have active at once. Schema ID - Provides for packets and / or bundles to be delivered out of order. Normally a hash of a frame's schema, but can also be integers or equivalent (e.g. in case resources don't allow for hash computation). Can also be used for security (e.g. HMAC). Clark, et al. Expires August 1, 2010 [Page 5] Internet-Draft DING Network Management January 2010 4. Schemas 4.1. Schema Format A schema should be defined on a node in either ASN.1 MIB format (as described by RFC 3418) or SMIng format (as described by RFC 3780). When sent across the wire, no data should be sent except the OIDs corresponding to the data being transmitted; it is assumed that both sending and receiving nodes will have matching schemas. This is verified by the "Schema ID" field as described below. 4.2. Schema Encoding When sending a schema, there is some additional information that must be included before the schema. This information as represented as a 1-byte 'Options' field. After this field, there is X bytes of option-related data (as determined by the value of the 'Options' field). The actual schema follows any data related to the Options field. 4.2.1. Encoding Overview A schema encoded into a bundle would look like. . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options [8 bits] | Option data... | Schema... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Encoded Schema The schema section of the above would look like. . . +-+-+-+-+-+-+-+-+-+-+-+-+ | OID | OID | OID | ... | +-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Schema Detail Where each "OID" in the above refers to an OID as defined in the schema running on the end node. Clark, et al. Expires August 1, 2010 [Page 6] Internet-Draft DING Network Management January 2010 The options bits are defined as. . . 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S|U|L|G|R|S|M|E| |C|I|E|Z|M|H|D|X| |H|D|N|P|V|A|5|T| +-+-+-+-+-+-+-+-+ Figure 3: Options The bits in the Options field represent the following: o SCH -- Schema bit. If set, this is a schema definition; otherwise, this bundle contains data. o UID -- Schema ID. If set, the first five bytes of the option data comprise a Schema ID. o LEN -- Length bit. If set, the option data contains an SDNV integer (after the Schema ID, if present) which represents the length of the schema (in bytes). o GZP -- GZIP bit. If set, the schema is compressed in the GZIP format. o RMV -- Remove bit. If set, the schema with a given Schema ID will be removed. o SHA -- SHA-1 bit. If set, use SHA-1 to compute the Schema ID. o MD5 -- MD5 bit. If set, use MD5 to compute the Schema ID. If this option is set, the last byte of the Schema ID should consist solely of '0's. o EXT -- Extension bit. If this bit is set, then the option data contains an SDNV integer of value X (after the Schema ID, if present, and after the length, if present), followed by X bytes of data. This is to allow the inclusion of additional options, should the need arise. If the RMV bit is set, the LEN and Schema ID options must also be set. When a host receives a request to remove a schema, it must not only ensure that the UIDs match, but also that the length provided in the option field matches that of the schema identified by the Schema ID. Given the nature of DTN, it is a distinct possibility that a request Clark, et al. Expires August 1, 2010 [Page 7] Internet-Draft DING Network Management January 2010 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 (as constrained by system resources and determined by network link characteristics). 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 request for removal currently queued by the system, that schema should be immediately discarded. 4.2.2. Schema Example For example, if a satellite has a MIB that associates an OID .92.2.3.1 with a thermal sensor, and another OID .92.2.3.2 that refers to a battery charge sensor, then a corresponding schema might be: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | .92.2.3.1 | .92.2.3.2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Example Schema This schema is saying that every update the satellite sends with a Schema ID corresponding to that of this schema will contain two data values: the data from the thermal sensor and the data from the battery charge sensor. Clark, et al. Expires August 1, 2010 [Page 8] Internet-Draft DING Network Management January 2010 5. Data Frames 5.1. Frame Format Data sent according to a schema must match the order of and number of fields in that schema. 5.2. Frame Encoding When sending a frame, there is some additional information that must be included before the frame. This information is represented as a 1-byte 'Options' field. After this field, there is X bytes of option-related data (as determined by the value of the 'Options' field). The actual frame follows any data related to the Options field. A frame encoded into a bundle would look like. . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options [8 bits] | Option data... | Frame... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Encoded Frame The bits in the Options field represent the following: The options bits are defined as. . . 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S|U|L|G|U|U|U|E| |C|I|E|Z|N|N|N|X| |H|D|N|P|U|U|U|T| +-+-+-+-+-+-+-+-+ Figure 6: Options o SCH -- Schema bit. If set, this is a schema definition; otherwise, this bundle contains data. o UID -- Schema ID bit. If set, the first five bytes of the option data comprise a Schema ID. o LEN -- Length bit. If set, the option data contains an SDNV integer (after the Schema ID, if present) which represents the length of the schema (in bytes). Clark, et al. Expires August 1, 2010 [Page 9] Internet-Draft DING Network Management January 2010 o GZP -- GZIP bit. If set, the frame is compressed in the GZIP format. o EXT -- Extension bit. If this bit is set, then the option data contains an SDNV integer of value X (after the Schema ID, if present, and after the length, if present), followed by X bytes of data. This is to allow the inclusion of additional options, should the need arise. o UNU -- Unused bit. The values in any bit marked as UNU should be ignored. 5.3. Frame Example To send an update corresponding to the schema defined in the Example Schema figure found in section 4, the frame section of the bundle would consist of: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 255 | 252 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Example assuming that the thermal and charge sensors reported values of 255 and 252, respectively. Clark, et al. Expires August 1, 2010 [Page 10] Internet-Draft DING Network Management January 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 1, 2010 [Page 11]