Network Working Group E. Stephan Internet Draft France Telecom R&D draft-stephan-ippm-test-packet-header-00.txt June 21, 2002 IPPM metrics measurement packet Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 Despite the growing availability of good measurement platforms, it is still impossible to generalize IPPM metrics measurement among heterogeneous points of measure. To do so, a set of measurement packets has to be standardized. This document defines an IPPM measurement packet suitable for performing the measure of the current IPPM metrics, for integrating those used by manufacturers and for allowing the IPPM WG to define other measurement packets in the future. Table of Contents 1. Introduction................................................2 2. Motivations and Goals.......................................2 3. The IPPM Framework..........................................3 4. Terminology.................................................3 4.1. Measurement packet definition...............................4 4.2. Measurement packet header (MPH).............................4 5. State of the art............................................4 5.1. ICMP........................................................4 Stephan Informational - Expires December 2002 [Page 1] Internet Draft IPPM measurement packet June 2002 5.2. Type-P......................................................4 5.3. Wire time and time stamping.................................5 5.4. Existing measurement fields.................................5 5.5. OWAMP requirements..........................................6 5.6. Interoperability requirements...............................6 5.7. SUB IP and IPNG needs.......................................7 5.8. Relationship with other organization........................7 6. IPPM Measurement packet framework...........................7 6.1. Measurement packet identification...........................8 6.2. RFC2330 Type-P..............................................8 6.3. RFC2330 Wire time and time stamping.........................8 6.4. IPPM measurement packet format..............................8 6.5. State machine limitation....................................8 6.6. Packet sequence number......................................9 6.7. Measure initiator scope.....................................9 6.8. Measurement packet length constraint........................9 6.9. Security....................................................9 7. Measurement packets headers definition.....................10 7.1. OWDP Test Packet...........................................10 7.2. MPH Base definition........................................11 7.3. Field type value...........................................11 7.4. Interdomain MPH............................................11 7.5. RoundtripDelay MPH.........................................12 7.6. Interdomain RoundtripDelay MPH.............................12 7.7. MPH with CRC...............................................12 7.8. Extension to the MPH Extension.............................13 7.9. Applicability statements...................................13 8. References.................................................14 9. Author's Addresses.........................................14 1. Introduction This document defines a framework for the definition of an IPPM measurement packet suitable for performing the measure of the current IPPM metrics, for integrating those used by manufacturers and for allowing the IPPM WG to define other measurement packets in the future. 2. Motivations and Goals Despite the growing availability of good measurement platforms, it is still impossible to generalize IPPM metrics measurement among heterogeneous points of measure. To do so, a set of measurement packets has to be standardized. There is a need for interoperability among heterogeneous manufacturer equipments to measure the performance of IP networks for different Type-P. Stephan Informational - Expires December 2002 [Page 2] Internet Draft IPPM measurement packet June 2002 This effort is motivated too by the need to perform end-to-end measures across administrative areas. Currently there are only two solutions. The first one consists in the concatenation of spatial metrics. The accuracy of the concatenation of spatial metrics is extremely variable. The measurements are performed per segment path. The packets metered are different. The Type-P used may be different. The wire time is systematically different. ICMP use is generalized but does not allow the description of the different Type-P needed in the measurement packets. The standardization of the access to the results of the measure of the metrics defined by the IPPM WG is a 'work in progress'. The proxy mode of the IPPM Reporting MIB provides a system of measure with an exchange point for the results of the measure. One limitation is the incapacity to generalize end-to-end measures. The main reason is the lack of standard measurement packets. This memo analyses the state of the art in the domain, then it defines a framework for the standardization of the measurement packets. Finally it proposes and motivates a definition for a measurement packet. 3. The IPPM Framework The IPPM Framework consists in 4 major components: + A general framework for defining performance metrics, described in the Framework for IP Performance Metrics, RFC 2330; + A set of standardized metrics, which conform to this framework. The IPPM Metrics for Measuring Connectivity, RFC 2678 [2]. The One-way Delay Metric for IPPM, RFC 2679 [3]. The One- way Packet Loss Metric for IPPM, RFC 2680 [4]. The Round-trip Delay Metric for IPPM, RFC 2681 [5]; + Emerging metrics which are being specified in respect of this framework; + A Reporting MIB to exchange the results of the measures. It is an interface between a system of measure and the administrative entities interested in these results. This proxy controls the access to the results. These entities use the results to compute statistics and aggregated metrics. 4. Terminology Stephan Informational - Expires December 2002 [Page 3] Internet Draft IPPM measurement packet June 2002 4.1. Measurement packet definition A Measurement packet is a regular Internet packet. It contains 3 semantic units, the packet header, the packet data and the measurement packet data. They are combined to produce a regular packet that encapsulates a measurement packet. The measurement packet data reuses the header of the packet to define the type-P of the packet and inserts a measurement packet header somewhere in the packet data. 4.2. Measurement packet header (MPH) It is a contiguous block of fields which semantics is specific to IPPM measures. The semantic of the fields does not depend on those of the Type-P. It is named 'measurement packet header' (MPH). 5. State of the art As Internet is designed for 'best effort' the specifications do not include the control of the quality of service provided. The IPPM WG has started an effort to standardize the protocols for measuring the performance of the network. It encounters 2 main issues. The measurement packets must not be easy to detect by the network equipments and must be easy to detect by measurement tools. The standard solution must be easy to implement and must not be a security hole. This section analyses the existing solutions and extracts the common parts to provide inputs for a first proposal. 5.1. ICMP ICMP if the only test packet that is standardized. There is no doubt that it is dramatically used. On the other hand ICMP has serious limitations. It cannot emulate type-P like UDP or TCP. 5.2. Type-P The Type-P corresponds to the suite of protocols present in the IP and SUB IP headers of the packet. Software based devices inserts the data needed for the measure after the header of the packets to increase the speed of the processing in the source and in the sink. The format of this measurement packet Stephan Informational - Expires December 2002 [Page 4] Internet Draft IPPM measurement packet June 2002 header differs according to the Type-P. It changes typically when fields of the packet header are used as data for the measurement. As the length of the header of the packet change with the Type-P, hardware based devices encapsulate a fixed length MPH near or at the end of the packet. It simplifies dramatically the design because the measurement data are located in the regular part of the packets. It generalizes the concept of Type-P for IPng, SUB IP and permit operational interoperability among heterogeneous SUB IP links. It facilitates the extraction of the MPH on the receiver's side. Both hardware and software solutions used the header of the packet to define the type-P, insert a MPH in the payload of the packets. They satisfy to the first issue. They differ on the location of the MPH in the packet. The hardware framework looks easier to standardize because the MPH is fixed length and is at a fixed location. 5.3. Wire time and time stamping This IPPM framework defines the wire time of a packet inserted on the network as the time that the last bit of the packets is sent. Most of the hardware implementations insert the timestamp on the fly and complement the binary value of the packet in a timestamp complement field. The delay between the timestamp insertion and the packet insertion on the wire is deterministic. The timestamp inserted is increased by the value of this delay while preserving the accuracy of the timestamp. This technique is generalized for link rate over gigabit/s. It is very accurate but requires larger field. Software devices do not share a common technique. The timestamp is inserted at different places, at different time according to the implementation and the operating system. There is not a common technique to adjust the timestamp value. The delay between the timestamp insertion and the packet insertion on the wire is not deterministic and introduces an initial jitter. 5.4. Existing measurement fields As the existing solutions implement the IPPM metrics they share the same semantic even if the fields order, name, unit, size and detailed semantic are different. The common fields are the following: The device that has sent the packet; The interface that has sent the packet; The stream, the packet belongs to; Stephan Informational - Expires December 2002 [Page 5] Internet Draft IPPM measurement packet June 2002 The absolute timestamp corresponding to the time the packet is sent; The complement of this absolute timestamp; The sequence number of the packet; The absolute timestamp corresponding to the time the packet is received; The complement of this absolute timestamp; A checksum computed on the previous fields. 5.5. OWAMP requirements The IPPM WG is standardizing a measurement protocol. The requirements are listed in the "A One-way Active Measurement Protocol Requirements" (draft-ietf-ippm-owdp-reqs-01.txt). The test protocol needs to have the following characteristics: + Be lightweight and easy to implement. + Be suitable for implementation on a wide range of measurement nodes. + Since the protocol needs to be able to measure individual packet delivery time and has to run on various machines, it needs to support UDP as transport protocol. + It should be possible to use varying packet sizes and network services, as negotiated using OWDP-Control. + To be a lowest common denominator, OWDP-Test packet format should only include universally meaningful fields, and minimum number of them. + It should be possible to make packets generated by OWDP-Test as small as possible, to be able to accurately measure paths where packet-splitting technologies such as ATM are used. 5.6. Interoperability requirements The requirement is to have operational interoperability among heterogeneous manufacturers and to perform one-way delay measurement across administrative areas. Inter domain interoperability and interoperability between heterogeneous manufacturers devices do not differ. The meaning of the common fields has to be adapted to the interoperability context. In a test involving heterogeneous equipments the values set up by the source have no meaning for the sink. The meaning of the administrative fields must be set by an entity common to the source and the sink. A field value sets by the source has no meaning Stephan Informational - Expires December 2002 [Page 6] Internet Draft IPPM measurement packet June 2002 for the sink excepted if the value refer to a shared referential. A typical example is the need to create a referential for the time. The issue does not consist only in having the MPH format to be recognized. The main need is to have the results of the measurement packets to be assigned to the same measure setup in the sink and in the source. The measure must be identified in the MHP. It must include a field that identifies the measure in the scope of the initiator of the measure. 5.7. SUB IP and IPNG needs The measurement packet must consider the measure of the performance of multicast services, mobile IP services and Ipv6. The protocol translation mechanisms and the coexistence between Ipv4 and Ipv6 are potential sources of interoperability of the measures. 5.8. Relationship with other organization The aim is to increase operational interoperability. Basically it consists in promoting the need to share the same measurement packets identification mechanism to unambiguously detect the measurements packets and avoid overlapping regarding the fields' values chosen. 6. IPPM Measurement packet framework The aim is to provide quickly a standard packet format to perform measurements of the IPPM metrics across administrative areas and among heterogeneous devices. The framework has the following requirements: + Respects the IPPM Framework requirements (RFC2330) regarding the Type-P and the accuracy; + Respects the requirements for the test protocol of OWAMP; + Specifies a format that allows the integration of the future needs; + Specifies a test packet format for including the MPH in regular packets; + Integrates the existing test packets format and concepts whenever it is possible. The requirements and the needs may be gathered in a strong constraint: to have operational interoperability among heterogeneous manufacturers and to perform one-way delay measurement across administrative areas for the different Type-P, including those that have short packet-length constraints. Stephan Informational - Expires December 2002 [Page 7] Internet Draft IPPM measurement packet June 2002 The basic Type-P are obviously UDP and TCP. 6.1. Measurement packet identification To distinguish measurement packets among regular packets, the last field of the MPH is a protocol identifier. 6.2. RFC2330 Type-P The header of the packet defines the type-P of the test packet from the network point of view. 6.3. RFC2330 Wire time and time stamping There is a strong requirement in the IPPM framework to have a timestamp consistent with the time the packet is inserted on the network. The specification must not increase the complexity of the time stamping at multi gigabit rates. The timestamp complement field is ignored by the metering task of the sink and is not required for software implementation. If this timestamp complement is the first field of the MPH it may be optional without introducing interoperability problems. 6.4. IPPM measurement packet format It integrates in the same definition the manufacturers formats and the IPPM measurement packet format. It reuses the concept of the measurement packet for high-speed rates, which inserts the MPH at the end of payload: The measurement packet inserts a 'measurement packet protocol identifier' field at the end of the measurement packet. This minimizes the modifications that have to be done in the manufactured solutions. It integrates the manufacturers in a standard framework and offers them proprietary evolution capabilities. It allows the IPPM WG to define several versions of the measurement packets, so it permits the definition of one format without introducing limitation in the future. 6.5. State machine limitation To guaranty operational interoperability the model is stateless excepted for semantic needs such as packet sequence order and security. That does not preclude the definition of more complex test packets in the future. Stephan Informational - Expires December 2002 [Page 8] Internet Draft IPPM measurement packet June 2002 6.6. Packet sequence number More and more services cross gateways. They may change the sequence numbering of the packets in the header (e.g. the initial value). A lot of metrics computation relies on the analysis of the order of the packets. To provide a trustable sequence of results there is a need for the sequence number to be integrated in the MPH. A proposal is to have it optional and to locate it at the beginning of the MPH, just after the timestamp complement. 6.7. Measure initiator scope The management framework of the IPPM-REPORTING-MIB defines a namespace for each initiator (owner) of a measure. Each measure is identified by its owner and by the number chosen by the initiator for this measure within its scope. These values provides to the source and sink with a shared identifier. This field is mandatory to discriminate concomitant measures set up between 2 points measures. It permits different initiators to set up measures concerning different metrics and Type-P. The fields 'device identifier', 'interface identifier' and 'stream identifier' are replaced with the fields 'initiator identifier' and 'measure identifier'. 6.8. Measurement packet length constraint Measurement messages must be variable length. It must support UDP as transport protocol and must be as small as possible especially for packet-splitting technologies such as ATM. The encapsulation on an UDP/Ipv4 datagram in an ATM cell, using AAL5 and the RFC1484 leaves 4 bytes free for the MPH (payload(48) - RFC1484(8) - IP(20) -UDP(8) -AAL5(8)). It is impossible to send a measurement packet of Type-P UDP in one ATM cell. On the other hand if it is considered that in ATM networks the QOS depends on the VCI characteristics and does not consider the embedded type-P of the IP packet, then the MPH length should be 12 bytes. Voip services need strong QOS control and have fixed message length. The length of the UDP payload is 28 bytes (12 RTP and 16 data). 6.9. Security To avoid the measurements systems to be used to make attacks there is a strong requirement to propose a security mechanism. The aim is to Stephan Informational - Expires December 2002 [Page 9] Internet Draft IPPM measurement packet June 2002 determine the different levels of security applicable in an inter domain and in a heterogeneous framework. The trivial level of security corresponds to measurement packets without security mechanism. A first level consists in concatenating the fields 'initiator identifier' and 'measure identifier' in a field 'signature'. The signature is computed using a key shared by the source and the sink. This level increases the integrity, the authentication of the MPH. It makes it very difficult for 'the man in the middle' to detect the type of measure, the measure and its initiator. More complex security mechanisms may be defined. 7. Measurement packets headers definition The fields are: MPH CRC or Checksum; MPH CRC or Checksum complement; Rx Timestamp complement; Rx Timestamp; Tx Timestamp complement; Tx Timestamp; Sqce number; Measure Id; Owner Id; Pro; MPH Version; Protocol Id. The optional fields are: MPH CRC or Checksum; MPH CRC or Checksum complement; Rx Timestamp complement; Rx Timestamp; Tx Timestamp complement. The proposal is to define 3 measurements packets headers, one which length is optimized, a second one, which take in account the needs for interdomain measurement and a third one, which is designed for high- speed measurement devices. 7.1. OWDP Test Packet Stephan Informational - Expires December 2002 [Page 10] Internet Draft IPPM measurement packet June 2002 The "One-way Delay Measurement Protocol" defines a unauthenticated test packet as following: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Integer part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Fractional part of seconds |S|U| Prec | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.2. MPH Base definition The proposed MPH is very closed to the OWDP definition. It is 12 bytes length. Its length corresponds to an Ipv4 packet sent in a single AAL5 cell. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | Pro |Type |Ver| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |E| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The bit E is used to indicate an extended PDU and to distinguish MPH from OWDP test packets. 7.3. Field type value type=1 : Interdomain MPH type=2 : RoundtripDelay MPH type=3 : Interdomain RoundtripDelay MPH type=4 : MPH with CRC 7.4. Interdomain MPH 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Owner Id | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Measure Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds | Stephan Informational - Expires December 2002 [Page 11] Internet Draft IPPM measurement packet June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | Pro |Type |Ver| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |E| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.5. RoundtripDelay MPH 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | Pro |Type |Ver| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |E| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.6. Interdomain RoundtripDelay MPH The MPH is 28 bytes length which corresponds to the length of a Voip PDU. Type is 1+2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Timestamp | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Owner Id | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Measure Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | Pro |Type |Ver| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |E| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.7. MPH with CRC Stephan Informational - Expires December 2002 [Page 12] Internet Draft IPPM measurement packet June 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | Pro |Type |Ver| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |E| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.8. Extension to the MPH Extension Manufacturers may insert proprietary extension at the beginning of the MPH while preserving measurement interoperability. The field 'Pro' indicates the number of blocks of 8 bytes, which carried proprietary data. 7.9. Applicability statements 7.9.1. On-the-fly timestamping on-the-fly insertion of timestamps requires the insertion of 1- complement fields to keep the checksum unchanged. 1-complement are considered as proprietary extension. The 1-complement fields are inserted at the beginning of the MPH As 'Rx Timestamp' is present 'type' has the value 2. As there are 2 blocks of 8 bytes the value of Pro is 2 ('Pro' is definitively a bad name for 'proprietary'). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Timestamp complement | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp complement | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rx Timestamp | Stephan Informational - Expires December 2002 [Page 13] Internet Draft IPPM measurement packet June 2002 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Integer part of seconds | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tx Timestamp Fractional part of seconds | Pro |Type |Ver| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number |E| Protocol Id | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8. References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [3] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [5]Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay Metric for IPPM.", RFC 2681, September 1999. 9. Author's Addresses Emile STEPHAN France Telecom R & D 2 avenue Pierre Marzin F-22307 Lannion cedex Phone: (+ 33) 2 96 05 11 11 Email: emile.stephan@francetelecom.com Full Copyright Statement "Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this Stephan Informational - Expires December 2002 [Page 14] Internet Draft IPPM measurement packet June 2002 document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Stephan Informational - Expires December 2002 [Page 15]