idnits 2.17.1 draft-irtf-nmrg-snmp-compression-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 2 instances of lines with control characters in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 11, 2001) is 8406 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '42' is mentioned on line 358, but not defined -- Looks like a reference, but probably isn't: 'TBD' on line 249 == Unused Reference: '1' is defined on line 597, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2393 (ref. '2') (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 2572 (ref. '3') (Obsoleted by RFC 3412) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '4') -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder 3 Internet-Draft TU Braunschweig 4 Expires: October 10, 2001 April 11, 2001 6 SNMP Payload Compression 7 draft-irtf-nmrg-snmp-compression-01.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 10, 2001. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 This memo defines a mechanism for lossless compression of SNMP 39 payloads. Compression is especially useful when retrieving large 40 amounts of data or when SNMP encryption is being used over a 41 transport which provides data compression. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Identifying Compressed Payload . . . . . . . . . . . . . . 4 48 3.1 Compression as an SNMPv3 Encryption Algorithm . . . . . . 4 49 3.2 Indicating Compression in the msgFlags . . . . . . . . . . 4 50 3.3 Compression as a new PDU Type . . . . . . . . . . . . . . 5 51 4. Negotiating Compression Algorithms . . . . . . . . . . . . 6 52 5. Compression Algorithms . . . . . . . . . . . . . . . . . . 6 53 5.1 DEFLATE . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 5.2 OID Delta Compression (ODC) . . . . . . . . . . . . . . . 7 55 5.2.1 ODC Algorithm . . . . . . . . . . . . . . . . . . . . . . 7 56 5.2.2 ODC Examples . . . . . . . . . . . . . . . . . . . . . . . 10 57 5.2.2.1 Simple Substitutions . . . . . . . . . . . . . . . . . . . 10 58 5.2.2.2 Range Substitutions . . . . . . . . . . . . . . . . . . . 11 59 5.2.2.3 Substitutions and Truncations . . . . . . . . . . . . . . 12 60 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 14 61 References . . . . . . . . . . . . . . . . . . . . . . . . 14 62 Author's Address . . . . . . . . . . . . . . . . . . . . . 14 63 Full Copyright Statement . . . . . . . . . . . . . . . . . 15 65 1. Introduction 67 This memo defines mechanisms for lossless compression of SNMP 68 payloads. Compression is useful when retrieving large amounts of 69 management data since the BER encoding used by SNMP is not very space 70 efficient and the payload tends to have a high degree of redundancy. 72 SNMP payload compression is especially useful when retrieving large 73 amounts of data. In particular, compression allows command 74 responders to put more data into responses to bulk retrieval 75 requests, which can significantly reduce the overall number of 76 transactions needed to retrieve a certain amount of data [5]. 78 SNMP payload compression is also useful when SNMP encryption is used. 79 Encrypting the SNMP payload causes the data to be random in nature, 80 rendering compression at lower protocol layers (e.g., IP Payload 81 Compression Protocol [2]) ineffective. If both compression and 82 encryption are required, then compression should be applied before 83 encryption. 85 2. Requirements 87 A solution for SNMP payload compression has to satisfy the following 88 requirements: 90 1. Compression must happen before encryption if compression is used 91 together with encryption. Compression is most useful if there 92 are regular patterns in the data. It is the nature of encryption 93 algorithms to destroy any regular pattern and hence encrypted 94 data does not compress very well. 96 2. SNMP payload compression should be able to support multiple 97 compression algorithms. This implies that SNMP engines must be 98 able to negotiate the compression algorithm they are using. 99 Instead of carrying a compression algorithm identifier in every 100 protocol message, it seems more effective to indicate compression 101 algorithms in a MIB module (similar to authentication or 102 encryption algorithms in SNMPv3). 104 3. Each SNMP message is compressed and decompressed by itself 105 without any relation to other SNMP messages ("stateless 106 compression"), as SNMP messages may arrive out of order or not 107 arrive at all. 109 4. The size of a compressed SNMP message must never exceed the size 110 of the uncompressed SNMP message ("non-expansion policy"). A 111 sender may send an uncompressed SNMP message if an attempt to 112 compress the message produces a result which is longer than the 113 uncompressed SNMP message. An SNMP engine configured to receive 114 compressed SNMP messages must thus also accept uncompressed SNMP 115 messages. 117 5. The abstract syntax of compressed SNMP messages must be defined 118 using ASN.1. This ensures that a compressed SNMP message has a 119 valid ASN.1/BER encoding which simplifies the integration into 120 existing SNMP toolkits. 122 6. It is desirable to define common compression algorithms in order 123 to achieve interoperability. The compression algorithms should 124 be openly available and they should represent different trade- 125 offs between compression efficiency and CPU efficiency. 127 3. Identifying Compressed Payload 129 It is necessary to distinguish between compressed and uncompressed 130 SNMP payload. There are several ways to implement this. The 131 following sections discuss alternatives that have been considered. 133 3.1 Compression as an SNMPv3 Encryption Algorithm 135 The idea behind the first approach is to treat compression as an 136 additional SNMPv3 encryption algorithm. In fact, compression as well 137 as encryption can both be treated as a loss-less data transformation. 138 This approach has the following advantages / disadvantages: 140 + No change required to the SNMPv3 specifications. 142 + Compression of the complete ScopedPDU. 144 - Support of N encryption algorithms and M compression algorithms 145 leads to N*M possible combinations. 147 - Compression requires authentication since there is no noAuthPriv 148 security level. 150 - Does not work with older and widely deployed versions of SNMP 151 (SNMPv1, SNMPv2c). 153 3.2 Indicating Compression in the msgFlags 155 To avoid some of the drawbacks of the previous approach, one can 156 treat compression independent of encryption by allocating an unused 157 bit in the msgFlags [3]) to indicate whether compression is used or 158 not. However, RFC 2572 [3]) says in section 6.4: 160 The remaining bits in msgFlags are reserved, and must be set to zero 161 when sending a message and should be ignored when receiving a 162 message. 164 Similarly, RFC 2572 [3] specifies in section 7.1 step 7) and in 165 section 7.2 step 5) that other bits in the msgFlags are set to zero 166 or ignored. This means that this alternative can not be supported by 167 an implementation which is strictly compliant to RFC 2572 [3]. 169 In summary, this approach has the following advantages / 170 disadvantages: 172 + Combination of M compression and N encryption algorithms possible 173 without having to define N*M algorithms. 175 + Compression can be used with or without encryption or 176 authentication. 178 + Compression of the complete ScopedPDU. 180 - Not strictly compliant to the current SNMPv3 specifications. 182 - Does not work with older widely deployed versions of SNMP (SNMPv1, 183 SNMPv2c). 185 3.3 Compression as a new PDU Type 187 The third alternative is to restrict compression to PDUs rather than 188 ScopedPDUs and to introduce a new PDU type for compressed payloads. 189 RFC 1157 [4] defines the SNMPv1 message header as follows: 191 Message ::= SEQUENCE { 192 version INTEGER { version-1(0) }, 193 community OCTET STRING, 194 data ANY -- e.g., PDUs if trivial authentication 195 -- is being used 196 } 198 Similarly, RFC 2572 [3] defines the ScopedPDU as follows: 200 ScopedPDU ::= SEQUENCE { 201 contextEngineID OCTET STRING, 202 contextName OCTET STRING, 203 data ANY -- e.g., PDUs as defined in RFC 1905 204 } 206 This means that a new PDU could be defined which holds the compressed 207 version of a PDU: 209 CompressedPDU ::= [42] IMPLICIT OCTET STRING 210 -- contains a compressed PDU 212 It is important to analyze how a compliant SNMP implementation 213 behaves when it receives an unknown PDU type. From a formal point of 214 view, any PDU which is a valid BER serialization of an ASN.1 type 215 must be accepted since the data portion is of the ASN.1 type ANY. In 216 practice, most SNMP implementations will only recognize the PDU types 217 defined in the SNMP specifications. 219 The SNMPv3 message processing model [3] defines in section 7.2 step 220 7) that parse errors while decoding the ScopedPDU cause the packet to 221 be discarded after incrementing snmpInASNParseErrs. Even an 222 implementation which is capable to decode arbitrary PDUs will have 223 problems to determine the pduType as defined in section 7.2 step 9). 224 This basically means that a compliant SNMPv3 engine will simply 225 discard compressed PDUs. 227 The SNMPv1 specification [4] defines in section 4.1 second step (4) 228 that parse errors while decoding the PDU will cause the SNMP engine 229 to drop the PDU. Hence, it can be expected that most implementations 230 will simply drop a compressed PDU. 232 In summary, this approach has the following advantages / 233 disadvantages: 235 + Combination of M compression and N encryption algorithms possible 236 without having to define N*M algorithms. 238 + Compression can be used with or without encryption or 239 authentication. 241 + Works with every version of SNMP. 243 - Not strictly compliant to the current SNMPv3 specifications. 245 - Compression of the PDU rather than the ScopedPDU. 247 4. Negotiating Compression Algorithms 249 [TBD] 251 5. Compression Algorithms 252 5.1 DEFLATE 254 The DEFLATE algorithm is a well-know compression algorithm which 255 achieves good compression ratios and which is used for example in RFC 256 2394 for IP payload compression. It is also used on the World Wide 257 Web to compress documents before transmission over HTTP. 259 Using DEFLATE for SNMP payload compression however shows some 260 undesirable aspects. First, DEFLATE compression is relatively CPU 261 intensive. Furthermore, the DEFLATE algorithm requires to transmit a 262 dictionary, which reduces the compression efficiency for small 263 messages. On the other hand, DEFLATE compresses both names and 264 values and may achieve particularly good compression if the encoded 265 values show a similar structure. 267 Experiments with DEFLATE show that it should not be used on 268 relatively short SNMP messages. Furthermore, DEFLATE introduces 269 significant delays due to the compression computations. Finally, 270 estimating message sizes is hard with DEFLATE since there is no upper 271 bound for the message length addition if one adds another varbind. 272 This has impacts in particular on the getbulk PDU implementation. It 273 is therefore not recommended to adopt DEFLATE compression. 275 5.2 OID Delta Compression (ODC) 277 SNMP payloads use OIDs to represent the names of SNMP variables. The 278 amount of space used for encoding these OIDs frequently exceeds the 279 space needed to represent the values identified by the OIDs. 280 Furthermore, subsequent OIDs usually have many sub-identifier in 281 common. 283 The OID Delta Compression (ODC) algorithm has been designed to reduce 284 the OID overhead inherent in SNMP messages. The general idea is to 285 encode an OID as a delta to the previous OID. The ODC algorithm only 286 achieves a reduction in the SNMP naming information. It does not 287 compress the data of MIB variables, even if the value itself is an 288 OID. (The reason for not compressing OID values is that they are (a) 289 relatively infrequent and (b) compressing value OIDs has negative 290 impact on the compression achieved for the following variable name.) 291 In many cases (e.g., when retrieving large tables which basically 292 contain numbers), the achieved compression ratio is significant while 293 the CPU cycles spent on the compression algorithm itself are very 294 small. 296 5.2.1 ODC Algorithm 298 The ODC algorithm encodes OID deltas using three mechansisms: 300 1. Substitution of a single sub-identifier values at a certain 301 position. A sub-identifier substitution is encoded as follows: 303 0 7 8 304 +---------------+--------------------------//-+ 305 | s-offset | BER encoded sub-identifier | 306 +---------------+--------------------------//-+ 308 s-offset Defines the offset of the sub-identifier to 309 substitute. The offset value is in the range 310 0-0x7f. The value 0 refers to the first OID 311 sub-identifier. 313 2. Substitution of ranges of sub-identifiers at a given starting 314 position. A substitution of a range of sub-identifiers is 315 encoded as follows: 317 0 7 8 15 16 318 +---------------+---------------+--------------------------//-+ 319 | r-offset | r-length | BER encoded sub-identifiers | 320 +---------------+---------------+--------------------------//-+ 322 r-offset Defines the offset of the sub-identifier range 323 to substitute. The offset value has the most 324 significant bit set and is in the range 325 0x80-0xff. The value 0x80 refers to the first 326 OID sub-identifier. 327 r-length Defines the number of BER encoded sub-identifiers 328 that follow the r-length field and which will 329 be substituted. The range of the r-length field 330 is 0x01-0x7f. 332 3. Truncation of OIDs (which may shorten or enlarge OIDs). A 333 truncation, which may only appear at the end, is encoded as 334 follows: 336 0 7 337 +---------------+ 338 | t-length | 339 +---------------+ 341 t-length Defines the new length of the OID in the range 342 0x01-0x7f. The t-length value specifies the number 343 if sub-identifiers minus 1. Hence, the value 0x01 344 identifies an OID which consists of two 345 sub-identifiers. Truncation may be used to shorten 346 or enlarge an OID. New sub-identifiers will have 347 the value 0 if an OID is enlarged. 349 An ODC compressed OID is simply the combination of several sub- 350 identifier or sub-identifier range substitutions followed by an 351 optional truncation. Note that substitutions can increase the size 352 of the OID if the offset or range specifies sub-identifier positions 353 outside of the previous OID. New sub-identifiers without an explicit 354 value assignement will have the value 0. An ODC compressed OID is 355 distinguished from a normal OID by introducing the following new 356 ASN.1 type: 358 CompOID ::= [42] IMPLICIT OCTET STRING 360 A high-level description of the compression algorithm is as follows: 362 1. Loop through the SNMP PDU until you find an OID name value pair 363 (varbind). 365 2. If it is the first varbind, make a copy of the OID, pass it to 366 the output buffer and continue with the next varbind. 368 3. Otherwise, compute the delta to the last OID and BER encode it 369 into the CompOID value. 371 4. If the CompOID representation is larger than the OID, pass the 372 OID to the output buffer, else pass the CompOID to the output 373 buffer. 375 5. Update the last OID and goto step 2 if there are additional 376 varbinds. 378 Some SNMP implementations use a reverse encoding scheme where PDUs 379 are encoded from the end to the beginning. The ODC algorithm can 380 also be used efficiently in this case by using an OID look-ahead of 1 381 varbind. 383 A high-level description of the decompression algorithm is as 384 follows: 386 1. Loop through the SNMP PDU until you find an OID name value pair 387 (varbind). 389 2. If the varbind name contains an uncompressed OID, pass it to the 390 output buffer and continue with the next varbind. 392 3. Otherwise, if the varbind name contains a compressed OID, loop 393 through the compressed OID value doing the following: 395 1. If the first byte is in the range 0-0x7f and there are more 396 bytes, then decode the following byte(s) as a BER encoded 397 sub-identifier and perform a sub-identifier substitution. 399 2. If the first byte is in the range 0x80-0xff, then read the 400 following byte as the r-length value. Decode the following 401 r-length BER encoded sub-identifier and perform a range 402 substitution. 404 3. If the first byte is in the range 0x01-0x7f and there are no 405 more bytes, then perform a truncation. 407 4. Pass the decoded OID to the output buffer. 409 5. Update the last OID and goto step 2 if there are additional 410 varbinds. 412 5.2.2 ODC Examples 414 This section shows some example ODC encodings. It is provided to 415 better understand how ODC encodings work. It is not intended to give 416 a formal analysis of the compression ratios that can be achieved on 417 arbitrary SNMP payload. 419 5.2.2.1 Simple Substitutions 421 Lets assume a command generator uses getbulk operations to retrieve 422 the tcpConnTable of the TCP-MIB. A good manager will do that by 423 retrieving the tcpConnState column. The command responder will 424 return a sequence of tcpConnState (1.3.6.1.2.1.6.13.1.1) values: 426 tcpConnState.0.0.0.0.21.0.0.0.0.0 = listen(2) 427 tcpConnState.0.0.0.0.22.0.0.0.0.0 = listen(2) 428 tcpConnState.0.0.0.0.23.0.0.0.0.0 = listen(2) 429 tcpConnState.0.0.0.0.98.0.0.0.0.0 = listen(2) 431 The BER encoding of this varbind list is the following sequence of 432 bytes: 434 30:18 // sequence 435 06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState 436 00:00:00:00:15:00:00:00:00:00 // instance identifier 437 02:01:02 // value 438 30:18 // sequence 439 06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState 440 00:00:00:00:16:00:00:00:00:00 // instance identifier 441 02:01:02 // value 442 30:18 // sequence 443 06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState 444 00:00:00:00:17:00:00:00:00:00 // instance identifier 445 02:01:02 // value 446 30:18 // sequence 447 06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState 448 00:00:00:00:62:00:00:00:00:00 // instance identifier 449 02:01:02 // value 451 Using ODC compression, the following sequence of bytes would be used: 453 30:18 // sequence 454 06:13:2B:06:01:02:01:06:0D:01:01: // tcpConnState 455 00:00:00:00:15:00:00:00:00:00 // instance identifier 456 02:01:02 // value 457 30:07 // sequence 458 2a:02:0E:16 // substitution 459 02:02:02 // value 460 30:07 // sequence 461 2a:02:0E:17 // substitution 462 02:01:02 // value 463 30:07 // sequence 464 2a:02:0E:62 // substitution 465 02:01:02 // value 467 In this particular example, the total size of the encoded varbind 468 list drops from 104 bytes to 53 bytes. 470 5.2.2.2 Range Substitutions 472 This example expands the previous example by showing how range 473 substitutions work. In this example, we assume that the command 474 responder will return a sequence of tcpConnState values with 475 different IP addresses in the instance identifier: 477 tcpConnState.134.169.34.190.50054.130.240.64.53.80 = closeWait(8) 478 tcpConnState.134.169.34.190.50366.212.185.76.85.80 = closeWait(8) 479 tcpConnState.134.169.34.190.53370.134.169.34.117.6000 = established(5) 480 tcpConnState.134.169.34.190.56398.134.169.34.190.120 = closeWait(8) 482 The BER encoding of this varbind list is the following sequence of 483 bytes: 485 30:1F // sequence 486 06:1A:2B:06:01:02:01:06:0D:01:01: // tcpConnState 487 81:06:81:29:22:81:3E:83:87:06: // instance 488 81:02:81:70:40:35:50 // identifier 489 02:01:08 // value 490 30:1F // sequence 491 06:1A:2B:06:01:02:01:06:0D:01:01: // tcpConnState 492 81:06:81:29:22:81:3E:83:89:3E: // instance 493 81:54:81:39:4C:55:50 // identifier 494 02:01:08 // value 495 30:20 // sequence 496 06:1B:2B:06:01:02:01:06:0D:01:01: // tcpConnState 497 81:06:81:29:22:81:3E:83:A0:7A: // instance 498 81:06:81:29:22:75:AE:70 // identifier 499 02:01:05 // value 500 30:20 // sequence 501 06:1B:2B:06:01:02:01:06:0D:01:01: // tcpConnState 502 81:06:81:29:22:81:3E:83:B8:4E: // instance 503 81:06:81:29:22:81:3E:78 // identifier 504 02:01:08 // value 506 Using ODC compression, the following sequence of bytes would be used: 508 30:1F // sequence 509 06:1A:2B:06:01:02:01:06:0D:01:01: // tcpConnState 510 81:06:81:29:22:81:3E:83:87:06: // instance 511 81:02:81:70:40:35:50 // identifier 512 02:01:08 // value 513 30:10 // sequence 514 2A:0B:8E:05: // range 515 83:89:3E:81:54:81:39:4C:55 // substitution 516 02:01:08 // value 517 30:12 // sequence 518 2A:0D:8E:06: // range 519 83:A0:7A:81:06:81:29:22:75:AE:70 // substitution 520 02:01:05 // value 521 30:0E // sequence 522 2A:09:0E:83:A0:7A // substitution 523 92:02:81:3E:78 // range substitution 524 02:01:08 // value 526 In this particular example, the total size of the encoded varbind 527 list drops from 134 bytes to 87 bytes. 529 5.2.2.3 Substitutions and Truncations 531 This example assumes that a command generator retrieves the 532 ipNetToMediaTable defined in the IP-MIB using a getbulk on 533 ipNetToMediaPhysAddress (1.3.6.1.2.1.4.22.1.2) and ipNetToMediaType 534 (1.3.6.1.2.1.4.22.1.4) pairs. The following values might be returned 535 for a system which only has one entry in the cache: 537 ipNetToMediaPhysAddress.2.224.8.8.0 = 01:00:5E:08:08:00 538 ipNetToMediaType.2.224.8.8.0 = dynamic(3) 539 ipNetToMediaNetAddress.2.224.8.8.0 = 224.8.8.0 540 ipRoutingDiscards.0 = 0 542 Note that the getbulk overshoots and retrieves the following 543 instances in lexicographic order, which is an ipNetToMediaNetAddress 544 (1.3.6.1.2.1.4.22.1.3) and an ipRoutingDiscards (1.3.6.1.2.1.4.23) 545 instance. 547 The BER encoding of this varbind list is the following sequence of 548 bytes: 550 30:19 // sequence 551 06:0F:2B:06:01:02:01:04:16:01:02: // ipNetToMediaPhysAddress 552 02:81:60:08:08:00 // instance identifier 553 04:06:01:00:5E:08:08:00 // value 554 30:14 // sequence 555 06:0F:2B:06:01:02:01:04:16:01:04: // ipNetToMediaType 556 02:81:60:08:08:00 // instance identifier 557 02:01:03 // value 558 30:17 // sequence 559 06:10:2B:06:01:02:01:04:16:01:03: // ipNetToMediaNetAddress 560 02:81:60:08:08:00 // instance identifier 561 40:04:E0:08:08:00 // value 562 30:0D // sequence 563 06:08:2B:06:01:02:01:04:17 // ipRoutingDiscards 564 00 // instance identifier 565 41:01:00 // value 567 Using ODC compression, the following sequence of bytes would be used: 569 30:19 // sequence 570 06:0F:2B:06:01:02:01:04:16:01:02: // ipNetToMediaPhysAddress 571 02:81:60:08:08:00 // instance identifier 572 04:06:01:00:5E:08:08:00 // value 573 30:07 // sequence 574 2A:02:09:04 // substitution 575 02:01:03 // value 576 30:0A // sequence 577 2A:02:09:04 // substitutions 578 40:04:E0:08:08:00 // value 579 30:0A // sequence 580 2A:05:87:02:23:00: // range substitution 581 08 // truncation 582 41:01:00 // value 584 In this particular example, the total size of the encoded varbind 585 list drops from 89 bytes to 60 bytes. 587 6. Acknowledgments 589 This document is the result of discussions within the Network 590 Management Research Group (NMRG). of the Internet Research Task 591 Force[6] (IRTF). Special thanks go to Luca Deri, Wes Hardacker, 592 Jean-Philippe Martin-Flatin, Joe Marzot, Aiko Pras, Ron Sprenkels, 593 Frank Strauss, and Bert Wijnen for their comments and suggestions. 595 References 597 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 598 Levels", BCP 14, RFC 2119, March 1997. 600 [2] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP Payload 601 Compression Protocol (IPComp)", RFC 2393, December 1998. 603 [3] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message 604 Processing and Dispatching for the Simple Network Management 605 Protocol (SNMP)", RFC 2572, April 1999. 607 [4] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "A Simple 608 Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990. 610 [5] Sprenkels, R. and J. Martin-Flatin, "Bulk Transfers of MIB 611 Data", Simple Times 7(1), March 1999. 613 [6] 615 Author's Address 617 Juergen Schoenwaelder 618 TU Braunschweig 619 Bueltenweg 74/75 620 38106 Braunschweig 621 Germany 623 Phone: +49 531 391-3289 624 EMail: schoenw@ibr.cs.tu-bs.de 626 Full Copyright Statement 628 Copyright (C) The Internet Society (2001). All Rights Reserved. 630 This document and translations of it may be copied and furnished to 631 others, and derivative works that comment on or otherwise explain it 632 or assist in its implementation may be prepared, copied, published 633 and distributed, in whole or in part, without restriction of any 634 kind, provided that the above copyright notice and this paragraph are 635 included on all such copies and derivative works. However, this 636 document itself may not be modified in any way, such as by removing 637 the copyright notice or references to the Internet Society or other 638 Internet organizations, except as needed for the purpose of 639 developing Internet standards in which case the procedures for 640 copyrights defined in the Internet Standards process must be 641 followed, or as required to translate it into languages other than 642 English. 644 The limited permissions granted above are perpetual and will not be 645 revoked by the Internet Society or its successors or assigns. 647 This document and the information contained herein is provided on an 648 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 649 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 650 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 651 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 652 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 654 Acknowledgement 656 Funding for the RFC Editor function is currently provided by the 657 Internet Society.