INTERNET-DRAFT N. Elkins Inside Products R. Hamilton Chemical Abstracts Service M. Ackermann Intended Status: Proposed Standard BCBS Michigan Expires: March 2015 September 8, 2014 IPv6 Performance and Diagnostic Metrics Destination Option draft-elkins-6man-ipv6-pdm-dest-option-07 Abstract To measure performance and to diagnose performance and connectivity problems, metrics embedded in each packet are critical for timely and accurate problem resolution. Such diagnostics may be interpreted in real-time or after the fact. The base metrics are: packet sequence number and packet timing. Metrics derived from these will be described separately. This document describes a new implementation of the existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Elkins Expires March 12, 2015 [Page 1] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-07 August 2014 Copyright and License Notice Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Performance and Diagnostic Metrics Destination Option . . . . . 3 2.1 Destination Options Header . . . . . . . . . . . . . . . . 3 2.2 Performance and Diagnostic Metrics Destination Option . . . 4 2.3 Timer-value scaling . . . . . . . . . . . . . . . . . . . . 7 2.4 Header Placement . . . . . . . . . . . . . . . . . . . . . 8 2.5 Implementation Considerations . . . . . . . . . . . . . . . 9 2.5.1 Dynamic Configuration Options . . . . . . . . . . . . . 9 2.5.2 Data Length Filtering . . . . . . . . . . . . . . . . . 9 2.5.3 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . 9 3 Backward Compatibility . . . . . . . . . . . . . . . . . . . . 10 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 10 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 10 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Informative References . . . . . . . . . . . . . . . . . . . 11 7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Elkins Expires March 12, 2015 [Page 2] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-07 August 2014 1 Introduction To measure performance and to diagnose performance and connectivity problems, metrics embedded in each packet are critical for timely and accurate problem resolution. Such diagnostics may be interpreted in real-time or after the fact. The base metrics are: packet sequence number and packet timing. Metrics derived from these will be described separately. This document describes a new implementation of an existing IPv6 Destination Options extension header, the Performance and Diagnostic Metrics (PDM) Destination Options extension header. For the rationale and usage of the PDM extension header, see "IPPM Considerations for the IPv6 PDM Destination Option" [ELK-IPPM]. [ELK-IPPM] discusses measurement of end-user Quality of Experience (QoE) as well as the details of the scaling factors used. The current document describes the fields in the PDM header itself. As defined in RFC2460 [RFC2460], destination options are carried by the IPv6 Destination Options extension header. Destination options include optional information that need be examined only by the IPv6 node given as the destination address in the IPv6 header, not by routers or other "middle boxes". This document specifies a new destination option, the Performance and Diagnostic Metrics (PDM) destination option. 1.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 RFC 2119 [RFC2119]. 2 Performance and Diagnostic Metrics Destination Option 2.1 Destination Options Header The IPv6 Destination Options Header is used to carry optional information that need be examined only by a packet's destination node(s). The Destination Options Header is identified by a Next Header value of 60 in the immediately preceding header and is defined in RFC2460 [RFC2460]. The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) is an implementation of the IPv6 Destination Options extension header (Next Header value = 60). The PDM does not require time synchronization. Elkins Expires March 12, 2015 [Page 3] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-07 August 2014 2.2 Performance and Diagnostic Metrics Destination Option The Performance and Diagnostic Metrics Destination Option (PDM) contains the following fields: TIMEBASE : Base timer unit SCALEDL : Scale for Delta Last Received SCALEDS : Scale for Delta Last Sent PSNTP : Packet Sequence Number This Packet PSNLR : Packet Sequence Number Last Received DELTALR : Delta Last Received DELTALS : Delta Last Sent For a full explanation of the SCALEDL, SCALEDS, DELTALR, DELTALS fields, see [ELK-IPPM]. The PDM destination option is encoded in type-length-value (TLV) format as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length |TB |ScaleDL | ScaleDS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN This Packet | PSN Last Received | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Delta Last Received | Delta Last Sent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Type TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780] Option Length 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields. This field MUST be set to 16. Time Base 2-bit unsigned integer. It will indicate the lowest granularity possible for this device. That is, for a value of 00 in the Time Base field, a value of 1 in the DELTA fields indicates 1 picosecond. Elkins Expires March 12, 2015 [Page 4] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-07 August 2014 The possible values of Time Base are as follows: 00 - picoseconds 01 - nanoseconds 10 - microseconds 11 - milliseconds Packet Sequence Number This Packet (PSNTP) 16-bit unsigned integer. This field will wrap. It is intended for human use. Initialized at a random number and monotonically incremented for packet on the 5-tuple. The 5-tuple consists of the source and destination IP addresses, the source and destination ports, and the upper layer protocol (ex. TCP, ICMP, etc). Operating systems MUST implement a separate packet sequence number counter per 5-tuple. Operating systems MUST NOT implement a single counter for all connections. Note: This is consistent with the current implementation of the IPID field in IPv4 for many, but not all, stacks. Packet Sequence Number Last Received (PSNLR) 16-bit unsigned integer. This is the PSN of the packet last received on the 5-tuple. Scale Delta Last Received (SCALEDLR) 7-bit signed integer. This is the scaling value for the Delta Last Received (DELTALR) field. The possible values are from -64 to +63. Scale Delta Last Sent (SCALEDLS) 7-bit signed integer. This is the scaling value for the Delta Last Sent (DELTALS) field. The possible values are from -64 to +63. Delta Last Received (DELTALR) A 16-bit unsigned integer field. DELTALR = Send time packet 2 - Receive time packet 1 Elkins Expires March 12, 2015 [Page 5] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-07 August 2014 The value is according to the scale in SCALEDLR. Delta Last Sent (DELTALS) A 16-bit unsigned integer field. Delta Last Sent = Receive time packet 2 - Send time packet 1 The value is in according to the scale in SCALEDLS. Option Type The two highest-order bits of the Option Type field are encoded to indicate specific processing of the option; for the PDM destination option, these two bits MUST be set to 00. This indicates the following processing requirements: 00 - skip over this option and continue processing the header. RFC2460 [RFC2460] defines other values for the Option Type field. These MUST NOT be used in the PDM. The other values are as follows: 01 - discard the packet. 10 - discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. 11 - discard the packet and, only if the packet's Destination Address was not a multicast address, send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. In keeping with RFC2460 [RFC2460], the third-highest-order bit of the Option Type specifies whether or not the Option Data of that option can change en-route to the packet's final destination. In the PDM, the value of the third-highest-order bit MUST be 0. The possible values are as follows: 0 - Option Data does not change en-route 1 - Option Data may change en-route Elkins Expires March 12, 2015 [Page 6] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-07 August 2014 The three high-order bits described above are to be treated as part of the Option Type, not independent of the Option Type. That is, a particular option is identified by a full 8-bit Option Type, not just the low-order 5 bits of an Option Type. 2.3 Timer-value scaling As discussed in [TRAM-TCPM] we propose storing not an entire time- interval value, but just the most significant bits of that value, along with a scaling factor to indicate the magnitude of the time- interval value. In our case, we will use the high-order 16 bits. The scaling value will be the number of bits in the timer register to the right of the 16th significant bit. That is, if the timer register contains this binary value: 1110100011010100101001010001000000000000 <-16 bits -><-24 bits -> then, the values stored would be 1110 1000 1101 0100 in binary (E8D4 hexadecimal) for the time value and 24 for the scaling value. Note that the displayed value is the binary equivalent of 1 second expressed in picoseconds. The below table represents a device which has a TimeBase of picosecond (or 00) The smallest and simplest value to represent is 1 picosecond; the time value stored is 1, and the scaling value is 0. Using values from the table below, we have: Time value in Encoded Scaling Delta time picoseconds value decimal -------------------------------------------------------- 1 picosecond 1 1 0 1 millisecond 3E8 3E8 0 1 microsecond F4240 F424 4 1 millisecond 3B9ACA00 3B9A 16 1 second E8D4A51000 E8D4 24 1 minute 3691D6AFC000 3691 32 1 hour cca2e51310000 CCA2 36 1 day 132f4579c980000 132F 44 365 days 1b5a660ea44b80000 1B5A 52 Sample binary values (high order 16 bits taken) 1 pico 1 0001 Elkins Expires March 12, 2015 [Page 7] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-07 August 2014 1 nanos 3E8 0011 1110 1000 1 micro F4240 1111 0100 0010 0100 0000 1 milli 3B9ACA00 0011 1011 1001 1010 1100 1010 0000 0000 1 sec. E8D4A51000 1110 1000 1101 0100 1010 0101 0001 0000 0000 0000 For further discussion on timing and scaling, please see "IPPM Considerations for the IPv6 PDM Destination Option" [ELK-IPPM]. 2.4 Header Placement The PDM destination option MUST be placed as follows: - Before the upper-layer header. That is, this is the last extension header. This follows the order defined in RFC2460 [RFC2460] IPv6 header Hop-by-Hop Options header Destination Options header Routing header Fragment header Authentication header Encapsulating Security Payload header Destination Options header upper-layer header For each IPv6 packet header, the PDM MUST NOT appear more than once. However, an encapsulated packet MAY contain a separate PDM associated with each encapsulated IPv6 header. The inclusion of a PDM in a packet affects the receiving node's processing of only this single packet. No state is created or modified in the receiving node as a result of receiving a PDM in a packet. Elkins Expires March 12, 2015 [Page 8] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-07 August 2014 2.5 Implementation Considerations The PDM destination options extension header SHOULD be turned on by each stack on a host node. 2.5.1 Dynamic Configuration Options If implemented, each operating system MUST have a default configuration parameter, e.g. diag_header_sys_default_value=yes/no. The operating system MAY also have a dynamic configuration option to change the configuration setting as needed. If the PDM destination options extension header is used, then it MAY be turned on for all packets flowing through the host, applied to an upper-layer protocol (TCP, UDP, SCTP, etc), a local port, or IP address only. These are at the discretion of the implementation. The PDM MUST NOT be changed dynamically via packet flow as this may create potential security violation or DoS attack by numerous packets turning the header on and off. As with all other destination options extension headers, the PDM is for destination nodes only. As specified above, intermediate devices MUST neither set nor modify this field. 2.5.2 Data Length Filtering Different results for derived metrics, such as, server delay, will be obtained if calculations are done including or excluding packets which have a data length of 0 or 1. Some protocols, for example, TCP, provide acknowledgements which have a length of 0. Keep-alive packets have a data length of 0 or 1. Operating systems may provide the user a choice of whether to include or exclude packets with a 0 or 1 byte data length. 2.5.3 5-tuple Aging Within the operating system, metrics must be kept on a 5-tuple basis. The 5-tuple is: SADDR : IP address of the sender SPORT : Port for sender DADDR : IP address of the destination DPORT : Port for destination PROTC : Protocol for upper layer (ex. TCP, UDP, ICMP) Elkins Expires March 12, 2015 [Page 9] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-07 August 2014 The question comes of when to stop keeping data or restarting the numbering for a 5-tuple. For example, in the case of TCP, at some point, the connection will terminate. Keeping data in control blocks forever, will have unfortunate consequences for the operating system. So, the recommendation is to use a known aging parameter such as Max Segment Lifetime (MSL) as defined in Transmission Control Protocol [RFC0793]. The choice of aging parameter is left up to the implementation. 3 Backward Compatibility The scheme proposed in this document is backward compatible with all the currently defined IPv6 extension headers. According to RFC2460 [RFC2460], if the destination node does not recognize this option, it should skip over this option and continue processing the header. 4 Security Considerations The PDM MUST NOT be changed dynamically via packet flow as this creates a possibility for potential security violations or DoS attacks by numerous packets turning the header on and off. 5 IANA Considerations An option type must be assigned by IANA for the Performance and Diagnostic Metrics (PDM) destination option. 6 References 6.1 Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000. Elkins Expires March 12, 2015 [Page 10] INTERNET DRAFT elkins-6man-ipv6-pdm-dest-option-07 August 2014 6.2 Informative References [TRAM-TCPM] Trammel, B., "Encoding of Time Intervals for the TCP Timestamp Option-01", Internet Draft, July 2013. [Work in Progress] [ELK-IPPM] Elkins, N., "IPPM Considerations for the IPv6 PDM Destination Option-00", Internet Draft, September 2014. 7 Acknowledgments The authors would like to thank Keven Haining, Bill Jouris, Sigfrido Perdomo and Fred Baker for their comments. Authors' Addresses Nalini Elkins Inside Products, Inc. 36A Upper Circle Carmel Valley, CA 93924 United States Phone: +1 831 659 8360 Email: nalini.elkins@insidethestack.com http://www.insidethestack.com Robert Hamilton Chemical Abstracts Service A Division of the American Chemical Society 2540 Olentangy River Road Columbus, Ohio 43202 United States Phone: +1 614 447 3600 x2517 Email: rhamilton@cas.org http://www.cas.org Michael S. Ackermann Blue Cross Blue Shield of Michigan P.O. Box 2888 Detroit, Michigan 48231 United States Phone: +1 310 460 4080 Email: mackermann@bcbsmi.com http://www.bcbsmi.com Elkins Expires March 12, 2015 [Page 11]