< draft-irtf-dtnrg-sdnv-06.txt   draft-irtf-dtnrg-sdnv-07.txt >
Network Working Group W. Eddy Network Working Group W. Eddy
Internet-Draft MTI Systems Internet-Draft MTI Systems
Intended status: Informational January 13, 2010 Intended status: Informational E. Davies
Expires: July 17, 2010 Expires: April 14, 2011 Folly Consulting
October 11, 2010
Using Self-Delimiting Numeric Values in Protocols Using Self-Delimiting Numeric Values in Protocols
draft-irtf-dtnrg-sdnv-06 draft-irtf-dtnrg-sdnv-07
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,
along with notes on implementation and usage. This document is a along with notes on implementation and usage. This document is a
product of the Delay Tolerant Networking Research Group and has been product of the Delay Tolerant Networking Research Group and has been
reviewed by that group. No objections to its publication as an RFC reviewed by that group. No objections to its publication as an RFC
were raised. were raised.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on April 14, 2011.
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 July 17, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problems with Fixed Value Fields . . . . . . . . . . . . . 3 1.1. Problems with Fixed Value Fields . . . . . . . . . . . . . 3
1.2. SDNVs for DTN Protocols . . . . . . . . . . . . . . . . . 4 1.2. SDNVs for DTN Protocols . . . . . . . . . . . . . . . . . 4
1.3. SDNV Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. SDNV Usage . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Definition of SDNVs . . . . . . . . . . . . . . . . . . . . . 7 2. Definition of SDNVs . . . . . . . . . . . . . . . . . . . . . 7
3. Basic Algorithms . . . . . . . . . . . . . . . . . . . . . . . 8 3. Basic Algorithms . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Encoding Algorithm . . . . . . . . . . . . . . . . . . . . 8 3.1. Encoding Algorithm . . . . . . . . . . . . . . . . . . . . 9
3.2. Decoding Algorithm . . . . . . . . . . . . . . . . . . . . 8 3.2. Decoding Algorithm . . . . . . . . . . . . . . . . . . . . 9
4. Comparison to Alternatives . . . . . . . . . . . . . . . . . . 10 3.3. Limitations of Implementations . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Comparison to Alternatives . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Informative References . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. SNDV Python Source Code . . . . . . . . . . . . . . . 19 8. Informative References . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A. SNDV Python Source Code . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
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-
skipping to change at page 8, line 5 skipping to change at page 7, line 52
any leading (most significant) zero bits in the input number might be any leading (most significant) zero bits in the input number might be
discarded by the SDNV encoder. Protocols that use SDNVs should not discarded by the SDNV encoder. Protocols that use SDNVs should not
rely on leading-zeros being retained after encoding and decoding rely on leading-zeros being retained after encoding and decoding
operations. (2) When decoding SDNVs, the relevant number of leading operations. (2) When decoding SDNVs, the relevant number of leading
zeros required to pad up to a machine word or other natural data unit zeros required to pad up to a machine word or other natural data unit
might be added. These are put in the most-significant positions in might be added. These are put in the most-significant positions in
order to not change the value of the number. Protocols using SDNVs order to not change the value of the number. Protocols using SDNVs
should consider situations where lost zero-padding may be should consider situations where lost zero-padding may be
problematic. problematic.
The issues of zero-padding are particularly relevant where an SDNV is
being used to represent a bit field to be transmitted by a protocol.
The specification of the protocol and any associated IANA registry
should specify the allocation and usage of bit positions within the
unencoded field. Both sender and receiver will know of this
allocation so that they are implicitly aware of the width of the bit
field. Unassigned and reserved bits in the unencoded field will be
treated as zeroes by the SDNV encoding prior to transmission.
Assuming the bit positions are numbered starting from 0 at the least
significant bit position in the integer representation, then if
higher numbered positions in the field contain all zeroes, the
encoding process may not transmit these bits explicitly (e.g., if all
the bit positions numbered 7 or higher are zeroes then the
transmitted SDNV can consist of just one octet). On reception the
decoding process will treat any untransmitted higher numbered bits as
zeroes.
3. Basic Algorithms 3. Basic Algorithms
This section describes some simple algorithms for creating and This section describes some simple algorithms for creating and
parsing SDNV fields. These may not be the most efficient algorithms parsing SDNV fields. These may not be the most efficient algorithms
possible, however, they are easy to read, understand, and implement. possible, however, they are easy to read, understand, and implement.
Appendix A contains Python source code implementing the routines Appendix A contains Python source code implementing the routines
described here. described here.
3.1. Encoding Algorithm 3.1. Encoding Algorithm
skipping to change at page 10, line 5 skipping to change at page 10, line 25
won't cause any bits to be lost, and re-allocate a larger piece of won't cause any bits to be lost, and re-allocate a larger piece of
memory for the result, if required. The pure time complexity is the memory for the result, if required. The pure time complexity is the
same as for the encoding algorithm given, but if re-allocation is same as for the encoding algorithm given, but if re-allocation is
needed due to the inability to predict the size of the result, needed due to the inability to predict the size of the result,
decoding may be slower. decoding may be slower.
These decoding steps include removal of any leftmost zero-padding These decoding steps include removal of any leftmost zero-padding
that might be used by an encoder to create encodings of a certain that might be used by an encoder to create encodings of a certain
length. length.
3.3. Limitations of Implementations
Because of efficiency considerations or convenience of internal
representation of decoded integers, implementations may choose to
limit the number of bits in SDNVs that they will handle. To avoid
interoperability problems any protocol that uses SDNVs must specify
the largest number of bits in an SDNV that an implementation of that
protocol is expected to handle.
For example Section 4.1 of [RFC5050] specifies that implementations
of the DTN Bundle Protocol are not required to handle SDNVs with more
than 64 bits in their unencoded value. Accordingly integer values
transmitted in SDNVs have an upper limit and SDNV encoded flag fields
must be limited to 64 bit positions in any future revisions of the
protocol unless the restriction is altered.
4. Comparison to Alternatives 4. Comparison to Alternatives
This section compares three alternative ways of implementing the This section compares three alternative ways of implementing the
concept of SDNVs: (1) the TLV scheme commonly used in the Internet concept of SDNVs: (1) the TLV scheme commonly used in the Internet
family, and many other families of protocols, (2) the old style of family, and many other families of protocols, (2) the old style of
SDNVs (both the SDNV-8 and SDNV-16) defined in an early stage of SDNVs (both the SDNV-8 and SDNV-16) defined in an early stage of
LTP's development [BRF04], and (3) the current SDNV format. LTP's development [BRF04], and (3) the current SDNV format.
The TLV method uses two fixed-length fields to hold the Type and The TLV method uses two fixed-length fields to hold the Type and
Length elements that then imply the syntax and semantics of the Value Length elements that then imply the syntax and semantics of the Value
skipping to change at page 17, line 26 skipping to change at page 18, line 26
[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] [I-D.hixie-thewebsocketprotocol]
Hickson, I., "The Web Socket protocol", Hickson, I., "The WebSocket protocol",
draft-hixie-thewebsocketprotocol-68 (work in progress), draft-hixie-thewebsocketprotocol-76 (work in progress),
December 2009. 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.
[RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission [RFC0713] Haverty, J., "MSDTP-Message Services Data Transmission
Protocol", RFC 713, April 1976. Protocol", RFC 713, April 1976.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
skipping to change at page 18, line 17 skipping to change at page 19, line 17
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol [RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007. Specification", RFC 5050, November 2007.
[RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider [RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider
Transmission Protocol - Motivation", RFC 5325, Transmission Protocol - Motivation", RFC 5325,
September 2008. September 2008.
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider [RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification", RFC 5326, Transmission Protocol - Specification", RFC 5326,
March 2008. September 2008.
Appendix A. SNDV Python Source Code Appendix A. SNDV Python Source Code
# sdnv_decode() takes a string argument (s), which is assumed to be # sdnv_decode() takes a string argument (s), which is assumed to be
# an SDNV, and optionally a number (slen) for the maximum number of # an SDNV, and optionally a number (slen) for the maximum number of
# bytes to parse from the string. The function returns a pair of # bytes to parse from the string. The function returns a pair of
# the non-negative integer n that is the numeric value encoded in # the non-negative integer n that is the numeric value encoded in
# the SDNV, and integer that is the distance parsed into the input # the SDNV, and integer that is the distance parsed into the input
# string. If the slen argument is not given (or is not a non-zero # string. If the slen argument is not given (or is not a non-zero
# number) then, s is parsed up to the first byte whose high-order # number) then, s is parsed up to the first byte whose high-order
skipping to change at page 21, line 5 skipping to change at page 22, line 5
for tp in tests: for tp in tests:
# test encoding function # test encoding function
if sdnv_encode(tp[0]) != tp[1]: if sdnv_encode(tp[0]) != tp[1]:
print "sdnv_encode fails on input %s" % hex(tp[0]) print "sdnv_encode fails on input %s" % hex(tp[0])
# test decoding function # test decoding function
if sdnv_decode(tp[1])[0] != tp[0]: if sdnv_decode(tp[1])[0] != tp[0]:
print "sdnv_decode fails on input %s, giving %s" % \ print "sdnv_decode fails on input %s, giving %s" % \
(hex(tp[0]), sdnv_decode(tp[1])) (hex(tp[0]), sdnv_decode(tp[1]))
Author's Address Authors' Addresses
Wesley M. Eddy Wesley M. Eddy
MTI Systems MTI Systems
NASA Glenn Research Center NASA Glenn Research Center
MS 500-ASRC; 21000 Brookpark Rd MS 500-ASRC; 21000 Brookpark Rd
Cleveland, OH 44135 Cleveland, OH 44135
Phone: 216-433-6682 Phone: 216-433-6682
Email: wes@mti-systems.com Email: wes@mti-systems.com
Elwyn Davies
Folly Consulting
Soham
UK
Phone:
Email: elwynd@folly.org.uk
URI:
 End of changes. 14 change blocks. 
30 lines changed or deleted 60 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/