Internet DRAFT - draft-elkins-v6ops-ipv6-pdm-recommended-usage
draft-elkins-v6ops-ipv6-pdm-recommended-usage
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]
