INTERNET-DRAFT N. Elkins Intended Status: Informational Inside Products M. Ackermann BCBS Michigan W. Jouris Inside Products K. Haining US Bank S. Perdomo DTCC Expires: April 2014 October 3, 2013 Recommended Usage of IPv6 PDM Option draft-elkins-v6ops-ipv6-pdm-recommended-usage-01 Abstract To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmission are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. The base metrics are: packet sequence number and packet timestamp. Metrics derived from these will be described separately. This document details the recommended usage for the IPv6 Performance and Diagnostic Metrics Destination Option (PDM). 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 April 14, 2014 [Page 1] INTERNET DRAFT-elkins-v6ops-ipv6-pdm-recommended-usage-01 October 2013 Copyright and License Notice Copyright (c) 2013 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 2 How to use Packet Sequence Number . . . . . . . . . . . . . . . 3 2.1 Limitations of Packet Capture . . . . . . . . . . . . . . . 4 2.1.1 Problem Scenario 1 . . . . . . . . . . . . . . . . . . . 4 2.1.2 Problem Scenario 2 . . . . . . . . . . . . . . . . . . . 4 2.1.3 Packet Sequence Number Provides Solution . . . . . . . . 5 2.2 Packet Sequence Number Replaces IPv4 IPID DeFacto Diagnostic Function . . . . . . . . . . . . . . . . . . . . 5 3 How to use the Timestamp . . . . . . . . . . . . . . . . . . . . 5 3.1 Time Synchronization . . . . . . . . . . . . . . . . . . . . 5 3.2 Response Time for Service Level Agreements . . . . . . . . . 5 3.3 Trending . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Elkins Expires April 14, 2014 [Page 2] INTERNET DRAFT-elkins-v6ops-ipv6-pdm-recommended-usage-01 October 2013 1 Introduction To diagnose performance and connectivity problems, metrics on real (non-synthetic) transmission are critical for timely end-to-end problem resolution. Such diagnostics may be real-time or after the fact, but must not impact an operational production network. The base metrics are: packet sequence number and packet timestamp. Metrics derived from these will be described separately. For background, please see draft-ackermann-tictoc-pdm-ntp-usage-00 [ACKPDM], draft-elkins-6man-ipv6-pdm-dest-option-02 [ELKPDM], draft- elkins-v6ops-ipv6-packet-sequence-needed-01 [ELKPSN], draft-elkins- v6ops-ipv6-end-to-end-rt-needed-01 [ELKRSP], and draft-elkins-ippm- pdm-metrics-00 [ELKIPPM]. These drafts are companions to this document. As discussed in the above Internet Drafts, current methods are inadequate for these purposes because they assume unreasonable access to intermediate devices, are cost prohibitive, require infeasible changes to a running production network, or do not provide timely data. The IPv6 Performance and Diagnostic Metrics destination option (PDM) provides a solution to these problems. This document will discuss how best to use the PDM. 2 How to use Packet Sequence Number In many large Enterprise Networks, during network diagnostics of an end-to-end connection, it becomes necessary to find the device along the path creating problems. Diagnostic data may be collected at multiple places along the path (if possible), or at the source and destination. Then, the diagnostic data must be matched. Packet sequence number is critical in this matching process. In IPv4 networks, the IPID field was used as a DeFacto sequence number. This was discussed at length in draft-elkins-v6ops-ipv6-packet-sequence- needed-01 [ELKPSN]. The packet sequence number provided in the PDM may be used in large multi-tier networks to see where the packet loss or packet corruption is happening. Multi-tier networks are those which have multiple routers or switches on the path between the sender and the receiver. Elkins Expires April 14, 2014 [Page 3] INTERNET DRAFT-elkins-v6ops-ipv6-pdm-recommended-usage-01 October 2013 2.1 Limitations of Packet Capture As discussed in draft-elkins-v6ops-ipv6-packet-sequence-needed-01 [ELKPSN], the only instrumentation which provides enough detail to diagnose end-to-end problems is a packet trace. Even though packets are the only reliable way to provide data at the needed granularity, there are limitations in operations on live production networks. How packet sequence number can alleviate the limitations are detailed below the problem description. 2.1.1 Problem Scenario 1 1. Packets are captured for analysis at places like large core switches. All packets are kept. Again, not necessarily for diagnostic reasons but for regulatory. (Ex. Records of all stock trades may need to be kept for a certain number of years.) 2. When there is a problem, an analyst extracts the needed information. 3. If the extract is done incorrectly, as often happens, or the packet capture itself is incorrect, then there are false duplicate packets which can be quite misleading and can lead to wrong conclusions. Are these real TCP duplicates? Is there congestion on the subnet? Are these retransmissions? Situations have been seen where routers incorrectly send two packets instead of one - is this such a situation? 2.1.2 Problem Scenario 2 Packet captures can be misleading for another. 1. In this scenario, packets are captured for analysis at places like a middleware box. The reason this is done is because problems are suspected with the box itself. 2. The box may not offer any way to tailor the packet capture. "You will get what we give you, how we give it to you!" is their philosophy, 3. The packet capture incorrectly duplicates only packets going to certain nodes. So, it is not possible to devise an algorithm or pattern whereby certain packets can be ignored 4. Again, there are false duplicate packets which can be misleading and can lead to wrong conclusions. Are these real TCP duplicates? Is there congestion on the subnet? Situations have been seen where routers incorrectly send two packets instead of one - is this such a Elkins Expires April 14, 2014 [Page 4] INTERNET DRAFT-elkins-v6ops-ipv6-pdm-recommended-usage-01 October 2013 situation? 2.1.3 Packet Sequence Number Provides Solution If a packet is a duplicate sent by a stack at a source host, the packet sequence number will not be the same. If a duplicate packet is seen with the same packet sequence number, it can be safely assumed that this is a 'false' duplicate and can be ignored. 2.2 Packet Sequence Number Replaces IPv4 IPID DeFacto Diagnostic Function draft-elkins-v6ops-ipv6-packet-sequence-needed-01 [ELKPSN] discussed a number of use cases where the IPv4 IPID reduced the time to diagnose problems on networks. The packet sequence number in the PDM will serve the same function for IPv6. The recommendation is to have the PDM used for all packets for all protocols so that timely diagnosis can occur. 3 How to use the Timestamp The timestamp contained in the PDM traveling along with the packet will be used to calculate end-to-end response time without requiring agents in devices along the path. The need for end-to-end response time, the background and current methods are discussed in draft- draft-elkins-v6ops-ipv6-end-to-end-rt-needed-01 [ELKRSP]. 3.1 Time Synchronization The timestamp used in the PDM is compatible with the Network Time Protocol (NTP) [RFC5905]. Many networks use NTP pervasively today. We recommend use of NTP so that the matching of timestamps and calculations of deltas can be easily done. 3.2 Response Time for Service Level Agreements In Networks, end-to-end response times are a critical component of Service Levels Agreements (SLAs). So, the recommended use of the PDM is to have it turned on for all applications which require SLAs and / or have a requirement for timely transmission. 3.3 Trending In addition to the need for tracking current service, end-to-end response time is valuable for capacity planning. By tracking response times, and identifying trends, it becomes possible to determine when network capacity is being approached. To allow tracking of trends in response time, we recommend having the PDM used Elkins Expires April 14, 2014 [Page 5] INTERNET DRAFT-elkins-v6ops-ipv6-pdm-recommended-usage-01 October 2013 for applications which may need additional capacity so that summary data on response times and their distributions can be maintained. 4 Security Considerations There are no security considerations. 5 IANA Considerations There are no IANA considerations. 6 References 6.1 Normative References [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. [ACKPDM] Ackermann, M., "draft-ackermann-tictoc-pdm-ntp-usage-00", Internet Draft, September 2013. [ELKPDM] Elkins, N., "draft-elkins-6man-ipv6-pdm-dest-option-02", Internet Draft, September 2013. [ELKRSP] Elkins, N., "draft-elkins-v6ops-ipv6-end-to-end-rt-needed- 01", Internet Draft, September 2013. [ELKPSN] Elkins, N., "draft-elkins-v6ops-ipv6-packet-sequence- needed-01", Internet Draft, September 2013. [ELKIPPM] Elkins, N., "draft-elkins-ippm-pdm-metrics-00", Internet Draft, September 2013. 7 Acknowledgments The authors would like to thank David Boyes and Rick Troth for their comments. Elkins Expires April 14, 2014 [Page 6] INTERNET DRAFT-elkins-v6ops-ipv6-pdm-recommended-usage-01 October 2013 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 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 Keven Haining US Bank 16900 W Capitol Drive Brookfield, WI 53005 United States Phone: +1 262 790 3551 Email: keven.haining@usbank.com http://www.usbank.com Sigfrido Perdomo Depository Trust and Clearing Corporation 55 Water Street New York, NY 10055 United States Phone: +1 917 842 7375 Email: s.perdomo@dtcc.com http://www.dtcc.com William Jouris Inside Products, Inc. 36A Upper Circle Carmel Valley, CA 93924 United States Phone: +1 925 855 9512 Email: bill.jouris@insidethestack.com http://www.insidethestack.com Elkins Expires April 14, 2014 [Page 7]