draft-ietf-ippm-6man-pdm-option-02.txt   draft-ietf-ippm-6man-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: October 13, 2016 April 11, 2016 Expires: December 9, 2016 June 7, 2016
IPv6 Performance and Diagnostic Metrics (PDM) Destination Option IPv6 Performance and Diagnostic Metrics (PDM) Destination Option
draft-ietf-ippm-6man-pdm-option-02 draft-ietf-ippm-6man-pdm-option-03
Table of Contents Table of Contents
1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 End User Quality of Service (QoS) . . . . . . . . . . . . . 4 1.2 End User Quality of Service (QoS) . . . . . . . . . . . . . 4
1.3 Need for a Packet Sequence Number . . . . . . . . . . . . . 5 1.3 Need for a Packet Sequence Number . . . . . . . . . . . . . 5
1.4 Rationale for proposed solution . . . . . . . . . . . . . . 5 1.4 Rationale for proposed solution . . . . . . . . . . . . . . 5
1.5 PDM Works in Collaboration with Other Headers . . . . . . . 6 1.5 PDM Works in Collaboration with Other Headers . . . . . . . 6
1.6 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6 1.6 IPv6 Transition Technologies . . . . . . . . . . . . . . . . 6
2 Measurement Information Derived from PDM . . . . . . . . . . . . 6 2 Measurement Information Derived from PDM . . . . . . . . . . . . 6
2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7 2.1 Round-Trip Delay . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 Server Delay . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Performance and Diagnostic Metrics Destination Option Layout . . 7 3 Performance and Diagnostic Metrics Destination Option Layout . . 7
3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7 3.1 Destination Options Header . . . . . . . . . . . . . . . . . 7
3.2 Performance and Diagnostic Metrics Destination Option . . . 7 3.2 Performance and Diagnostic Metrics Destination Option . . . 7
3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 11 3.3 Header Placement . . . . . . . . . . . . . . . . . . . . . . 10
3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 11 3.4 Header Placement Using IPSec ESP Mode . . . . . . . . . . . 11
3.5 Implementation Considerations . . . . . . . . . . . . . . . 12 3.5 Implementation Considerations . . . . . . . . . . . . . . . 11
3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 12 3.6 Dynamic Configuration Options . . . . . . . . . . . . . . . 12
3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 12 3.6 5-tuple Aging . . . . . . . . . . . . . . . . . . . . . . . 12
4 Considerations of Timing Representation . . . . . . . . . . . . 13 4 Considerations of Timing Representation . . . . . . . . . . . . 12
4.1 Encoding the Delta-Time Values . . . . . . . . . . . . . . . 13 4.1 Encoding the Delta-Time Values . . . . . . . . . . . . . . . 12
4.2 Timer registers are different on different hardware . . . . 13 4.2 Timer registers are different on different hardware . . . . 13
4.3 Timer Units on Other Systems . . . . . . . . . . . . . . . . 14 4.3 Timer Units on Other Systems . . . . . . . . . . . . . . . . 13
4.4 Time Base . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4 Time Base . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5 Timer-value scaling . . . . . . . . . . . . . . . . . . . . 15 4.5 Timer-value scaling . . . . . . . . . . . . . . . . . . . . 14
4.6 Limitations with this encoding method . . . . . . . . . . . 16 4.6 Limitations with this encoding method . . . . . . . . . . . 15
4.7 Lack of precision induced by timer value truncation . . . . 16 4.7 Lack of precision induced by timer value truncation . . . . 16
5 PDM Flow - Simple Client Server . . . . . . . . . . . . . . . . 17 5 PDM Flow - Simple Client Server . . . . . . . . . . . . . . . . 17
5.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1 Step 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.2 Step 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.3 Step 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5.4 Step 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.5 Step 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 21 6 Other Flows . . . . . . . . . . . . . . . . . . . . . . . . . . 21
6.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . . . 22 6.1 PDM Flow - One Way Traffic . . . . . . . . . . . . . . . . . 21
6.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . . . 23 6.2 PDM Flow - Multiple Send Traffic . . . . . . . . . . . . . . 22
6.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . . . 24 6.3 PDM Flow - Multiple Send with Errors . . . . . . . . . . . . 23
7 Potential Overhead Considerations . . . . . . . . . . . . . . . 25 7 Potential Overhead Considerations . . . . . . . . . . . . . . . 25
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 26 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 26
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1 Normative References . . . . . . . . . . . . . . . . . . . 27 10.1 Normative References . . . . . . . . . . . . . . . . . . . 27
10.2 Informative References . . . . . . . . . . . . . . . . . . 27 10.2 Informative References . . . . . . . . . . . . . . . . . . 27
11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Abstract Abstract
skipping to change at page 4, line 32 skipping to change at page 4, line 32
destination option. destination option.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
1.2 End User Quality of Service (QoS) 1.2 End User Quality of Service (QoS)
The difference between timing values in the PDM traveling along with The timing values in the PDM embedded in the packet will be used to
the packet will be used to estimate QoS as experienced by an end user estimate QoS as experienced by an end user device.
device.
For many applications, the key user performance indicator is response For many applications, the key user performance indicator is response
time. When the end user is an individual, he is generally time. When the end user is an individual, he is generally
indifferent to what is happening along the network; what he really indifferent to what is happening along the network; what he really
cares about is how long it takes to get a response back. But this is cares about is how long it takes to get a response back. But this is
not just a matter of individuals' personal convenience. In many not just a matter of individuals' personal convenience. In many
cases, rapid response is critical to the business being conducted. cases, rapid response is critical to the business being conducted.
When the end user is a device (e.g. with the Internet of Things), When the end user is a device (e.g. with the Internet of Things),
what matters is the speed with which requested data can be what matters is the speed with which requested data can be
transferred -- specifically, whether the requested data can be transferred -- specifically, whether the requested data can be
transferred in time to accomplish the desired actions. This can be transferred in time to accomplish the desired actions. This can be
important when the relevant external conditions are subject to rapid important when the relevant external conditions are subject to rapid
change. change.
Response time and consistency are not just "nice to have". On many Low, reliable and acceptable responses times are not just "nice to
networks, the impact can be financial hardship or endanger human have". On many networks, the impact can be financial hardship or
life. In some cities, the emergency police contact system operates endanger human life. In some cities, the emergency police contact
over IP, law enforcement uses TCP/IP networks, transactions on our system operates over IP, law enforcement uses TCP/IP networks,
stock exchanges are settled using IP networks. The critical nature transactions on our stock exchanges are settled using IP networks.
of such activities to our daily lives and financial well-being demand The critical nature of such activities to our daily lives and
a simple solution to support measurements. financial well-being demand a simple solution to support response
time measurements.
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 isolate the factors along the network path
creating problems. Diagnostic data may be collected at multiple responsible for problems. Diagnostic data may be collected at
places along the path (if possible), or at the source and multiple places along the path (if possible), or at the source and
destination. Then, in post-collection processing, the diagnostic destination. Then, in post-collection processing, the diagnostic
data corresponding to each packet at different observation points data corresponding to each packet at different observation points
must be matched for proper measurements. A sequence number in each must be matched for proper measurements. A sequence number in each
packet provides sufficient basis for the matching process. If need packet provides sufficient basis for the matching process. If need
be, the timing fields may be used along with the sequence number to be, the timing fields may be used along with the sequence number to
ensure uniqueness. ensure uniqueness.
This method of data collection along the path is of special use to This method of data collection along the path is of special use to
determine where packet loss or packet corruption is happening. determine where packet loss or packet corruption is happening.
skipping to change at page 7, line 35 skipping to change at page 7, line 35
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 needs to 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. 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
SCALEDTLR: Scale for Delta Time Last Received SCALEDTLR: Scale for Delta Time Last Received
SCALEDTLS: Scale for Delta Time Last Sent SCALEDTLS: Scale for Delta Time Last Sent
PSNTP : Packet Sequence Number This Packet PSNTP : Packet Sequence Number This Packet
skipping to change at page 9, line 18 skipping to change at page 9, line 17
Scale Delta Time Last Sent (SCALEDTLS) Scale Delta Time Last Sent (SCALEDTLS)
7-bit signed integer. This is the scaling value for the Delta Time 7-bit signed integer. This is the scaling value for the Delta Time
Last Sent (DELTATLS) field. The possible values are from -128 to Last Sent (DELTATLS) field. The possible values are from -128 to
+127. +127.
Packet Sequence Number This Packet (PSNTP) Packet Sequence Number This Packet (PSNTP)
16-bit unsigned integer. This field will wrap. It is intended for 16-bit unsigned integer. This field will wrap. It is intended for
human use. That is, while to be used while analyzing packet traces. use while analyzing packet traces.
Initialized at a random number and monotonically incremented for each Initialized at a random number and incremented monotonically for each
packet on the 5-tuple. The 5-tuple consists of the source and packet of the session flow of the 5-tuple. The 5-tuple consists of
destination IP addresses, the source and destination ports, and the the source and destination IP addresses, the source and destination
upper layer protocol (ex. TCP, ICMP, etc). The random number ports, and the upper layer protocol (ex. TCP, ICMP, etc). The
initialization is to make it harder to spoof and insert such packets. random number initialization is intended to make it harder to spoof
and insert such packets.
Operating systems MUST implement a separate packet sequence number Operating systems MUST implement a separate packet sequence number
counter per 5-tuple. Operating systems MUST NOT implement a single counter per 5-tuple. Operating systems MUST NOT implement a single
counter for all connections. counter for all connections.
Packet Sequence Number Last Received (PSNLR) Packet Sequence Number Last Received (PSNLR)
16-bit unsigned integer. This is the PSN of the packet last received 16-bit unsigned integer. This is the PSNTP of the packet last
on the 5-tuple. received on the 5-tuple.
Delta Time Last Received (DELTATLR) Delta Time Last Received (DELTATLR)
A 16-bit unsigned integer field. The value is according to the scale A 16-bit unsigned integer field. The value is set according to the
in SCALEDTLR. scale in SCALEDTLR.
DELTATLR = Send time packet 2 - Receive time packet 1 DELTATLR = Send time packet 2 - Receive time packet 1
Delta TimeLast Sent (DELTATLS) Delta TimeLast Sent (DELTATLS)
A 16-bit unsigned integer field. The value is according to the A 16-bit unsigned integer field. The value is set according to the
scale in SCALEDTLS. scale in SCALEDTLS.
Delta Time Last Sent = Receive time packet 2 - Send time packet 1 Delta Time Last Sent = Receive time packet 2 - Send time packet 1
Option Type Option Type
The two highest-order bits of the Option Type field are encoded to The two highest-order bits of the Option Type field are encoded to
indicate specific processing of the option; for the PDM destination indicate specific processing of the option; for the PDM destination
option, these two bits MUST be set to 00. This indicates the option, these two bits MUST be set to 00. This indicates the
following processing requirements: following processing requirements:
00 - skip over this option and continue processing the header. 00 - skip over this option and continue processing the header.
RFC2460 [RFC2460] defines other values for the Option Type field. RFC2460 [RFC2460] defines other values for the Option Type field.
These MUST NOT be used in the PDM. The other values are as follows: These MUST NOT be used in the PDM.
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 In keeping with RFC2460 [RFC2460], the third-highest-order bit of the
Option Type specifies whether or not the Option Data of that option Option Type specifies whether or not the Option Data of that option
can change en-route to the packet's final destination. 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 In the PDM, the value of the third-highest-order bit MUST be 0. The
possible values are as follows: possible values are as follows:
0 - Option Data does not change en-route 0 - Option Data does not change en-route
skipping to change at page 26, line 45 skipping to change at page 26, line 24
attacks by numerous packets turning the header on and off. attacks by numerous packets turning the header on and off.
Attackers may also send many packets from multiple ports, for example Attackers may also send many packets from multiple ports, for example
by doing a port scan. This will cause the stack to create many by doing a port scan. This will cause the stack to create many
control blocks. This is the same problem as seen for SYN flood control blocks. This is the same problem as seen for SYN flood
attacks. Similar protections should be implemented by the stack to attacks. Similar protections should be implemented by the stack to
preserve the integrity of memory. preserve the integrity of memory.
9 IANA Considerations 9 IANA Considerations
Option Type to be assigned by IANA [RFC2780]. This draft requests an Option Type assignment in the Destination
Options and Hop-by-Hop Options sub-registry of Internet Protocol
Version 6 (IPv6) Parameters [ref to RFCs and URL below].
http://www.iana.org/assignments/ipv6-parameters/ipv6-
parameters.xhtml#ipv6-parameters-2
Hex Value Binary Value Description Reference
act chg rest
-------------------------------------------------------------------
TBD TBD Performance and [This draft]
Diagnostic Metrics
(PDM)
10 References 10 References
10.1 Normative References 10.1 Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[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.
 End of changes. 22 change blocks. 
55 lines changed or deleted 55 lines changed or added

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