idnits 2.17.1 draft-ietf-ippm-twamp-time-format-05.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 (March 12, 2017) is 2599 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 ZTE Corp. 4 Intended status: Standards Track I. Meilik 5 Expires: September 13, 2017 Broadcom 6 March 12, 2017 8 Support of IEEE-1588 time stamp format in Two-Way Active Measurement 9 Protocol (TWAMP) 10 draft-ietf-ippm-twamp-time-format-05 12 Abstract 14 This document describes an OPTIONAL feature for active performance 15 measurement protocols allowing use of the Precision Time Protocol 16 time stamp format defined in IEEE-1588v2-2008, as an alternative to 17 the Network Time Protocol that is currently used. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 13, 2017. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions used in this document . . . . . . . . . . . . 3 55 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 56 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 57 2. OWAMP and TWAMP Extensions . . . . . . . . . . . . . . . . . 3 58 2.1. Timestamp Format Negotiation in Setting Up Connection in 59 OWAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Timestamp Format Negotiation in Setting Up Connection in 61 TWAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3. OWAMP-Test and TWAMP-Test Update . . . . . . . . . . . . 5 63 2.3.1. Consideration for TWAMP Light mode . . . . . . . . . 6 64 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 70 1. Introduction 72 One-Way Active Measurement Protocol (OWAMP) [RFC4656] defines that 73 only the NTP [RFC5905] format of a time stamp can be used in OWAMP- 74 Test protocol. Two-Way Active Measurement Protocol (TWAMP) [RFC5357] 75 adopted the OWAMP-Test packet format and extended it by adding a 76 format for a reflected test packet. Both the sender's and 77 reflector's packets time stamps are expected to follow the 64-bit 78 long NTP format [RFC5905]. NTP, when used over Internet, typically 79 achieves clock accuracy of about 5ms to 100ms. Surveys conducted 80 recently suggest that 90% devices achieve accuracy of better than 100 81 ms and 99% - better than 1 sec. It should be noted that NTP 82 synchronizes clocks on the control plane, not on data plane. 83 Distribution of clock within a node may be supported by independent 84 NTP domain or via interprocess communication in multiprocessor 85 distributed system. Any of the mentioned solutions will be subject 86 to additional queuing delays that negatively affect data plane clock 87 accuracy. 89 Precision Time Protocol (PTP) [IEEE.1588.2008] has gained wide 90 support since the development of OWAMP and TWAMP. PTP, using on-path 91 support and other mechanisms, allows sub-microsecond clock accuracy. 92 PTP is now supported in multiple implementations of fast forwarding 93 engines and thus accuracy achieved by PTP is the accuracy of clock in 94 data plane. An option to use a more accurate clock as a source of 95 time stamps for IP performance measurements is one of this 96 specification's advantages. Another advantage is realized by 97 simplification of hardware in data plane. To support OWAMP or TWAMP 98 test protocol time stamps must be converted from PTP to NTP. That 99 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 specification is not only to allow end- 106 points of a test session to use timestamp format other than NTP but 107 to support backwards compatibility with nodes that do not yet support 108 this extension. 110 1.1. Conventions used in this document 112 1.1.1. Terminology 114 IPPM: IP Performance Measurement 116 NTP: Network Time Protocol 118 PTP: Precision Time Protocol 120 TWAMP: Two-Way Active Measurement Protocol 122 OWAMP: One-Way Active Measurement Protocol 124 1.1.2. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 [RFC2119]. 131 2. OWAMP and TWAMP Extensions 133 OWAMP connection establishment follows the procedure defined in 134 Section 3.1 of [RFC4656] and additional steps in TWAMP described in 135 Section 3.1 of [RFC5357]. In these procedures, the Modes field has 136 been used to identify and select specific communication capabilities. 137 At the same time the Modes field has been recognized and used as 138 extension mechanism [RFC6038]. The new feature requires one bit 139 position for Server and Control-Client to negotiate which timestamp 140 format can be used in some or all test sessions invoked with this 141 control connection. The end-point of the test session, Session- 142 Sender and Session-Receiver or Session-Reflector, that supports this 143 extension MUST be capable to interpret NTP and PTPv2 timestamp 144 formats. If the end-point does not support this extension, then the 145 value of PTPv2 Timestamp flag MUST be 0 because it is in Must Be Zero 146 field. If the value of PTPv2 Timestamp flags is 0, then the 147 advertising node can use and interpret only NTP timestamp format. 149 Use of PTPv2 Timestamp flags is discussed in the following sub- 150 sections. For details on the assigned values and bit positions see 151 the Section 3. 153 2.1. Timestamp Format Negotiation in Setting Up Connection in OWAMP 155 In OWAMP-Test [RFC4656] the Session-Receiver and/or Fetch-Client 156 interpret collected timestamps. Thus, the Server uses the Modes 157 field timestamp format to indicate which formats the Session-Receiver 158 is capable to interpret. The Control-Client inspects values set by 159 the Server for timestamp formats and sets values in the Modes field 160 of the Set-Up-Response message according to timestamp formats 161 Session-Sender can use. The rules of setting timestamp flags in 162 Modes field in server greeting and Set-Up-Response messages and 163 interpreting them are as follows: 165 o If the Session-Receiver supports this extension, then the Server 166 that establishes test sessions on its behalf MUST set PTPv2 167 Timestamp flag to 1 in the server greeting message per the 168 requirement listed in Section 2. Otherwise, the PTPv2 Timestamp 169 flag will be set to 0 to indicate that the Session-Receiver 170 interprets only NTP format. 172 o If the Control-Client receives greeting message with the PTPv2 173 Timestamp flag set to 0, then the Session-Sender MUST use NTP 174 format for timestamp in the test session and Control-Client SHOULD 175 set PTPv2 Timestamp flag to 0 in accordance with [RFC4656]. If 176 the Session-Sender cannot use NTP timestamps, then the Control- 177 Client SHOULD close the TCP connection associated with the OWAMP- 178 Control session. 180 o If the Control-Client receives greeting message with the PTPv2 181 Timestamp flag set to 1 and the Session-Sender can set timestamp 182 in PTPv2 format, then the Control-Client MUST set the PTPv2 183 Timestamp flag to 1 in Modes field in the Set-Up-Response message 184 and the Session-Sender MUST use PTPv2 timestamp format. 186 o If the Session-Sender doesn't support this extension and can set 187 timestamp only in NTP format, then the PTPv2 Timestamp flag in 188 Modes field in the Set-Up-Response message will be set to 0 as 189 part of Must Be Zero and the Session-Sender use NTP format. 191 If OWAMP-Control uses Fetch-Session commands, then selection and use 192 of one or another timestamp format is local decision for both 193 Session-Sender and Session-Receiver. 195 2.2. Timestamp Format Negotiation in Setting Up Connection in TWAMP 197 In TWAMP-Test [RFC5357] the Session-Sender interprets collected 198 timestamps. Hence, in the Modes field a Server advertises timestamp 199 formats that the Session-Reflector can use in TWAMP-Test message. 200 The choice of the timestamp format to be used by the Session-Sender 201 is a local decision. The Control-Client inspects the Modes field and 202 sets timestamp flags values to indicate which format will be used by 203 the Session-Reflector. The rules of setting and interpreting flag 204 values are as follows: 206 o Server MUST set to 1 value of PTPv2 Timestamp flag in its greeting 207 message if Session-Reflector can set timestamp in PTPv2 format. 208 Otherwise the PTPv2 Timestamp flag MUST be set to 0. 210 o If value of the PTPv2 Timestamp flag in received server greeting 211 message equals 0, then Session-Reflector does not support this 212 extension and will use NTP timestamp format. Control-Client 213 SHOULD set PTPv2 Timestamp flag to 0 in Set-Up-Response message in 214 accordance with [RFC5357]. 216 o Control-Client MUST set PTPv2 Timestamp flag value to 1 in Modes 217 field in the Set-Up-Response message if Server advertised ability 218 of the Session-Reflector to use PTPv2 format for timestamps. 219 Otherwise the flag MUST be set to 0. 221 o If the values of PTPv2 Timestamp flag in the Set-Up-Response 222 message equals 0, then that means that Session-Sender can only 223 interpret NTP timestamp format. Then the Session-Reflector MUST 224 use NTP timestamp format. If the Session-Reflector does not 225 support NTP format then Server and MUST close the TCP connection 226 associated with the TWAMP-Control session. 228 2.3. OWAMP-Test and TWAMP-Test Update 230 Participants of a test session need to indicate which timestamp 231 format being used. The specification is to use Z field in Error 232 Estimate defined in Section 4.1.2 of [RFC4656]. The new 233 interpretation of the Error Estimate is in addition to it specifying 234 error estimate and synchronization, Error Estimate indicates format 235 of a collected timestamp. And this specification changes the 236 semantics of the Z bit field, the one between S and Scale fields, to 237 be referred as Timestamp format and value MUST be set per the 238 following: 240 o 0 - NTP 64 bit format of a timestamp; 242 o 1 - PTPv2 truncated format of a timestamp. 244 As result of this value of the Z field from Error Estimate, Sender 245 Error Estimate or Send Error Estimate and Receive Error Estimate 246 SHOULD NOT be ignored and MUST be used when calculating delay and 247 delay variation metrics based on collected timestamps. 249 2.3.1. Consideration for TWAMP Light mode 251 This document does not specify how Session-Sender and Session- 252 Reflector in TWAMP Light mode are informed of timestamp format to be 253 used. It is assumed that, for example, configuration could be used 254 to direct Session-Sender and Session-Reflector respectively to use 255 timestamp format per their capabilities and rules listed in 256 Section 2.2. 258 3. IANA Considerations 260 The TWAMP-Modes registry defined in [RFC5618]. 262 IANA is requested to reserve a new PTPv2 Timestamp as follows: 264 +--------------+------------------+---------------------+-----------+ 265 | Value | Description | Semantics | Reference | 266 +--------------+------------------+---------------------+-----------+ 267 | TBA1 | PTPv2 Timestamp | bit position TBA2 | This | 268 | (proposed | Capability | (proposed 8) | document | 269 | 256) | | | | 270 +--------------+------------------+---------------------+-----------+ 272 Table 1: New Timestamp Capability 274 4. Security Considerations 276 Use of particular format of a timestamp in test session does not 277 appear to introduce any additional security threat to hosts that 278 communicate with OWAMP and/or TWAMP as defined in [RFC4656], 279 [RFC5357] respectively. The security considerations that apply to 280 any active measurement of live networks are relevant here as well. 281 See the Security Considerations sections in [RFC4656] and [RFC5357]. 283 5. Acknowledgements 285 The authors would like to thank Lakshmikanthan and Suchit Bansal for 286 their insightful suggestions. The authors would like to thank David 287 Allan for his thorough review and thoughtful comments. 289 6. Normative References 291 [IEEE.1588.2008] 292 "Standard for a Precision Clock Synchronization Protocol 293 for Networked Measurement and Control Systems", 294 IEEE Standard 1588, March 2008. 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 302 Zekauskas, "A One-way Active Measurement Protocol 303 (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, 304 . 306 [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. 307 Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", 308 RFC 5357, DOI 10.17487/RFC5357, October 2008, 309 . 311 [RFC5618] Morton, A. and K. Hedayat, "Mixed Security Mode for the 312 Two-Way Active Measurement Protocol (TWAMP)", RFC 5618, 313 DOI 10.17487/RFC5618, August 2009, 314 . 316 [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, 317 "Network Time Protocol Version 4: Protocol and Algorithms 318 Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, 319 . 321 [RFC6038] Morton, A. and L. Ciavattone, "Two-Way Active Measurement 322 Protocol (TWAMP) Reflect Octets and Symmetrical Size 323 Features", RFC 6038, DOI 10.17487/RFC6038, October 2010, 324 . 326 Authors' Addresses 328 Greg Mirsky 329 ZTE Corp. 331 Email: gregimirsky@gmail.com 332 Israel Meilik 333 Broadcom 335 Email: israel@broadcom.com