Network Working Group E. Stephan Internet-Draft France Telecom Expires: September 15, 2005 L. Liang University of Surrey March 17, 2005 IP Performance Metrics (IPPM) metrics for spatial and multicast draft-stephan-ippm-multimetrics-00.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 September 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract The IETF IP Performance Metrics (IPPM) working group has standardized metrics for measuring end-to-end performance between 2 points. This memo defines 2 sets of metrics to extend these end-to-end ones. It defines spatial metrics for measuring the performance of segments along a path and metrics for measuring the performance of a group of users in multiparty communications. Stephan & Liang Expires September 15, 2005 [Page 1] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1 Multiparty metric . . . . . . . . . . . . . . . . . . . . 5 2.2 Spatial metric . . . . . . . . . . . . . . . . . . . . . . 5 2.3 One-to-group metric . . . . . . . . . . . . . . . . . . . 5 3. Motivations for multiparty metrics . . . . . . . . . . . . . . 5 4. Spatial metrics definitions . . . . . . . . . . . . . . . . . 6 4.1 A Definition for Spatial One-way Delay Stream . . . . . . 6 4.2 A Definition for Spatial One-way Packet Loss Stream . . . 8 4.3 A Definition for Spatial One-way Jitter Stream . . . . . . 9 4.4 Discussion on spatial statistics . . . . . . . . . . . . . 10 5. One-to-group metrics definitions . . . . . . . . . . . . . . . 10 5.1 A Definition for one-to-group One-way Delay Stream . . . . 10 5.2 A Definition for one-to-group One-way Packet Loss Stream . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3 A Definition for one-to-group One-way Jitter Stream . . . 12 5.4 Discussion on one-to-group statistics . . . . . . . . . . 13 6. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 16 8.2 Informative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . . 18 Stephan & Liang Expires September 15, 2005 [Page 2] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 1. Introduction The metrics specified in this memo are built on notions introduced and discussed in the IPPM Framework document, RFC 2330 [RFC2330]. The reader should be familiar with these documents. This memo makes use of definitions of end-to-end One-way Delay Metrics defined in the RFC 2679 [RFC2679] to define metrics for decomposition of end-to-end one-way delays measurements. This memo makes use of definitions of end-to-end One-way Packet loss Metrics defined in the RFC 2680 [RFC2680] to define metrics for decomposition of end-to-end one-way packet loss measurements. The IPPM defined a framework for metric definitions and end-to-end measurements: o A general framework for defining performance metrics, described in the Framework for IP Performance Metrics, RFC 2330 [RFC2330]; o A One-way Active Measurement Protocol Requirements, RFC 3763 [RFC3763]; o A One-way Active Measurement Protocol (OWAMP) [work in progress]; o An IP Performance Metrics Registry [work in progress]; It specified a set of end-to-end metrics, which conform to this framework: o The IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]; o The One-way Delay Metric for IPPM, RFC 2679 [RFC2679]; o The One-way Packet Loss Metric for IPPM, RFC 2680 [RFC2680]; o The Round-trip Delay Metric for IPPM, RFC 2681 [RFC2681]; o A Framework for Defining Empirical Bulk Transfer Capacity Metrics RFC 3148 [RFC3148]; o One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357]; o IP Packet Delay Variation Metric for IPPM, RFC 3393 [RFC3393]; o Network performance measurement for periodic streams, RFC 3432 [RFC3432]; Stephan & Liang Expires September 15, 2005 [Page 3] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 o Packet Reordering Metric for IPPM [Work in progress]; Based on these works, this memo defines 2 kinds of multi party metrics. Firstly it defines spatial metrics: o Using the Type-P-One-way-Delay metric, a 'sample', called Type-P-Spatial-One-way-Delay-Stream, will be introduced to decompose an end-to-end Type-P-One-way-Delay in a spatial sequence of one-way delays. o Using the Type-P-Spatial-One-way-Delay-Stream metric, a 'sample', called Type-P-Spatial-One-way-Packet-Loss-Stream, will be introduced to decompose an end-to-end Type-P-One-way-Packet-Loss in a spatial sequence of packet loss. o Using the Type-P-Spatial-One-way-Delay-Stream metric, a 'sample', called Type-P-Spatial-One-way-Jitter-Stream, will be introduced to decompose an end-to-end Type-P-One-way-ipdv in a spatial sequence of jitter. Then it defines one-to-group metrics. o Using one test packet sent from one sender to a group of receivers, a 'sample', called Type-P-one-to-group-One-way-Delay-Stream, will be introduced to define the list of Type-P-one-way-delay between this sender and the group of receivers. o Using one test packet sent from one sender to a group of receivers, a 'sample', called Type-P-one-to-group-One-way-Packet-Loss-Stream, will be introduced to define the list of Type-P-One-way-Packet-Loss between this sender and the group of receivers o Using one test packet sent from one sender to a group of receivers, a 'sample', called Type-P-one-to-group-One-way-Jitter-Stream, will be introduced to define the list of Type-P-One-way-ipdv between this sender and the group of receivers o Then a discussion section presents the set of statistics that may be computed on the top of these metrics to present the QoS in a view of a group of users as well as the requirements of relative QoS on multiparty communications. Stephan & Liang Expires September 15, 2005 [Page 4] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 2. Terminology 2.1 Multiparty metric A metric is said to be multiparty if the definition involved two or more measurement points. 2.2 Spatial metric A metric is said to be spatial if one of the hosts involved is neither the source nor the destination of the metered packet. 2.3 One-to-group metric A metric is said to be one-to-group if the measured packet is sent by one source and received by several destinations. 3. Motivations for multiparty metrics All IPPM metrics are defined for end-to-end measurement. These metrics provide very good guides for measurement in the pair communications. However, further efforts should be put to define metrics for multiparty measurements such as one to one trajectory metrics and one to multipoints metrics. To understand the connection situation between one source and any one receiver in the multiparty communication group, we need the decomposition of instantaneous end-to-end measures. It will give us very detailed insight into each branch of the routing tree in terms of node-to-node absolute QoS. It can provide clear and helpful information for engineers to identify the connection with problems in a complex multiparty routing tree. Decomposition of instantaneous end-to-end measures is needed: o The PCE WG requires definitions of protocol-independent metrics for measuring path quality. The minimum criteria are spatial one-way delay, spatial packet loss and spatial jitter. o The PSAMP WG defines capabilities to sample packets in a way to to support measurement. Defining spatial one-way metrics provides PSAMP and IPPM measurement frameworks with common definition to measure trajectory performance. o Traffic engineering and troubleshooting applications require spatial views of the one-way delay consumption and packet loss location identification. Stephan & Liang Expires September 15, 2005 [Page 5] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 o Monitoring the QoS of point-to-multipoint and inter-domain communication require spatial decomposition of the one-way delay and of the packet loss. While the node-to-node based spatial measures can provide very useful data in the view of each connection, we also need measures to present the performance of a multiparty communication in the view of a group with consideration that it involves a group of people rather than two. As a consequence a simple one-way metric cannot describe the multi-connection situation. We need some new metrics to collect performance of all the connections for further statistics analysis. A group of metrics are proposed in this stage named one-to-group performance metrics based on the unicast metrics defined in IPPM WG. One-to-group performance metrics are needed for several reasons: o For designing and engineering multicast trees and MPLS point-to-multipoint LSP; o For evaluating and controlling of the quality of the multicast services; o For controlling the performance of the inter domain multicast services; o For presenting and evaluating the relative QoS requirements for the multiparty communications. 4. Spatial metrics definitions 4.1 A Definition for Spatial One-way Delay Stream This section is coupled with the definition of Type-P-One-way-Delay. Consequently when a parameter from section 3 of [RFC2679] is first used in this section, it will be tagged with a trailing asterisk. 4.1.1 Metric Name Type-P-Spatial-One-way-Delay-Stream Stephan & Liang Expires September 15, 2005 [Page 6] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 4.1.2 Metric Parameters + Src*, the IP address of the sender. + Dst*, the IP address of the receiver. + i, An integer which ordered the hosts in the path. + Hi, exchange points of the path digest. + T*, a time. + dT* a delay, + dT1,..., dTn a list of delay. + P*, the specification of the packet type. + , a path digest. 4.1.3 Metric Units A sequence of times. 4.1.4 Definition Given a Type-P packet sent by the sender Src at wire-time (first bit) T to the receiver Dst in the path . Given the sequence of values such that dT is the Type-P-One-way-Delay from Src to Dst and such that for each Hi of the path, T+dTi is either a real number corresponding to the wire-time the packet passes (last bit received) Hi, or undefined if the packet never passes Hi. Type-P-Spatial-One-way-Delay-Stream metric is defined for the path as the sequence of values . 4.1.5 Discussion and Methodologies TODO: See sections 3.5 and 3.6 of [RFC2679]. TODO: discuss the impact of the MP location in the passive decive with PSAMP: wiretime of the last bit of the packet on the receiver side' seems appropriate. Stephan & Liang Expires September 15, 2005 [Page 7] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 4.2 A Definition for Spatial One-way Packet Loss Stream This section is coupled with the definition of Type-P-One-way-Packet-Loss. Then when a parameter from the section 2 of [RFC2680] is first used in this section, it will be tagged with a trailing asterisk. 4.2.1 Metric Name Type-P-Spatial-One-way-Packet-Loss-Stream 4.2.2 Metric Parameters + Src*, the IP address of the sender. + Dst*, the IP address of the receiver. + i, An integer which ordered the hosts in the path. + Hi, exchange points of the path digest. + T*, a time. + dT1,..., dTn, dT, a list of delay. + P*, the specification of the packet type. + , a path digest. + B1, B2, ..., Bi, ..., Bn, a list of boolean. 4.2.3 Metric Units A sequence of booleans. 4.2.4 Definition Given a Type-P packet sent by the sender Src at time T to the receiver Dst in the path . Given the sequence of times the packet passes , Type-P-One-way-Packet-Lost-Stream metric is defined as the sequence of values such that for each Hi of the path, a value of Bi of 0 means that dTi is a finite value, and a value of 1 means that dTi is undefined. Stephan & Liang Expires September 15, 2005 [Page 8] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 4.3 A Definition for Spatial One-way Jitter Stream This section uses parameters from the definition of Type-P-One-way-ipdv. When a parameter from section 2 of [RFC3393] is first used in this section, it will be tagged with a trailing asterisk. 4.3.1 Metric Name Type-P-Spatial-One-way-Jitter-Stream 4.3.2 Metric Parameters + Src*, the IP address of the sender. + Dst*, the IP address of the receiver. + i, An integer which ordered the hosts in the path. + Hi, exchange points of the path digest. + T1*, the time the first apcket was sent. + T2*, the time the second apcket was sent. + P, the specification of the packet type. + P1, the first packet sent at time T1. + P2, the second packet sent at time T2. + , a path digest. + , the Type-P-Spatial-One-way-Delay-Stream for packet sent at time T1; + , the Type-P-Spatial-One-way-Delay-Stream for packet sent at time T2; + L*, a packet length in bits. The packets of a Type P packet stream from which the Type-P-Spatial-One-way-Delay-Stream metric is taken MUST all be of the same length. Stephan & Liang Expires September 15, 2005 [Page 9] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 4.3.3 Metric Units A sequence of times. 4.3.4 Definition Given the Type-P packet having the size L and sent by the sender Src at wire-time (first bit) T1 to the receiver Dst in the path . Given the Type-P packet having the size L and sent by the sender Src at wire-time (first bit) T2 to the receiver Dst in the same path. Given the Type-P-Spatial-One-way-Delay-Stream of the packet P1. Given the Type-P-Spatial-One-way-Delay-Stream of the packet P2. Type-P-Spatial-One-way-Jitter-Stream metric is defined as the sequence of values Such that for each Hi of the path, dT2.i-dT1.i is either a real number if the packets P1 and P2 passes Hi at wire-time (last bit)dT1.i, respectively dT2.i, or undefined if at least one of them never passes Hi. T2-T1 is the inter-packet emission interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv at T1,T2*. 4.3.5 Discussion and Methodologies TODO: See sections ?? and ?? of [RFC3393]. TODO: discuss the fact that the path may change: T2-T1 should be very small. max 1 ms ? 4.4 Discussion on spatial statistics TODO 5. One-to-group metrics definitions 5.1 A Definition for one-to-group One-way Delay Stream 5.1.1 Metric Name Type-P-one-to-group-One-way-Delay-Stream Stephan & Liang Expires September 15, 2005 [Page 10] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 5.1.2 Metric Parameters + Src, the IP address of a host acting as the source. + Recv1,..., RecvN, the IP addresses of the N hosts acting as receivers. + T, a time. + dT1,...,dTn a list of time. + P, the specification of the packet type. 5.1.3 Metric Units The value of a Type-P-one-to-group-One-way-Delay-Stream is a set of singletons metrics Type-P-One-way-Delay [RFC2679]. 5.1.4 Definition Given a Type P packet sent by the source Src at Time T, given the N hosts { Recv1,...,RecvN } which receive the packet at the time { T+dT1,...,T+dTn }, a Type-P-one-to-group-One-way-Delay-Stream is defined as the set of the Type-P-One-way-Delay singleton between Src and each receiver with value of { dT1, dT2,...,dTn }. 5.2 A Definition for one-to-group One-way Packet Loss Stream 5.2.1 Metric Name Type-P-one-to-group-One-way-Packet-Loss-Stream 5.2.2 Metric Parameters + Src, the IP address of a host acting as the source. + Recv1,..., RecvN, the IP addresses of the N hosts acting as receivers. + T, a time. + T1,...,Tn, a list of time. + P, the specification of the packet type. Stephan & Liang Expires September 15, 2005 [Page 11] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 5.2.3 Metric Units The value of a Type-P-one-to-group-One-way-Packet-Loss-Stream is a set of singletons metrics Type-P-One-way-Packet-Loss [RFC2680]. 5.2.4 Definition Given a Type P packet sent by the source Src at T and the N hosts, Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a Type-P-one-to-group-One-way-Packet-Loss-Stream is defined as a set of the Type-P-One-way-Packet-Loss singleton between Src and each of the receivers {,,..., }. 5.3 A Definition for one-to-group One-way Jitter Stream 5.3.1 Metric Name Type-P-one-to-group-One-way-Jitter-Stream 5.3.2 Metric Parameters + Src, the IP address of a host acting as the source. + Recv1,..., RecvN, the IP addresses of the N hosts acting as receivers. + T1, a time. + T2, a time. + ddT1,...,ddTn, a list of time. + P, the specification of the packet type. + F, a selection function defining unambiguously the two packets from the stream selected for the metric. 5.3.3 Metric Units The value of a Type-P-one-to-group-One-way-Jitter-Stream is a set of singletons metrics Type-P-One-way-ipdv [RFC3393]. 5.3.4 Definition Given a Type P packet stream, Type-P-one-to-group-One-way- Jitter-Stream is defined for two packets from the source Src to the N Stephan & Liang Expires September 15, 2005 [Page 12] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 hosts {Recv1,...,RecvN },which are selected by the selection function F, as the difference between the value of the Type-P-one-to-group-One-way-Delay-Stream from Src to { Recv1,..., RecvN } at time T1 and the value of the Type-P-one-to-group- One-way-Delay-Stream from Src to { Recv1,...,RecvN } at time T2. T1 is the wire-time at which Scr sent the first bit of the first packet, and T2 is the wire-time at which Src sent the first bit of the second packet. This metric is derived from the Type-P-one-to- group-One-way-Delay-Stream metric. Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one- to-group-One-way-Jitter-Stream from Src to { Recv1,...,RecvN } at T1, T2 is {ddT1,...,ddTn} means that Src sent two packets, the first at wire-time T1 (first bit), and the second at wire-time T2 (first bit) and the packets were received by { Recv1,...,RecvN } at wire-time {dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time {dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 5.4 Discussion on one-to-group statistics The defined one-to-group metrics above can all be directly achieved from the relevant unicast one-way metrics. They managed to collect all unicast measurement results of one-way metrics together in one profile and sort them by receivers and packets in a multicast group. They can provide sufficient information regarding the network performance in terms of each receiver and guide engineers to indentify patential problem happened on each branch of a multicast routing tree. However, these metrics can not be directly used to conveniently present the performance in terms of a group and neither to identify the relative QoS situation. One may say that no matter how many people join the communication, the connections can still be treated as a set of one-to-one connection. However, we might not describe a multiparty communication by a set of one-way measurement metrics because of the difficulty for understanding and the lack of convenience. For instance, an engineer might not describe the connections of a multiparty online conference in terms of one-to-group one-way delay for user A and B, B and C, and C and A because people might be confused. If there are more users in the same communication, the description might be very long. And he might use the one-way metrics with worst and the best value to give users an idea of the QoS range of the service they are providing. But it is not clear enough and might not be accurate in a large multiparty communication scenario. From the QoS point of view, the multiparty communication services not only require the absolute QoS support but also the relative QoS. The Stephan & Liang Expires September 15, 2005 [Page 13] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 relative QoS means the difference between absolute QoS of all users. Directly using the one-way metrics cannot present the relative QoS situation. However, if we use the variations of all users one-way parameters, we can have new metrics to measure the difference of the absolute QoS and hence provide the threshold value of relative QoS that a multiparty service might demand. A very good example of the high relative QoS requirement is the online gaming. A very light worse delay will result in failure in the game. We have to use the new statitic metrics to define exactly how small the relative delay the online gaming requires. There are many other services, e.g. online biding, online stock market, etc., need a rule to judge the relative QoS requirement. Therefore, we can see the importance of new statistic metrics to feed this need. We might use some one-to-group statistic conceptions to present the group performance and relative QoS. In this stage, we define one-to-group mean stream and one-to-group variation stream. These statistics are offered mostly to be illustrative of what could be done. One-to-group mean streams are trying to measure the overall QoS for a multicast group associated to one source. It is a reflection of the absolute QoS of a multiparty communication service when we treat all receivers as one customer. It can also present the trend of the absolute QoS of all receivers, i.e., it shows that most of the receivers in the multiparty communication service trend to receive an absolute QoS close to the mean. One-to-group variation streams are trying to measure how the QoS varies among all of the users in a multicast group associated to one source. The word "variation" in this memo is the population standard deviation. It reflects the relative QoS situation in a multiparty communication service, i.e., the level of the difference between the absolute QoS of each receivers. Using the one-to-group mean and one-to-group variation concepts, we can have a much clear understand on the QoS of a multiparty communication service in terms of its trend and range. There can be mean and variation stream definitions for each of the three one-to-group metrics defined above. We only present the definition of Type-P-one-to-group-One-way- Delay-Mean-Stream and Type-P-one-to-group-One-way-Delay-Variation-Stream as examples in this memo. 5.4.1 Type-P-one-to-group-One-way-Delay-Mean-Stream Given a Type-P-one-to-group-One-way-Delay-Stream, the mean stream of all { dT1, dT2,...,dTn } for the packet from Src at time T to { Stephan & Liang Expires September 15, 2005 [Page 14] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 Recv1,...,RecvN }. For example, suppose we take a sample and the results are: Delay_Stream = < {T1,...,Tn} {T'1,...,T'n} {T''1,...T''n} > Then the mean stream would be: Delay_Mean_Stream = < DM1 DM2 DM3 > = < sum{T1,...,Tn}/n sum{T'1,...,T'n}/n sum{T''1,...T''n}/n > 5.4.2 Type-P-one-to-group-One-way-Delay-Variation-Stream Given a Type-P-one-to-group-One-way-Delay-Stream, the variation stream of all { dT1, dT2,...,dTn } for the packet from Src at time T to { Recv1,...,RecvN }. We still take the above Delay_Stream as a sample and the variation stream would be: Delay_Variation_Stream = < DV1 DV2 DV3 > =< (SUM{(T1-DM1)^2,...,(Tn-DM1)^2)}/n)^(1/2) (SUM{(T'1-DM2)^2,...,(T'n-DM2)^2)}/n)^(1/2) (SUM{(T''1-DM3)^2,...,(T''n-DM3)^2)}/n)^(1/2) > 6. Open issues Do we define statistic for spatial delay, loss and jitter ? Stephan & Liang Expires September 15, 2005 [Page 15] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 7. Security Considerations TODO: see owd pl, jitter rfc. TODO: Add a sentence on relation with passive. TODO: one-to-group metrics defined here are not intrusive: they rely on measures of owd... 8. References 8.1 Normative References [RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2679] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. 8.2 Informative References [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [RFC2681] Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001. [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample Metrics", RFC 3357, August 2002. [RFC3432] Raisanen, V., Grotefeld, G. and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002. [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active Measurement Protocol (OWAMP) Requirements", RFC 3763, Stephan & Liang Expires September 15, 2005 [Page 16] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 April 2004. Authors' Addresses Stephan Emile France Telecom Division R & D 2 avenue Pierre Marzin Lannion, F-22307 Fax: +33 2 96 05 18 52 EMail: emile.stephan@francetelecom.com Lei Liang CCSR, University of Surrey Guildford Surrey, GU2 7XH Fax: +44 1483 683641 EMail: L.Liang@surrey.ac.uk Stephan & Liang Expires September 15, 2005 [Page 17] Internet-Draft Spatial and Multicast Metrics for IPPM March 2005 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 (2005). 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. Stephan & Liang Expires September 15, 2005 [Page 18]