< draft-irtf-dtnrg-sdnv-01.txt   draft-irtf-dtnrg-sdnv-02.txt >
Network Working Group W. Eddy Network Working Group W. Eddy
Internet-Draft Verizon Internet-Draft Verizon
Intended status: Informational January 9, 2009 Intended status: Informational May 22, 2009
Expires: July 13, 2009 Expires: November 23, 2009
Using Self-Delimiting Numeric Values in Protocols Using Self-Delimiting Numeric Values in Protocols
draft-irtf-dtnrg-sdnv-01 draft-irtf-dtnrg-sdnv-02
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 to IETF 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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 32 skipping to change at page 1, line 32
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.
This Internet-Draft will expire on July 13, 2009. This Internet-Draft will expire on November 23, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
Self-Delimiting Numeric Values (SDNVs) have recently been introduced Self-Delimiting Numeric Values (SDNVs) have recently been introduced
as a field type within proposed Delay-Tolerant Networking protocols. as a field type in proposed Delay-Tolerant Networking protocols.
The basic goal of an SDNV is to hold a non-negative integer value of SDNVs encode an arbitrary-length non-negative integer with minimum
arbitrary magnitude, without consuming much more space than wire-overhead. They are intended to provide protocol flexibility
necessary. The primary motivation is to conserve the bits sent without sacrificing economy, and to assist in future-proofing
across low-capacity or energy-intensive links typical of NASA deep- protocols under development. This document describes formats and
space missions, with a secondary goal of allowing the protocol to algorithms for SDNV encoding and decoding, along with notes on
automatically adjust to unforseen usage scenarios. This can be implementation and usage.
desirable in that it allows protocol designers to avoid making
difficult and potentially erroneous engineering decisions that may
have to be hacked around in the future. This document describes
formats and algorithms for SDNV encoding and decoding, and discusses
implementation and usage of SDNVs.
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 . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Encoding Algorithm . . . . . . . . . . . . . . . . . . . . 8 3.1. Encoding Algorithm . . . . . . . . . . . . . . . . . . . . 8
3.2. Decoding Algorithm . . . . . . . . . . . . . . . . . . . . 8 3.2. Decoding Algorithm . . . . . . . . . . . . . . . . . . . . 8
4. Comparison to Alternatives . . . . . . . . . . . . . . . . . . 10 4. Comparison to Alternatives . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
8. Informative References . . . . . . . . . . . . . . . . . . . . 16 8. Informative References . . . . . . . . . . . . . . . . . . . . 17
Appendix A. SNDV Python Source Code . . . . . . . . . . . . . . . 18 Appendix A. SNDV Python Source Code . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
This section begins by describing a common problem encountered in This document is a product of the Internet Research Task Force (IRTF)
Delay-Tolerant Networking (DTN) Research Group (DTNRG). The document
has received review and support within the DTNRG, as discussed in the
Acknowledgements section of this document.
This document begins by describing a common problem encountered in
network protocol engineering. It then provides some background on network protocol engineering. It then provides some background on
the Self-Delimiting Numeric Values (SDNVs) proposed for use in Delay- the Self-Delimiting Numeric Values (SDNVs) proposed for use in DTN
Tolerant Networking (DTN) protocols, and motivates their potential protocols, and motivates their potential applicability in other
applicability in other networking protocols. The DTN Research Group networking protocols. The DTNRG has created SDNVs to meet the
(DTNRG) within the Internet Research Task Force was created SDNVs to challenges it attempts to solve, and it has been noted that SDNVs
meet the challenges it attempts to solve, and it has been noted that closely resemble certain constructs within ASN.1 and even older ITU
SDNVs closely resemble certain constructs within ASN.1 and even older protocols, so the problems are not new or unique to DTN, nor is the
ITU protocols, so the problems are not new or unique to DTN, nor is solution too radical for more mundane uses.
the solution too radical for more mundane uses.
SDNVs are tersely defined in both the bundle protocol [RFC5050] and
LTP [RFC5326] specifications, due to the flow of document production
in the DTNRG. This document clarifies and further explains the
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
desire to keep fields as small as possible, in order to reduce the desire to keep fields as small as possible, in order to reduce the
protocol's overhead on the wire, and also allow for fast processing. protocol's overhead on the wire, and also allow for fast processing.
Since protocols can be used many years (even decades) after they are Since protocols can be used many years (even decades) after they are
designed, and networking technology has tended to change rapidly, it designed, and networking technology has tended to change rapidly, it
is not uncommon for the use, deployment, or performance of a is not uncommon for the use, deployment, or performance of a
skipping to change at page 4, line 25 skipping to change at page 4, line 34
Of course, in both the case of the TCP receive window and IPv4 Of course, in both the case of the TCP receive window and IPv4
address length, the field size chosen by the designers seemed like a address length, the field size chosen by the designers seemed like a
good idea at the time. The fields were more than big enough for the good idea at the time. The fields were more than big enough for the
originally perceived usage of the protocols, and yet were small originally perceived usage of the protocols, and yet were small
enough to allow the total headers to remain compact and relatively enough to allow the total headers to remain compact and relatively
easy and efficient to parse on machines of the time. The fixed sizes easy and efficient to parse on machines of the time. The fixed sizes
that were defined represented a tradeoff between the scalability of that were defined represented a tradeoff between the scalability of
the protocol versus the overhead and efficiency of processing. In the protocol versus the overhead and efficiency of processing. In
both cases, these engineering decisions turned out to be painfully both cases, these engineering decisions turned out to be painfully
incorrect. restrictive in the longer term.
1.2. SDNVs for DTN Protocols 1.2. SDNVs for DTN Protocols
In proposals for the DTN Bundle Protocol (BP) [SB05] and Licklider In specifications for the DTN Bundle Protocol (BP) [RFC5050] and
Transmission Protocol (LTP) [RBF06], SDNVs have been used for several Licklider Transmission Protocol (LTP) [RFC5326], SDNVs have been used
fields including identifiers, payload/header lengths, and serial for several fields including identifiers, payload/header lengths, and
(sequence) numbers. SDNVs were developed for use in these types of serial (sequence) numbers. SDNVs were developed for use in these
fields, to avoid sending more bytes than needed, as well as avoiding types of fields, to avoid sending more bytes than needed, as well as
fixed sizes that may not end up being appropriate. For example, avoiding fixed sizes that may not end up being appropriate. For
since LTP is intended primarily for use in long-delay interplanetary example, since LTP is intended primarily for use in long-delay
communications [BRF06], where links may be fairly low in capacity, it interplanetary communications [RFC5325], where links may be fairly
is desirable to avoid the header overhead of routinely sending a 64- low in capacity, it is desirable to avoid the header overhead of
bit field where a 16-bit field would suffice. Since many of the routinely sending a 64-bit field where a 16-bit field would suffice.
nodes implementing LTP are expected to be beyond the current range of Since many of the nodes implementing LTP are expected to be beyond
human spaceflight, upgrading their on-board LTP implementations to the current range of human spaceflight, upgrading their on-board LTP
use longer values if the defined fields are found to be too short implementations to use longer values if the defined fields are found
would also be problematic. Furthermore, extensions similar in to be too short would also be problematic. Furthermore, extensions
mechanism to TCP's Window Scale option are unsuitable for use in DTN similar in mechanism to TCP's Window Scale option are unsuitable for
protocols since due to high delays, DTN protocols must avoid use in DTN protocols since due to high delays, DTN protocols must
handshaking and configuration parameter negotiation to the greatest avoid handshaking and configuration parameter negotiation to the
extent possible. All of these reasons make the choice of SDNVs for greatest extent possible. All of these reasons make the choice of
use in DTN protocols particularly wise. SDNVs for use in DTN protocols attractive.
1.3. SDNV Usage 1.3. SDNV Usage
In short, an SDNV is simply a way of representing non-negative In short, an SDNV is simply a way of representing non-negative
integers (both positive integers of arbitrary magnitude and 0), integers (both positive integers of arbitrary magnitude and 0),
without expending too-much unneccessary space. This definition without expending too-much unneccessary space. This definition
allows SDNVs to represent many common protocol header fields, such allows SDNVs to represent many common protocol header fields, such
as: as:
o Random identification fields as used in the IPsec Security o Random identification fields as used in the IPsec Security
Parameters Index or in IP headers for fragment reassembly (Note: Parameters Index or in IP headers for fragment reassembly (Note:
the 16-bit IP ID field for fragment reassembly was recently found the 16-bit IP ID field for fragment reassembly was recently found
to be too short in some environments [I-D.heffner-frag-harmful]), to be too short in some environments [RFC4963]),
o Sequence numbers as in TCP or SCTP, o Sequence numbers as in TCP or SCTP,
o Values used in cryptographic algorithms such as RSA keys, Diffie- o Values used in cryptographic algorithms such as RSA keys, Diffie-
Hellman key-agreement, or coordinates of points on elliptic Hellman key-agreement, or coordinates of points on elliptic
curves. curves.
o Message lengths as used in file transfer protocols. o Message lengths as used in file transfer protocols.
o Nonces and cookies. o Nonces and cookies.
skipping to change at page 7, line 45 skipping to change at page 7, line 45
To be perfectly clear, and avoid potential interoperability issues To be perfectly clear, and avoid potential interoperability issues
(as have occurred with ASN.1 BER time values), we explicitly state (as have occurred with ASN.1 BER time values), we explicitly state
two considerations regarding zero-padding. (1) When encoding SDNVs, two considerations regarding zero-padding. (1) When encoding SDNVs,
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. order to not change the value of the number. Protocols using SDNVs
should consider situations where lost zero-padding may be
problematic.
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. Only SDNV's of the currently-used form are described here. Only SDNV's of the currently-used form are
considered in this section. considered in this section.
skipping to change at page 10, line 38 skipping to change at page 10, line 38
granularity of the possible Value lengths, and can contribute some granularity of the possible Value lengths, and can contribute some
degree of bloat if Values do not fit neatly within the available degree of bloat if Values do not fit neatly within the available
decoded Lengths. decoded Lengths.
In the SDNV format originally used by LTP, parsing the first byte of In the SDNV format originally used by LTP, parsing the first byte of
the SDNV told an implementation how much space was required to hold the SDNV told an implementation how much space was required to hold
the contained value. There were two different types of SDNVs defined the contained value. There were two different types of SDNVs defined
for different ranges of use. The SDNV-8 type could hold values up to for different ranges of use. The SDNV-8 type could hold values up to
127 in a single byte, while the SDNV-16 type could hold values up to 127 in a single byte, while the SDNV-16 type could hold values up to
32,767 in 2 bytes. Both formats could encode values requiring up to 32,767 in 2 bytes. Both formats could encode values requiring up to
N bytes in N+2 bytes, where N<127. The two major difference between N bytes in N+2 bytes, where N<127. The major difference between this
this old SDNV format and the currently-used SDNV format is that the old SDNV format and the currently-used SDNV format is that the new
new format is not as easily decoded as the old format was, but the format is not as easily decoded as the old format was, but the new
new format also has absolutely no limitation on its length. format also has absolutely no limitation on its length.
The advantage in ease of parsing that the old format manifests itself The advantage in ease of parsing the old format manifests itself in
in two aspects: (1) the size of the value is determinable ahead of two aspects: (1) the size of the value is determinable ahead of time,
time, in a way equivalent to parsing a TLV, and (2) the actual value in a way equivalent to parsing a TLV, and (2) the actual value is
is directly encoded and decoded, without shifting and masking bits as directly encoded and decoded, without shifting and masking bits as is
is required in the new format. For these reasons, the old format required in the new format. For these reasons, the old format
requires less computational overhead to deal with, but is also very requires less computational overhead to deal with, but is also very
limited, in that it can only hold a 1024-bit number, at maximum. limited, in that it can only hold a 1024-bit number, at maximum.
Since according to IETF Best Current Practices, an asymmetric Since according to IETF Best Current Practices, an asymmetric
cryptography key needed to last for a long term requires using moduli cryptography key needed to last for a long term requires using moduli
of over 1228 bits [RFC3766], this could be seen as a severe of over 1228 bits [RFC3766], this could be seen as a severe
limitation of the old-style of SDNVs, which the currently-used style limitation of the old-style of SDNVs, which the currently-used style
does not suffer from. does not suffer from.
Table 1 compares the maximum values that can be encoded into SDNVs of Table 1 compares the maximum values that can be encoded into SDNVs of
various lengths using the old SDNV-8/16 method and the current SDNV various lengths using the old SDNV-8/16 method and the current SDNV
skipping to change at page 13, line 5 skipping to change at page 12, line 52
| 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 In general, it seems like the most promising use of SDNVs may be to
define the Length field of a TLV structure to be an SDNV whose value define the Length field of a TLV structure to be an SDNV whose value
is the length of the TLV's Value field. This leverages the strengths is the length of the TLV's Value field. This leverages the strengths
of the SDNV format and limits the effects of its weaknesses. of the SDNV format and limits the effects of its weaknesses.
Another aspect of comparison between SDNVs and alternatives using
fixed-length fields is the result of errors in transmission. Bit-
errors in an SDNV can result in either errors in the decoded value,
or parsing errors in subsequent fields of the protocol. In fixed-
length fields, bit-errors always result in errors to the decoded
value rather than parsing errors in subsequent fields. If the
decoded values from either type of field encoding (SDNV or fixed-
length) are used as indexes, offsets, or lengths of further fields in
the protocol, similar failures result.
5. Security Considerations 5. Security Considerations
The only security considerations with regards to SDNVs are that code The only security considerations with regards to SDNVs are that code
which parses SDNVs should have bounds-checking logic and be capable which parses SDNVs should have bounds-checking logic and be capable
of handling cases where an SDNV's value is beyond the code's ability of handling cases where an SDNV's value is beyond the code's ability
to parse. These precautions can prevent potential exploits involving to parse. These precautions can prevent potential exploits involving
SDNV decoding routines. SDNV decoding routines.
Stephen Farrell noted that very early definitions of SDNVs also Stephen Farrell noted that very early definitions of SDNVs also
allowed negative integers. This was considered a potential security allowed negative integers. This was considered a potential security
skipping to change at page 15, line 7 skipping to change at page 16, line 7
decoders map the Length field to a signed integer and are vulnerable decoders map the Length field to a signed integer and are vulnerable
in this way. An SDNV decoder should be based on unsigned types and in this way. An SDNV decoder should be based on unsigned types and
not have this issue. not have this issue.
6. IANA Considerations 6. IANA Considerations
This document has no IANA considerations. This document has no IANA considerations.
7. Acknowledgements 7. Acknowledgements
Scott Burleigh, Manikantan Ramadas, Michael Demmer, Stephen Farrell Scott Burleigh, Manikantan Ramadas, Michael Demmer, Stephen Farrell,
and other members of the IRTF DTN Research Group contributed to the and other members of the IRTF DTN Research Group contributed to the
development and usage of SDNVs in DTN protocols. George Jones and development and usage of SDNVs in DTN protocols. George Jones and
Keith Scott from Mitre, Lloyd Wood, Gerardo Izquierdo, and Joel Keith Scott from Mitre, Lloyd Wood, Gerardo Izquierdo, Joel Halpern,
Halpern also contributed useful comments on and criticisms of this and Peter TB Brett also contributed useful comments on and criticisms
document. of this document. DTNRG last call comments on the draft were sent to
the mailing list by Lloyd Wood, Will Ivancic, Jim Wyllie, William
Edwards, Hans Kruse, Janico Greifenberg, Teemu Karkkainen, Stephen
Farrell, and Scott Burleigh.
Work on this document was performed at NASA's Glenn Research Center, Work on this document was performed at NASA's Glenn Research Center,
in support of the NASA Space Communications Architecture Working in support of the NASA Space Communications Architecture Working
Group (SCAWG), NASA's Earth Science Technology Office (ESTO), and the Group (SCAWG), NASA's Earth Science Technology Office (ESTO), and the
FAA/Eurocontrol Future Communications Study (FCS). FAA/Eurocontrol Future Communications Study (FCS).
8. Informative References 8. Informative References
[ASN1] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1). [ASN1] ITU-T Rec. X.680, "Abstract Syntax Notation One (ASN.1).
Specification of Basic Notation", ISO/IEC 8824-1:2002, Specification of Basic Notation", ISO/IEC 8824-1:2002,
2002. 2002.
[ASN1-BER] [ASN1-BER]
ITU-T Rec. X.690, "Abstract Syntax Notation One (ASN.1). ITU-T Rec. X.690, "Abstract Syntax Notation One (ASN.1).
Encoding Rules: Specification of Basic Encoding Rules Encoding Rules: Specification of Basic Encoding Rules
(BER), Canonical Encoding Rules (CER) and Distinguished (BER), Canonical Encoding Rules (CER) and Distinguished
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", draft-irtf-dtnrg-ltp-00 (expired), Transmission Protocol",
May 2004. draft-irtf-dtnrg-ltp-00 (replaced), May 2004.
[BRF06] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider
Transmission Protocol - Motivation",
draft-irtf-dtnrg-ltp-motivation-02 (work in progress),
March 2006.
[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.heffner-frag-harmful]
Heffner, J., "IPv4 Reassembly Errors at High Data Rates",
draft-heffner-frag-harmful-05 (work in progress),
May 2007.
[RBF06] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification",
draft-irtf-dtnrg-ltp-04 (work in progress), March 2006.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions [RFC1323] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992. for High Performance", RFC 1323, May 1992.
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000. November 2000.
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys", BCP 86, Public Keys Used For Exchanging Symmetric Keys", BCP 86,
RFC 3766, April 2004. RFC 3766, April 2004.
[SB05] Scott, K. and S. Burleigh, "Bundle Protocol [RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
Specification", draft-irtf-dtnrg-bundle-spec-04 (work in Errors at High Data Rates", RFC 4963, July 2007.
progress), November 2005.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, November 2007.
[RFC5325] Burleigh, S., Ramadas, M., and S. Farrell, "Licklider
Transmission Protocol - Motivation", RFC 5325,
September 2008.
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification", RFC 5326,
March 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 an # sdnv_decode() takes a string argument s, which is assumed to be an
# SDNV. The function returns a pair of the non-negative integer n # SDNV. The function returns a pair of the non-negative integer n
# that is the numeric value encoded in the SDNV, and and integer l # that is the numeric value encoded in the SDNV, and and integer l
# that is the distance parsed into the input string. If the slen # that is the distance parsed into the input string. If the slen
# argument is not given (or is not a non-zero number) then, s is # argument is not given (or is not a non-zero number) then, s is
# parsed up to the first byte whose high-order bit is 0 -- the # parsed up to the first byte whose high-order bit is 0 -- the
# length of the SDNV portion of s does not have to be pre-computed # length of the SDNV portion of s does not have to be pre-computed
skipping to change at page 20, line 10 skipping to change at page 21, line 10
# 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 Author's Address
Wesley M. Eddy Wesley M. Eddy
Verizon Federal Network Systems Verizon Federal Network Systems
NASA Glenn Research Center NASA Glenn Research Center
21000 Brookpark Rd, MS 54-5 21000 Brookpark Rd
Cleveland, OH 44135 Cleveland, OH 44135
Phone: 216-433-6682 Phone: 216-433-6682
Email: weddy@grc.nasa.gov Email: weddy@grc.nasa.gov
 End of changes. 21 change blocks. 
91 lines changed or deleted 105 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/