Internet Engineering Task Force Lijun Qian INTERNET-DRAFT Rutgers University Expiration Date: April 2000 Anwar Elwalid Bell Labs Indra Widjaja Fujitsu Network Communications ICMP Extension for One-Way Performance Metrics Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract In this document we define two new ICMP message types. These new types of ICMP messages can be used as probe packets to support a variety of measurement applications. This draft gives detailed definition and format of these two new ICMP message types. It is in full conformance with the original RFC on ICMP [1], and complements the work of the IPPM working group [6][7][8]. The extension of ICMP for one-way traffic measurement is also useful for traffic engineering. 1. Introduction The Internet Control Message Protocol (ICMP) allows hosts/routers to Elwalid et al. Expires April 2000 [Page 1] Internet Draft ICMP Extension for One-Way Performance October 1999 send error or control messages to other hosts/routers. ICMP provides communication between the Internet Protocol software on one machine and the Internet Protocol software on another[4]. ICMP is considered a required part of IP and must be included in every IP implementation. Although ICMP messages are encapsulated and sent using IP, ICMP is NOT considered a higher level protocol than IP. 2. One-Way Performance Metrics One-way performance metrics such as one-way delay and one-way loss are useful in many situations. Unfortunately, the current ICMP messages do not accommodate format that would facilitate such measurements. ICMP messages type 15 and 16, information request and information reply messages, are now considered obsolete and should NOT be implemented by hosts [2]. In this document, we propose adding two message types that would enable one-way measurements. 3. Backward Compatibility ICMP extensions proposed in this document MUST be backward compatible with the syntax described in RFC-792 [1]. 4. Probe Request and Reply The ICMP messages types are listed below in table 1. Type Name Reference ---- ------------------------- -------------------- 0 Echo Reply [RFC792] 1 Unassigned [JBP] 2 Unassigned [JBP] 3 Destination Unreachable [RFC792] 4 Source Quench [RFC792] 5 Redirect [RFC792] 6 Alternate Host Address [JBP] 7 Unassigned [JBP] 8 Echo [RFC792] 9 Router Advertisement [RFC1256] 10 Router Selection [RFC1256] 11 Time Exceeded [RFC792] 12 Parameter Problem [RFC792] 13 Timestamp [RFC792] 14 Timestamp Reply [RFC792] 15 Information Request [RFC792] (obsolete) Elwalid et al. Expires April 2000 [Page 2] Internet Draft ICMP Extension for One-Way Performance October 1999 16 Information Reply [RFC792] (obsolete) 17 Address Mask Request [RFC950] 18 Address Mask Reply [RFC950] 19 Reserved (for Security) [Solo] 20-29 Reserved (for Robustness Experiment) [ZSu] 30 Traceroute [RFC1393] 31 Datagram Conversion Error [RFC1475] 32 Mobile Host Redirect [David Johnson] 33 IPv6 Where-Are-You [Bill Simpson] 34 IPv6 I-Am-Here [Bill Simpson] 35 Mobile Registration Request [Bill Simpson] 36 Mobile Registration Reply [Bill Simpson] 37 Domain Name Request [Simpson] 38 Domain Name Reply [Simpson] 39 SKIP [Markson] 40 Photuris [Simpson] 41-255 Reserved [JBP] Table 1. The ICMP messages types The format of ICMP message type 41 for Probe Request and type 42 for Probe Reply (need to get the official types from the IANA) is encoded as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originate Timestamp (first 4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Originate Timestamp (next 4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp (first 4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Timestamp (next 4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As described in [1], all ICMP messages begin with the same 3 fields: Type field (8 bits), Code field (8 bits) and Checksum field (16 bits). Elwalid et al. Expires April 2000 [Page 3] Internet Draft ICMP Extension for One-Way Performance October 1999 The type field indicates the type of the message. Its value determines the format of the remaining data. The code field depends on the message type. It is used to create an additional level of message granularity. The checksum field is used to detect data corruption in the entire ICMP message. IP Fields: Addresses The address of the source in a probe request message MUST be the destination of the probe reply message. To form a probe reply message, the source and destination addresses are simply reversed, the type value changed to 42, and the checksum recomputed. ICMP Fields: Type 41 for probe request message; 42 for probe reply message. Code 0 for probe data 1 for clear 2 for clear acknowledge Checksum The checksum is the 16-bit ones's complement of the one's complement sum of the entire ICMP message starting with the ICMP Type field. For computing the checksum, the checksum field should be first set to zero. Identifier An identifier to aid in matching probe replies to probe requests. The identifier of a probe reply is obtained from the invoking probe request. Elwalid et al. Expires April 2000 [Page 4] Internet Draft ICMP Extension for One-Way Performance October 1999 Description The identifier may be used by the sender to aid in matching the replies with the requests. For example, the identifier might be used like a port in TCP or UDP to identify a session. The destination returns these same values in the reply. The data received (a probe) in the probe request message is returned in the probe reply together with additional information on receive timestamp and destination sequence number. All timestamps are 64 bits. The current time is expressed in elapsed seconds and microseconds since 00:00 Universal Coordinated Time, January 1, 1970. The resolution of the system clock is hardware dependent; the time may be updated continuously or in clock ticks. The Originate Timestamp is the time the sender last touches the message before sending it, the Receive Timestamp is the time the receiver first touches the message on receipt. The first four octets record the time in seconds, and the next four octets give the microseconds granularity. The source encodes a Source Sequence Number to notify the destination how many probe packets have been transmitted by the source. The destination encodes a destination Sequence Number to notify the source how many probe packets have been received by the destination. If the time is not available in microseconds or cannot be provided with respect to midnight UT then any time can be inserted in a timestamp provided the high order bit of the timestamp is also set to indicate this non-standard value. ICMP message type 41 and 42 SHOULD be implemented in all internet hosts that support one-way traffic measurement. The delay of a packet on any route can be obtained by transmitting an ICMP probe request packet from the source to the destination. The ICMP probe request packet is timestamped at the source at time t1 and recorded at the destination at time t2. Then (t2-t1) is the total delay adjusted with the time difference between the source clock and destination clock. For applications which synchronization is needed, estimation of one-way delay may be done based on [9][10]. Network Time Protocol is defined in [11] and is beyond the scope of this document. The specific synchronization technique which determines the accuracy of the measurement is Elwalid et al. Expires April 2000 [Page 5] Internet Draft ICMP Extension for One-Way Performance October 1999 beyond the scope of this document. When an ICMP probe reply packet returns, the source is able to estimate the one-way packet loss rate based on the two sequence numbers encoded in the ICMP probe reply packet. The detailed procedure is included in Appendix 1. The mechanism is intended to combat against losses and re-ordering in the reverse channel. It is recommended that if responses are reordered, then the sender uses the most recent response; that is, the response with the higher "x" value. 5. Security Considerations This memo presents no security considerations beyond those that have been presented by current ICMP applications. 6. Acknowledgement The authors thank Ron Bonica for useful discussions. 7. Reference [1] RFC 792, "Internet Control Message Protocol", J.Postel, Sep.,1981. [2] RFC 1122, "Requirements for Internet hosts -- Communication layers, R.Braden ed., Oct.,1989. [3] R. Bonica et al., "ICMP Extensions for MPLS", , May 1999. [4] Internetworking with TCP/IP, vol.1 (3rd. Ed.), D.E.Comer, Prentice Hall, Inc., 1995. [5] Internet Draft: MATE: MPLS Adaptive Traffic Engineering, Indra Widjaja and Anwar Elwalid, July, 1998. . [6] RFC 2330, "Framework for IP Performance Metrics", V.Paxson et.al., May, 1998. [7] RFC 2679, "A One-way Delay Metric for IPPM", G.Almes et.al., Sep.1999. [8] RFC 2680, "A One-way Packet Loss Metric for IPPM", G.Almes et.al., Sep.1999. [9] RFC 956, "Algorithms for Synchronizing Network Clocks", D.L.Mills, Sep.1985. [10]RFC 957, "Experiments in Network Clock Synchronization", D.L.Mills, Sep.1985. [11]RFC 1305, "Network Time Protocol(Ver.3) - Specification, Implementation and Analysis", D.L.Mills, Mar.1992. Elwalid et al. Expires April 2000 [Page 6] Internet Draft ICMP Extension for One-Way Performance October 1999 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. If an endpoint (sender or receiver) wants to terminate the measurement phase and clears its state, it sends an ICMP packet with Code = 1. Upon receiving this, the recipient is obligated to acknowledge this with Code = 2. This exchange should be reliable in the sense that the endpoint keeps re-transmitting, if neccessary, until it receives the acknowledgement. Sender behavior: 0. Create ICMP control block and set Source_Sequence_Number = 1. 1. Send an ICMP Request. 2. Set an inter-probe interval timer. 3. If receive a Reply with Source_Sequence_Number = x, and Destination_Sequence_Number = y, updates one-way packet loss to 1 - y / x. 4. If measurement is completed, # clear measurement Send ICMP Request with Code = 1 and wait for an acknowledgement. Re-transmit until the ack is received. Go to 6. 5. If the inter-probe interval timer expires, Increment Source_Sequence_Number. Go to 1. 6. Clear control block and done. Elwalid et al. Expires April 2000 [Page 7] Internet Draft ICMP Extension for One-Way Performance October 1999 Receiver behavior: 1. Receive an ICMP Request. 2. If (Code = 1) Clear control block, if any. Acknowledge with Code = 2 Go to 5. 3. If is not found, # this is the first packet in the train Create an ICMP control block. Set Destination_Sequence_Number to 1. S <- Source_Sequence_Number. Send an ICMP Reply. Set a timer for the control block Clear control block if timer expires Else # this is the succeding packet If (Source_Sequence_Number > S) S <- Source_Sequence_Number. Increment Destination_Sequence_Number Send an ICMP Reply. Else # out-of-order packet is detected # clear measurement Send ICMP Reply with Code = 1 and wait for an acknowledgement. Re-transmit until the ack is received. Clear control block Go to 5. 4. Go to 1. 5. Done. Elwalid et al. Expires April 2000 [Page 8]