< draft-elwalid-icmp-ext-00.txt   draft-elwalid-icmp-ext-01.txt >
Internet Engineering Task Force Lijun Qian Internet Engineering Task Force Lijun Qian
INTERNET-DRAFT Rutgers University INTERNET-DRAFT Rutgers University
Expiration Date: April 2000 Anwar Elwalid Expiration Date: January 2001 Anwar Elwalid
Bell Labs Bell Labs
Indra Widjaja Indra Widjaja
Fujitsu Network Communications Fujitsu Network Communications
ICMP Extension for One-Way Performance Metrics ICMP Extension for One-Way Performance Metrics
<draft-elwalid-icmp-ext-00.txt> <draft-elwalid-icmp-ext-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 4, line 34 skipping to change at page 4, line 34
ICMP Fields: ICMP Fields:
Type Type
41 for probe request message; 41 for probe request message;
42 for probe reply message. 42 for probe reply message.
Code Code
0 for probe data 0 for probe data;
1 for clear;
1 for clear 2 for clear acknowledgement.
2 for clear acknowledge
Checksum Checksum
The checksum is the 16-bit ones's complement of the one's The checksum is the 16-bit ones's complement of the one's
complement sum of the entire ICMP message starting with the complement sum of the entire ICMP message starting with the
ICMP Type field. For computing the checksum, the checksum ICMP Type field. For computing the checksum, the checksum
field should be first set to zero. field should be first set to zero.
Identifier Identifier
skipping to change at page 5, line 41 skipping to change at page 5, line 38
source. The destination encodes a destination Sequence Number source. The destination encodes a destination Sequence Number
to notify the source how many probe packets have been received to notify the source how many probe packets have been received
by the destination. by the destination.
If the time is not available in microseconds or cannot be If the time is not available in microseconds or cannot be
provided with respect to midnight UT then any time can be provided with respect to midnight UT then any time can be
inserted in a timestamp provided the high order bit of the inserted in a timestamp provided the high order bit of the
timestamp is also set to indicate this non-standard value. timestamp is also set to indicate this non-standard value.
ICMP message type 41 and 42 SHOULD be implemented in all internet ICMP message type 41 and 42 SHOULD be implemented in all internet
hosts that support one-way traffic measurement. hosts to support one-way traffic measurement.
The delay of a packet on any route can be obtained by transmitting The delay of a packet on any route can be obtained by transmitting
an ICMP probe request packet from the source to the destination. an ICMP probe request packet from the source to the destination.
The ICMP probe request packet is timestamped at the source at The ICMP probe request packet is timestamped at the source at
time t1 and recorded at the destination at time t2. Then (t2-t1) time t1 and recorded at the destination at time t2. Then (t2-t1)
is the total delay adjusted with the time difference between the is the total delay adjusted with the time difference between the
source clock and destination clock. For applications which source clock and destination clock. For applications which
synchronization is needed, estimation of one-way delay may be done synchronization is needed, estimation of one-way delay may be done
based on [9][10]. Network Time Protocol is defined in [11] and is based on [9][10]. Network Time Protocol is defined in [11] and is
beyond the scope of this document. The specific synchronization beyond the scope of this document. The specific synchronization
technique which determines the accuracy of the measurement is technique which determines the accuracy of the measurement is
beyond the scope of this document. beyond the scope of this document.
When an ICMP probe reply packet returns, the source is able to When an ICMP probe reply packet returns, the source is able to
estimate the one-way packet loss rate based on the two estimate the one-way packet loss rate based on the two
sequence numbers encoded in the ICMP probe reply packet. The sequence numbers encoded in the ICMP probe reply packet. The
detailed procedure is included in Appendix 1. The mechanism is detailed procedure is included in Appendix 1. The mechanism is
intended to combat against losses and re-ordering in the reverse intended to combat against losses and re-ordering in the reverse
channel. channel. It is recommended that if responses are reordered, then
It is recommended that if responses are reordered, then the the sender uses the most recent response; that is, the response
sender uses the most recent response; that is, the response
with the higher "x" value. with the higher "x" value.
5. Security Considerations 5. Security Considerations
This memo presents no security considerations beyond those that have This memo presents no security considerations beyond those that have
been presented by current ICMP applications. been presented by current ICMP applications.
6. Acknowledgement 6. Acknowledgement
The authors thank Ron Bonica for useful discussions. The authors thank Ron Bonica for useful discussions.
skipping to change at page 6, line 37 skipping to change at page 6, line 35
[1] RFC 792, "Internet Control Message Protocol", J.Postel, Sep.,1981. [1] RFC 792, "Internet Control Message Protocol", J.Postel, Sep.,1981.
[2] RFC 1122, "Requirements for Internet hosts -- Communication layers, [2] RFC 1122, "Requirements for Internet hosts -- Communication layers,
R.Braden ed., Oct.,1989. R.Braden ed., Oct.,1989.
[3] R. Bonica et al., "ICMP Extensions for MPLS", <draft-bonica-icmp- [3] R. Bonica et al., "ICMP Extensions for MPLS", <draft-bonica-icmp-
mpls-01.txt>, May 1999. mpls-01.txt>, May 1999.
[4] Internetworking with TCP/IP, vol.1 (3rd. Ed.), D.E.Comer, Prentice [4] Internetworking with TCP/IP, vol.1 (3rd. Ed.), D.E.Comer, Prentice
Hall, Inc., 1995. Hall, Inc., 1995.
[5] Internet Draft: MATE: MPLS Adaptive Traffic Engineering, Indra Widjaja [5] Internet Draft: MATE: MPLS Adaptive Traffic Engineering, Indra Widjaja
and Anwar Elwalid, July, 1998. <draft-widjaja-mpls-mate-00.txt>. and Anwar Elwalid, July, 1998. <draft-widjaja-mpls-mate-00.txt>.
[6] RFC 2330, "Framework for IP Performance Metrics", V.Paxson et.al., [6] RFC 2330, "Framework for IP Performance Metrics", V.Paxson et.al.,
May, 1998. May,1998.
[7] RFC 2679, "A One-way Delay Metric for IPPM", G.Almes et.al., [7] RFC 2679, "A One-way Delay Metric for IPPM", G.Almes et.al.,
Sep.1999. Sep.1999.
[8] RFC 2680, "A One-way Packet Loss Metric for IPPM", G.Almes et.al., [8] RFC 2680, "A One-way Packet Loss Metric for IPPM", G.Almes et.al.,
Sep.1999. Sep.1999.
[9] RFC 956, "Algorithms for Synchronizing Network Clocks", D.L.Mills, [9] RFC 956, "Algorithms for Synchronizing Network Clocks", D.L.Mills,
Sep.1985. Sep.1985.
[10]RFC 957, "Experiments in Network Clock Synchronization", D.L.Mills, [10]RFC 957, "Experiments in Network Clock Synchronization", D.L.Mills,
Sep.1985. Sep.1985.
[11]RFC 1305, "Network Time Protocol(Ver.3) - Specification, [11]RFC 1305, "Network Time Protocol(Ver.3) - Specification,
Implementation and Analysis", D.L.Mills, Mar.1992. Implementation and Analysis", D.L.Mills, Mar.1992.
8. Authors' Addresses:
Lijun Qian
Department of Electrical Engineering
Rutgers University
Email: ljqian@ece.rutgers.edu
Anwar Elwalid
Bell Labs Lucent Technologies
Murray Hill, NJ 07974, USA
Phone: 908 582-7589
Email: anwar@lucent.com
Indra Widjaja
Fujitsu Network Communications
Two Blue Hill Plaza
Pearl River, NY 10965, USA
Phone: 914-731-2244
Email: indra.widjaja@fnc.fujitsu.com
Appendix 1. Appendix 1.
If an endpoint (sender or receiver) wants to terminate the If an endpoint (sender or receiver) wants to terminate the
measurement phase and clears its state, it sends an ICMP packet with measurement phase and clears its state, it sends an ICMP packet with
Code = 1. Upon receiving this, the recipient is obligated to Code = 1. Upon receiving this, the recipient is obligated to
acknowledge this with Code = 2. This exchange should be reliable in acknowledge this with Code = 2. This exchange should be reliable in
the sense that the endpoint keeps re-transmitting, if neccessary, the sense that the endpoint keeps re-transmitting, if neccessary,
until it receives the acknowledgement. until it receives the acknowledgement.
Sender behavior: Sender behavior:
0. Create ICMP control block and set Source_Sequence_Number = 1. 0. Create ICMP control block and set Source_Sequence_Number = 1.
1. Send an ICMP Request. 1. Send an ICMP Request with Originate_Timestamp = t1.
2. Set an inter-probe interval timer. 2. Set an inter-probe interval timer.
3. If receive a Reply with Source_Sequence_Number = x, and 3. If receive a Reply with Source_Sequence_Number = x, and
Destination_Sequence_Number = y, Destination_Sequence_Number = y,
updates one-way packet loss to 1 - y / x. updates one-way packet loss to 1 - y / x.
4. If measurement is completed, 4. If receive a Reply with Code = 1
Clear control block, if any.
Acknowledge with Code = 2
Go to 7.
5. If measurement is completed,
# clear measurement # clear measurement
Send ICMP Request with Code = 1 Send ICMP Request with Code = 1
and wait for an acknowledgement. and wait for an acknowledgement.
Re-transmit until the ack is received. Re-transmit until the ack is received.
Go to 6. Go to 7.
5. If the inter-probe interval timer expires, 6. If the inter-probe interval timer expires,
Increment Source_Sequence_Number. Increment Source_Sequence_Number.
Go to 1. Go to 1.
6. Clear control block and done. 7. Clear control block and done.
Receiver behavior: Receiver behavior:
1. Receive an ICMP Request. 1. Receive an ICMP Request.
2. If (Code = 1) 2. If (Code = 1)
Clear control block, if any. Clear control block, if any.
Acknowledge with Code = 2 Acknowledge with Code = 2 Go to 5.
Go to 5.
3. If <Source_IP, Dest_IP, Identifier> is not found, 3. If <Source_IP, Dest_IP, Identifier> is not found,
# this is the first packet in the train # this is the first packet in the train
Create an ICMP control block. Create an ICMP control block.
Set Destination_Sequence_Number to 1. Set Destination_Sequence_Number to 1.
S <- Source_Sequence_Number. S <- Source_Sequence_Number.
Send an ICMP Reply. Send an ICMP Reply with Receive_Timestamp = t2.
Set a timer for the control block Set a timer for the control block
Clear control block if timer expires Clear control block if timer expires
Else # this is the succeding packet Else # this is the succeding packet
If (Source_Sequence_Number > S) If (Source_Sequence_Number > S)
S <- Source_Sequence_Number. S <- Source_Sequence_Number.
Increment Destination_Sequence_Number Increment Destination_Sequence_Number
Send an ICMP Reply. Send an ICMP Reply with Receive_Timestamp =
t2.
Else Else
# out-of-order packet is detected # out-of-order packet is detected
# clear measurement # clear measurement
Send ICMP Reply with Code = 1 Send ICMP Reply with Code = 1
and wait for an acknowledgement. and wait for an acknowledgement.
Re-transmit until the ack is received. Re-transmit until the ack is received.
Clear control block Clear control block
Go to 5. Go to 5.
4. Go to 1. 4. Go to 1.
5. Done. 5. Done.
 End of changes. 16 change blocks. 
42 lines changed or deleted 25 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/