< draft-irtf-nmrg-snmp-compression-00.txt   draft-irtf-nmrg-snmp-compression-01.txt >
Network Working Group J. Schoenwaelder, Editor
Network Working Group J. Schoenwaelder
Internet-Draft TU Braunschweig Internet-Draft TU Braunschweig
Expires December 1999 20 June 1999 Expires: October 10, 2001 April 11, 2001
SNMP Payload Compression SNMP Payload Compression
draft-irtf-nmrg-snmp-compression-01.txt
<draft-irtf-nmrg-snmp-compression-00.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026. Internet-Drafts are working all provisions of Section 10 of RFC2026.
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute Internet-Drafts are working documents of the Internet Engineering
working documents as Internet-Drafts. 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 Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html.
Distribution of this document is unlimited. Please send comments to This Internet-Draft will expire on October 10, 2001.
the Network Management Research Group <nmrg@ibr.cs.tu-bs.de>.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
This memo defines a mechanism for lossless compression of SNMP This memo defines a mechanism for lossless compression of SNMP
payloads. Compression is especially useful when retrieving large payloads. Compression is especially useful when retrieving large
amounts of data or when SNMP encryption is used. amounts of data or when SNMP encryption is being used over a
transport which provides data compression.
Table of Contents Table of Contents
1 Introduction ................................................. 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2 Requirements and Alternatives ................................ 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Compression as an SNMPv3 Encryption Algorithm .............. 3 3. Identifying Compressed Payload . . . . . . . . . . . . . . 4
2.2 Indicating Compression in the msgFlags ..................... 4 3.1 Compression as an SNMPv3 Encryption Algorithm . . . . . . 4
2.3 Compression as a new PDU type .............................. 4 3.2 Indicating Compression in the msgFlags . . . . . . . . . . 4
3 Acknowledgments .............................................. 6 3.3 Compression as a new PDU Type . . . . . . . . . . . . . . 5
4 References ................................................... 6 4. Negotiating Compression Algorithms . . . . . . . . . . . . 6
5 Editor's Address ............................................. 6 5. Compression Algorithms . . . . . . . . . . . . . . . . . . 6
6 Full Copyright Statement ..................................... 7 5.1 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2 OID Delta Compression (ODC) . . . . . . . . . . . . . . . 7
5.2.1 ODC Algorithm . . . . . . . . . . . . . . . . . . . . . . 7
5.2.2 ODC Examples . . . . . . . . . . . . . . . . . . . . . . . 10
5.2.2.1 Simple Substitutions . . . . . . . . . . . . . . . . . . . 10
5.2.2.2 Range Substitutions . . . . . . . . . . . . . . . . . . . 11
5.2.2.3 Substitutions and Truncations . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This memo defines a mechanism for lossless compression of SNMP This memo defines mechanisms for lossless compression of SNMP
payloads. Compression is useful when retrieving large amounts of payloads. Compression is useful when retrieving large amounts of
management data since the BER encoding used by SNMP is not very space management data since the BER encoding used by SNMP is not very space
efficient and the data tends to have a high degree of redundancy. efficient and the payload tends to have a high degree of redundancy.
SNMP payload compression is especially useful when SNMP encryption is SNMP payload compression is especially useful when retrieving large
used. Encrypting the SNMP payload causes the data to be random in amounts of data. In particular, compression allows command
nature, rendering compression at lower protocol layers (e.g., IP responders to put more data into responses to bulk retrieval
Payload Compression Protocol [2]) ineffective. If both compression requests, which can significantly reduce the overall number of
and encryption are required, compression MUST be applied before transactions needed to retrieve a certain amount of data [5].
encryption.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", SNMP payload compression is also useful when SNMP encryption is used.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this Encrypting the SNMP payload causes the data to be random in nature,
document are to be interpreted as described in RFC 2119 [1]. rendering compression at lower protocol layers (e.g., IP Payload
Compression Protocol [2]) ineffective. If both compression and
encryption are required, then compression should be applied before
encryption.
2. Requirements and Alternatives 2. Requirements
A solution for SNMP payload compression has to satisfy the following A solution for SNMP payload compression has to satisfy the following
requirements: requirements:
- Compression must happen before encryption if compression is used 1. Compression must happen before encryption if compression is used
together with encryption. Compression is most useful if there are together with encryption. Compression is most useful if there
regular pattern in the data. It is the nature of encryption are regular patterns in the data. It is the nature of encryption
algorithms to destroy any regular pattern and hence encrypted data algorithms to destroy any regular pattern and hence encrypted
does not compress very well. data does not compress very well.
- SNMP payload compression should support multiple compression 2. SNMP payload compression should be able to support multiple
algorithms. This means that communicating SNMP engines must be able compression algorithms. This implies that SNMP engines must be
to find agreement on the compression algorithm they are using. able to negotiate the compression algorithm they are using.
Instead of carrying compression algorithm identifier in every Instead of carrying a compression algorithm identifier in every
protocol message, it seems more effective to indicate compression protocol message, it seems more effective to indicate compression
algorithms in a MIB module (similar to authentication or encryption algorithms in a MIB module (similar to authentication or
algorithms in SNMPv3). encryption algorithms in SNMPv3).
2.1. Compression as an SNMPv3 Encryption Algorithm 3. Each SNMP message is compressed and decompressed by itself
without any relation to other SNMP messages ("stateless
compression"), as SNMP messages may arrive out of order or not
arrive at all.
The basic idea behind the first alternative is to treat compression 4. The size of a compressed SNMP message must never exceed the size
as an SNMPv3 encryption algorithm. This has the following advantages of the uncompressed SNMP message ("non-expansion policy"). A
/ disadvantages: sender may send an uncompressed SNMP message if an attempt to
compress the message produces a result which is longer than the
uncompressed SNMP message. An SNMP engine configured to receive
compressed SNMP messages must thus also accept uncompressed SNMP
messages.
5. The abstract syntax of compressed SNMP messages must be defined
using ASN.1. This ensures that a compressed SNMP message has a
valid ASN.1/BER encoding which simplifies the integration into
existing SNMP toolkits.
6. It is desirable to define common compression algorithms in order
to achieve interoperability. The compression algorithms should
be openly available and they should represent different trade-
offs between compression efficiency and CPU efficiency.
3. Identifying Compressed Payload
It is necessary to distinguish between compressed and uncompressed
SNMP payload. There are several ways to implement this. The
following sections discuss alternatives that have been considered.
3.1 Compression as an SNMPv3 Encryption Algorithm
The idea behind the first approach is to treat compression as an
additional SNMPv3 encryption algorithm. In fact, compression as well
as encryption can both be treated as a loss-less data transformation.
This approach has the following advantages / disadvantages:
+ No change required to the SNMPv3 specifications. + No change required to the SNMPv3 specifications.
+ Compression of the complete ScopedPDU.
- Support of N encryption algorithms and M compression algorithms - Support of N encryption algorithms and M compression algorithms
leads to N*M possible combinations. leads to N*M possible combinations.
- Compression requires authentication since there is no noAuthPriv - Compression requires authentication since there is no noAuthPriv
security level. security level.
+ Compression of the complete ScopedPDU. - Does not work with older and widely deployed versions of SNMP
(SNMPv1, SNMPv2c).
- Does not work with older versions of SNMP (SNMPv1, SNMPv2c).
2.2. Indicating Compression in the msgFlags 3.2 Indicating Compression in the msgFlags
To avoid some of the drawbacks of the previous approach, one can To avoid some of the drawbacks of the previous approach, one can
treat compression independent of encryption by allocating an unused treat compression independent of encryption by allocating an unused
bit in the msgFlags [3] to indicate whether compression is used or bit in the msgFlags [3]) to indicate whether compression is used or
not. However, RFC 2572 [3] says in section 6.4: not. However, RFC 2572 [3]) says in section 6.4:
The remaining bits in msgFlags are reserved, and MUST be set to The remaining bits in msgFlags are reserved, and must be set to zero
zero when sending a message and SHOULD be ignored when receiving when sending a message and should be ignored when receiving a
a message. message.
Similarly, RFC 2572 [3] specifies in section 7.1 step 7) and in Similarly, RFC 2572 [3] specifies in section 7.1 step 7) and in
section 7.2 step 5) that other bits msgFlags are set to zero or section 7.2 step 5) that other bits in the msgFlags are set to zero
ignored. This means that this alternative can not be supported by an or ignored. This means that this alternative can not be supported by
implementation which is compliant to RFC 2572 [3]. an implementation which is strictly compliant to RFC 2572 [3].
In summary, this approach has the following advantages / In summary, this approach has the following advantages /
disadvantages: disadvantages:
- Not strictly compliant to the current SNMPv3 specifications.
+ Combination of M compression and N encryption algorithms possible + Combination of M compression and N encryption algorithms possible
without having to define N*M algorithms. without having to define N*M algorithms.
+ Compression can be used with or without encryption or + Compression can be used with or without encryption or
authentication. authentication.
+ Compression of the complete ScopedPDU. + Compression of the complete ScopedPDU.
- Does not work with older versions of SNMP (SNMPv1, SNMPv2c). - Not strictly compliant to the current SNMPv3 specifications.
2.3. Compression as a new PDU type - Does not work with older widely deployed versions of SNMP (SNMPv1,
SNMPv2c).
3.3 Compression as a new PDU Type
The third alternative is to restrict compression to PDUs rather than The third alternative is to restrict compression to PDUs rather than
ScopedPDUs and to introduce a new PDU type for compressed payloads. ScopedPDUs and to introduce a new PDU type for compressed payloads.
RFC 1157 [4] defines the SNMPv1 message header as follows: RFC 1157 [4] defines the SNMPv1 message header as follows:
Message ::= SEQUENCE { Message ::= SEQUENCE {
version INTEGER { version-1(0) }, version INTEGER { version-1(0) },
community OCTET STRING, community OCTET STRING,
data ANY -- e.g., PDUs if trivial authentication data ANY -- e.g., PDUs if trivial authentication
-- is being used -- is being used
} }
Similarly, RFC 2572 [3] defines the ScopedPDU as follows: Similarly, RFC 2572 [3] defines the ScopedPDU as follows:
ScopedPDU ::= SEQUENCE { ScopedPDU ::= SEQUENCE {
contextEngineID OCTET STRING, contextEngineID OCTET STRING,
contextName OCTET STRING, contextName OCTET STRING,
data ANY -- e.g., PDUs as defined in RFC 1905 data ANY -- e.g., PDUs as defined in RFC 1905
} }
This means that a new PDU could be defined which holds the compressed This means that a new PDU could be defined which holds the compressed
version of a PDU: version of a PDU:
CompressedPDU ::= [42] IMPLICIT OCTET STRING CompressedPDU ::= [42] IMPLICIT OCTET STRING
-- contains a compressed PDU -- contains a compressed PDU
Its important to analyze how a compliant SNMP implementation behaves It is important to analyze how a compliant SNMP implementation
when it receives an unknown PDU type. From a formal point of view, behaves when it receives an unknown PDU type. From a formal point of
any PDU which is a valid BER serialization of an ASN.1 type must be view, any PDU which is a valid BER serialization of an ASN.1 type
accepted since the data portion is of the ASN.1 type ANY. In must be accepted since the data portion is of the ASN.1 type ANY. In
practice, most SNMP implementations will only recognize the PDU types practice, most SNMP implementations will only recognize the PDU types
defined in the SNMP specifications. defined in the SNMP specifications.
The SNMPv3 message processing model [3] defines in section 7.2 step The SNMPv3 message processing model [3] defines in section 7.2 step
7) that parse errors while decoding the ScopedPDU cause the packet to 7) that parse errors while decoding the ScopedPDU cause the packet to
be discarded after incrementing snmpInASNParseErrs. Even an be discarded after incrementing snmpInASNParseErrs. Even an
implementation which is capable to decode arbitrary PDUs will have implementation which is capable to decode arbitrary PDUs will have
problems to determine the pduType as defined in section 7.2 step 9). problems to determine the pduType as defined in section 7.2 step 9).
This basically means that a compliant SNMPv3 engine will simply This basically means that a compliant SNMPv3 engine will simply
discard compressed PDUs. discard compressed PDUs.
The SNMPv1 specification [4] defines in section 4.1 second step (4) The SNMPv1 specification [4] defines in section 4.1 second step (4)
that parse errors while decoding the PDU will cause the SNMP engine that parse errors while decoding the PDU will cause the SNMP engine
to drop the PDU. Hence, it can be expected that most implementations to drop the PDU. Hence, it can be expected that most implementations
will simply drop a compressed PDU. will simply drop a compressed PDU.
In summary, this approach has the following advantages / In summary, this approach has the following advantages /
disadvantages: disadvantages:
- Not strictly compliant to the current SNMPv3 specifications.
+ Combination of M compression and N encryption algorithms possible + Combination of M compression and N encryption algorithms possible
without having to define N*M algorithms. without having to define N*M algorithms.
+ Compression can be used with or without encryption or + Compression can be used with or without encryption or
authentication. authentication.
+ Works with every version of SNMP.
- Not strictly compliant to the current SNMPv3 specifications.
- Compression of the PDU rather than the ScopedPDU. - Compression of the PDU rather than the ScopedPDU.
+ Works with every version of SNMP. 4. Negotiating Compression Algorithms
3. Acknowledgments [TBD]
This document is the result of discussions of the Network Management 5. Compression Algorithms
Research Group (NMRG). Special thanks go to the following 5.1 DEFLATE
participants for their comments and contributions:
Luca Deri, Jean-Philippe Martin-Flatin, Aiko Pras, Ron Sprenkels, The DEFLATE algorithm is a well-know compression algorithm which
Bert Wijnen. achieves good compression ratios and which is used for example in RFC
2394 for IP payload compression. It is also used on the World Wide
Web to compress documents before transmission over HTTP.
4. References Using DEFLATE for SNMP payload compression however shows some
undesirable aspects. First, DEFLATE compression is relatively CPU
intensive. Furthermore, the DEFLATE algorithm requires to transmit a
dictionary, which reduces the compression efficiency for small
messages. On the other hand, DEFLATE compresses both names and
values and may achieve particularly good compression if the encoded
values show a similar structure.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Experiments with DEFLATE show that it should not be used on
Levels", BCP 14, RFC 2119, March 1997. relatively short SNMP messages. Furthermore, DEFLATE introduces
significant delays due to the compression computations. Finally,
estimating message sizes is hard with DEFLATE since there is no upper
bound for the message length addition if one adds another varbind.
This has impacts in particular on the getbulk PDU implementation. It
is therefore not recommended to adopt DEFLATE compression.
[2] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload 5.2 OID Delta Compression (ODC)
Compression Protocol (IPComp)", RFC 2393, December 1998.
[3] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message SNMP payloads use OIDs to represent the names of SNMP variables. The
Processing and Dispatching for the Simple Network Management amount of space used for encoding these OIDs frequently exceeds the
Protocol (SNMP)", RFC 2572, April 1999. space needed to represent the values identified by the OIDs.
Furthermore, subsequent OIDs usually have many sub-identifier in
common.
[4] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple The OID Delta Compression (ODC) algorithm has been designed to reduce
Network Management Protocol (SNMP)", RFC 1157, May 1990. the OID overhead inherent in SNMP messages. The general idea is to
encode an OID as a delta to the previous OID. The ODC algorithm only
achieves a reduction in the SNMP naming information. It does not
compress the data of MIB variables, even if the value itself is an
OID. (The reason for not compressing OID values is that they are (a)
relatively infrequent and (b) compressing value OIDs has negative
impact on the compression achieved for the following variable name.)
In many cases (e.g., when retrieving large tables which basically
contain numbers), the achieved compression ratio is significant while
the CPU cycles spent on the compression algorithm itself are very
small.
5. Editor's Address 5.2.1 ODC Algorithm
Juergen Schoenwaelder The ODC algorithm encodes OID deltas using three mechansisms:
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3283 1. Substitution of a single sub-identifier values at a certain
EMail: schoenw@ibr.cs.tu-bs.de position. A sub-identifier substitution is encoded as follows:
6. Full Copyright Statement 0 7 8
+---------------+--------------------------//-+
| s-offset | BER encoded sub-identifier |
+---------------+--------------------------//-+
Copyright (C) The Internet Society (1999). All Rights Reserved. s-offset Defines the offset of the sub-identifier to
substitute. The offset value is in the range
0-0x7f. The value 0 refers to the first OID
sub-identifier.
2. Substitution of ranges of sub-identifiers at a given starting
position. A substitution of a range of sub-identifiers is
encoded as follows:
0 7 8 15 16
+---------------+---------------+--------------------------//-+
| r-offset | r-length | BER encoded sub-identifiers |
+---------------+---------------+--------------------------//-+
r-offset Defines the offset of the sub-identifier range
to substitute. The offset value has the most
significant bit set and is in the range
0x80-0xff. The value 0x80 refers to the first
OID sub-identifier.
r-length Defines the number of BER encoded sub-identifiers
that follow the r-length field and which will
be substituted. The range of the r-length field
is 0x01-0x7f.
3. Truncation of OIDs (which may shorten or enlarge OIDs). A
truncation, which may only appear at the end, is encoded as
follows:
0 7
+---------------+
| t-length |
+---------------+
t-length Defines the new length of the OID in the range
0x01-0x7f. The t-length value specifies the number
if sub-identifiers minus 1. Hence, the value 0x01
identifies an OID which consists of two
sub-identifiers. Truncation may be used to shorten
or enlarge an OID. New sub-identifiers will have
the value 0 if an OID is enlarged.
An ODC compressed OID is simply the combination of several sub-
identifier or sub-identifier range substitutions followed by an
optional truncation. Note that substitutions can increase the size
of the OID if the offset or range specifies sub-identifier positions
outside of the previous OID. New sub-identifiers without an explicit
value assignement will have the value 0. An ODC compressed OID is
distinguished from a normal OID by introducing the following new
ASN.1 type:
CompOID ::= [42] IMPLICIT OCTET STRING
A high-level description of the compression algorithm is as follows:
1. Loop through the SNMP PDU until you find an OID name value pair
(varbind).
2. If it is the first varbind, make a copy of the OID, pass it to
the output buffer and continue with the next varbind.
3. Otherwise, compute the delta to the last OID and BER encode it
into the CompOID value.
4. If the CompOID representation is larger than the OID, pass the
OID to the output buffer, else pass the CompOID to the output
buffer.
5. Update the last OID and goto step 2 if there are additional
varbinds.
Some SNMP implementations use a reverse encoding scheme where PDUs
are encoded from the end to the beginning. The ODC algorithm can
also be used efficiently in this case by using an OID look-ahead of 1
varbind.
A high-level description of the decompression algorithm is as
follows:
1. Loop through the SNMP PDU until you find an OID name value pair
(varbind).
2. If the varbind name contains an uncompressed OID, pass it to the
output buffer and continue with the next varbind.
3. Otherwise, if the varbind name contains a compressed OID, loop
through the compressed OID value doing the following:
1. If the first byte is in the range 0-0x7f and there are more
bytes, then decode the following byte(s) as a BER encoded
sub-identifier and perform a sub-identifier substitution.
2. If the first byte is in the range 0x80-0xff, then read the
following byte as the r-length value. Decode the following
r-length BER encoded sub-identifier and perform a range
substitution.
3. If the first byte is in the range 0x01-0x7f and there are no
more bytes, then perform a truncation.
4. Pass the decoded OID to the output buffer.
5. Update the last OID and goto step 2 if there are additional
varbinds.
5.2.2 ODC Examples
This section shows some example ODC encodings. It is provided to
better understand how ODC encodings work. It is not intended to give
a formal analysis of the compression ratios that can be achieved on
arbitrary SNMP payload.
5.2.2.1 Simple Substitutions
Lets assume a command generator uses getbulk operations to retrieve
the tcpConnTable of the TCP-MIB. A good manager will do that by
retrieving the tcpConnState column. The command responder will
return a sequence of tcpConnState (1.3.6.1.2.1.6.13.1.1) values:
tcpConnState.0.0.0.0.21.0.0.0.0.0 = listen(2)
tcpConnState.0.0.0.0.22.0.0.0.0.0 = listen(2)
tcpConnState.0.0.0.0.23.0.0.0.0.0 = listen(2)
tcpConnState.0.0.0.0.98.0.0.0.0.0 = listen(2)
The BER encoding of this varbind list is the following sequence of
bytes:
30:18 // sequence
06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState
00:00:00:00:15:00:00:00:00:00 // instance identifier
02:01:02 // value
30:18 // sequence
06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState
00:00:00:00:16:00:00:00:00:00 // instance identifier
02:01:02 // value
30:18 // sequence
06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState
00:00:00:00:17:00:00:00:00:00 // instance identifier
02:01:02 // value
30:18 // sequence
06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState
00:00:00:00:62:00:00:00:00:00 // instance identifier
02:01:02 // value
Using ODC compression, the following sequence of bytes would be used:
30:18 // sequence
06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState
00:00:00:00:15:00:00:00:00:00 // instance identifier
02:01:02 // value
30:07 // sequence
2a:02:0E:16 // substitution
02:02:02 // value
30:07 // sequence
2a:02:0E:17 // substitution
02:01:02 // value
30:07 // sequence
2a:02:0E:62 // substitution
02:01:02 // value
In this particular example, the total size of the encoded varbind
list drops from 104 bytes to 53 bytes.
5.2.2.2 Range Substitutions
This example expands the previous example by showing how range
substitutions work. In this example, we assume that the command
responder will return a sequence of tcpConnState values with
different IP addresses in the instance identifier:
tcpConnState.134.169.34.190.50054.130.240.64.53.80 = closeWait(8)
tcpConnState.134.169.34.190.50366.212.185.76.85.80 = closeWait(8)
tcpConnState.134.169.34.190.53370.134.169.34.117.6000 = established(5)
tcpConnState.134.169.34.190.56398.134.169.34.190.120 = closeWait(8)
The BER encoding of this varbind list is the following sequence of
bytes:
30:1F // sequence
06:1A:2B:06:01:02:01:06:0D:01:01: // tcpConnState
81:06:81:29:22:81:3E:83:87:06: // instance
81:02:81:70:40:35:50 // identifier
02:01:08 // value
30:1F // sequence
06:1A:2B:06:01:02:01:06:0D:01:01: // tcpConnState
81:06:81:29:22:81:3E:83:89:3E: // instance
81:54:81:39:4C:55:50 // identifier
02:01:08 // value
30:20 // sequence
06:1B:2B:06:01:02:01:06:0D:01:01: // tcpConnState
81:06:81:29:22:81:3E:83:A0:7A: // instance
81:06:81:29:22:75:AE:70 // identifier
02:01:05 // value
30:20 // sequence
06:1B:2B:06:01:02:01:06:0D:01:01: // tcpConnState
81:06:81:29:22:81:3E:83:B8:4E: // instance
81:06:81:29:22:81:3E:78 // identifier
02:01:08 // value
Using ODC compression, the following sequence of bytes would be used:
30:1F // sequence
06:1A:2B:06:01:02:01:06:0D:01:01: // tcpConnState
81:06:81:29:22:81:3E:83:87:06: // instance
81:02:81:70:40:35:50 // identifier
02:01:08 // value
30:10 // sequence
2A:0B:8E:05: // range
83:89:3E:81:54:81:39:4C:55 // substitution
02:01:08 // value
30:12 // sequence
2A:0D:8E:06: // range
83:A0:7A:81:06:81:29:22:75:AE:70 // substitution
02:01:05 // value
30:0E // sequence
2A:09:0E:83:A0:7A // substitution
92:02:81:3E:78 // range substitution
02:01:08 // value
In this particular example, the total size of the encoded varbind
list drops from 134 bytes to 87 bytes.
5.2.2.3 Substitutions and Truncations
This example assumes that a command generator retrieves the
ipNetToMediaTable defined in the IP-MIB using a getbulk on
ipNetToMediaPhysAddress (1.3.6.1.2.1.4.22.1.2) and ipNetToMediaType
(1.3.6.1.2.1.4.22.1.4) pairs. The following values might be returned
for a system which only has one entry in the cache:
ipNetToMediaPhysAddress.2.224.8.8.0 = 01:00:5E:08:08:00
ipNetToMediaType.2.224.8.8.0 = dynamic(3)
ipNetToMediaNetAddress.2.224.8.8.0 = 224.8.8.0
ipRoutingDiscards.0 = 0
Note that the getbulk overshoots and retrieves the following
instances in lexicographic order, which is an ipNetToMediaNetAddress
(1.3.6.1.2.1.4.22.1.3) and an ipRoutingDiscards (1.3.6.1.2.1.4.23)
instance.
The BER encoding of this varbind list is the following sequence of
bytes:
30:19 // sequence
06:0F:2B:06:01:02:01:04:16:01:02: // ipNetToMediaPhysAddress
02:81:60:08:08:00 // instance identifier
04:06:01:00:5E:08:08:00 // value
30:14 // sequence
06:0F:2B:06:01:02:01:04:16:01:04: // ipNetToMediaType
02:81:60:08:08:00 // instance identifier
02:01:03 // value
30:17 // sequence
06:10:2B:06:01:02:01:04:16:01:03: // ipNetToMediaNetAddress
02:81:60:08:08:00 // instance identifier
40:04:E0:08:08:00 // value
30:0D // sequence
06:08:2B:06:01:02:01:04:17 // ipRoutingDiscards
00 // instance identifier
41:01:00 // value
Using ODC compression, the following sequence of bytes would be used:
30:19 // sequence
06:0F:2B:06:01:02:01:04:16:01:02: // ipNetToMediaPhysAddress
02:81:60:08:08:00 // instance identifier
04:06:01:00:5E:08:08:00 // value
30:07 // sequence
2A:02:09:04 // substitution
02:01:03 // value
30:0A // sequence
2A:02:09:04 // substitutions
40:04:E0:08:08:00 // value
30:0A // sequence
2A:05:87:02:23:00: // range substitution
08 // truncation
41:01:00 // value
In this particular example, the total size of the encoded varbind
list drops from 89 bytes to 60 bytes.
6. Acknowledgments
This document is the result of discussions within the Network
Management Research Group (NMRG). of the Internet Research Task
Force[6] (IRTF). Special thanks go to Luca Deri, Wes Hardacker,
Jean-Philippe Martin-Flatin, Joe Marzot, Aiko Pras, Ron Sprenkels,
Frank Strauss, and Bert Wijnen for their comments and suggestions.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload
Compression Protocol (IPComp)", RFC 2393, December 1998.
[3] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[4] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple
Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[5] Sprenkels, R. and J. Martin-Flatin, "Bulk Transfers of MIB
Data", Simple Times 7(1), March 1999.
[6] <http://www.irtf.org/>
Author's Address
Juergen Schoenwaelder
TU Braunschweig
Bueltenweg 74/75
38106 Braunschweig
Germany
Phone: +49 531 391-3289
EMail: schoenw@ibr.cs.tu-bs.de
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 54 change blocks. 
110 lines changed or deleted 500 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/