Internet DRAFT - draft-ietf-ippm-checksum-trailer

draft-ietf-ippm-checksum-trailer



Network Working Group                                         T. Mizrahi
Internet Draft                                                   Marvell
Intended status: Experimental
Expires: August 2016                                    February 9, 2016

                UDP Checksum Complement in OWAMP and TWAMP
                  draft-ietf-ippm-checksum-trailer-06.txt


Abstract

   The One-Way Active Measurement Protocol (OWAMP) and the Two-Way
   Active Measurement Protocol (TWAMP) are used for performance
   monitoring in IP networks. Delay measurement is performed in these
   protocols by using timestamped test packets. Some implementations use
   hardware-based timestamping engines that integrate the accurate
   transmission timestamp into every outgoing OWAMP/TWAMP test packet
   during transmission.  Since these packets are transported over UDP,
   the UDP checksum field is then updated to reflect this modification.
   This document proposes to use the last 2 octets of every test packet
   as a Checksum Complement, allowing timestamping engines to reflect
   the checksum modification in the last 2 octets rather than in the UDP
   checksum field. The behavior defined in this document is completely
   interoperable with existing OWAMP/TWAMP implementations.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   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 August 9, 2016.




Mizrahi, T.             Expires August 9, 2016                 [Page 1]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1. Introduction...................................................2
   2. Conventions used in this document..............................5
      2.1. Terminology...............................................5
      2.2. Abbreviations.............................................5
   3. Using the UDP Checksum Complement in OWAMP and TWAMP...........6
      3.1. Overview..................................................6
      3.2. OWAMP / TWAMP Test Packets with Checksum Complement.......6
         3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement.9
         3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum
         Complement.................................................10
         3.2.3. Reception of OWAMP/TWAMP with Checksum Complement...10
      3.3. Interoperability with Existing Implementations...........10
      3.4. Using the Checksum Complement with or without Authentication
      ..............................................................10
         3.4.1. Checksum Complement in Authenticated Mode...........10
         3.4.2. Checksum Complement in Encrypted Mode...............11
   4. Security Considerations.......................................11
   5. IANA Considerations...........................................12
   6. Acknowledgments...............................................12
   7. References....................................................12
      7.1. Normative References.....................................12
      7.2. Informative References...................................13
   Appendix A. Checksum Complement Usage Example....................13

1. Introduction

   The One-Way Active Measurement Protocol ([OWAMP]) and the Two-Way
   Active Measurement Protocol ([TWAMP]) are used for performance
   monitoring in IP networks.



Mizrahi, T.             Expires August 9, 2016                 [Page 2]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


   Delay and delay variation are two of the metrics that OWAMP/TWAMP can
   measure. This measurement is performed using timestamped test
   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
   and its implementation. In order to facilitate accurate timestamping,
   an implementation can use a hardware based timestamping engine, as
   shown in Figure 1. In such cases, the OWAMP/TWMAP packets are sent
   and received by a software layer, whereas the timestamping engine
   modifies every outgoing test packet by incorporating its accurate
   transmission time into the <Timestamp> field in the packet.

































Mizrahi, T.             Expires August 9, 2016                 [Page 3]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


                  OWAMP/TWAMP-enabled Node
                    +-------------------+
                    |                   |
                    |   +-----------+   |
     Software       |   |OWAMP/TWAMP|   |
                    |   | protocol  |   |
                    |   +-----+-----+   |
                    |         |         |     +---------------------+
                    |   +-----+-----+   |    / Intermediate entity  |
                    |   | Accurate  |   |   /  in charge of:        |
     ASIC/FPGA      |   | Timestamp |   |  /__ -Timestamping        |
                    |   |  engine   |   |     |-Updating checksum or|
                    |   +-----------+   |     | Checksum Complement |
                    |         |         |     +---------------------+
                    +---------+---------+
                              |
                              |test packets
                              |
                          ___ v _
                         /   \_/ \__
                        /           \_
                       /     IP      /
                       \_  Network  /
                        /           \
                        \__/\_   ___/
                              \_/

               Figure 1 Accurate Timestamping in OWAMP/TWAMP

   OWAMP/TWAMP test packets are transported over UDP. When the UDP
   payload is changed by an intermediate entity such as the timestamping
   engine, the UDP Checksum field must be updated to reflect the new
   payload. When using UDP over IPv4 ([UDP]), an intermediate entity
   that cannot update the value of the UDP checksum has no choice except
   to assign a value of zero to the checksum field, causing the receiver
   to ignore the checksum field and potentially accept corrupted
   packets. UDP over IPv6, as defined in [IPv6], does not allow a zero
   checksum, except in specific cases [ZeroChecksum]. As discussed in
   [ZeroChecksum], the use of a zero checksum is generally not
   recommended, and should be avoided to the extent possible.





Mizrahi, T.             Expires August 9, 2016                 [Page 4]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


   Since an intermediate entity only modifies a specific field in the
   packet, i.e. the timestamp field, the UDP checksum update can be
   performed incrementally, using the concepts presented in [Checksum].

   A similar problem is addressed in Annex E of [IEEE1588]. When the
   Precision Time Protocol (PTP) is transported over IPv6, two octets
   are appended to the end of the PTP payload for UDP checksum updates.
   The value of these two octets can be updated by an intermediate
   entity, causing the value of the UDP checksum field to remain
   correct.

   This document defines a similar concept for [OWAMP] and [TWAMP],
   allowing intermediate entities to update OWAMP/TWAMP test packets and
   maintain the correctness of the UDP checksum by modifying the last 2
   octets of the packet.

   The term Checksum Complement is used throughout this document and
   refers to the 2 octets at the end of the UDP payload, used for
   updating the UDP checksum by intermediate entities.

   The usage of the Checksum Complement can in some cases simplify the
   implementation, since if the packet data is processed in a serial
   order, it is simpler to first update the timestamp field, and then
   update the Checksum Complement rather than to update the timestamp
   and then update the UDP checksum, residing at the UDP header.

   The Checksum Complement mechanism is also defined for the Network
   Time Protocol in [NTPComp].

2. Conventions used in this document

2.1. Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [KEYWORDS].

2.2. Abbreviations

   HMAC     Hashed Message Authentication Code

   OWAMP    One-Way Active Measurement Protocol

   PTP      Precision Time Protocol

   TWAMP    Two-Way Active Measurement Protocol



Mizrahi, T.             Expires August 9, 2016                 [Page 5]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


   UDP      User Datagram Protocol

3. Using the UDP Checksum Complement in OWAMP and TWAMP

3.1. Overview

   The UDP Checksum Complement is a two-octet field that is piggybacked
   at the end of the test packet. It resides in the last 2 octets of the
   UDP payload.

                   +----------------------------------+
                   |       IPv4 / IPv6 Header         |
                   +----------------------------------+
                   |            UDP Header            |
                   +----------------------------------+
            ^      |                                  |
            |      |          OWAMP / TWAMP           |
           UDP     |             packet               |
          Payload  +----------------------------------+
            |      |UDP Checksum Complement (2 octets)|
            v      +----------------------------------+

          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

   The One-Way Active Measurement Protocol [OWAMP], and the Two-Way
   Active Measurement Protocol [TWAMP] both make use of timestamped test
   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 TWAMP test packets, sent by the sender to the reflector.

   o  In TWAMP test packets, sent by the reflector to the sender.

   OWAMP/TWAMP test packets are transported over UDP, either over IPv4
   or over IPv6. This document applies to both OWAMP/TWAMP over IPv4 and
   over IPv6.



Mizrahi, T.             Expires August 9, 2016                 [Page 6]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


   OWAMP/TWAMP test packets contain a Packet Padding field. This
   document proposes to use the last 2 octets of the Packet Padding
   field as the Checksum Complement. In this case the Checksum
   Complement is always the last 2 octets of the UDP payload, and thus
   the field is located UDP Length - 2 octets after the beginning of the
   UDP header.

   Figure 3 illustrates the OWAMP test packet format including the UDP
   Checksum Complement.

    0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Timestamp                            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        Error Estimate         |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   .                         Packet Padding                        .
   .                                                               .
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |      Checksum Complement      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 3 Checksum Complement in OWAMP Test Packets

   Figure 4 illustrates the TWAMP test packet format including the UDP
   Checksum Complement.

















Mizrahi, T.             Expires August 9, 2016                 [Page 7]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016



   0                   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Timestamp                            |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Error Estimate        |           MBZ                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Receive Timestamp                    |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sender Sequence Number                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Sender Timestamp                         |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Sender Error Estimate    |           MBZ                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Sender TTL   |                                               |
   +-+-+-+-+-+-+-+-+                                               +
   |                                                               |
   .                                                               .
   .                         Packet Padding                        .
   .                                                               .
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                               |     Checksum Complement       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Figure 4 Checksum Complement in TWAMP Test Packets

   The length of the Packet Padding field in test packets is announced
   during the session initiation through the <Padding Length> field in
   the Request-Session message [OWAMP], or in the Request-TW-Session
   [TWAMP].

   When a Checksum Complement is included, the <Padding Length> MUST be
   sufficiently long to include the Checksum Complement:

   o  In OWAMP the padding length is at least 2 octets, allowing the
      sender to incorporate the Checksum Complement in the last 2 octets
      of the padding.


Mizrahi, T.             Expires August 9, 2016                 [Page 8]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


   o  In TWAMP the padding length is at least 29 octets in
      unauthenticated mode, and at least 58 octets long in authenticated
      mode. The additional padding is required since the header of
      reflector test packets is longer than the header of sender test
      packets. The difference between the sender packet and the
      reflector packet is 27 octets in unauthenticated mode, and 56
      octets in authenticated mode.
      Thus, the padding in reflector test packets is shorter than in
      sender packet. Using at least 29 octets of padding (58 in
      authenticated mode) in sender test packets allows both the sender
      and the reflector to use a 2-octet Checksum Complement.
      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
      reflection and symmetrical size. When at least one of these
      features is enabled, the Request-TW-Session includes the <Padding
      Length> field, as well as a <Length of padding to reflect> field.
      In this case both fields must be sufficiently long to allow at
      least 2 octets of padding in both sender test packets and
      reflector test packets.
      Specifically, when octet reflection is enabled, the two length
      fields must be defined such that the padding expands at least 2
      octets beyond the end of the reflected octets.

   As described in Section 1. , the extensions described in this
   document are implemented by two logical layers, a protocol layer and
   a timestamping layer. It is assumed that the two layers are
   synchronized about whether the usage of the Checksum Complement is
   enabled or not; since both logical layers reside in the same network
   device, it is assumed there is no need for a protocol that
   synchronizes this information between the two layers. When Checksum
   Complement usage is enabled, the protocol layer must take care to
   verify that test packets include the necessary padding, and avoiding
   the need for the timestamping layer to verify that en-route test
   packets include the necessary padding.

3.2.1. Transmission of OWAMP/TWAMP with Checksum Complement

   The transmitter of an OWAMP/TWAMP test packet MAY include a Checksum
   Complement field, incorporated in the last 2 octets of the Packet
   Padding.

   A transmitter that includes a Checksum Complement in its outgoing
   test packets MUST include a Packet Padding in these packets, the


Mizrahi, T.             Expires August 9, 2016                 [Page 9]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


   length of which MUST be sufficient to include the Checksum
   Complement. The length of the padding field is negotiated during
   session initiation, as described in Section 3.2.

3.2.2. Intermediate Updates of OWAMP/TWAMP with Checksum Complement

   An intermediate entity that receives and alters an OWAMP/TWAMP test
   packet can alter either the UDP Checksum field or the Checksum
   Complement field in order to maintain the correctness of the UDP
   checksum value.

3.2.3. Reception of OWAMP/TWAMP with Checksum Complement

   This document does not impose new requirements on the receiving end
   of an OWAMP/TWAMP test packet.

   The UDP layer at the receiving end verifies the UDP Checksum of
   received test packets, and the OWAMP/TWAMP layer should treat the
   Checksum Complement as part of the Packet Padding.

3.3. Interoperability with Existing Implementations

   The behavior defined in this document does not impose new
   requirements on the reception behavior of OWAMP/TWAMP test packets.
   The protocol stack of the receiving host performs the conventional
   UDP checksum verification, and thus the existence of the Checksum
   Complement is transparent from the perspective of the receiving host.
   Therefore, the functionality described in this document allows
   interoperability with existing implementations that comply to [OWAMP]
   or [TWAMP].

3.4. Using the Checksum Complement with or without Authentication

   Both OWAMP and TWAMP may use authentication or encryption, as defined
   in [OWAMP] and [TWAMP].

3.4.1. Checksum Complement in Authenticated Mode

   OWAMP and TWAMP test packets can be authenticated using an HMAC
   (Hashed Message Authentication Code). The HMAC covers some of the
   fields in the test packet header. The HMAC does not cover the
   Timestamp field and the Packet Padding field.

   A Checksum Complement MAY be used when authentication is enabled. In
   this case an intermediate entity can timestamp test packets and
   update their Checksum Complement field without modifying the HMAC.



Mizrahi, T.             Expires August 9, 2016                [Page 10]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


3.4.2. Checksum Complement in Encrypted Mode

   When OWAMP and TWAMP are used in encrypted mode, the Timestamp field
   is encrypted.

   A Checksum Complement SHOULD NOT be used in encrypted mode. The
   Checksum Complement is effective in unauthenticated and in
   authenticated mode, allowing the intermediate entity to perform
   serial processing of the packet without storing-and-forwarding it.

   On the other hand, in encrypted mode an intermediate entity that
   timestamps a test packet must also re-encrypt the packet accordingly.
   Re-encryption typically requires the intermediate entity to store the
   packet, re-encrypt it, and then forward it. Thus, from an
   implementer's perspective, the Checksum Complement has very little
   value in encrypted mode, as it does not necessarily simplify the
   implementation.

   Note: while [OWAMP] and [TWAMP] include an inherent security
   mechanism, these protocols can be secured by other measures, e.g.,
   [IPPMIPsec]. For similar reasons as described above, a Checksum
   Complement SHOULD NOT be used in this case.

4. Security Considerations

   This document describes how a Checksum Complement extension can be
   used for maintaining the correctness of the UDP checksum.

   The purpose of this extension is to ease the implementation of
   accurate timestamping engines, as described in Figure 1. The
   extension is intended to be used internally in an OWAMP/TWAMP enabled
   node, and not intended to be used by intermediate switches and
   routers that reside between the sender and the receiver/reflector.
   Any modification of a test packet by intermediate switches or routers
   should be considered a malicious MITM attack.

   It is important to emphasize that the scheme described in this
   document does not increase the protocol's vulnerability to MITM
   attacks; a MITM who maliciously modifies a packet and its Checksum
   Complement is logically equivalent to a MITM attacker who modifies a
   packet and its UDP Checksum field.

   The concept described in this document is intended to be used only in
   unauthenticated or in authenticated mode. As described in Section
   3.4.2. , in encrypted mode using the Checksum Complement does not
   simplify the implementation compared to using the conventional
   Checksum, and therefore the Checksum Complement should not be used.


Mizrahi, T.             Expires August 9, 2016                [Page 11]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


5. IANA Considerations

   There are no IANA actions required by this document.

   RFC Editor: please delete this section before publication.

6. Acknowledgments

   The authors gratefully acknowledge Al Morton, Greg Mirsky, Steve
   Baillargeon, Brian Haberman, and Spencer Dawkins for their helpful
   comments.

   This document was prepared using 2-Word-v2.0.template.dot.

7. References

7.1. Normative References

   [KEYWORDS]    Bradner, S., "Key words for use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

   [IPv6]        Deering, S., Hinden, R., "Internet Protocol, Version 6
                 (IPv6) Specification", RFC 2460, December 1998.

   [Checksum]    Rijsinghani, A., "Computation of the Internet Checksum
                 via Incremental Update", RFC 1624, May 1994.

   [UDP]         Postel, J., "User Datagram Protocol", RFC 768, August
                 1980.

   [OWAMP]       Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and
                 Zekauskas, M., "A One-way Active Measurement Protocol
                 (OWAMP)", RFC 4656, September 2006.

   [TWAMP]       Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and
                 Babiarz, J., "A Two-Way Active Measurement Protocol
                 (TWAMP)", RFC 5357, October 2008.

   [RFC6038]     Morton, A., Ciavattone, L., "Two-Way Active
                 Measurement Protocol (TWAMP) Reflect Octets and
                 Symmetrical Size Features", RFC 6038, October 2010.








Mizrahi, T.             Expires August 9, 2016                [Page 12]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


7.2. Informative References

   [IEEE1588]    IEEE TC 9 Instrumentation and Measurement Society,
                 "1588 IEEE Standard for a Precision Clock
                 Synchronization Protocol for Networked Measurement and
                 Control Systems Version 2", IEEE Standard, 2008.

   [IPPMIPsec]   Pentikousis, K., Zhang, E., Cui, Y., "IKEv2-Derived
                 Shared Secret Key for the One-Way Active Measurement
                 Protocol (OWAMP) and Two-Way Active Measurement
                 Protocol (TWAMP)", RFC 7717, December 2015.

   [NTPComp]     Mizrahi, T., "UDP Checksum Complement in the Network
                 Time Protocol (NTP)", draft-ietf-ntp-checksum-trailer
                 (work in progress), October 2015.

   [ZeroChecksum] Fairhurst, G., Westerlund, M., "Applicability
                 Statement for the Use of IPv6 UDP Datagrams with Zero
                 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)



Mizrahi, T.             Expires August 9, 2016                [Page 13]

Internet-Draft   OWAMP and TWAMP Checksum Complement      February 2016


   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

   Tal Mizrahi
   Marvell
   6 Hamada St.
   Yokneam, 20692 Israel

   Email: talmi@marvell.com


























Mizrahi, T.             Expires August 9, 2016                [Page 14]