< draft-gundogan-icnrg-ccnx-timetlv-05.txt   draft-irtf-icnrg-ccnx-timetlv-00.txt >
ICNRG C. Gundogan ICNRG C. Gündoğan
Internet-Draft TC. Schmidt Internet-Draft TC. Schmidt
Intended status: Experimental HAW Hamburg Intended status: Experimental HAW Hamburg
Expires: 25 July 2022 D. Oran Expires: 29 October 2022 D. Oran
Network Systems Research and Design Network Systems Research and Design
M. Waehlisch M. Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
21 January 2022 27 April 2022
Alternative Delta Time Encoding for CCNx Using Compact Floating-Point Alternative Delta Time Encoding for CCNx Using Compact Floating-Point
Arithmetic Arithmetic
draft-gundogan-icnrg-ccnx-timetlv-05 draft-irtf-icnrg-ccnx-timetlv-00
Abstract Abstract
CCNx utilizes delta time for a number of functions. When using CCNx CCNx utilizes delta time for a number of functions. When using CCNx
in environments with constrained nodes and/or bandwidth constrained in environments with constrained nodes or bandwidth constrained
networks, it is valuable to have a compressed representation of delta networks, it is valuable to have a compressed representation of delta
time. In order to do so, either accuracy or dynamic range has to be time. In order to do so, either accuracy or dynamic range has to be
sacrificed. Since the current uses of delta time do not require both sacrificed. Since the current uses of delta time do not require both
simultaneously, one can consider a logarithmic encoding such as that simultaneously, one can consider a logarithmic encoding such as that
specified in [IEEE.754.2019]. This document updates _CCNx messages specified in [RFC5497] and [IEEE.754.2019]. This document updates
in TLV Format_ (RFC8609) to specify this alternative encoding. _CCNx messages in TLV Format_ [RFC8609] to specify this alternative
encoding.
Status of This Memo Status of This Memo
This Internet-Draft is submitted 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). 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 25 July 2022. This Internet-Draft will expire on 29 October 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Usage of Time Values in CCNx . . . . . . . . . . . . . . . . 3 3. Usage of Time Values in CCNx . . . . . . . . . . . . . . . . 3
3.1. Relative Time in CCNx . . . . . . . . . . . . . . . . . . 3 3.1. Relative Time in CCNx . . . . . . . . . . . . . . . . . . 3
3.2. Absolute Time in CCNx . . . . . . . . . . . . . . . . . . 3 3.2. Absolute Time in CCNx . . . . . . . . . . . . . . . . . . 3
4. A Compact Time Representation with Logarithmic Range . . . . 4 4. A Compact Time Representation with Logarithmic Range . . . . 4
5. Protocol Integration of the Compact Time Representation . . . 6 5. Protocol Integration of the Compact Time Representation . . . 6
5.1. Interest Lifetime . . . . . . . . . . . . . . . . . . . . 7 5.1. Interest Lifetime . . . . . . . . . . . . . . . . . . . . 7
5.2. Recommended Cache Time . . . . . . . . . . . . . . . . . 8 5.2. Recommended Cache Time . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 9 Appendix A. Test Vectors . . . . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Efficient Time Value Approximation . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
CCNx utilizes time values for a number of functions. Some of these CCNx utilizes time values for a number of functions. Some of these
are expressed as absolute time, others as delta time. When using are expressed as absolute time, others as delta time. CCNx is well
CCNx in environments with constrained nodes and/or bandwidth suited for Internet of Things (IoT) applications [RFC7927]. When
using CCNx in environments with constrained nodes or bandwidth
constrained networks, it is valuable to have a compact representation constrained networks, it is valuable to have a compact representation
of time values. For example [RFC9139] specifies a compression scheme of time values. For example [RFC9139] and [ICNLOWPAN] specify a
useful over IEEE 802.15.4 networks. However, any compact time compression scheme useful over IEEE 802.15.4 networks. However, any
representation has to sacrifice either accuracy or dynamic range or compact time representation has to sacrifice accuracy or dynamic
both. For some time uses this is relatively straightforward to range. For some time uses this is relatively straightforward to
achieve, for other uses, it is not. This document discusses the achieve, for other uses, it is not. This document discusses the
various cases, and proposes a compact encoding that is easily various cases, and proposes a compact encoding that is easily
accommodated for delta times. accommodated for delta times.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 3, line 32 skipping to change at page 3, line 38
2.4.2, 10.3 of [RFC8569]). It is a hop-by-hop header value, and is 2.4.2, 10.3 of [RFC8569]). It is a hop-by-hop header value, and is
currently encoded via the T_INTLIFE TLV as a 64-bit integer currently encoded via the T_INTLIFE TLV as a 64-bit integer
([RFC8609] section 3.4.1). While formally an optional TLV, in all ([RFC8609] section 3.4.1). While formally an optional TLV, in all
but some corner cases every Interest message is expected to carry the but some corner cases every Interest message is expected to carry the
Interest Lifetime TLV, and hence having compact encoding is Interest Lifetime TLV, and hence having compact encoding is
particularly valuable for keeping Interest messages short. particularly valuable for keeping Interest messages short.
Since the current uses of delta time do not require both accuracy and Since the current uses of delta time do not require both accuracy and
dynamic range simultaneously, one can consider a logarithmic encoding dynamic range simultaneously, one can consider a logarithmic encoding
such as that specified in [IEEE.754.2019] and outlined in Section 4. such as that specified in [IEEE.754.2019] and outlined in Section 4.
This document updates CCNx messages in TLV Format ([RFC8609]) to This document updates _CCNx messages in TLV Format_ [RFC8609] to
permit this alternative encoding for selected time values. See permit this alternative encoding for selected time values. See
Section 6 for the specific actions needed to register this Section 6 for the specific actions needed to register this
alternative compact representation of Interest Lifetime. alternative compact representation of Interest Lifetime.
3.2. Absolute Time in CCNx 3.2. Absolute Time in CCNx
CCNx, as currently specified in [RFC8569], utilizes absolute time for CCNx, as currently specified in [RFC8569], utilizes absolute time for
various important functions. Each of these absolute time usages various important functions. Each of these absolute time usages
poses a different challenge for a compact representation. These are poses a different challenge for a compact representation. These are
discussed in the following subsections. discussed in the following subsections.
3.2.1. Signature Time and Expiry Time 3.2.1. Signature Time and Expiry Time
_Signature Time_ is the time the signature of a content object was _Signature Time_ is the time the signature of a content object was
generated (sections 8.2-8.4 [RFC8569]). _Expiry Time_ indicates the generated (sections 8.2-8.4 [RFC8569]). _Expiry Time_ indicates the
expiry time of a content object (section 4 [RFC8569]). Both values expiry time of a content object (section 4 [RFC8569]). Both values
are content message TLVs and represent absolute timestamps in are content message TLVs and represent absolute timestamps in
milliseconds since the UTC epoch (i.e., an NTP timestamp). They are milliseconds since the UTC epoch (i.e., an NTP timestamp). They are
currently encoded via the T_SIGTIME and T_EXPIRY TLVs as 64-bit currently encoded via the T_SIGTIME and T_EXPIRY TLVs as 64-bit
unsigned integers (see section 3.6.4.1.4.5 [RFC8609] and section unsigned integers (see section 3.6.4.1.4.5 and 3.6.2.2.2 [RFC8609]).
3.6.2.2.2 [RFC8609]).
Both time values could be in the past, or in the future, potentially Both time values could be in the past, or in the future, potentially
by a large delta. They are also included in the security envelope of by a large delta. They are also included in the security envelope of
the message. Therefore, it seems there is no practical way to define the message. Therefore, it seems there is no practical way to define
an alternative compact encoding that preserves its semantics and an alternative compact encoding that preserves its semantics and
security properties; hence we don't consider it further as a security properties; hence we don't consider it further as a
candidate. candidate.
3.2.2. Recommended Cache Time 3.2.2. Recommended Cache Time
skipping to change at page 7, line 14 skipping to change at page 7, line 14
* The alternative of assigning new TLV registry values does not * The alternative of assigning new TLV registry values does not
substantially mitigate the interoperability problems anyway. substantially mitigate the interoperability problems anyway.
The following lists alternative approaches of integrating the compact The following lists alternative approaches of integrating the compact
time representation for time offsets in CCNx messages. A further time representation for time offsets in CCNx messages. A further
analysis, discussion, and decision on the best suited approach will analysis, discussion, and decision on the best suited approach will
be added as the document progresses. be added as the document progresses.
1. Relative time TLVs (e.g., T_INTLIFETIME) include nested TLVs to 1. Relative time TLVs (e.g., T_INTLIFETIME) include nested TLVs to
hint at the used encoding. This approach is the least intrusive hint at the used encoding. This approach allows for versatility
integration, but adds a TLV overhead that negates the benefits of in defining new time encodings, but adds a TLV overhead that
the compact time representation. negates the benefits of the compact time representation.
2. A new TLV type for T_INTLIFETIME with a compact time 2. A new TLV type for the compact time representation is defined
representation (T_INTLIFETIME_COMPACT) is defined. The packet (T_INTLIFETIME_COMPACT). The packet header grammar from
header grammar from [RFC8609] is updated to allow for [RFC8609] is updated to allow for T_INTLIFETIME_COMPACT at the
T_INTLIFETIME_COMPACT at the same level of the currently defined same level of the currently defined T_INTLIFETIME.
T_INTLIFETIME with an exclusive or.
5.1. Interest Lifetime 5.1. Interest Lifetime
The Interest Lifetime definition in [RFC8609] allows for a variable- The Interest Lifetime definition in [RFC8609] allows for a variable-
length lifetime representation, where a length of 1 encodes the length lifetime representation, where a length of 1 encodes the
linear range [0,255] in milliseconds. This document changes the linear range [0,255] in milliseconds. This document changes the
definition to always encode 1-byte Interest lifetime values in the definition to always encode 1-byte Interest lifetime values in the
compact time value representation (Figure 4). compact time value representation (Figure 4).
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_INTLIFE | Length = 1 |
+---------------+---------------+---------------+---------------+
| COMPACT_TIME |
+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_INTLIFE | Length > 1 | | T_INTLIFE | Length > 1 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ / / /
/ Lifetime (Length octets) / / Lifetime (Length octets) /
/ / / /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_INTLIFE | Length = 1 |
+---------------+---------------+---------------+---------------+
| COMPACT_TIME |
+---------------+
Figure 4: Changes to the definition of the Interest Lifetime TLV. Figure 4: Changes to the definition of the Interest Lifetime TLV.
A note on legacy forwarders: A forwarder that does not support this
compact time representation will interpret the time value as an
Interest lifetime between 0 and 255 milliseconds. This may lead to a
degradation of network performance, since Pending Interest
Table (PIT) entries timeout quicker than expected.
5.2. Recommended Cache Time 5.2. Recommended Cache Time
The Recommended Cache Time definition in [RFC8609] specifies an The Recommended Cache Time definition in [RFC8609] specifies an
absolute time representation that is of a length fixed to 8 bytes. absolute time representation that is of a length fixed to 8 bytes.
This document changes the definition to always encode 1-byte This document changes the definition to always encode 1-byte
Recommended Cache Time values in the compact relative time value Recommended Cache Time values in the compact relative time value
representation (Figure 5). representation (Figure 5).
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
| T_CACHETIME | Length = 1 |
+---------------+---------------+---------------+---------------+
| COMPACT_TIME |
+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_CACHETIME | Length = 8 | | T_CACHETIME | Length = 8 |
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
/ / / /
/ Recommended Cache Time / / Recommended Cache Time /
/ / / /
+---------------+---------------+---------------+---------------+ +---------------+---------------+---------------+---------------+
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_CACHETIME | Length = 1 |
+---------------+---------------+---------------+---------------+
| COMPACT_TIME |
+---------------+
Figure 5: Changes to the definition of the Recommended Cache Time Figure 5: Changes to the definition of the Recommended Cache Time
TLV. TLV.
The packet processing is adapted to calculate an absolute time from The packet processing is adapted to calculate an absolute time from
the relative time code based on the absolute reception time. On the relative time code based on the absolute reception time. On
transmission, a new relative time code is calculated based on the transmission, a new relative time code is calculated based on the
current system time. current system time.
A note on legacy forwarders: A forwarder that does not support this
compact time representation is expected to consider a Recommended
Cache Time with length 1 as a structural or syntactical error and
discard the packet. Otherwise, a forwarder interprets the compact
1-byte time value as an absolute time far in the past, which impacts
cache utilization.
6. IANA Considerations 6. IANA Considerations
Based on the approach of integration, certain TLV registries from Based on the approach of integration, certain TLV registries from
[RFC8609] need to be updated. [RFC8609] need to be updated.
7. Security Considerations 7. Security Considerations
This document makes no semantic changes to [RFC8569], nor to any of This document makes no semantic changes to [RFC8569], nor to any of
the security properties of the message encodings of [RFC8609], and the security properties of the message encodings of [RFC8609], and
hence has the same security considerations as those two existing hence has the same security considerations as those two existing
documents. documents.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
8.2. Informative References
[ICNLOWPAN]
Gündoğan, C., Kietzmann, P., Schmidt, T., and M. Wählisch,
"Designing a LoWPAN convergence layer for the Information
Centric Internet of Things", Computer Communications, Vol.
164, No. 1, p. 114–123, Elsevier, December 2020,
<https://doi.org/10.1016/j.comcom.2020.10.002>.
[IEEE.754.2019] [IEEE.754.2019]
Institute of Electrical and Electronics Engineers, C/MSC - Institute of Electrical and Electronics Engineers, C/MSC -
Microprocessor Standards Committee, "Standard for Microprocessor Standards Committee, "Standard for
Floating-Point Arithmetic", June 2019, Floating-Point Arithmetic", June 2019,
<https://standards.ieee.org/content/ieee-standards/en/ <https://standards.ieee.org/content/ieee-standards/en/
standard/754-2019.html>. standard/754-2019.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
DOI 10.17487/RFC5497, March 2009, DOI 10.17487/RFC5497, March 2009,
<https://www.rfc-editor.org/info/rfc5497>. <https://www.rfc-editor.org/info/rfc5497>.
[RFC7927] Kutscher, D., Ed., Eum, S., Pentikousis, K., Psaras, I.,
Corujo, D., Saucez, D., Schmidt, T., and M. Waehlisch,
"Information-Centric Networking (ICN) Research
Challenges", RFC 7927, DOI 10.17487/RFC7927, July 2016,
<https://www.rfc-editor.org/info/rfc7927>.
[RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric [RFC8569] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Semantics", RFC 8569, Networking (CCNx) Semantics", RFC 8569,
DOI 10.17487/RFC8569, July 2019, DOI 10.17487/RFC8569, July 2019,
<https://www.rfc-editor.org/info/rfc8569>. <https://www.rfc-editor.org/info/rfc8569>.
[RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric [RFC8609] Mosko, M., Solis, I., and C. Wood, "Content-Centric
Networking (CCNx) Messages in TLV Format", RFC 8609, Networking (CCNx) Messages in TLV Format", RFC 8609,
DOI 10.17487/RFC8609, July 2019, DOI 10.17487/RFC8609, July 2019,
<https://www.rfc-editor.org/info/rfc8609>. <https://www.rfc-editor.org/info/rfc8609>.
8.2. Informative References
[RFC9139] Gündoğan, C., Schmidt, T., Wählisch, M., Scherb, C., [RFC9139] Gündoğan, C., Schmidt, T., Wählisch, M., Scherb, C.,
Marxer, C., and C. Tschudin, "Information-Centric Marxer, C., and C. Tschudin, "Information-Centric
Networking (ICN) Adaptation to Low-Power Wireless Personal Networking (ICN) Adaptation to Low-Power Wireless Personal
Area Networks (LoWPANs)", RFC 9139, DOI 10.17487/RFC9139, Area Networks (LoWPANs)", RFC 9139, DOI 10.17487/RFC9139,
November 2021, <https://www.rfc-editor.org/info/rfc9139>. November 2021, <https://www.rfc-editor.org/info/rfc9139>.
Appendix A. Test Vectors Appendix A. Test Vectors
The test vectors in Table 1 show sample time codes and their The test vectors in Table 1 show sample time codes and their
corresponding time values according to the algorithm outlined in corresponding time values according to the algorithm outlined in
skipping to change at page 10, line 29 skipping to change at page 11, line 5
+-----------+----------------------+ +-----------+----------------------+
| 0x30 | 2.000000 | | 0x30 | 2.000000 |
+-----------+----------------------+ +-----------+----------------------+
| 0xF8 | 67108864.000000 | | 0xF8 | 67108864.000000 |
+-----------+----------------------+ +-----------+----------------------+
| 0xFF | 125829120.000000 | | 0xFF | 125829120.000000 |
+-----------+----------------------+ +-----------+----------------------+
Table 1: Test Vectors Table 1: Test Vectors
Appendix B. Efficient Time Value Approximation
A forwarder frequently converts compact time into milliseconds to
compare Interest lifetimes and the duration of cache entries. On
many architectures, multiplication and division perform slower than
addition, subtraction, and bit shifts. The following equations
approximate the formulas in Section 4, and scale from seconds into
the milliseconds range by applying a factor of 2^10 instead of 10^3.
This results in an error of 2.4%.
b == 0: 2^10 * a * 2^-3 * 2^1 * 2^-5
= a << 3
b > 0: (2^10 + a * 2^-3 * 2^10) * 2^b * 2^-5
= (1 << 5 + a << 2) << b
Acknowledgments Acknowledgments
We would like to thank the active members of the ICNRG research group We would like to thank the active members of the ICNRG research group
for constructive thoughts. In particular, we thank Marc Mosko for for constructive thoughts. In particular, we thank Marc Mosko and
his feedback on the encoding scheme, the provided pseudo code, and Ken Calvert for their valuable feedback on the encoding scheme and
test vectors. the protocol integration.
Authors' Addresses Authors' Addresses
Cenk Gundogan Cenk Gündoğan
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
D-20099 Hamburg D-20099 Hamburg
Germany Germany
Phone: +4940428758067 Phone: +4940428758067
Email: cenk.guendogan@haw-hamburg.de Email: cenk.guendogan@haw-hamburg.de
URI: http://inet.haw-hamburg.de/members/cenk-gundogan URI: http://inet.haw-hamburg.de/members/cenk-gundogan
Thomas C. Schmidt Thomas C. Schmidt
HAW Hamburg HAW Hamburg
Berliner Tor 7 Berliner Tor 7
D-20099 Hamburg D-20099 Hamburg
Germany Germany
Email: t.schmidt@haw-hamburg.de Email: t.schmidt@haw-hamburg.de
URI: http://inet.haw-hamburg.de/members/schmidt URI: http://inet.haw-hamburg.de/members/schmidt
Dave Oran Dave Oran
Network Systems Research and Design Network Systems Research and Design
4 Shady Hill Square 4 Shady Hill Square
Cambridge, MA 02138 Cambridge, MA 02138
United States of America United States of America
Email: daveoran@orandom.net Email: daveoran@orandom.net
Matthias Waehlisch Matthias Waehlisch
link-lab & FU Berlin link-lab & FU Berlin
Hoenower Str. 35 Hoenower Str. 35
D-10318 Berlin D-10318 Berlin
Germany Germany
Email: mw@link-lab.net Email: mw@link-lab.net
URI: http://www.inf.fu-berlin.de/~waehl URI: http://www.inf.fu-berlin.de/~waehl
 End of changes. 35 change blocks. 
64 lines changed or deleted 102 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/