< draft-irtf-dtnrg-sdnv-08.txt   draft-irtf-dtnrg-sdnv-09.txt >
Network Working Group W. Eddy Network Working Group W. Eddy
Internet-Draft MTI Systems Internet-Draft MTI Systems
Intended status: Informational E. Davies Intended status: Informational E. Davies
Expires: July 30, 2011 Folly Consulting Expires: August 27, 2011 Folly Consulting
January 26, 2011 February 23, 2011
Using Self-Delimiting Numeric Values in Protocols Using Self-Delimiting Numeric Values in Protocols
draft-irtf-dtnrg-sdnv-08 draft-irtf-dtnrg-sdnv-09
Abstract Abstract
Self-Delimiting Numeric Values (SDNVs) have recently been introduced Self-Delimiting Numeric Values (SDNVs) have recently been introduced
as a field type in proposed Delay-Tolerant Networking protocols. as a field type in proposed Delay-Tolerant Networking protocols.
SDNVs encode an arbitrary-length non-negative integer or arbitrary- SDNVs encode an arbitrary-length non-negative integer or arbitrary-
length bit-string with minimum overhead. They are intended to length bit-string with minimum overhead. They are intended to
provide protocol flexibility without sacrificing economy, and to provide protocol flexibility without sacrificing economy, and to
assist in future-proofing protocols under development. This document assist in future-proofing protocols under development. This document
describes formats and algorithms for SDNV encoding and decoding, describes formats and algorithms for SDNV encoding and decoding,
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on July 30, 2011. This Internet-Draft will expire on August 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 16 skipping to change at page 3, line 16
This document is a product of the Internet Research Task Force (IRTF) This document is a product of the Internet Research Task Force (IRTF)
Delay-Tolerant Networking (DTN) Research Group (DTNRG). The document Delay-Tolerant Networking (DTN) Research Group (DTNRG). The document
has received review and support within the DTNRG, as discussed in the has received review and support within the DTNRG, as discussed in the
Acknowledgements section of this document. Acknowledgements section of this document.
This document begins by describing the drawbacks of using fixed-width This document begins by describing the drawbacks of using fixed-width
protocol fields. It then provides some background on the Self- protocol fields. It then provides some background on the Self-
Delimiting Numeric Values (SDNVs) proposed for use in DTN protocols, Delimiting Numeric Values (SDNVs) proposed for use in DTN protocols,
and motivates their potential applicability in other networking and motivates their potential applicability in other networking
protocols. One example of SDNVs being used outside of the DTN protocols. The DTNRG has created SDNVs to meet the challenges it
protocols is in Hixie's Web Socket protocol attempts to solve, and it has been noted that SDNVs closely resemble
[I-D.hixie-thewebsocketprotocol], which includes a binary frame certain constructs within ASN.1 and even older ITU protocols, so the
length indicator field identical to an SDNV. The DTNRG has created problems are not new or unique to DTN. SDNVs focus strictly on
SDNVs to meet the challenges it attempts to solve, and it has been numeric values or bitstrings, while other mechanisms have been
noted that SDNVs closely resemble certain constructs within ASN.1 and developed for encoding more complex data structures, such as ASN.1
even older ITU protocols, so the problems are not new or unique to encoding rules, and Haverty's MSDTP [RFC0713]. Because of this
DTN. SDNVs focus strictly on numeric values or bitstrings, while focus, SDNVs are can be quickly implemented with only a small amount
other mechanisms have been developed for encoding more complex data of code.
structures, such as ASN.1 encoding rules, and Haverty's MSDTP
[RFC0713]. Because of this focus, SDNVs are can be quickly
implemented with only a small amount of code.
SDNVs are tersely defined in both the bundle protocol [RFC5050] and SDNVs are tersely defined in both the bundle protocol [RFC5050] and
LTP [RFC5326] specifications, due to the flow of document production LTP [RFC5326] specifications, due to the flow of document production
in the DTNRG. This document clarifies and further explains the in the DTNRG. This document clarifies and further explains the
motivations and engineering decisions behind SDNVs. motivations and engineering decisions behind SDNVs.
1.1. Problems with Fixed Value Fields 1.1. Problems with Fixed Value Fields
Protocol designers commonly face an optimization problem in Protocol designers commonly face an optimization problem in
determining the proper size for header fields. There is a strong determining the proper size for header fields. There is a strong
skipping to change at page 7, line 10 skipping to change at page 7, line 10
Length field of a TLV structure to be an SDNV whose value is the Length field of a TLV structure to be an SDNV whose value is the
length of the TLV's Value field. In this way, one can avoid forcing length of the TLV's Value field. In this way, one can avoid forcing
large numbers from being directly encoded as an SDNV, yet retain the large numbers from being directly encoded as an SDNV, yet retain the
extensibility that using SDNVs grants. extensibility that using SDNVs grants.
2. Definition of SDNVs 2. Definition of SDNVs
Early in the work of the DTNRG, it was agreed that the properties of Early in the work of the DTNRG, it was agreed that the properties of
an SDNV were useful for DTN protocols. The exact SDNV format used by an SDNV were useful for DTN protocols. The exact SDNV format used by
the DTNRG evolved somewhat over time before the publication of the the DTNRG evolved somewhat over time before the publication of the
initial RFCs on LTP and the BP. An earlier version bore resemblance initial RFCs on LTP and the BP. An earlier version (see [BRF04])
to the ASN.1 [ASN1] Basic Encoding Rules (BER) [ASN1-BER] for lengths bore a resemblance to the ASN.1 [ASN1] Basic Encoding Rules (BER)
(Section 8.1.3 of X.690). The current SDNV format is the one used by [ASN1-BER] for lengths (Section 8.1.3 of X.690). The current SDNV
ASN.1 BER for encoding tag identifiers greater than or equal to 31 format is the one used by ASN.1 BER for encoding tag identifiers
(Section 8.1.2.4.2 of X.690). A comparison between the current SDNV greater than or equal to 31 (Section 8.1.2.4.2 of X.690). A
format and the early SDNV format is made in Section 4. comparison between the current SDNV format and the early SDNV format
is made in Section 4.
The format currently used is very simple. Before encoding, an The format currently used is very simple. Before encoding, an
integer is represented as a left-to-right bitstring beginning with integer is represented as a left-to-right bitstring beginning with
its most significant bit, and ending with its least significant bit. its most significant bit, and ending with its least significant bit.
If the bitstring's length is not a multiple of 7, then the string is If the bitstring's length is not a multiple of 7, then the string is
left-padded with zeros. When transmitted, the bits are encoded into left-padded with zeros. When transmitted, the bits are encoded into
a series of bytes. The low-order 7 bits of each byte in the encoded a series of bytes. The low-order 7 bits of each byte in the encoded
format are taken left-to-right from the integer's bitstring format are taken left-to-right from the integer's bitstring
representation. The most significant bit of each byte specifies representation. The most significant bit of each byte specifies
whether it is the final byte of the encoded value (when it holds a whether it is the final byte of the encoded value (when it holds a
skipping to change at page 13, line 47 skipping to change at page 13, line 47
| | | | | | | | | | | |
| 129 | 2^1024 - 1 | 2^903 - 1 | 8 | 129 | | 129 | 2^1024 - 1 | 2^903 - 1 | 8 | 129 |
| | | | | | | | | | | |
| 130 | N/A | 2^910 - 1 | N/A | 130 | | 130 | N/A | 2^910 - 1 | N/A | 130 |
| | | | | | | | | | | |
| 256 | N/A | 2^1792 - 1 | N/A | 256 | | 256 | N/A | 2^1792 - 1 | N/A | 256 |
+-------+---------------+-------------+---------------+-------------+ +-------+---------------+-------------+---------------+-------------+
Table 1 Table 1
In general, it seems like the most promising use of SDNVs may be to Suggested usages of the SDNV format that leverage its strengths and
define the Length field of a TLV structure to be an SDNV whose value limit the effects of its weaknesses are discussed in Section 1.3.
is the length of the TLV's Value field. As previously discussed,
this leverages the strengths of the SDNV format and limits the
effects of its weaknesses.
Another aspect of comparison between SDNVs and alternatives using Another aspect of comparison between SDNVs and alternatives using
fixed-length fields is the result of errors in transmission. Bit- fixed-length fields is the result of errors in transmission. Bit-
errors in an SDNV can result in either errors in the decoded value, errors in an SDNV can result in either errors in the decoded value,
or parsing errors in subsequent fields of the protocol. In fixed- or parsing errors in subsequent fields of the protocol. In fixed-
length fields, bit errors always result in errors to the decoded length fields, bit errors always result in errors to the decoded
value rather than parsing errors in subsequent fields. If the value rather than parsing errors in subsequent fields. If the
decoded values from either type of field encoding (SDNV or fixed- decoded values from either type of field encoding (SDNV or fixed-
length) are used as indexes, offsets, or lengths of further fields in length) are used as indexes, offsets, or lengths of further fields in
the protocol, similar failures result. the protocol, similar failures result.
skipping to change at page 18, line 25 skipping to change at page 18, line 25
Encoding Rules (DER)", ISO/IEC 8825-1:2002, 2002. Encoding Rules (DER)", ISO/IEC 8825-1:2002, 2002.
[BRF04] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider [BRF04] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider
Transmission Protocol", Transmission Protocol",
draft-irtf-dtnrg-ltp-00 (replaced), May 2004. draft-irtf-dtnrg-ltp-00 (replaced), May 2004.
[Hain05] Hain, T., "A Pragmatic Report on IPv4 Address Space [Hain05] Hain, T., "A Pragmatic Report on IPv4 Address Space
Consumption", Internet Protocol Journal Vol. 8, No. 3, Consumption", Internet Protocol Journal Vol. 8, No. 3,
September 2005. September 2005.
[I-D.hixie-thewebsocketprotocol]
Hickson, I., "The WebSocket protocol",
draft-hixie-thewebsocketprotocol-76 (work in progress),
May 2010.
[IEN21] Cerf, V. and J. Postel, "Specification of Internetwork [IEN21] Cerf, V. and J. Postel, "Specification of Internetwork
Transmission Control Program: TCP Version 3", Internet Transmission Control Program: TCP Version 3", Internet
Experimental Note 21, January 1978. Experimental Note 21, January 1978.
[Manning09] [Manning09]
Manning, c., Raghavan, P., and H. Schuetze, "Introduction Manning, c., Raghavan, P., and H. Schuetze, "Introduction
to Information Retrieval", Cambridge University to Information Retrieval", Cambridge University
Press ISBN-13: 978-0521865715, 2009, Press ISBN-13: 978-0521865715, 2009,
<http://informationretrieval.org/>. <http://informationretrieval.org/>.
 End of changes. 7 change blocks. 
32 lines changed or deleted 22 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/