< draft-elkins-ippm-pdm-option-02.txt   draft-elkins-ippm-pdm-option-03.txt >
INTERNET-DRAFT N. Elkins INTERNET-DRAFT N. Elkins
Inside Products Inside Products
R. Hamilton R. Hamilton
Chemical Abstracts Service Chemical Abstracts Service
M. Ackermann M. Ackermann
Intended Status: Proposed Standard BCBS Michigan Intended Status: Proposed Standard BCBS Michigan
Expires: April 2015 October 20, 2014 Expires: August 2015 February 14, 2015
IPPM Considerations for the IPv6 PDM Destination Option IPPM Considerations for the IPv6 PDM Destination Option
draft-elkins-ippm-pdm-option-02 draft-elkins-ippm-pdm-option-03
Table of Contents Table of Contents
1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 End User Quality of Service (QoS) . . . . . . . . . . . . . 3 1.2 End User Quality of Service (QoS) . . . . . . . . . . . . . 4
1.3 Need for a Packet Sequence Number . . . . . . . . . . . . . 4 1.3 Need for a Packet Sequence Number . . . . . . . . . . . . . 5
1.4 Rationale for proposed solution . . . . . . . . . . . . . . 4 1.4 Rationale for proposed solution . . . . . . . . . . . . . . 5
2 Measurement Information Derived from PDM . . . . . . . . . . . 5 1.5 PDM Works in Collaboration with Other Headers . . . . . . . 5
2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 5 2 Measurement Information Derived from PDM . . . . . . . . . . . . 6
2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 6
3 Performance and Diagnostic Metrics Destination Option Layout . . 6 2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 Destination Options Header . . . . . . . . . . . . . . . . 6 3 Performance and Diagnostic Metrics Destination Option Layout . . 7
3.2 Performance and Diagnostic Metrics Destination Option . . . 6 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7
4 Considerations of Timing Representation . . . . . . . . . . . . 9 3.2 Performance and Diagnostic Metrics Destination Option . . . 7
4.1 Encoding the Delta-Time Values . . . . . . . . . . . . . . . 9 4 Considerations of Timing Representation . . . . . . . . . . . . 10
4.2 Timer registers are different on different hardware . . . . 9 4.1 Encoding the Delta-Time Values . . . . . . . . . . . . . . . 10
4.3 Timer Units on Other Systems . . . . . . . . . . . . . . . . 10 4.2 Timer registers are different on different hardware . . . . 10
4.4 Time Base . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3 Timer Units on Other Systems . . . . . . . . . . . . . . . . 11
4.5 Timer-value scaling . . . . . . . . . . . . . . . . . . . . 10 4.4 Time Base . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6 Limitations with this encoding method . . . . . . . . . . . 12 4.5 Timer-value scaling . . . . . . . . . . . . . . . . . . . . 12
4.7 Lack of precision induced by timer value truncation . . . . 12 4.6 Limitations with this encoding method . . . . . . . . . . . 13
5 Sample Implementation Flow PDM . . . . . . . . . . . . . . . . . 13 4.7 Lack of precision induced by timer value truncation . . . . 14
5.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5 PDM Flow - Simple Client Server . . . . . . . . . . . . . . . . 15
5.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6 Security Considerations . . . . . . . . . . . . . . . . . . . . 17 5.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 6 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . . . 19
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 18 6.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . . . 20
8.2 Informative References . . . . . . . . . . . . . . . . . . . 18 6.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . . . 21
9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 18 7 Potential Overhead Considerations . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 23
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 23
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1 Normative References . . . . . . . . . . . . . . . . . . . 23
10.2 Informative References . . . . . . . . . . . . . . . . . . 24
11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Abstract Abstract
To assess performance problems, measurements based on optional To assess performance problems, measurements based on optional
sequence numbers and timing may be embedded in each packet. Such sequence numbers and timing may be embedded in each packet. Such
measurements may be interpreted in real-time or after the fact. An measurements may be interpreted in real-time or after the fact. An
implementation of the existing IPv6 Destination Options extension implementation of the existing IPv6 Destination Options extension
header, the Performance and Diagnostic Metrics (PDM) Destination header, the Performance and Diagnostic Metrics (PDM) Destination
Options extension header has been proposed in a companion document. Options extension header has been proposed in a companion document.
This document specifies the field limits, calculations, and usage of This document specifies the field limits, calculations, and usage of
skipping to change at page 2, line 39 skipping to change at page 2, line 45
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 5 skipping to change at page 5, line 5
change. change.
Response time and consistency are not just "nice to have". On many Response time and consistency are not just "nice to have". On many
networks, the impact can be financial hardship or endanger human networks, the impact can be financial hardship or endanger human
life. In some cities, the emergency police contact system operates life. In some cities, the emergency police contact system operates
over IP, law enforcement uses TCP/IP networks, transactions on our over IP, law enforcement uses TCP/IP networks, transactions on our
stock exchanges are settled using IP networks. The critical nature stock exchanges are settled using IP networks. The critical nature
of such activities to our daily lives and financial well-being demand of such activities to our daily lives and financial well-being demand
a solution. a solution.
1.3 Need for a Packet Sequence Number 1.3 Need for a Packet Sequence Number
While performing network diagnostics of an end-to-end connection, it While performing network diagnostics of an end-to-end connection, it
often becomes necessary to find the device along the network path often becomes necessary to find the device along the network path
creating problems. Diagnostic data may be collected at multiple creating problems. Diagnostic data may be collected at multiple
places along the path (if possible), or at the source and places along the path (if possible), or at the source and
destination. Then, the diagnostic data corresponding to each packet destination. Then, the diagnostic data corresponding to each packet
at different observation points must be matched for proper at different observation points must be matched for proper
measurements. A sequence number in each packet provides sufficient measurements. A sequence number in each packet provides sufficient
basis for the matching process. If need be, the timing fields may be basis for the matching process. If need be, the timing fields may be
used along with the sequence number to ensure uniqueness. used along with the sequence number to ensure uniqueness.
skipping to change at page 5, line 5 skipping to change at page 5, line 45
instrumentation instrumentation
4. No time synchronization needed between session partners 4. No time synchronization needed between session partners
The PDM provides the ability to quickly determine if the (latency) The PDM provides the ability to quickly determine if the (latency)
problem is in the network or in the server (application). More problem is in the network or in the server (application). More
intermediate measurements may be needed if the host or network intermediate measurements may be needed if the host or network
discrimination is not sufficient. At the client, TCP/IP stack time discrimination is not sufficient. At the client, TCP/IP stack time
vs. applications time may still need to be broken out by client vs. applications time may still need to be broken out by client
software. software.
2 Measurement Information Derived from PDM 1.5 PDM Works in Collaboration with Other Headers
The purpose of the PDM is not to supplant all the variables present
in all other headers but to provide data which is not available or
very difficult to get. The way PDM would be used is by a technician
(or tool) looking at a packet capture. Within the packet capture,
they would have available to them the layer 2 header, IP header (v6
or v4), TCP, UCP, ICMP, SCTP or other headers. All information
would be looked at together to make sense of the packet flow. The
technician or processing tool could analyze, report or ignore the
data from PDM, as necessary.
For an example of how PDM can help with TCP retransmit problems,
please look at section 8.
2 Measurement Information Derived from PDM
Each packet contains information about the sender and receiver. In IP Each packet contains information about the sender and receiver. In IP
protocol, the identifying information is called a "5-tuple". protocol, the identifying information is called a "5-tuple".
The 5-tuple consists of: The 5-tuple consists of:
SADDR : IP address of the sender SADDR : IP address of the sender
SPORT : Port for sender SPORT : Port for sender
DADDR : IP address of the destination DADDR : IP address of the destination
DPORT : Port for destination DPORT : Port for destination
skipping to change at page 5, line 43 skipping to change at page 7, line 4
Round-trip delay is the end-to-end delay for a packet from a source Round-trip delay is the end-to-end delay for a packet from a source
host to a destination host. This measurement has been defined, and host to a destination host. This measurement has been defined, and
the advantages and disadvantages discussed in "A Round-trip Delay the advantages and disadvantages discussed in "A Round-trip Delay
Metric for IPPM" [RFC2681]. Metric for IPPM" [RFC2681].
2.2 Server Delay 2.2 Server Delay
Server delay is the interval between when a packet is received by a Server delay is the interval between when a packet is received by a
device and the first corresponding packet is sent back in response. device and the first corresponding packet is sent back in response.
This may be "Server Processing Time". It may also be a delay caused This may be "Server Processing Time". It may also be a delay caused
by acknowledgements. Server processing time includes the time taken by acknowledgements. Server processing time includes the time taken
by the combination of the stack and application to return the by the combination of the stack and application to return the
response. The stack delay may be related to network performance. If response. The stack delay may be related to network performance. If
this aggregate time is seen as a problem, and there is a need to make this aggregate time is seen as a problem, and there is a need to make
a clear distinction between application processing time and stack a clear distinction between application processing time and stack
delay, including that caused by the network, then more client based delay, including that caused by the network, then more client based
measurements are needed. measurements are needed.
3 Performance and Diagnostic Metrics Destination Option Layout 3 Performance and Diagnostic Metrics Destination Option Layout
3.1 Destination Options Header 3.1 Destination Options Header
The IPv6 Destination Options Header is used to carry optional The IPv6 Destination Options Header is used to carry optional
information that need be examined only by a packet's destination information that need be examined only by a packet's destination
node(s). The Destination Options Header is identified by a Next node(s). The Destination Options Header is identified by a Next
Header value of 60 in the immediately preceding header and is defined Header value of 60 in the immediately preceding header and is defined
in RFC2460 [RFC2460]. The IPv6 Performance and Diagnostic Metrics in RFC2460 [RFC2460]. The IPv6 Performance and Diagnostic Metrics
Destination Option (PDM) is an implementation of the Destination Destination Option (PDM) is an implementation of the Destination
Options Header (Next Header value = 60). The PDM does not require Options Header (Next Header value = 60). The PDM does not require
time synchronization. time synchronization.
3.2 Performance and Diagnostic Metrics Destination Option 3.2 Performance and Diagnostic Metrics Destination Option
The IPv6 Performance and Diagnostic Metrics Destination Option (PDM) The IPv6 Performance and Diagnostic Metrics Destination Option (PDM)
contains the following fields: contains the following fields:
TIMEBASE : Base timer unit TIMEBASE : Base timer unit
SCALEDL : Scale for Delta Last Received SCALEDL : Scale for Delta Last Received
SCALEDS : Scale for Delta Last Sent SCALEDS : Scale for Delta Last Sent
PSNTP : Packet Sequence Number This Packet PSNTP : Packet Sequence Number This Packet
PSNLR : Packet Sequence Number Last Received PSNLR : Packet Sequence Number Last Received
DELTALR : Delta Last Received DELTALR : Delta Last Received
skipping to change at page 13, line 26 skipping to change at page 15, line 5
1 day 141DD76000 507 26 1:07.108863 1 day 141DD76000 507 26 1:07.108863
Maximum value 3FFFFFFFFFF 7FF 31 35:47.483647 Maximum value 3FFFFFFFFFF 7FF 31 35:47.483647
So, when measuring the delay between transmission of two packets, or So, when measuring the delay between transmission of two packets, or
between the reception of two packets, any delay shorter than 50 days between the reception of two packets, any delay shorter than 50 days
21 hours and change can be stored in this encoded fashion within 16 21 hours and change can be stored in this encoded fashion within 16
bits. When you encode, for example, a DTN response time delay of 50 bits. When you encode, for example, a DTN response time delay of 50
days, 21 hours and 40 minutes, you can be assured of accuracy within days, 21 hours and 40 minutes, you can be assured of accuracy within
35 minutes. 35 minutes.
5 Sample Implementation Flow PDM 5 PDM Flow - Simple Client Server
Following is a sample simple flow for the PDM with one packet sent Following is a sample simple flow for the PDM with one packet sent
from Host A and one packet received by Host B. The PDM does not from Host A and one packet received by Host B. The PDM does not
require time synchronization between Host A and Host B. The require time synchronization between Host A and Host B. The
calculations to derive meaningful metrics for network diagnostics are calculations to derive meaningful metrics for network diagnostics are
shown below each packet sent or received. shown below each packet sent or received.
Each packet, in addition to the PDM contains information on the Each packet, in addition to the PDM contains information on the
sender and receiver. As discussed before, a 5-tuple consists of: sender and receiver. As discussed before, a 5-tuple consists of:
skipping to change at page 17, line 40 skipping to change at page 19, line 5
PSNLR : Packet Sequence Number Last Received: 12 PSNLR : Packet Sequence Number Last Received: 12
DELTALR : Delta Last Received: 0 DELTALR : Delta Last Received: 0
SCALEDL : Scale of Delta LR 0 SCALEDL : Scale of Delta LR 0
DELTALS : Delta Last Sent: 105e (12 seconds) DELTALS : Delta Last Sent: 105e (12 seconds)
SCALEDL : Scale of Delta LR 26 SCALEDL : Scale of Delta LR 26
TIMEBASE : Granularity of Time: 00 (Picoseconds) TIMEBASE : Granularity of Time: 00 (Picoseconds)
To calculate Two-Way Delay, any packet capture device may look at To calculate Two-Way Delay, any packet capture device may look at
these packets and do what is necessary. these packets and do what is necessary.
6 Security Considerations 6 Other Flows
TBD. It is conceivable that in allowing this Destination Option What we have discussed so far is a simple flow with one packet sent
through a firewall, that other malicious traffic may be allowed and one returned. Let's look at how PDM may be useful in other
through. types of flows.
7 IANA Considerations 6.1 PDM Flow - One Way Traffic
The flow on a particular session may not be a send-receive paradigm.
Let us consider some other situations. In the case of a one-way
flow, one might see the following:
Packet Sender PSN PSN Delta Delta
This Packet Last Recvd Last Recvd Last Sent
=====================================================================
1 Server 1 0 0 0
2 Server 2 0 0 5
3 Server 3 0 0 12
4 Server 4 0 0 20
What does this mean and how is it useful?
In a one-way flow, only the Delta Last Sent will be seen as used.
Recall, Delta Last Sent is the difference between the send of one
packet from a device and the next. This is a measure of throughput
for the sender - according to the sender's point of view. That is,
it is a measure of how fast is the application itself (with stack
time included) able to send packets.
How might this be useful? If one is having a performance issue at
the client and sees that packet 2, for example, is sent after 5
microseconds from the server but takes 3 minutes to arrive at the
destination, then one may safely conclude that there are delays in
the path other than at the server which may be causing the delivery
issue of that packet. Such delays may include the network links,
middle-boxes, etc.
Now, true one-way traffic is quite rare. What people often mean by
"one-way" traffic is an application such as FTP where a group of
packets (for example, a TCP window size worth) is sent, then the
sender waits for acknowledgment. This type of flow would actually
fall into the "multiple-send" traffic model.
6.2 PDM Flow - Multiple Send Traffic
Assume that two packets are sent with each send from the server.
Packet Sender PSN PSN Delta Delta
This Packet Last Recvd Last Recvd Last Sent
=====================================================================
1 Server 1 0 0 0
2 Server 2 0 0 5
3 Client 1 1 20 0
4 Server 3 1 10 15
How might this be used?
Notice that in packet 3, the client has a value of Delta Last
received of 20. Recall that Delta Last Received is the Send time of
packet 3 - receive time of packet 2. So, what does one know now?
In this case, Delta Last Received is the processing time for the
Client to send the next packet.
How to interpret this depends on what is actually being sent.
Remember, PDM is not being used in isolation, but to supplement the
fields found in other headers. Let's take some examples:
1. Client is sending a standalone TCP ACK. One would find this by
looking at the payload length in the IPv6 header and the TCP
Acknowledgement field in the TCP header. So, in this case, the
client is taking 20 units to send back the ACK. This may or may not
be interesting.
2. Client is sending data with the packet. Again, one would find
this by looking at the payload length in the IPv6 header and the TCP
Acknowledgement field in the TCP header. So, in this case, the
client is taking 20 units to send back data. This may represent
"User Think Time". Again, this may or may not be interesting, in
isolation. But, if there is a performance problem receiving data at
the server, then taken in conjunction with RTT or other packet timing
information, this information may be quite interesting.
Of course, one also needs to look at the PSN Last Received field to
make sure of the interpretation of this data. That is, to make
sure that the Delta Last Received corresponds to the packet of
interest.
The benefits of PDM are that we have such information available in a
uniform manner for all applications and all protocols without
extensive changes required to applications.
6.3 PDM Flow - Multiple Send with Errors
One might wonder if all of the functions of PDM might be better
suited to TCP or a TCP option. Let us take the case of how PDM may
help in a case of TCP retransmissions in a way that TCP options or
TCP ACK / SEQ would not.
Assume that three packets are sent with each send from the server.
From the server, this is what is seen.
Pkt Sender PSN PSN Delta Delta TCP Data
This Pkt LastRecvd LastRecvd LastSent SEQ Bytes
=====================================================================
1 Server 1 0 0 0 123 100
2 Server 2 0 0 5 223 100
3 Server 3 0 0 5 333 100
The client however, does not get all the packets. From the client,
this is what is seen for the packets sent from the server.
Pkt Sender PSN PSN Delta Delta TCP Data
This Pkt LastRecvd LastRecvd LastSent SEQ Bytes
=====================================================================
1 Server 1 0 0 0 123 100
2 Server 3 0 0 5 333 100
Let's assume that the server now retransmits the packet.
(Obviously, a duplicate acknowledgment sequence for fast retransmit
or a retransmit timeout would occur. To illustrate the point, these
packets are being left out.)
So, then if a TCP retransmission is done, then from the client, this
is what is seen for the packets sent from the server.
Pkt Sender PSN PSN Delta Delta TCP Data
This Pkt LastRecvd LastRecvd LastSent SEQ Bytes
=====================================================================
1 Server 4 0 0 30 223 100
The server has resent the old packet 2 with TCP sequence number of
223. The retransmitted packet now has a PSN This Packet value of 4.
The Delta Last Sent is 30 - the time between sending the packet with
PSN of 3 and this current packet.
Let's say that packet 4 STILL does not make it. Then, after some
amount of time (RTO) then the packet with TCP sequence number of 223
is resent.
From the client, this is what is seen for the packets sent from the
server.
Pkt Sender PSN PSN Delta Delta TCP Data
This Pkt LastRecvd LastRecvd LastSent SEQ Bytes
=====================================================================
1 Server 5 0 0 60 223 100
If now, this packet makes it, one has a very good idea that packets
exist which are being sent from the server as retransmissions and not
making it to the client. This is because the PSN of the resent
packet from the server is 5 rather than 4. If we had used TCP
sequence number alone, we would never have seen this situation.
Because the TCP sequence number in all situations is 223.
This situation would be experienced by the user of the application
(the human being actually sitting somewhere) as a "hangs" or long
delay between packets. On large networks, to diagnose problems such
as these where packets are lost somewhere on the network, one has to
take multiple traces to find out exactly where.
The first thing is to start with doing a trace at the client and the
server. So, we can see if the server sent a particular packet and
the client received it. If the client did not receive it, then we
start tracking back to trace points at the router right after the
server and the router right before the client. Did they get these
packets which the server has sent? This is a time consuming
activity.
With PDM, we can speed up the diagnostic time because we may be able
to use only the trace taken at the client to see what the server is
sending.
7 Potential Overhead Considerations
Questions have been posed as to the potential overhead of PDM.
First, PDM is entirely optional. That is, a site may choose to
implement PDM or not as they wish. If they are happy with the costs
of PDM vs. the benefits, then the choice should be theirs.
Below is a table outlining the potential overhead in terms of
additional time to deliver the response to the end user.
Packet
Bytes RTT BPM PDM Bytes New RTT Overhead
=====================================================================
1000 1000 milli 1 16 1016.000 16.000 milli
1000 100 milli 10 16 101.600 1.600 milli
1000 10 milli 100 16 10.160 .160 milli
1000 1 milli 1000 16 1.016 .016 milli
Below are some examples of actual RTTs for packets traversing large
enterprise networks. The first example is for packets going to
multiple business partners.
Packet
Bytes RTT BPM PDM Bytes New RTT Overhead
=====================================================================
1000 17 milli 58 16 17.360 .360 milli
The second example is for packets at a large enterprise customer
within a data center. Notice that the scale is now in microseconds
rather than milliseconds.
Packet
Bytes RTT BPM PDM Bytes New RTT Overhead
=====================================================================
1000 20 micro 50 16 20.320 320 micro
8 Security Considerations
TBD.
9 IANA Considerations
Option Type TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780]. Option Type TBD = 0xXX (TBD) [To be assigned by IANA] [RFC2780].
8 References 10 References
8.1 Normative References 10.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip
Delay Metric for IPPM", RFC 2681, September 1999. Delay Metric for IPPM", RFC 2681, September 1999.
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP 37, RFC Values In the Internet Protocol and Related Headers", BCP 37, RFC
2780, March 2000. 2780, March 2000.
[IBM-POPS] IBM Corporation, "IBM z/Architecture Principles of [IBM-POPS] IBM Corporation, "IBM z/Architecture Principles of
Operation", SA22-7832, 1990-2012 Operation", SA22-7832, 1990-2012
8.2 Informative References 10.2 Informative References
[ELK-PDM] Elkins, N., "draft-elkins-6man-ipv6-pdm-dest-option-09", [ELK-PDM] Elkins, N., "draft-elkins-6man-ipv6-pdm-dest-option-09",
Internet Draft, October 2014. [Work in Progress] Internet Draft, October 2014. [Work in Progress]
[TRAM-TCPM] Trammel, B., "Encoding of Time Intervals for the TCP [TRAM-TCPM] Trammel, B., "Encoding of Time Intervals for the TCP
Timestamp Option-01", Internet Draft, July 2013. [Work in Progress] Timestamp Option-01", Internet Draft, July 2013. [Work in Progress]
9 Acknowledgments 11 Acknowledgments
The authors would like to thank Keven Haining, Al Morton, Brian The authors would like to thank Keven Haining, Al Morton, Brian
Trammel, David Boyes, and Rick Troth for their comments and Trammel, David Boyes, and Rick Troth for their comments and
assistance. assistance.
Authors' Addresses Authors' Addresses
Nalini Elkins Nalini Elkins
Inside Products, Inc. Inside Products, Inc.
36A Upper Circle 36A Upper Circle
 End of changes. 17 change blocks. 
49 lines changed or deleted 278 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/