draft-ietf-ippm-checksum-trailer-05.txt   draft-ietf-ippm-checksum-trailer-06.txt 
Network Working Group T. Mizrahi Network Working Group T. Mizrahi
Internet Draft Marvell Internet Draft Marvell
Intended status: Experimental Intended status: Experimental
Expires: May 2016 November 16, 2015 Expires: August 2016 February 9, 2016
UDP Checksum Complement in OWAMP and TWAMP UDP Checksum Complement in OWAMP and TWAMP
draft-ietf-ippm-checksum-trailer-05.txt draft-ietf-ippm-checksum-trailer-06.txt
Abstract Abstract
The One-Way Active Measurement Protocol (OWAMP) and the Two-Way The One-Way Active Measurement Protocol (OWAMP) and the Two-Way
Active Measurement Protocol (TWAMP) are used for performance Active Measurement Protocol (TWAMP) are used for performance
monitoring in IP networks. Delay measurement is performed in these monitoring in IP networks. Delay measurement is performed in these
protocols by using timestamped test packets. Some implementations use protocols by using timestamped test packets. Some implementations use
hardware-based timestamping engines that integrate the accurate hardware-based timestamping engines that integrate the accurate
transmission timestamp into every outgoing OWAMP/TWAMP test packet transmission timestamp into every outgoing OWAMP/TWAMP test packet
during transmission. Since these packets are transported over UDP, during transmission. Since these packets are transported over UDP,
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 May 16, 2016. This Internet-Draft will expire on August 9, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 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 Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
2. Conventions used in this document..............................4 2. Conventions used in this document..............................5
2.1. Terminology...............................................4 2.1. Terminology...............................................5
2.2. Abbreviations.............................................5 2.2. Abbreviations.............................................5
3. Using the UDP Checksum Complement in OWAMP and TWAMP...........5 3. Using the UDP Checksum Complement in OWAMP and TWAMP...........6
3.1. Overview..................................................5 3.1. Overview..................................................6
3.2. OWAMP / TWAMP Test Packets with Checksum Complement.......5 3.2. OWAMP / TWAMP Test Packets with Checksum Complement.......6
3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement.8 3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement.9
3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum 3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum
Complement..................................................9 Complement.................................................10
3.2.3. Reception of OWAMP/TWAMP with Checksum Complement....9 3.2.3. Reception of OWAMP/TWAMP with Checksum Complement...10
3.3. Interoperability with Existing Implementations............9 3.3. Interoperability with Existing Implementations...........10
3.4. Using the Checksum Complement with or without Authentication 3.4. Using the Checksum Complement with or without Authentication
...............................................................9 ..............................................................10
3.4.1. Checksum Complement in Authenticated Mode............9 3.4.1. Checksum Complement in Authenticated Mode...........10
3.4.2. Checksum Complement in Encrypted Mode................9 3.4.2. Checksum Complement in Encrypted Mode...............11
4. Security Considerations.......................................10 4. Security Considerations.......................................11
5. IANA Considerations...........................................10 5. IANA Considerations...........................................12
6. Acknowledgments...............................................11 6. Acknowledgments...............................................12
7. References....................................................11 7. References....................................................12
7.1. Normative References.....................................11 7.1. Normative References.....................................12
7.2. Informative References...................................11 7.2. Informative References...................................13
Appendix A. Checksum Complement Usage Example....................13
1. Introduction 1. Introduction
The One-Way Active Measurement Protocol ([OWAMP]) and the Two-Way The One-Way Active Measurement Protocol ([OWAMP]) and the Two-Way
Active Measurement Protocol ([TWAMP]) are used for performance Active Measurement Protocol ([TWAMP]) are used for performance
monitoring in IP networks. monitoring in IP networks.
Delay and delay variation are two of the metrics that OWAMP/TWAMP can Delay and delay variation are two of the metrics that OWAMP/TWAMP can
measure. This measurement is performed using timestamped test measure. This measurement is performed using timestamped test
packets. packets. In some use cases, such as carrier networks, these two
metrics are an essential aspect of the Service Level Agreement (SLA),
and therefore must be measured with a high degree of accuracy. If
packets are timestamped in hardware as they exit the host, then
greater accuracy is possible in comparison to higher-layer timestamps
(as explained further below).
The accuracy of delay measurements relies on the timestamping method The accuracy of delay measurements relies on the timestamping method
and its implementation. In order to facilitate accurate timestamping, and its implementation. In order to facilitate accurate timestamping,
an implementation can use a hardware based timestamping engine, as an implementation can use a hardware based timestamping engine, as
shown in Figure 1. In such cases, the OWAMP/TWMAP packets are sent shown in Figure 1. In such cases, the OWAMP/TWMAP packets are sent
and received by a software layer, whereas the timestamping engine and received by a software layer, whereas the timestamping engine
modifies every outgoing test packet by incorporating its accurate modifies every outgoing test packet by incorporating its accurate
transmission time into the <Timestamp> field in the packet. transmission time into the <Timestamp> field in the packet.
OWAMP/TWAMP-enabled Node OWAMP/TWAMP-enabled Node
skipping to change at page 5, line 39 skipping to change at page 6, line 28
+----------------------------------+ +----------------------------------+
^ | | ^ | |
| | OWAMP / TWAMP | | | OWAMP / TWAMP |
UDP | packet | UDP | packet |
Payload +----------------------------------+ Payload +----------------------------------+
| |UDP Checksum Complement (2 octets)| | |UDP Checksum Complement (2 octets)|
v +----------------------------------+ v +----------------------------------+
Figure 2 Checksum Complement in OWAMP/TWAMP Test Packet Figure 2 Checksum Complement in OWAMP/TWAMP Test Packet
The Checksum Complement is used to compensate for changes performed
in the packet by intermediate entities, as described in the
introduction. An example of the usage of the Checksum Complement is
provided in Appendix A.
3.2. OWAMP / TWAMP Test Packets with Checksum Complement 3.2. OWAMP / TWAMP Test Packets with Checksum Complement
The One-Way Active Measurement Protocol [OWAMP], and the Two-Way The One-Way Active Measurement Protocol [OWAMP], and the Two-Way
Active Measurement Protocol [TWAMP] both make use of timestamped test Active Measurement Protocol [TWAMP] both make use of timestamped test
packets. A Checksum Complement MAY be used in the following cases: packets. A Checksum Complement MAY be used in the following cases:
o In OWAMP test packets, sent by the sender to the receiver. o In OWAMP test packets, sent by the sender to the receiver.
o In TWAMP test packets, sent by the sender to the reflector. o In TWAMP test packets, sent by the sender to the reflector.
skipping to change at page 8, line 5 skipping to change at page 9, line 5
the Request-Session message [OWAMP], or in the Request-TW-Session the Request-Session message [OWAMP], or in the Request-TW-Session
[TWAMP]. [TWAMP].
When a Checksum Complement is included, the <Padding Length> MUST be When a Checksum Complement is included, the <Padding Length> MUST be
sufficiently long to include the Checksum Complement: sufficiently long to include the Checksum Complement:
o In OWAMP the padding length is at least 2 octets, allowing the o In OWAMP the padding length is at least 2 octets, allowing the
sender to incorporate the Checksum Complement in the last 2 octets sender to incorporate the Checksum Complement in the last 2 octets
of the padding. of the padding.
o In TWAMP the padding length is at least 29 octets. The additional o In TWAMP the padding length is at least 29 octets in
padding is required since the header of reflector test packets is unauthenticated mode, and at least 58 octets long in authenticated
27 octets longer than the header of sender test packets. Thus, the mode. The additional padding is required since the header of
padding in reflector test packets is 27 octets shorter than in reflector test packets is longer than the header of sender test
sender packet. Using 29 octets of padding in sender test packets packets. The difference between the sender packet and the
allows both the sender and the reflector to use a 2-octet Checksum reflector packet is 27 octets in unauthenticated mode, and 56
Complement. octets in authenticated mode.
Note: the 27-octet difference between the sender packet and the Thus, the padding in reflector test packets is shorter than in
reflector packet is specifically in unauthenticated mode, whereas sender packet. Using at least 29 octets of padding (58 in
in authenticated mode the difference between the sender and authenticated mode) in sender test packets allows both the sender
receiver packets is 56 octets. As specified in Section 3.4. , the and the reflector to use a 2-octet Checksum Complement.
Checksum Complement should only be used in unauthenticated mode. Note: if the minimal length requirement is not met, the reflector
cannot use a Checksum Complement in the reflected test packets,
but the sender can use a Checksum Complement in the test packets
it transmits.
o Two optional TWAMP features are defined in [RFC6038]: octet o Two optional TWAMP features are defined in [RFC6038]: octet
reflection and symmetrical size. When at least one of these reflection and symmetrical size. When at least one of these
features is enabled, the Request-TW-Session includes the <Padding features is enabled, the Request-TW-Session includes the <Padding
Length> field, as well as a <Length of padding to reflect> field. Length> field, as well as a <Length of padding to reflect> field.
In this case both fields must be sufficiently long to allow at In this case both fields must be sufficiently long to allow at
least 2 octets of padding in both sender test packets and least 2 octets of padding in both sender test packets and
reflector test packets. reflector test packets.
Specifically, when octet reflection is enabled, the two length Specifically, when octet reflection is enabled, the two length
fields must be defined such that the padding expands at least 2 fields must be defined such that the padding expands at least 2
skipping to change at page 9, line 18 skipping to change at page 10, line 21
packet can alter either the UDP Checksum field or the Checksum packet can alter either the UDP Checksum field or the Checksum
Complement field in order to maintain the correctness of the UDP Complement field in order to maintain the correctness of the UDP
checksum value. checksum value.
3.2.3. Reception of OWAMP/TWAMP with Checksum Complement 3.2.3. Reception of OWAMP/TWAMP with Checksum Complement
This document does not impose new requirements on the receiving end This document does not impose new requirements on the receiving end
of an OWAMP/TWAMP test packet. of an OWAMP/TWAMP test packet.
The UDP layer at the receiving end verifies the UDP Checksum of The UDP layer at the receiving end verifies the UDP Checksum of
received test packets, and the OWAMP/TWAMP layer SHOULD treat the received test packets, and the OWAMP/TWAMP layer should treat the
Checksum Complement as part of the Packet Padding. Checksum Complement as part of the Packet Padding.
3.3. Interoperability with Existing Implementations 3.3. Interoperability with Existing Implementations
The behavior defined in this document does not impose new The behavior defined in this document does not impose new
requirements on the reception behavior of OWAMP/TWAMP test packets. requirements on the reception behavior of OWAMP/TWAMP test packets.
The protocol stack of the receiving host performs the conventional The protocol stack of the receiving host performs the conventional
UDP checksum verification, and thus the existence of the Checksum UDP checksum verification, and thus the existence of the Checksum
Complement is transparent from the perspective of the receiving host. Complement is transparent from the perspective of the receiving host.
Therefore, the functionality described in this document allows Therefore, the functionality described in this document allows
skipping to change at page 11, line 9 skipping to change at page 12, line 13
Checksum, and therefore the Checksum Complement should not be used. Checksum, and therefore the Checksum Complement should not be used.
5. IANA Considerations 5. IANA Considerations
There are no IANA actions required by this document. There are no IANA actions required by this document.
RFC Editor: please delete this section before publication. RFC Editor: please delete this section before publication.
6. Acknowledgments 6. Acknowledgments
The authors gratefully acknowledge Al Morton, Greg Mirsky, and Steve The authors gratefully acknowledge Al Morton, Greg Mirsky, Steve
Baillargeon for their helpful comments. Baillargeon, Brian Haberman, and Spencer Dawkins for their helpful
comments.
This document was prepared using 2-Word-v2.0.template.dot. This document was prepared using 2-Word-v2.0.template.dot.
7. References 7. References
7.1. Normative References 7.1. Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 11, line 49 skipping to change at page 13, line 12
Measurement Protocol (TWAMP) Reflect Octets and Measurement Protocol (TWAMP) Reflect Octets and
Symmetrical Size Features", RFC 6038, October 2010. Symmetrical Size Features", RFC 6038, October 2010.
7.2. Informative References 7.2. Informative References
[IEEE1588] IEEE TC 9 Instrumentation and Measurement Society, [IEEE1588] IEEE TC 9 Instrumentation and Measurement Society,
"1588 IEEE Standard for a Precision Clock "1588 IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and Synchronization Protocol for Networked Measurement and
Control Systems Version 2", IEEE Standard, 2008. Control Systems Version 2", IEEE Standard, 2008.
[IPPMIPsec] Pentikousis, K., Zhang, E., Cui, Y., "IKEv2-based [IPPMIPsec] Pentikousis, K., Zhang, E., Cui, Y., "IKEv2-Derived
Shared Secret Key for O/TWAMP", draft-ietf-ippm-ipsec Shared Secret Key for the One-Way Active Measurement
(work in progress), May 2015. Protocol (OWAMP) and Two-Way Active Measurement
Protocol (TWAMP)", RFC 7717, December 2015.
[NTPComp] Mizrahi, T., "UDP Checksum Complement in the Network [NTPComp] Mizrahi, T., "UDP Checksum Complement in the Network
Time Protocol (NTP)", draft-ietf-ntp-checksum-trailer Time Protocol (NTP)", draft-ietf-ntp-checksum-trailer
(work in progress), October 2015. (work in progress), October 2015.
[ZeroChecksum] Fairhurst, G., Westerlund, M., "Applicability [ZeroChecksum] Fairhurst, G., Westerlund, M., "Applicability
Statement for the Use of IPv6 UDP Datagrams with Zero Statement for the Use of IPv6 UDP Datagrams with Zero
Checksums", RFC 6936, April 2013. Checksums", RFC 6936, April 2013.
Appendix A. Checksum Complement Usage Example
Consider a session between an OWAMP sender and an OWAMP receiver, in
which the sender transmits test packets to the receiver.
The sender's software layer generates an OWAMP test packet with a
timestamp T, and a UDP checksum value U. The value of U is the
checksum of the UDP header, UDP payload, and pseudo-header. Thus, U
is equal to:
U = Const + checksum(T) (1)
Where 'Const' is the checksum of all the fields that are covered by
the checksum except the timestamp T.
Recall that the sender's software emits the test packet with a
Checksum Complement field, which is simply the last two bytes of the
padding. In this example it is assumed that the sender initially
assigns zero to these two bytes.
The sender's timestamping engine updates the timestamp field to the
accurate time, changing its value from T to T'. The sender also
updates the Checksum Complement field from zero to a new value C,
such that:
checksum(C) = checksum(T) - checksum(T') (2)
When the test packet is transmitted by the sender's timestamping
engine, the value of the checksum remains U as before:
U = Const + checksum(T) = Const + checksum(T)+ checksum(T')-
checksum(T') = Const + checksum(T') + checksum(C) (3)
Thus, after the timestamping engine has updated the timestamp, U
remains the correct checksum of the packet.
When the test packet reaches the receiver, the receiver performs a
conventional UDP checksum computation, and the computed value is U.
Since the Checksum Complement is part of the padding, the value of
checksum(C) is transparently included in the computation, as per
Equation (3), without requiring special treatment by the receiver.
Authors' Addresses Authors' Addresses
Tal Mizrahi Tal Mizrahi
Marvell Marvell
6 Hamada St. 6 Hamada St.
Yokneam, 20692 Israel Yokneam, 20692 Israel
Email: talmi@marvell.com Email: talmi@marvell.com
 End of changes. 15 change blocks. 
41 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/