One document matched: draft-irtf-dtnrg-ding-network-management-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 10:44:53 |