idnits 2.17.1 draft-ietf-ippm-6man-pdm-option-04.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 (September 13, 2016) is 2783 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) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT N. Elkins 3 Inside Products 4 R. Hamilton 5 Chemical Abstracts Service 6 M. Ackermann 7 Intended Status: Proposed Standard BCBS Michigan 8 Expires: March 17, 2017 September 13, 2016 10 IPv6 Performance and Diagnostic Metrics (PDM) Destination Option 11 draft-ietf-ippm-6man-pdm-option-04 13 Abstract 15 To assess performance problems, measurements based on optional 16 sequence numbers and timing may be embedded in each packet. Such 17 measurements may be interpreted in real-time or after the fact. An 18 implementation of the existing IPv6 Destination Options extension 19 header, the Performance and Diagnostic Metrics (PDM) Destination 20 Options extension header as well as the field limits, calculations, 21 and usage of the PDM in measurement are included in this document. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as 31 Internet-Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/1id-abstracts.html 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 Copyright and License Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 50 3: This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.2 End User Quality of Service (QoS) . . . . . . . . . . . . . 4 65 1.3 Need for a Packet Sequence Number . . . . . . . . . . . . . 5 66 1.4 Rationale for defined solution . . . . . . . . . . . . . . . 5 67 1.5 PDM Works in Collaboration with Other Headers . . . . . . . 6 68 1.6 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6 69 2 Measurement Information Derived from PDM . . . . . . . . . . . . 6 70 2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7 71 2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 72 3 Performance and Diagnostic Metrics Destination Option Layout . . 7 73 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7 74 3.2 Performance and Diagnostic Metrics Destination Option . . . 7 75 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 10 76 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 11 77 3.5 Implementation Considerations . . . . . . . . . . . . . . . 12 78 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 12 79 3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 12 80 4 Considerations of Timing Representation . . . . . . . . . . . . 12 81 4.1 Encoding the Delta-Time Values . . . . . . . . . . . . . . . 12 82 4.2 Timer registers are different on different hardware . . . . 13 83 4.3 Timer Units on Other Systems . . . . . . . . . . . . . . . . 13 84 4.4 Time Base . . . . . . . . . . . . . . . . . . . . . . . . . 14 85 4.5 Timer-value scaling . . . . . . . . . . . . . . . . . . . . 14 86 4.6 Limitations with this encoding method . . . . . . . . . . . 15 87 4.7 Lack of precision induced by timer value truncation . . . . 16 88 5 PDM Flow - Simple Client Server . . . . . . . . . . . . . . . . 17 89 5.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 5.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 91 5.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 5.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 5.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 6 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 21 95 6.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . . . 21 96 6.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . . . 22 97 6.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . . . 23 98 7 Potential Overhead Considerations . . . . . . . . . . . . . . . 25 99 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 26 100 8.1. SYN Flood and Resource Consumption Attacks . . . . . . . . 26 101 8.2 Pervasive monitoring . . . . . . . . . . . . . . . . . . . 26 102 8.3 PDM as a Covert Channel . . . . . . . . . . . . . . . . . . 27 103 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 27 104 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 10.1 Normative References . . . . . . . . . . . . . . . . . . . 28 106 10.2 Informative References . . . . . . . . . . . . . . . . . . 28 107 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 110 1 Background 112 To assess performance problems, measurements based on optional 113 sequence numbers and timing may be embedded in each packet. Such 114 measurements may be interpreted in real-time or after the fact. 116 As defined in RFC2460 [RFC2460], destination options are carried by 117 the IPv6 Destination Options extension header. Destination options 118 include optional information that need be examined only by the IPv6 119 node given as the destination address in the IPv6 header, not by 120 routers or other "middle boxes". This document specifies a new 121 destination option, the Performance and Diagnostic Metrics (PDM) 122 destination option. This document specifies the layout, field 123 limits, calculations, and usage of the PDM in measurement. 125 1.1 Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC 2119 [RFC2119]. 131 1.2 End User Quality of Service (QoS) 133 The timing values in the PDM embedded in the packet will be used to 134 estimate QoS as experienced by an end user device. 136 For many applications, the key user performance indicator is response 137 time. When the end user is an individual, he is generally 138 indifferent to what is happening along the network; what he really 139 cares about is how long it takes to get a response back. But this is 140 not just a matter of individuals' personal convenience. In many 141 cases, rapid response is critical to the business being conducted. 143 When the end user is a device (e.g. with the Internet of Things), 144 what matters is the speed with which requested data can be 145 transferred -- specifically, whether the requested data can be 146 transferred in time to accomplish the desired actions. This can be 147 important when the relevant external conditions are subject to rapid 148 change. 150 Low, reliable and acceptable responses times are not just "nice to 151 have". On many networks, the impact can be financial hardship or 152 endanger human life. In some cities, the emergency police contact 153 system operates over IP, law enforcement uses TCP/IP networks, 154 transactions on our stock exchanges are settled using IP networks. 156 The critical nature of such activities to our daily lives and 157 financial well-being demand a simple solution to support response 158 time measurements. 160 1.3 Need for a Packet Sequence Number 162 While performing network diagnostics of an end-to-end connection, it 163 often becomes necessary to isolate the factors along the network path 164 responsible for problems. Diagnostic data may be collected at 165 multiple places along the path (if possible), or at the source and 166 destination. Then, in post-collection processing, the diagnostic 167 data corresponding to each packet at different observation points 168 must be matched for proper measurements. A sequence number in each 169 packet provides sufficient basis for the matching process. If need 170 be, the timing fields may be used along with the sequence number to 171 ensure uniqueness. 173 This method of data collection along the path is of special use to 174 determine where packet loss or packet corruption is happening. 176 The packet sequence number needs to be unique in the context of the 177 session (5-tuple). See section 2 for a definition of 5-tuple. 179 1.4 Rationale for defined solution 181 The current IPv6 specification does not provide timing nor a similar 182 field in the IPv6 main header or in any extension header. So, we 183 define the IPv6 Performance and Diagnostic Metrics destination option 184 (PDM). 186 Advantages include: 188 1. Real measure of actual transactions. 189 2. Independence from transport layer protocols. 190 3. Ability to span organizational boundaries with consistent 191 instrumentation 192 4. No time synchronization needed between session partners 193 5. Ability to handle all transport protocols (TCP, UDP, SCTP, etc) 194 in a uniform way 196 The PDM provides the ability to quickly determine if the (latency) 197 problem is in the network or in the server (application). More 198 intermediate measurements may be needed if the host or network 199 discrimination is not sufficient. At the client, TCP/IP stack time 200 vs. applications time may still need to be broken out by client 201 software. 203 1.5 PDM Works in Collaboration with Other Headers 205 The purpose of the PDM is not to supplant all the variables present 206 in all other headers but to provide data which is not available or 207 very difficult to get. The way PDM would be used is by a technician 208 (or tool) looking at a packet capture. Within the packet capture, 209 they would have available to them the layer 2 header, IP header (v6 210 or v4), TCP, UCP, ICMP, SCTP or other headers. All information 211 would be looked at together to make sense of the packet flow. The 212 technician or processing tool could analyze, report or ignore the 213 data from PDM, as necessary. 215 For an example of how PDM can help with TCP retransmit problems, 216 please look at section 8. 218 1.6 IPv6 Transition Technologies 220 In the path to full implementation of IPv6, transition technologies 221 such as translation or tunneling may be employed. The PDM header is 222 not expected to work in such scenarios. It is likely that an IPv6 223 packet containing PDM will be dropped if using IPv6 transition 224 technologies. 226 2 Measurement Information Derived from PDM 228 Each packet contains information about the sender and receiver. In IP 229 protocol, the identifying information is called a "5-tuple". 231 The 5-tuple consists of: 233 SADDR : IP address of the sender 234 SPORT : Port for sender 235 DADDR : IP address of the destination 236 DPORT : Port for destination 237 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP, etc.) 239 The PDM contains the following base fields: 241 PSNTP : Packet Sequence Number This Packet 242 PSNLR : Packet Sequence Number Last Received 243 DELTATLR : Delta Time Last Received 244 DELTATLS : Delta Time Last Sent 246 Other fields for scaling and time base are also in the PDM and will 247 be described in section 3. 249 This information, combined with the 5-tuple, allows the measurement 250 of the following metrics: 252 1. Round-trip delay 253 2. Server delay 255 2.1 Round-Trip Delay 257 Round-trip *Network* delay is the delay for packet transfer from a 258 source host to a destination host and then back to the source host. 259 This measurement has been defined, and the advantages and 260 disadvantages discussed in "A Round-trip Delay Metric for IPPM" 261 [RFC2681]. 263 2.2 Server Delay 265 Server delay is the interval between when a packet is received by a 266 device and the first corresponding packet is sent back in response. 267 This may be "Server Processing Time". It may also be a delay caused 268 by acknowledgements. Server processing time includes the time taken 269 by the combination of the stack and application to return the 270 response. The stack delay may be related to network performance. If 271 this aggregate time is seen as a problem, and there is a need to make 272 a clear distinction between application processing time and stack 273 delay, including that caused by the network, then more client based 274 measurements are needed. 276 3 Performance and Diagnostic Metrics Destination Option Layout 278 3.1 Destination Options Header 280 The IPv6 Destination Options Header is used to carry optional 281 information that needs to be examined only by a packet's destination 282 node(s). The Destination Options Header is identified by a Next 283 Header value of 60 in the immediately preceding header and is defined 284 in RFC2460 [RFC2460]. The IPv6 Performance and Diagnostic Metrics 285 Destination Option (PDM) is an implementation of the Destination 286 Options Header. The PDM does not require time synchronization. 288 3.2 Performance and Diagnostic Metrics Destination Option 290 The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) 291 contains the following fields: 293 TIMEBASE : Base timer unit 294 SCALEDTLR: Scale for Delta Time Last Received 295 SCALEDTLS: Scale for Delta Time Last Sent 296 PSNTP : Packet Sequence Number This Packet 297 PSNLR : Packet Sequence Number Last Received 298 DELTATLR : Delta Time Last Received 299 DELTATLS : Delta Time Last Sent 301 The PDM destination option is encoded in type-length-value (TLV) 302 format as follows: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Option Type | Option Length |TB |ScaleDTLR | ScaleDTLS | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | PSN This Packet | PSN Last Received | 310 |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Delta Time Last Received | Delta Time Last Sent | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Option Type 316 TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] 318 Option Length 320 8-bit unsigned integer. Length of the option, in octets, excluding 321 the Option Type and Option Length fields. This field MUST be set to 322 16. 324 Time Base 326 2-bit unsigned integer. It will indicate the lowest granularity 327 possible for this device. That is, for a value of 00 in the Time 328 Base field, a value of 1 in the DELTA fields indicates 1 329 microsecond. 331 This field is being included so that a device may choose the 332 granularity which most suits its timer ticks. That is, so that it 333 does not have to do more work than needed to convert values required 334 for the PDM. 336 The possible values of Time Base are as follows: 338 00 - milliseconds 339 01 - microseconds 340 10 - nanoseconds 341 11 - picoseconds 343 Scale Delta Time Last Received (SCALEDTLR) 345 7-bit signed integer. This is the scaling value for the Delta Time 346 Last Received (DELTATLR) field. The possible values are from -128 to 347 +127. See Section 4 for further discussion on Timing Considerations 348 and formatting of the scaling values. 350 Scale Delta Time Last Sent (SCALEDTLS) 352 7-bit signed integer. This is the scaling value for the Delta Time 353 Last Sent (DELTATLS) field. The possible values are from -128 to 354 +127. 356 Packet Sequence Number This Packet (PSNTP) 358 16-bit unsigned integer. This field will wrap. It is intended for 359 use while analyzing packet traces. 361 Initialized at a random number and incremented monotonically for each 362 packet of the session flow of the 5-tuple. The 5-tuple consists of 363 the source and destination IP addresses, the source and destination 364 ports, and the upper layer protocol (ex. TCP, ICMP, etc). The 365 random number initialization is intended to make it harder to spoof 366 and insert such packets. 368 Operating systems MUST implement a separate packet sequence number 369 counter per 5-tuple. Operating systems MUST NOT implement a single 370 counter for all connections. 372 Packet Sequence Number Last Received (PSNLR) 374 16-bit unsigned integer. This is the PSNTP of the packet last 375 received on the 5-tuple. 377 Delta Time Last Received (DELTATLR) 379 A 16-bit unsigned integer field. The value is set according to the 380 scale in SCALEDTLR. 382 Delta Time Last Received = (Send time packet 2 - Receive time packet 383 1) 384 Delta Time Last Sent (DELTATLS) 386 A 16-bit unsigned integer field. The value is set according to the 387 scale in SCALEDTLS. 389 Delta Time Last Sent = (Receive time packet 2 - Send time packet 1) 391 Option Type 393 The two highest-order bits of the Option Type field are encoded to 394 indicate specific processing of the option; for the PDM destination 395 option, these two bits MUST be set to 00. This indicates the 396 following processing requirements: 398 00 - skip over this option and continue processing the header. 400 RFC2460 [RFC2460] defines other values for the Option Type field. 401 These MUST NOT be used in the PDM. 403 In keeping with RFC2460 [RFC2460], the third-highest-order bit of the 404 Option Type specifies whether or not the Option Data of that option 405 can change en-route to the packet's final destination. 407 In the PDM, the value of the third-highest-order bit MUST be 0. The 408 possible values are as follows: 410 0 - Option Data does not change en-route 412 1 - Option Data may change en-route 414 The three high-order bits described above are to be treated as part 415 of the Option Type, not independent of the Option Type. That is, a 416 particular option is identified by a full 8-bit Option Type, not just 417 the low-order 5 bits of an Option Type. 419 3.3 Header Placement 421 The PDM destination option MUST be placed as follows: 423 - Before the upper-layer header or the ESP header. 425 This follows the order defined in RFC2460 [RFC2460] 427 IPv6 header 429 Hop-by-Hop Options header 430 Destination Options header <-------- 432 Routing header 434 Fragment header 436 Authentication header 438 Encapsulating Security Payload header 440 Destination Options header <------------ 442 upper-layer header 444 Note that there is a choice of where to place the Destination Options 445 header. If using ESP mode, please see section 3.4 of this document 446 for placement of the PDM Destination Options header. 448 For each IPv6 packet header, the PDM MUST NOT appear more than once. 449 However, an encapsulated packet MAY contain a separate PDM associated 450 with each encapsulated IPv6 header. 452 3.4 Header Placement Using IPSec ESP Mode 454 IP Encapsulating Security Payload (ESP) is defined in [RFC4303] and 455 is widely used. Section 3.1.1 of [RFC4303] discusses placement of 456 Destination Options Headers. Below is the diagram from [RFC4303] 457 discussing placement. PDM MUST be placed before the ESP header in 458 order to work. If placed before the ESP header, the PDM header will 459 flow in the clear over the network thus allowing gathering of 460 performance and diagnostic data without sacrificing security. 462 BEFORE APPLYING ESP 464 --------------------------------------- 465 IPv6 | | ext hdrs | | | 466 | orig IP hdr |if present| TCP | Data | 467 --------------------------------------- 469 AFTER APPLYING ESP 470 --------------------------------------------------------- 471 IPv6 | orig |hop-by-hop,dest*,| |dest| | | ESP | ESP| 472 |IP hdr|routing,fragment.|ESP|opt*|TCP|Data|Trailer| ICV| 473 --------------------------------------------------------- 474 |<--- encryption ---->| 475 |<------ integrity ------>| 477 * = if present, could be before ESP, after ESP, or both 479 3.5 Implementation Considerations 481 The PDM destination options extension header SHOULD be turned on by 482 each stack on a host node. It MAY also be turned on only in case of 483 diagnostics needed for problem resolution. 485 3.6 Dynamic Configuration Options 487 If implemented, each operating system MUST have a default 488 configuration parameter, e.g. diag_header_sys_default_value=yes/no. 489 The operating system MAY also have a dynamic configuration option to 490 change the configuration setting as needed. 492 If the PDM destination options extension header is used, then it MAY 493 be turned on for all packets flowing through the host, applied to an 494 upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP 495 address only. These are at the discretion of the implementation. 497 As with all other destination options extension headers, the PDM is 498 for destination nodes only. As specified above, intermediate devices 499 MUST neither set nor modify this field. 501 3.6 5-tuple Aging 503 Within the operating system, metrics must be kept on a 5-tuple basis. 505 The 5-tuple is: 507 SADDR : IP address of the sender SPORT : Port for sender DADDR : IP 508 address of the destination DPORT : Port for destination PROTC : 509 Protocol for upper layer (ex. TCP, UDP, ICMP) 511 The question comes of when to stop keeping data or restarting the 512 numbering for a 5-tuple. For example, in the case of TCP, at some 513 point, the connection will terminate. Keeping data in control blocks 514 forever, will have unfortunate consequences for the operating system. 516 So, the recommendation is to use a known aging parameter such as Max 517 Segment Lifetime (MSL) as defined in Transmission Control Protocol 518 [RFC0793] to reuse or drop the control block. The choice of aging 519 parameter is left up to the implementation. 521 4 Considerations of Timing Representation 523 4.1 Encoding the Delta-Time Values 525 This section makes reference to and expands on the document "Encoding 526 of Time Intervals for the TCP Timestamp Option" [TRAM-TCPM]. 528 4.2 Timer registers are different on different hardware 530 One of the problems with timestamp recording is the variety of 531 hardware that generates the time value to be used. Different CPUs 532 track the time in registers of different sizes, and the most- 533 frequently-iterated bit could be the first on the left or the first 534 on the right. In order to generate some examples here it is necessary 535 to indicate the type of timer register being used. 537 As described in the "IBM z/Architecture Principles of Operation" 538 [IBM-POPS], the Time-Of-Day clock in a zSeries CPU is a 104-bit 539 register, where bit 51 is incremented approximately every 540 microsecond: 542 1 543 0 1 2 3 4 5 6 0 544 +--------+---------+---------+---------+---------+---------+--+...+ 545 | | | | | |* | | 546 +--------+---------+---------+---------+---------+---------+--+...+ 547 ^ ^ ^ 548 0 51 = 1 usec 103 550 To represent these values concisely a hexadecimal representation will 551 be used, where each digit represents 4 binary bits. Thus: 553 0000 0000 0000 0001 = 1 timer unit (2**-12 usec, or about 244 psec) 554 0000 0000 0000 1000 = 1 microsecond 555 0000 0000 003E 8000 = 1 millisecond 556 0000 0000 F424 0000 = 1 second 557 0000 0039 3870 0000 = 1 minute 558 0000 0D69 3A40 0000 = 1 hour 559 0001 41DD 7600 0000 = 1 day 561 Note that only the first 64 bits of the register are commonly 562 represented, as that represents a count of timer units on this 563 hardware. Commonly the first 52 bits are all that are displayed, as 564 that represents a count of microseconds. 566 4.3 Timer Units on Other Systems 568 This encoding method works the same with other hardware clock 569 formats. The method uses a microsecond as the basic value and allows 570 for large time differentials. 572 4.4 Time Base 574 This specification allows for the fact that different CPU TOD clocks 575 use different binary points. For some clocks, a value of 1 could 576 indicate 1 microsecond, whereas other clocks could use the value 1 to 577 indicate 1 millisecond. In the former case, the binary digits to the 578 right of that binary point measure 2**(-n) microseconds, and in the 579 latter case, 2**(-n) milliseconds. 581 The Time Base allows us to ensure we have a common reference, at the 582 very least, common knowledge of what the binary point is for the 583 transmitted values. 585 We define a base unit for the time. This is a 2-bit integer 586 indicating the lowest granularity possible for this device. That is, 587 for a value of 00 in the Time Base field, a value of 1 in the DELTA 588 fields indicates 1 picosecond. 590 The possible values of Time Base are as follows: 592 00 - milliseconds 593 01 - microseconds 594 10 - nanoseconds 595 11 - picoseconds 597 Time base is not necessarily equivalent to length of one timer tick. 598 That is, on many, if not all, systems, the timer tick value will not 599 be in complete units of nanoseconds, milliseconds, etc. For example, 600 on an IBM zSeries machine, one timer tick (or clock unit) is 2 to the 601 -12th microseconds. 603 Therefore, some amount of conversion may be needed to approximate 604 Time Base units. 606 4.5 Timer-value scaling 608 As discussed in [TRAM-TCPM] we define storing not an entire time- 609 interval value, but just the most significant bits of that value, 610 along with a scaling factor to indicate the magnitude of the time- 611 interval value. In our case, we will use the high-order 16 bits. The 612 scaling value will be the number of bits in the timer register to the 613 right of the 16th significant bit. That is, if the timer register 614 contains this binary value: 616 1110100011010100101001010001000000000000 617 <-16 bits -><-24 bits -> 619 then, the values stored would be 1110 1000 1101 0100 in binary (E8D4 620 hexadecimal) for the time value and 24 for the scaling value. Note 621 that the displayed value is the binary equivalent of 1 second 622 expressed in picoseconds. 624 The below table represents a device which has a TimeBase of 625 picosecond (or 00). The smallest and simplest value to represent is 626 1 picosecond; the time value stored is 1, and the scaling value is 0. 627 Using values from the table below, we have: 629 Time value in Encoded Scaling 630 Delta time picoseconds value decimal 631 -------------------------------------------------------- 632 1 picosecond 1 1 0 633 1 nanosecond 3E8 3E8 0 634 1 microsecond F4240 F424 4 635 1 millisecond 3B9ACA00 3B9A 16 636 1 second E8D4A51000 E8D4 24 637 1 minute 3691D6AFC000 3691 32 638 1 hour cca2e51310000 CCA2 36 639 1 day 132f4579c980000 132F 44 640 365 days 1b5a660ea44b80000 1B5A 52 642 Sample binary values (high order 16 bits taken) 644 1 psec 1 0001 645 1 nsec 3E8 0011 1110 1000 646 1 usec F4240 1111 0100 0010 0100 0000 647 1 msec 3B9ACA00 0011 1011 1001 1010 1100 1010 0000 0000 648 1 sec E8D4A51000 1110 1000 1101 0100 1010 0101 0001 0000 0000 0000 650 4.6 Limitations with this encoding method 652 If we follow the specification in [TRAM-TCPM], the size of one of 653 these time-interval fields is limited to this 11-bit value and five- 654 bit scale, so that they fit into a 16-bit space. With that 655 limitation, the maximum value that could be stored in 16 bits is: 657 11-bit value Scale 658 ============= ====== 659 1111 1111 111 1 1111 661 or an encoded value of 3FF and a scale value of 31. This value 662 corresponds to any time differential between: 664 || 665 11 1111 1111 1000 0000 0000 0000 0000 0000 0000 0000 (binary) 666 3 F F 8 0 0 0 0 0 0 0 (hexadecimal) 668 and 670 11 1111 1111 1111 1111 1111 1111 1111 1111 1111 1111 (binary) 671 3 F F F F F F F F F F (hexadecimal) 673 This time value, 3FFFFFFFFFF, converts to 50 days, 21 hours, 40 674 minutes and 46.511103 seconds. A time differential 1 microsecond 675 longer won't fit into 16 bits using this encoding method. 677 4.7 Lack of precision induced by timer value truncation 679 When the bit values following the first 11 significant bits are 680 truncated, obviously loss of precision in the value. The range of 681 values that will be truncated to the same encoded value is 682 2**(Scale)-1 microseconds. 684 The smallest time differential value that will be truncated is 686 1000 0000 0000 = 2.048 msec 688 The value 690 1000 0000 0001 = 2.049 msec 692 will be truncated to the same encoded value, which is 400 in hex, 693 with a scale value of 1. With the scale value of 1, the value range 694 is calculated as 2**1 - 1, or 1 usec, which you can see is the 695 difference between these minimum and maximum values. 697 With that in mind, let's look at that table of delta time values 698 again, where the Precision is the range from the smallest value 699 corresponding to this encoded value to the largest: 701 Time value in Encoded 702 Delta time microseconds value Scale Precision 703 1 microsecond 1 1 0 0:00.000000 704 1 millisecond 38E 38E 0 0:00.000000 705 1 second F4240 7A1 9 0:00.000511 706 1 minute 3938700 727 15 0:00.032767 707 1 hour D693A400 6B4 21 0:02.097151 708 1 day 141DD76000 507 26 1:07.108863 709 Maximum value 3FFFFFFFFFF 7FF 31 35:47.483647 710 So, when measuring the delay between transmission of two packets, or 711 between the reception of two packets, any delay shorter than 50 days 712 21 hours and change can be stored in this encoded fashion within 16 713 bits. When you encode, for example, a DTN response time delay of 50 714 days, 21 hours and 40 minutes, you can be assured of accuracy within 715 35 minutes. 717 5 PDM Flow - Simple Client Server 719 Following is a sample simple flow for the PDM with one packet sent 720 from Host A and one packet received by Host B. The PDM does not 721 require time synchronization between Host A and Host B. The 722 calculations to derive meaningful metrics for network diagnostics are 723 shown below each packet sent or received. 725 Each packet, in addition to the PDM contains information on the 726 sender and receiver. As discussed before, a 5-tuple consists of: 728 SADDR : IP address of the sender 729 SPORT : Port for sender 730 DADDR : IP address of the destination 731 DPORT : Port for destination 732 PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP) 734 It should be understood that the packet identification information is 735 in each packet. We will not repeat that in each of the following 736 steps. 738 5.1 Step 1 740 Packet 1 is sent from Host A to Host B. The time for Host A is set 741 initially to 10:00AM. 743 The time and packet sequence number are saved by the sender 744 internally. The packet sequence number and delta times are sent in 745 the packet. 747 Packet 1 749 +----------+ +----------+ 750 | | | | 751 | Host | ----------> | Host | 752 | A | | B | 753 | | | | 754 +----------+ +----------+ 756 PDM Contents: 758 PSNTP : Packet Sequence Number This Packet: 25 759 PSNLR : Packet Sequence Number Last Received: - 760 DELTATLR : Delta Time Last Received: - 761 SCALEDTLR: Scale of Delta Time Last Received: 0 762 DELTATLS : Delta Time Last Sent: - 763 SCALEDTLS: Scale of Delta Time Last Sent: 0 764 TIMEBASE : Granularity of Time: 00 (Milliseconds) 766 Internally, within the sender, Host A, it must keep: 768 Packet Sequence Number of the last packet sent: 25 769 Time the last packet was sent: 10:00:00 771 Note, the initial PSNTP from Host A starts at a random number. In 772 this case, 25. The time in these examples is shown in seconds for 773 the sake of simplicity. 775 5.2 Step 2 777 Packet 1 is received at Host B. Its time is set to one hour later 778 than Host A. In this case, 11:00AM 780 Internally, within the receiver, Host B, it must note: 782 Packet Sequence Number of the last packet received: 25 783 Time the last packet was received : 11:00:03 785 Note, this timestamp is in Host B time. It has nothing whatsoever to 786 do with Host A time. The Packet Sequence Number of the last packet 787 received will become PSNLR which will be sent out in the packet sent 788 by Host B in the next step. The time last received will be used to 789 calculate the DELTALR value to be sent out in the packet sent by Host 790 B in the next step. 792 5.3 Step 3 794 Packet 2 is sent by Host B to Host A. Note, the initial packet 795 sequence number (PSNTP) from Host B starts at a random number. In 796 this case, 12. Before sending the packet, Host B does a calculation 797 of deltas. Since Host B knows when it is sending the packet, and it 798 knows when it received the previous packet, it can do the following 799 calculation: 801 Sending time : packet 2 - receive time : packet 1 802 We will call the result of this calculation: Delta Time Last Received 803 (DELTATLR) 805 That is: 807 Delta Time Last Received = (Sending time: packet 2 - receive time: 808 packet 1) 810 Note, both sending time and receive time are saved internally in Host 811 B. They do not travel in the packet. Only the Delta is in the 812 packet. 814 Assume that within Host B is the following: 816 Packet Sequence Number of the last packet received: 25 817 Time the last packet was received: 11:00:03 818 Packet Sequence Number of this packet: 12 819 Time this packet is being sent: 11:00:07 821 We can now calculate a delta value to be sent out in the packet. 822 DELTATLR becomes: 824 4 seconds = 11:00:07 - 11:00:03 826 This is the derived metric: Server Delay. The time and scaling 827 factor must be calculated. Then, this value, along with the packet 828 sequence numbers will be sent to Host A as follows: 830 Packet 2 832 +----------+ +----------+ 833 | | | | 834 | Host | <---------- | Host | 835 | A | | B | 836 | | | | 837 +----------+ +----------+ 839 PDM Contents: 841 PSNTP : Packet Sequence Number This Packet: 12 842 PSNLR : Packet Sequence Number Last Received: 25 843 DELTATLR : Delta Time Last Received: 3A35 (4 seconds) 844 SCALEDTLR: Scale of Delta Time Last Received: 25 845 DELTATLS : Delta Time Last Sent: - 846 SCALEDTLS: Scale of Delta Time Last Sent: 0 847 TIMEBASE : Granularity of Time: 00 (Milliseconds) 849 The metric left to be calculated is the Round-Trip Delay. This will 850 be calculated by Host A when it receives Packet 2. 852 5.4 Step 4 854 Packet 2 is received at Host A. Remember, its time is set to one 855 hour earlier than Host B. Internally, it must note: 857 Packet Sequence Number of the last packet received: 12 858 Time the last packet was received : 10:00:12 860 Note, this timestamp is in Host A time. It has nothing whatsoever to 861 do with Host B time. 863 So, now, Host A can calculate total end-to-end time. That is: 865 End-to-End Time = Time Last Received - Time Last Sent 867 For example, packet 25 was sent by Host A at 10:00:00. Packet 12 was 868 received by Host A at 10:00:12 so: 870 End-to-End time = 10:00:12 - 10:00:00 or 12 (Server and Network RT 871 delay combined). This time may also be called total Overall Round- 872 trip time (which includes Network RTT and Host Response Time). 874 This derived metric we will call Delta Time Last Sent (DELTATLS) 876 We can now also calculate round trip delay. The formula is: 878 Round trip delay = (Delta Time Last Sent - Delta Time Last Received) 880 Or: 882 Round trip delay = 12 - 4 or 8 884 Now, the only problem is that at this point all metrics are in Host A 885 only and not exposed in a packet. To do that, we need a third packet. 887 Note: this simple example assumes one send and one receive. That 888 is done only for purposes of explaining the function of the PDM. In 889 cases where there are multiple packets returned, one would take the 890 time in the last packet in the sequence. The calculations of such 891 timings and intelligent processing is the function of post-processing 892 of the data. 894 5.5 Step 5 896 Packet 3 is sent from Host A to Host B. 898 +----------+ +----------+ 899 | | | | 900 | Host | ----------> | Host | 901 | A | | B | 902 | | | | 903 +----------+ +----------+ 905 PDM Contents: 907 PSNTP : Packet Sequence Number This Packet: 26 908 PSNLR : Packet Sequence Number Last Received: 12 909 DELTATLR : Delta Time Last Received: 0 910 SCALEDTLS: Scale of Delta Time Last Received 0 911 DELTATLS : Delta Time Last Sent: 105e (12 seconds) 912 SCALEDTLR: Scale of Delta Time Last Received: 26 913 TIMEBASE : Granularity of Time: 00 (Milliseconds) 915 To calculate Two-Way Delay, any packet capture device may look at 916 these packets and do what is necessary. 918 6 Other Flows 920 What we have discussed so far is a simple flow with one packet sent 921 and one returned. Let's look at how PDM may be useful in other 922 types of flows. 924 6.1 PDM Flow - One Way Traffic 926 The flow on a particular session may not be a send-receive paradigm. 927 Let us consider some other situations. In the case of a one-way 928 flow, one might see the following: 930 Packet Sender PSN PSN Delta Time Delta Time 931 This Packet Last Recvd Last Recvd Last Sent 932 ===================================================================== 933 1 Server 1 0 0 0 934 2 Server 2 0 0 5 935 3 Server 3 0 0 12 936 4 Server 4 0 0 20 938 What does this mean and how is it useful? 939 In a one-way flow, only the Delta Time Last Sent will be seen as 940 used. Recall, Delta Time Last Sent is the difference between the 941 send of one packet from a device and the next. This is a measure of 942 throughput for the sender - according to the sender's point of view. 943 That is, it is a measure of how fast is the application itself (with 944 stack time included) able to send packets. 946 How might this be useful? If one is having a performance issue at 947 the client and sees that packet 2, for example, is sent after 5 948 microseconds from the server but takes 3 minutes to arrive at the 949 destination, then one may safely conclude that there are delays in 950 the path other than at the server which may be causing the delivery 951 issue of that packet. Such delays may include the network links, 952 middle-boxes, etc. 954 Now, true one-way traffic is quite rare. What people often mean by 955 "one-way" traffic is an application such as FTP where a group of 956 packets (for example, a TCP window size worth) is sent, then the 957 sender waits for acknowledgment. This type of flow would actually 958 fall into the "multiple-send" traffic model. 960 6.2 PDM Flow - Multiple Send Traffic 962 Assume that two packets are sent for each ACK from the server. For 963 example, a TCP flow will do this, per RFC1122 [RFC1122] Section- 964 4.2.3. 966 Packet Sender PSN PSN Delta Time Delta Time 967 This Packet Last Recvd Last Recvd Last Sent 968 ===================================================================== 969 1 Server 1 0 0 0 970 2 Server 2 0 0 5 971 3 Client 1 2 20 0 972 4 Server 3 1 10 15 974 How might this be used? 976 Notice that in packet 3, the client has a value of Delta Time Last 977 received of 20. Recall that Delta Time Last Received is the Send 978 time of packet 3 - receive time of packet 2. So, what does one know 979 now? In this case, Delta Time Last Received is the processing time 980 for the Client to send the next packet. 982 How to interpret this depends on what is actually being sent. 983 Remember, PDM is not being used in isolation, but to supplement the 984 fields found in other headers. Let's take some examples: 986 1. Client is sending a standalone TCP ACK. One would find this by 987 looking at the payload length in the IPv6 header and the TCP 988 Acknowledgement field in the TCP header. So, in this case, the 989 client is taking 20 units to send back the ACK. This may or may not 990 be interesting. 992 2. Client is sending data with the packet. Again, one would find 993 this by looking at the payload length in the IPv6 header and the TCP 994 Acknowledgement field in the TCP header. So, in this case, the 995 client is taking 20 units to send back data. This may represent 996 "User Think Time". Again, this may or may not be interesting, in 997 isolation. But, if there is a performance problem receiving data at 998 the server, then taken in conjunction with RTT or other packet timing 999 information, this information may be quite interesting. 1001 Of course, one also needs to look at the PSN Last Received field to 1002 make sure of the interpretation of this data. That is, to make 1003 sure that the Delta Last Received corresponds to the packet of 1004 interest. 1006 The benefits of PDM are that we have such information available in a 1007 uniform manner for all applications and all protocols without 1008 extensive changes required to applications. 1010 6.3 PDM Flow - Multiple Send with Errors 1012 Let us now look at a case of how PDM may be able to help in a case of 1013 TCP retransmission and add to the information that is sent in the TCP 1014 header. 1016 Assume that three packets are sent with each send from the server. 1018 From the server, this is what is seen. 1020 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 1021 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 1022 ===================================================================== 1023 1 Server 1 0 0 0 123 100 1024 2 Server 2 0 0 5 223 100 1025 3 Server 3 0 0 5 333 100 1027 The client, however, does not receive all the packets. From the 1028 client, this is what is seen for the packets sent from the server. 1030 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 1031 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 1032 ===================================================================== 1033 1 Server 1 0 0 0 123 100 1034 2 Server 3 0 0 5 333 100 1036 Let's assume that the server now retransmits the packet. 1037 (Obviously, a duplicate acknowledgment sequence for fast retransmit 1038 or a retransmit timeout would occur. To illustrate the point, these 1039 packets are being left out.) 1041 So, then if a TCP retransmission is done, then from the client, this 1042 is what is seen for the packets sent from the server. 1044 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 1045 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 1046 ===================================================================== 1047 1 Server 4 0 0 30 223 100 1049 The server has resent the old packet 2 with TCP sequence number of 1050 223. The retransmitted packet now has a PSN This Packet value of 4. 1051 The Delta Last Sent is 30 - the time between sending the packet with 1052 PSN of 3 and this current packet. 1054 Let's say that packet 4 is lost again. Then, after some amount of 1055 time (RTO) then the packet with TCP sequence number of 223 is resent. 1057 From the client, this is what is seen for the packets sent from the 1058 server. 1060 Pkt Sender PSN PSN Delta Time Delta Time TCP Data 1061 This Pkt LastRecvd LastRecvd LastSent SEQ Bytes 1062 ===================================================================== 1063 1 Server 5 0 0 60 223 100 1065 If now, this packet arrives at the destination, one has a very good 1066 idea that packets exist which are being sent from the server as 1067 retransmissions and not arriving at the client. This is because the 1068 PSN of the resent packet from the server is 5 rather than 4. If we 1069 had used TCP sequence number alone, we would never have seen this 1070 situation. The TCP sequence number in all situations is 223. 1072 This situation would be experienced by the user of the application 1073 (the human being actually sitting somewhere) as a "hangs" or long 1074 delay between packets. On large networks, to diagnose problems such 1075 as these where packets are lost somewhere on the network, one has to 1076 take multiple traces to find out exactly where. 1078 The first thing is to start with doing a trace at the client and the 1079 server. So, we can see if the server sent a particular packet and 1080 the client received it. If the client did not receive it, then we 1081 start tracking back to trace points at the router right after the 1082 server and the router right before the client. Did they get these 1083 packets which the server has sent? This is a time consuming 1084 activity. 1086 With PDM, we can speed up the diagnostic time because we may be able 1087 to use only the trace taken at the client to see what the server is 1088 sending. 1090 7 Potential Overhead Considerations 1092 Questions have been posed as to the potential overhead of PDM. 1093 First, PDM is entirely optional. That is, a site may choose to 1094 implement PDM or not as they wish. If they are happy with the costs 1095 of PDM vs. the benefits, then the choice should be theirs. 1097 Below is a table outlining the potential overhead in terms of 1098 additional time to deliver the response to the end user for various 1099 assumed RTTs. 1101 Bytes RTT Bytes Bytes New Overhead 1102 in Packet Per Milli in PDM RTT 1103 ===================================================================== 1104 1000 1000 milli 1 16 1016.000 16.000 milli 1105 1000 100 milli 10 16 101.600 1.600 milli 1106 1000 10 milli 100 16 10.160 .160 milli 1107 1000 1 milli 1000 16 1.016 .016 milli 1109 Below are some examples of actual RTTs for packets traversing large 1110 enterprise networks. The first example is for packets going to 1111 multiple business partners. 1113 Bytes RTT Bytes Bytes New Overhead 1114 in Packet Per Milli in PDM RTT 1115 ===================================================================== 1116 1000 17 milli 58 16 17.360 .360 milli 1118 The second example is for packets at a large enterprise customer 1119 within a data center. Notice that the scale is now in microseconds 1120 rather than milliseconds. 1122 Bytes RTT Bytes Bytes New Overhead 1123 in Packet Per Micro in PDM RTT 1124 ===================================================================== 1125 1000 20 micro 50 16 20.320 .320 micro 1127 8 Security Considerations 1129 PDM does not introduce any new security weakness. 1131 8.1. SYN Flood and Resource Consumption Attacks 1133 PDM needs to calculate the deltas for time and keep track of the 1134 sequence numbers. This means that control blocks must be kept at the 1135 end hosts per 5-tuple. Any time a control block is kept, an 1136 attacker can try to mis-use the control blocks such that there is a 1137 compromise of the end host. 1139 PDM is used only at the end hosts and the control blocks are only 1140 kept at the end host and not at routers or middle boxes. Remember, 1141 PDM is an implementation of the Destination Option extension header. 1143 A "SYN flood" type of attack succeeds because a TCP SYN packet is 1144 small but it causes the end host to start creating a place holder for 1145 the session such that quite a bit of control block and other storage 1146 is used. This is an asynchronous type of attack in that a small 1147 amount of work by the attacker creates a large amount of work by the 1148 resource attacked. 1150 For PDM, the amount of data to be kept is quite small. That is, the 1151 control block is quite lightweight. Concerns about SYN Flood and 1152 other type of resource consumption attacks (memory, processing power, 1153 etc) can be alleviated by having a limit on the size of the control 1154 block. 1156 We recommend that implementation of PDM SHOULD have a limit on the 1157 size of the control blocks used. 1159 8.2 Pervasive monitoring 1161 Since PDM passes in the clear, a concern arises as to whether the 1162 data can be used to fingerprint the system or somehow obtain 1163 information about the contents of the payload. 1165 Let us discuss fingerprinting of the end host first. It is possible 1166 that seeing the pattern of deltas or the absolute values could give 1167 some information as to the speed of the end host - that is, if it is 1168 a very fast system or an older, slow device. This may be useful to 1169 the attacker. However, if the attacker has access to PDM, the 1170 attacker also has access to the entire packet and could make such a 1171 deduction based merely on the time frames elapsed between packets 1172 WITHOUT PDM. 1174 As far as deducing the content of the payload, it appears to us that 1175 PDM is quite unhelpful in this regard. 1177 8.3 PDM as a Covert Channel 1179 PDM provides a set of fields in the packet which could be used to 1180 leak data. But, there is no real reason to suspect that PDM would 1181 be chosen rather than another part of the payload or another 1182 Extension Header. 1184 A firewall or another device could sanity check the fields within the 1185 PDM but randomly assigned sequence numbers and delta times might be 1186 expected to vary widely. The biggest problem though is how an 1187 attacker would get access to PDM in the first place to leak data. 1188 The attacker would have to either compromise the end host or have Man 1189 in the Middle (MitM). It is possible that either one could change 1190 the fields. But, then the other end host would get sequence numbers 1191 and deltas that don't make any sense. Presumably, one is using PDM 1192 and doing packet tracing for diagnostic purposes, so the changes 1193 would be obvious. It is conceivable that someone could compromise 1194 an end host and make it start sending packets with PDM without the 1195 knowledge of the host. But, again, the bigger problem is the 1196 compromise of the end host. Once that is done, the attacker 1197 probably has better ways to leak data. 1199 Having said that, an implementation SHOULD stop using PDM if it gets 1200 some number of "nonsensical" sequence numbers. 1202 9 IANA Considerations 1204 This draft requests an Option Type assignment in the Destination 1205 Options and Hop-by-Hop Options sub-registry of Internet Protocol 1206 Version 6 (IPv6) Parameters [ref to RFCs and URL below]. 1208 http://www.iana.org/assignments/ipv6-parameters/ipv6- 1209 parameters.xhtml#ipv6-parameters-2 1211 Hex Value Binary Value Description Reference 1212 act chg rest 1213 ------------------------------------------------------------------- 1214 TBD TBD Performance and [This draft] 1215 Diagnostic Metrics 1216 (PDM) 1218 10 References 1220 10.1 Normative References 1222 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 1223 793, September 1981. 1225 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 1226 Communication Layers", RFC 1122, October 1989. 1228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1229 Requirement Levels", BCP 14, RFC 2119, March 1997. 1231 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1232 (IPv6) Specification", RFC 2460, December 1998. 1234 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1235 Delay Metric for IPPM", RFC 2681, September 1999. 1237 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 1238 Values In the Internet Protocol and Related Headers", BCP 37, RFC 1239 2780, March 2000. 1241 [RFC4303] Kent, S, "IP Encapsulating Security Payload (ESP)", RFC 1242 4303, December 2005. 1244 10.2 Informative References 1246 [TRAM-TCPM] Trammel, B., "Encoding of Time Intervals for the TCP 1247 Timestamp Option-01", Internet Draft, July 2013. [Work in Progress] 1249 [IBM-POPS] IBM Corporation, "IBM z/Architecture Principles of 1250 Operation", SA22-7832, 1990-2012 1252 11 Acknowledgments 1254 The authors would like to thank Keven Haining, Al Morton, Brian 1255 Trammel, David Boyes, Bill Jouris, Richard Scheffenegger, and Rick 1256 Troth for their comments and assistance. 1258 Authors' Addresses 1260 Nalini Elkins 1261 Inside Products, Inc. 1262 36A Upper Circle 1263 Carmel Valley, CA 93924 1264 United States 1265 Phone: +1 831 659 8360 1266 Email: nalini.elkins@insidethestack.com 1267 http://www.insidethestack.com 1269 Robert Hamilton 1270 Chemical Abstracts Service 1271 A Division of the American Chemical Society 1272 2540 Olentangy River Road 1273 Columbus, Ohio 43202 1274 United States 1275 Phone: +1 614 447 3600 x2517 1276 Email: rhamilton@cas.org 1277 http://www.cas.org 1279 Michael S. Ackermann 1280 Blue Cross Blue Shield of Michigan 1281 P.O. Box 2888 1282 Detroit, Michigan 48231 1283 United States 1284 Phone: +1 310 460 4080 1285 Email: mackermann@bcbsm.com 1286 http://www.bcbsm.com