IPv6 Working Group Jian Zhang Hongfei Chen Internet Draft Huawei Techonologies Expires: October 2006 April 7, 2006 IPv6 measurement header draft-jian-ipv6-meaheader-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 7, 2006. Jian et al. Expires October 7, 2006 [Page 1] Internet-Draft meaheader April 2006 Copyright Notice Copyright (C) The Internet Society (2006). All Rights Reserved. Abstract The purpose of this document is to introduce a measurement header. Measurement header is a new type of IPv6 extended header used for network measurement. The information needed by measurement carried in measurement header. The parameters can be calculated based on these information. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Table of Contents 1. Introduction................................................3 2. Application scenario.........................................3 2.1. Scenario 1: One-way measurement.........................3 2.2. Scenario 2: Two-way measurement.........................4 2.3. Scenario 3: High layer protocol measurement.............4 3. Measurement header..........................................5 3.1. Format.................................................5 3.2. Measurement Options.....................................6 3.2.1. Measurement Options Format.........................7 3.2.2. Pad1..............................................7 3.2.3. PadN..............................................8 3.2.4. Entry Time Stamp...................................8 3.2.5. Exit Time Stamp....................................9 4. IANA considerations........................................10 5. Security Considerations.....................................10 6. References.................................................11 6.1. Normative References...................................11 6.2. Informative References.................................11 Author's Addresses............................................11 Intellectual Property Statement................................12 Disclaimer of Validity........................................12 Copyright Statement...........................................12 Acknowledgment................................................13 Jian et al. Expires October 7, 2006 [Page 2] Internet-Draft meaheader April 2006 1. Introduction This document describes a measurement header for IPv6 specification. Measurement header is an IPv6 extended header used by network performance measurement. This document also defines some measurement options used to carry measurement information. Some application scenarios that measurement header can be used are described. 2. Application scenario 2.1. Scenario 1: One-way measurement One-way measurement is an important method to assess the performance of IP network. The performance parameters, such as IP packet delay, IP packet delay variation and so on, are used to assess the status of network. In the traditional measurement methodology, delay is calculated by t2, the time that packet arrives destination node, minus t1, the time that packet leaves source node. They are got from source node and destination node by complex protocol and special packets. For IPv6 with measurement header, source node records the time stamp (t1) when sends measurement packet, and destination node records the time stamp (t2) when receives the measurement packet. The delay of packet can be directly calculated by t2 minus t1. In the measurement, source node increases the sequence of measurement header. If the sequence is not continuum or disorder, then there may be packets lost or disorder in the network. Test packets with Measurement Header -----------------------------------------> IPv6 Network ------------------------- Source Node | | Destination Node -------- | | -------- | | | | | | | |------| |------| | -------- | | -------- | | ------------------------- Figure 1: Scenario 1 Jian et al. Expires October 7, 2006 [Page 3] Internet-Draft meaheader April 2006 2.2. Scenario 2: Two-way measurement Two-way performance of network is important for some applications, such as voice/video message, transactions and so on. When performing two-way measurement, source node records time stamp and sends request measurement packet. When received the request packet, destination node records the time stamp when the packet was received, copies the time stamp in request packet to reply packet, records time stamp when the packet was sent, and sends the reply packet to source node. Source node records time stamp of reply packet. The delay for total and segments can be calculated by t2 (entry time stamp) minus t1 (exit time stamp). Request packets with Measurement Header -----------------------------------------> Ack Packets with Measurement Header <----------------------------------------- IPv6 Network ------------------------- Source Node | | Destination Node -------- | | -------- | | | | | | | |------| |------| | -------- | | -------- | | ------------------------- Figure 2: Scenario 2 2.3. Scenario 3: High layer protocol measurement Using IPv6 Measurement Header, it is convenience to measure IP performance. It can also measure high layer protocol performance, such as TCP, UDP, FTP, DHCP, HTTP and so on, worked together with high layer protocols. It can simplify the measurement of high layer protocols by inserted the measurement header into high layer protocols packets. High layer protocol can calculate the performance parameters based on the information carried in measurement header. Jian et al. Expires October 7, 2006 [Page 4] Internet-Draft meaheader April 2006 3. Measurement header 3.1. Format The measurement header is identified by a Next Header value in the immediately preceding header. The value should be assigned by IANA. The measurement header has the following format: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Proto | Header Len | MH Type |I|O| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | . . . Message Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Measurement Header format. Payload Proto 8-bit selector. Identifies the type of header immediately following the Measurement Header. Uses the same values as the IPv6 Next Header field [IPv6]. Header Len 8-bit unsigned integer, representing the length of the Measurement Header in units of 8 octets, excluding the first 8 octets. The length of the Measurement Header MUST be a multiple of 8 octets. MH Type 8-bit selector. Identifies the particular measurement message in question. An unrecognized MH Type field MUST be discard silently. Current values are specified as follow: o 0 - unidirectional measurement message o 1 - request message of bi-directional measurement Jian et al. Expires October 7, 2006 [Page 5] Internet-Draft meaheader April 2006 o 2 - reply message of bi-directional messurement I flag o 0 - don't record the time stamp that the packet entry the interface. o 1 - record the time stamp that the packet entry the interface. O flag o 0 - don't record the time stamp that the packet exits the interface. o 1 - record the time stamp that the packet exits the interface. Reserved 6-bit field reserved for future use. The value MUST be initialized to zero by the sender, and MUST be ignored by the receiver. Sequence A 16-bit unsigned integer used by receiving node to sequence request measurement message and by the sending node to match a returned reply measurement message with this request message. Message Data A variable length field containing the data specific to the indicated measurement header type and flags. 3.2. Measurement Options Measurement messages can include zero or more measurement options. This allows optional fields that may not be needed in every use of a particular Measurement Header, as well as future extensions to the format of the messages. Such options are included in the message data field of the message itself, after the fixed portion of the message data. The presence of measurement options will be indicated by the Header Len of the Measurement Header. Jian et al. Expires October 7, 2006 [Page 6] Internet-Draft meaheader April 2006 3.2.1. Measurement Options Format Measurement options use a type-length-value (TLV) format 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Length | Option Data... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Measurement Options TLV format. Option Type 8-bit identifier of the type of measurement option. When processing a Measurement Header containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST quietly ignore and skip over the option, correctly handling any remaining options in the message. Option Length 8-bit unsigned integer, representing the length in octets of the measurement option, not including the Option Type and Option Length fields. Option Data A variable length field that contains data specific to the option. 3.2.2. Pad1 The Pad1 option has format as follows: 0 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Type = 0 | +-+-+-+-+-+-+-+-+ Figure 5: Pad1 option format NOTE! The format of the Pad1 option is a special case - it has neither Option Length nor Option Data fields. The Pad1 option is used to insert one octet of padding in the Measurement Options area of a Measurement Header. If more than one octet of padding is required, the PadN option, described next, should be used rather than multiple Pad1 options. Jian et al. Expires October 7, 2006 [Page 7] Internet-Draft meaheader April 2006 3.2.3. PadN The PadN option has format as follow: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | Type = 1 | Option Length | Option Data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - Figure 6: PadN option format The PadN option is used to insert two or more octets of padding in the Measurement Options area of a measurement message. For N octets of padding, the Option Length field contains the value N-2, and the Option Data consists of N-2 zero-valued octets. PadN Option data MUST be ignored by the receiver. 3.2.4. Entry Time Stamp Entry Time Stamp has format as follow: 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 = 2 | Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Recorded IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Time Stamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Entry Time Stamp Option Format Entry Time Stamp option is used to record the time when the device has received the packet from link. Recorded IPv6 Address is a unicast routable IPv6 address identified the device that processed this packet. This address should be identical with the address in Exit Time Stamp Option. Jian et al. Expires October 7, 2006 [Page 8] Internet-Draft meaheader April 2006 Time Stamp Option is the time that the packet has been received by the device. The time stamp follows the format defined in [NTP]. It is a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits. 3.2.5. Exit Time Stamp Exit Time Stamp has format as follow: 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 = 3 | Length = 24 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Recorded IPv6 Address + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Time Stamp + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Exit Time Stamp Option Format Exit Time Stamp option is used to record the time when the device forwards the packet to link. Recorded IPv6 Address is a unicast routable IPv6 address identified the device that processed this packet. This address should be identical with the address in Entry Time Stamp Option. Time Stamp Option is the time that the packet forwards to link by the device. The time stamp follows the format defined in [NTP]. It is a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits and the fraction part in the last 32 bits. If the end-to-end delay needs to be calculated, the source node should record Exit Time Stamp Option, and the destination node should record the Entry Time Stamp Option. The end-to-end delay can be Jian et al. Expires October 7, 2006 [Page 9] Internet-Draft meaheader April 2006 calculated by destination Entry Time Stamp minus source Exit Time Stamp. 4. IANA considerations IANA services are required for this document. The values for new measurement header and measurement options must be assigned from the IPv6 [IPv6] numbering space. 5. Security Considerations IPv6 already contains mechanism for security. As a result, the vulnerabilities of the new measurement header defined in this document are similar to those that already exist for IPv6. Measurement header only provides a basic instrument used for IPv6 network performance measurement. This document does not provide any methodology used for IPv6 network performance measurement. The security need to be considered by the measurement methodology using the measurement options. Jian et al. Expires October 7, 2006 [Page 10] Internet-Draft meaheader April 2006 6. References 6.1. Normative References [IPv6] Stephen E. Deering. and Robert M. Hinden. "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, Cisco Systems, Inc., December 1998. [NTP] David L. Mills. "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992. [IPDV] Carlo Demichelis. and Philip Chimento. "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [NPM] Vilho Raisanen. and Glenn Grotefeld. "Network performance measurement with periodic streams", RFC 3432, November 2002. [OWAMP] Stanislav Shalunov. and Benjamin Teitelbaum. "One-way Active Measurement Protocol (OWAMP) Requirements", RFC 3763, April 2004. [FIPM] Vern Paxson and Guy Almes. "Framework for IP Performance Metrics", RFC 2330, May 1998. [IPPM] Jamshid Mahdavi. and Vern Paxson. "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. 6.2. Informative References [Y.1540] "Internet protocol data communication service - IP packet transfer and availability performance parameters", ITU-T, 12/2002 Author's Addresses Jian Zhang Huawei Technologies Co., LTD. No. 3 Xinxi Road, Shangdi, HaiDian District, Beijing City, The P.R.China Email: hwzhj@huawei.com Jian et al. Expires October 7, 2006 [Page 11] Internet-Draft meaheader April 2006 HongFei Chen Huawei Technologies Co., LTD. No. 3 Xinxi Road, Shangdi, HaiDian District, Beijing City, The P.R.China Email: chenhongfei@huawei.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). Jian et al. Expires October 7, 2006 [Page 12] Internet-Draft meaheader April 2006 This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jian et al. Expires October 7, 2006 [Page 13]