One document matched: draft-irtf-dtnrg-ding-network-management-01.txt
Differences from 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-01
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 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
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.4. Example Subscription Request . . . . . . . . . . . . . . . 11
5. Scheduled Frames . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Scheduled Frame Container Overview . . . . . . . . . . . . 13
5.2. Scheduled Frame Entries . . . . . . . . . . . . . . . . . 14
5.3. Scheduled Frame Entry Example . . . . . . . . . . . . . . 14
6. Removal Requests . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Clark, et al. Expires August 1, 2010 [Page 3]
Internet-Draft DING Network Management January 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" can be one of two things: a time interval or a set of
conditions. If a time interval is specified, then the provider will
send all data listed in the accompanying schema to the subscriber at
a frequency defined by this interval. If a set of conditions is
specified, then the provider will send all data listed in the
Clark, et al. Expires August 1, 2010 [Page 4]
Internet-Draft DING Network Management January 2010
accompanying schema to the subscriber only when all specified
conditions have been met (emulating SNMP's TRAP functionality).
When a provider sends a set of data (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 and schedule associated with that scheduled 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).
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 5]
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 6]
Internet-Draft DING Network Management January 2010
3. Service Definitions
Frame - A collection of consecutive bytes organized into a single
logical unit.
Magic - All DING protocol traffic use the initial four bits to
specify the type of request and / or frame being sent. 15 unique
types are supported with the use of these four bits, and an unlimited
number of types are supported through the use of the '1111' magic and
the EXT bit of the options field.
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 data to a subscriber.
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 1, 2010 [Page 7]
Internet-Draft DING Network Management January 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 1, 2010 [Page 8]
Internet-Draft DING Network Management January 2010
4. Subscription Requests
4.1. Subscription Request Overview
A subscription request is composed of the following fields:
o Magic -- 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 1, 2010 [Page 9]
Internet-Draft DING Network Management January 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 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.
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 1, 2010 [Page 10]
Internet-Draft DING Network Management January 2010
Example schedule request header (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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MGC | 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 1, 2010 [Page 11]
Internet-Draft DING Network Management January 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
*** TODO ***
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 4: 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 1, 2010 [Page 12]
Internet-Draft DING Network Management January 2010
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xf73492aaecb | | 108000 | .92.2.3.1 > 120 |
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: 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 1, 2010 [Page 13]
Internet-Draft DING Network Management January 2010
5. Scheduled Frames
5.1. Scheduled Frame Container Overview
A scheduled frame container is composed of the following fields:
o Magic -- 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 6: 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 1, 2010 [Page 14]
Internet-Draft DING Network Management January 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MGC | OPTN | NSF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SFX [NSF entries] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: 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 which should be used to parse this
data. Variable length field.
Data -- Data which corresponds to a schema. Each 'Data' field in the
schema corresponds to the value mapped from a single OID.
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+
| SCHEMA_ID | | DATA | | DATA | | ... |
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+-+-+-+ ~ +-+-+-+
Figure 8: 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
satellite, in this case) might look like:
Clark, et al. Expires August 1, 2010 [Page 15]
Internet-Draft DING Network Management January 2010
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xf73492aaecb | | 170 | 252 |
+-+-+-+-+-+-+-+-+ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Satellite's Scheduled Frame Entry
assuming that the thermal and charge sensors reported values of 170
and 252, respectively.
Clark, et al. Expires August 1, 2010 [Page 16]
Internet-Draft DING Network Management January 2010
6. Removal Requests
Sent by a subscriber to unsubscribe (quit receiving scheduled frames
from a provider). *** TODO ***
Clark, et al. Expires August 1, 2010 [Page 17]
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 18]
| PAFTECH AB 2003-2026 | 2026-04-24 09:08:20 |