idnits 2.17.1 draft-ietf-ippm-twamp-time-format-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2016) is 2863 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE.1588.2008' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Mirsky 3 Internet-Draft Ericsson 4 Intended status: Standards Track I. Meilik 5 Expires: December 19, 2016 Broadcom 6 June 17, 2016 8 Support of IEEE-1588 time stamp format in Two-Way Active Measurement 9 Protocol (TWAMP) 10 draft-ietf-ippm-twamp-time-format-00 12 Abstract 14 This document describes an OPTIONAL feature for active performance 15 measurement protocols allowing use of time stamp format defined in 16 IEEE-1588v2-2008. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 19, 2016. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Conventions used in this document . . . . . . . . . . . . 3 54 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 55 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 56 2. OWAMP and TWAMP Extensions . . . . . . . . . . . . . . . . . 3 57 2.1. Timestamp Format Negotiation in Setting Up Connection in 58 OWAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.2. Timestamp Format Negotiation in Setting Up Connection in 60 TWAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. OWAMP-Test and TWAMP-Test Update . . . . . . . . . . . . 5 62 2.3.1. Consideration for TWAMP Light mode . . . . . . . . . 6 63 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 66 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 One-Way Active Measurement Protocol (OWAMP) [RFC4656] defines that 72 only the NTP [RFC5905] format of a time stamp can be used in OWAMP- 73 Test protocol. Two-Way Active Measurement Protocol (TWAMP) [RFC5357] 74 adopted the OWAMP-Test packet format and extended it by adding a 75 format for a reflected test packet. Both the sender's and 76 reflector's packets time stamps are expected to follow the 64-bit 77 long NTP format [RFC5905]. NTP, when used over Internet, typically 78 achieves clock accuracy of about 5ms to 100ms. Surveys conducted 79 recently suggest that 90% devices achieve accuracy of better than 100 80 ms and 99% - better than 1 sec. It should be noted that NTP 81 synchronizes clocks on the control plane, not on data plane. 82 Distribution of clock wiitin a node may be supported by independent 83 NTP domain or via interprocess communication in multiprocessor 84 distributed system. And of mentioned solutions will be subject to 85 additional queuing delays that negatively affect data plane clock 86 accuracy. 88 Precision Time Protocol (PTP) [IEEE.1588.2008] has gained wide 89 support since the development of OWAMP and TWAMP. PTP, using on-path 90 support and other mechanisms, allows sub-microsecond clock accuracy. 91 PTP is now supported in multiple implementations of fast forwarding 92 engines and thus accuracy achieved by PTP is the accuracy of clock in 93 data plane. Thus providing option to use more accurate clock as 94 source of time stamps for IP performance measurement is one of 95 advantages this proposal helps to achive. Another advantage realized 96 by simplification of hardware in data plane. To support OWAMP or 97 TWAMP test protocol time stamps must be converted from PTP to NTP. 99 That requires resources, use of micro-code or additional processing 100 elements, that are always limited. To address this, this document 101 proposes optional extensions to Control and Test protocols to support 102 use of IEEE-1588v2 time stamp format as optional alternative to the 103 NTP time stamp format. 105 One of the goals of this proposal is not only allow end-points of a 106 test session to use other than NTP timestamp but to support backwards 107 compatibility with nodes that do not yet support this extension. 109 1.1. Conventions used in this document 111 1.1.1. Terminology 113 IPPM: IP Performance Measurement 115 NTP: Network Time Protocol 117 PTP: Precision Time Protocol 119 TWAMP: Two-Way Active Measurement Protocol 121 OWAMP: One-Way Active Measurement Protocol 123 1.1.2. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 127 "OPTIONAL" in this document are to be interpreted as described in 128 [RFC2119]. 130 2. OWAMP and TWAMP Extensions 132 OWAMP connection establishment follows the procedure defined in 133 Section 3.1 of [RFC4656] and additional steps in TWAMP described in 134 Section 3.1 of [RFC5357]. In these procedures the Modes field been 135 used to identify and select specific communication capabilities. At 136 the same time the Modes field been recognized and used as extension 137 mechanism [RFC6038]. The new feature requires one bit position for 138 Server and Control-Client to negotiate which timestamp format can be 139 used in some or all test sessions invoked with this control 140 connection. The end-point of the test session, Session-Sender and 141 Session-Receiver or Session-Reflector, that supports this extension 142 MUST be capable to interpret NTP and PTPv2 timestamp formats. If the 143 end-point does not support this extension, then the value of PTPv2 144 Timestamp flag MUST be 0 because it is in Must Be Zero field. If 145 value of PTPv2 Timestamp flags is 0, then the advertising node can 146 use and interpret only NTP timestamp format. 148 Use of PTPv2 Timestamp flags discussed in the following sub-sections. 149 For details on the assigned values and bit positions see the 150 Section 3. 152 2.1. Timestamp Format Negotiation in Setting Up Connection in OWAMP 154 In OWAMP-Test [RFC4656] it is the Session-Receiver and/or Fetch- 155 Client that are interpreting collected timestamps. Thus announced by 156 a Server in the Modes field timestamp format indicates which formats 157 the Session-Receiver is capable to interpret. The Control-Client 158 inspects values set by the Server for timestamp formats and sets 159 values in the Modes field of the Set-Up-Response message according to 160 timestamp formats Session-Sender is capable of using. The rules of 161 setting timestamp flags in Modes field in server greeting and Set-Up- 162 Response messages and interpreting them are as follows: 164 o The Server that establishes test sessions for Session-Receiver 165 that supports this extension MUST set PTPv2 Timestamp flag to 1 in 166 the server greeting message according to the requirement listed in 167 Section 2. 169 o If PTPv2 Timestamp flag of the server greeting message that the 170 Control-Client receives has value 0, then the Session-Sender MUST 171 use NTP format for timestamp in the test session and Control- 172 Client SHOULD set PTPv2 Timestamp flag to 0 in accordance with 173 [RFC4656]. If the Session-Sender cannot use NTP timestamps, then 174 the Control-Client SHOULD close the TCP connection associated with 175 the OWAMP-Control session. 177 o If the Session-Sender can set timestamp in PTPv2 format, then the 178 Control-Client MUST set the PTPv2 Timestamp flag to 1in Modes 179 field in the Set-Up-Response message and the Session-Sender MUST 180 set timestamp in PTPv2 timestamp format. Otherwise the Control- 181 Client MUST set the PTPv2 Timestamp flag in the Set-Up-Response 182 message to 0. 184 o Otherwise, if the Session-Sender can set timestamp in NTP format, 185 then the Session-Sender MUST set timestamp in NTP timestamp 186 format. Otherwise the Control-Client SHOULD close the TCP 187 connection associated with the OWAMP-Control session.. 189 If values of both NTP and PTPv2 Timestamp flags in the Set-Up- 190 Response message are equal to 0, then that indicates that the 191 Control-Client can set timestamp only in NTP format. 193 If OWAMP-Control uses Fetch-Session commands, then selection and use 194 of one or another timestamp format is local decision for both 195 Session-Sender and Session-Receiver. 197 2.2. Timestamp Format Negotiation in Setting Up Connection in TWAMP 199 In TWAMP-Test [RFC5357] it is the Session-Sender that is interpreting 200 collected timestamps. Hence, in the Modes field a Server advertises 201 timestamp formats that the Session-Reflector can use in TWAMP-Test 202 message. The choice of the timestamp format to be used by the 203 Session-Sender is a local decision. The Control-Client inspects the 204 Modes field and sets timestamp flags values to indicate which format 205 will be used by the Session-Reflector. The rules of setting and 206 interpreting flag values are as follows: 208 o Server MUST set to 1 value of PTPv2 Timestamp flag in its greeting 209 message if Session-Reflector can set timestamp in PTPv2 format. 210 Otherwise the PTPv2 Timestamp flag MUST be set to 0. 212 o If value of the PTPv2 Timestamp flag in received server greeting 213 message equals 0, then Session-Reflector does not support this 214 extension and will use NTP timestamp format. Control-Client 215 SHOULD set PTPv2 Timestamp flag to 0 in Set-Up-Response message in 216 accordance with [RFC5357]. 218 o Control-Client MUST set PTPv2 Timestamp flag value to 1 in Modes 219 field in the Set-Up-Response message if Server advertised ability 220 of the Session-Reflector to use PTPv2 format for timestamps. 221 Otherwise the flag MUST be set to 0. 223 o If the values of PTPv2 Timestamp flag in the Set-Up-Response 224 message equals 0, then that means that Session-Sender can only 225 interpret NTP timestamp format. Then the Session-Reflector MUST 226 use NTP timestamp format. If the Session-Reflector does not 227 support NTP format for timestamps then Server and SHOULD close the 228 TCP connection associated with the TWAMP-Control session. 230 2.3. OWAMP-Test and TWAMP-Test Update 232 Participants of a test session need to indicate which timestamp 233 format being used. The proposal is to use Z field in Error Estimate 234 defined in Section 4.1.2 of [RFC4656]. The new interpretation of the 235 Error Estimate is in addition to it specifying error estimate and 236 synchronization, Error Estimate indicates format of a collected 237 timestamp. And this proposal changes the semantics of the Z bit 238 field, the one between S and Scale fields, to be referred as 239 Timestamp format and value MUST be set according to the following: 241 o 0 - NTP 64 bit format of a timestamp; 243 o 1 - PTPv2 truncated format of a timestamp. 245 As result of this value of the Z field from Error Estimate, Sender 246 Error Estimate or Send Error Estimate and Receive Error Estimate 247 SHOULD NOT be ignored and MUST be used when calculating delay and 248 delay variation metrics based on collected timestamps. 250 2.3.1. Consideration for TWAMP Light mode 252 This document does not specify how Session-Sender and Session- 253 Reflector in TWAMP Light mode are informed of timestamp format to be 254 used. It is assumed that, for example, configuration could be used 255 to direct Session-Sender and Session-Reflector respectively to use 256 timestamp format according to their capabilities and rules listed in 257 Section 2.2. 259 3. IANA Considerations 261 The TWAMP-Modes registry defined in [RFC5618]. 263 IANA is requested to reserve a new PTPv2 Timestamp as follows: 265 +--------------+------------------+---------------------+-----------+ 266 | Value | Description | Semantics | Reference | 267 +--------------+------------------+---------------------+-----------+ 268 | TBA1 | PTPv2 Timestamp | bit position TBA2 | This | 269 | (proposed | Capability | (proposed 8) | document | 270 | 256) | | | | 271 +--------------+------------------+---------------------+-----------+ 273 Table 1: New Timestamp Capability 275 4. Security Considerations 277 Use of particular format of a timestamp in test session does not 278 appear to introduce any additional security threat to hosts that 279 communicate with OWAMP and/or TWAMP as defined in [RFC4656], 280 [RFC5357] respectively. The security considerations that apply to 281 any active measurement of live networks are relevant here as well. 282 See the Security Considerations sections in [RFC4656] and [RFC5357]. 284 5. Acknowledgements 286 The authors would like to thank Lakshmikanthan and Suchit Bansal for 287 their insightful suggestions. The authors would like to thank David 288 Allan for his thorough review and thoughtful comments. 290 6. Normative References 292 [IEEE.1588.2008] 293 "Standard for a Precision Clock Synchronization Protocol 294 for Networked Measurement and Control Systems", 295 IEEE Standard 1588, March 2008. 297 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 298 Requirement Levels", BCP 14, RFC 2119, 299 DOI 10.17487/RFC2119, March 1997, 300 . 302 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 303 Zekauskas, "A One-way Active Measurement Protocol 304 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 305 . 307 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 308 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 309 RFC 5357, DOI 10.17487/RFC5357, October 2008, 310 . 312 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 313 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 314 DOI 10.17487/RFC5618, August 2009, 315 . 317 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 318 "Network Time Protocol Version 4: Protocol and Algorithms 319 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 320 . 322 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 323 Protocol (TWAMP) Reflect Octets and Symmetrical Size 324 Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, 325 . 327 Authors' Addresses 329 Greg Mirsky 330 Ericsson 332 Email: gregory.mirsky@ericsson.com 333 Israel Meilik 334 Broadcom 336 Email: israel@broadcom.com