idnits 2.17.1 draft-ietf-ippm-multimetrics-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1956. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1967. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1980. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 426: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 531: '... [RFC2679] says that the path traversed by the packet SHOULD be...' RFC 2119 keyword, line 554: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 666: '...loss measurement SHOULD be respectful ...' RFC 2119 keyword, line 741: '...ipdv measurement SHOULD be respectful ...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1, 2007) is 6265 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) ** Obsolete normative reference: RFC 4148 (Obsoleted by RFC 6248) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Stephan 3 Internet-Draft France Telecom 4 Intended status: Informational L. Liang 5 Expires: September 2, 2007 University of Surrey 6 A. Morton 7 AT&T Labs 8 March 1, 2007 10 IP Performance Metrics (IPPM) for spatial and multicast 11 draft-ietf-ippm-multimetrics-03 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 2, 2007. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2007). 42 Abstract 44 The IETF IP Performance Metrics (IPPM) working group has standardized 45 metrics for measuring end-to-end performance between 2 points. This 46 memo defines 2 sets of metrics to extend these end-to-end ones. It 47 defines spatial metrics for measuring the performance of segments 48 along a path and metrics for measuring the performance of a group of 49 users in multiparty communications. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.1. Multiparty metric . . . . . . . . . . . . . . . . . . . . 6 56 2.2. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 6 57 2.3. Spatial metric points of interest . . . . . . . . . . . . 6 58 2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 6 59 2.5. One-to-group metric points of interest . . . . . . . . . . 6 60 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 6 61 2.7. Vector . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.8. Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3. Motivations for spatial and one-to-group metrics . . . . . . . 8 64 3.1. spatial metrics . . . . . . . . . . . . . . . . . . . . . 8 65 3.2. One-to-group metrics . . . . . . . . . . . . . . . . . . . 9 66 3.3. Discussion on Group-to-one and Group-to-group metrics . . 10 67 4. Spatial metrics definitions . . . . . . . . . . . . . . . . . 10 68 4.1. A Definition for Spatial One-way Delay Vector . . . . . . 10 69 4.2. A Definition of a sample of One-way Delay of a sub path . 13 70 4.3. A Definition for Spatial One-way Packet Loss Vector . . . 16 71 4.4. A Definition for Spatial One-way Jitter Vector . . . . . . 17 72 4.5. Pure Passive Metrics . . . . . . . . . . . . . . . . . . . 19 73 4.6. Discussion on spatial statistics . . . . . . . . . . . . . 21 74 5. One-to-group metrics definitions . . . . . . . . . . . . . . . 21 75 5.1. A Definition for one-to-group One-way Delay . . . . . . . 21 76 5.2. A Definition for one-to-group One-way Packet Loss . . . . 22 77 5.3. A Definition for one-to-group One-way Jitter . . . . . . . 22 78 6. One-to-Group Sample Statistics . . . . . . . . . . . . . . . . 24 79 6.1. Discussion on the Impact of packet loss on statistics . . 26 80 6.2. General Metric Parameters . . . . . . . . . . . . . . . . 27 81 6.3. One-to-Group one-way Delay Statistics . . . . . . . . . . 28 82 6.4. One-to-Group one-way Loss Statistics . . . . . . . . . . . 31 83 6.5. One-to-Group one-way Delay Variation Statistics . . . . . 33 84 7. Measurement Methods: Scaleability and Reporting . . . . . . . 33 85 7.1. Computation methods . . . . . . . . . . . . . . . . . . . 34 86 7.2. Measurement . . . . . . . . . . . . . . . . . . . . . . . 35 87 7.3. effect of Time and Space Aggregation Order on Group 88 Stats . . . . . . . . . . . . . . . . . . . . . . . . . . 35 89 7.4. effect of Time and Space Aggregation Order on Spatial 90 Stats . . . . . . . . . . . . . . . . . . . . . . . . . . 37 91 8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 37 92 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37 93 9.1. passive measurement . . . . . . . . . . . . . . . . . . . 37 94 9.2. one-to-group metric . . . . . . . . . . . . . . . . . . . 37 95 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 96 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 98 12.1. Normative References . . . . . . . . . . . . . . . . . . . 42 99 12.2. Informative References . . . . . . . . . . . . . . . . . . 43 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 101 Intellectual Property and Copyright Statements . . . . . . . . . . 45 103 1. Introduction 105 The metrics specified in this memo are built on notions introduced 106 and discussed in the IPPM Framework document, RFC 2330 [RFC2330]. 107 The reader should be familiar with these documents. 109 This memo makes use of definitions of end-to-end One-way Delay 110 Metrics defined in the RFC 2679 [RFC2679] to define metrics for 111 decomposition of end-to-end one-way delays measurements. 113 This memo makes use of definitions of end-to-end One-way Packet loss 114 Metrics defined in the RFC 2680 [RFC2680] to define metrics for 115 decomposition of end-to-end one-way packet loss measurements. 117 The IPPM WG defined a framework for metric definitions and end-to-end 118 measurements: 120 o A general framework for defining performance metrics, described in 121 the Framework for IP Performance Metrics [RFC2330]; 123 o A One-way Active Measurement Protocol Requirements [RFC3763]; 125 o A One-way Active Measurement Protocol (OWAMP) [RFC4656]; 127 o An IP Performance Metrics Registry [RFC4148]; 129 It specified a set of end-to-end metrics, which conform to this 130 framework: 132 o The IPPM Metrics for Measuring Connectivity [RFC2678]; 134 o The One-way Delay Metric for IPPM [RFC2679]; 136 o The One-way Packet Loss Metric for IPPM [RFC2680]; 138 o The Round-trip Delay Metric for IPPM [RFC2681]; 140 o A Framework for Defining Empirical Bulk Transfer Capacity Metrics 141 [RFC3148]; 143 o One-way Loss Pattern Sample Metrics [RFC3357]; 145 o IP Packet Delay Variation Metric for IPPM [RFC3393]; 147 o Network performance measurement for periodic streams [RFC3432]; 149 o Packet Reordering Metric for IPPM [RFC4737][Work in progress]; 150 Based on these works, this memo defines 2 kinds of multi party 151 metrics. 153 Firstly it defines spatial metrics: 155 o A 'sample', called Type-P-Spatial-One-way-Delay-Vector, will be 156 introduced to divide an end-to-end Type-P-One-way-Delay in a 157 spatial sequence of one-way delays. 159 o A 'sample', called Type-P-Spatial-One-way-Packet-Loss-Vector, will 160 be introduced to divide an end-to-end Type-P-One-way-Packet-Loss 161 in a spatial sequence of packet loss. 163 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 164 called Type-P-Spatial-One-way-Jitter-Vector, will be introduced to 165 divide an end-to-end Type-P-One-way-ipdv in a spatial sequence of 166 jitter. 168 o Using the Type-P-Spatial-One-way-Delay-Vector metric, a 'sample', 169 called Type-P-subpath-One-way-Delay-Stream, will be introduced to 170 define the one-way-delay between a pair of host of the path. This 171 metric is similar to Type-P-One-way-Delay-Stream. 173 o Using Type-P-subpath-One-way-Delay-Stream, a 'sample' Type-P- 174 Passive-One-way-Delay-Stream will be introduced to define passive 175 metrics. These metrics are designed for pure passive measurement 176 methodology as introduced by PSAMP WG. 178 Then it defines one-to-group metrics. 180 o Using one test packet sent from one sender to a group of 181 receivers, a 'sample', called Type-P-one-to-group-One-way-Delay- 182 Vector, will be introduced to define the list of Type-P-one-way- 183 delay between this sender and the group of receivers. 185 o Using one test packet sent from one sender to a group of 186 receivers, a 'sample', called Type-P-one-to-group-One-way-Packet- 187 Loss-Vector, will be introduced to define the list of Type-P-One- 188 way-Packet-Loss between this sender and the group of receivers 190 o Using one test packet sent from one sender to a group of 191 receivers, a 'sample', called Type-P-one-to-group-One-way-Jitter- 192 Vector, will be introduced to define the list of Type-P-One-way- 193 ipdv between this sender and the group of receivers 195 o Then a discussion section presents the set of statistics that may 196 be computed on the top of these metrics to present the QoS in a 197 view of a group of users as well as the requirements of relative 198 QoS on multiparty communications. 200 2. Terminology 202 2.1. Multiparty metric 204 A metric is said to be multiparty if the definition involved more 205 than two sources or destinations in the measurements. All multiparty 206 metrics define a set of hosts called "points of interest", where one 207 host is the source and other hosts are the measurement collection 208 points. For example, if the set of points of interest is < ha, hb, 209 hc, ..., hn >, where ha is the source and < hb, hc, ..., hn > are the 210 destinations, then measurements may be conducted between < ha, hb>, < 211 ha, hc>, ..., . 213 2.2. Spatial metric 215 A metric is said to be spatial if one of the hosts involved is 216 neither the source nor the destination of the metered packet. 218 2.3. Spatial metric points of interest 220 Points of interest of a spatial metric are the routers or sibling in 221 the path between source and destination (in addition to the source 222 and the destination themselves). 224 2.4. One-to-group metric 226 A metric is said to be one-to-group if the measured packet is sent by 227 one source and (potentially) received by several destinations. Thus, 228 the topology of the communication group can be viewed as a centre- 229 distributed or server-client topology with the source as the centre/ 230 server in the topology. 232 2.5. One-to-group metric points of interest 234 Points of interest of One-to-group metrics are the set of host 235 destinations receiving packets from the source (in addition to the 236 source itself). 238 2.6. Reference point 240 The centre/server in the one-to-group measurement that is controlled 241 by network operators can be a very good reference point where 242 measurement data can be collected for further processing although the 243 actual measurements have to be carried out at all points of interest. 244 I.e., the measurement points will be all clients/receivers while the 245 reference point acts as source for the one-to-group metric. Thus, we 246 can define the reference point as the host while the statistic 247 calculation will be carried out. 249 2.7. Vector 251 A group of singletons is the set of results of the observation of the 252 behaviour of the same packet at different places of a network. 254 A Vector is a set of singletons, which are a set of results of the 255 observation of the behaviour of the same packet at different places 256 of a network at different time. For instance, if One-way delay 257 singletons observed at N receivers for Packet P sent by the source 258 Src are dT1, dT2,..., dTN, it can be say that a vector V with N 259 elements can be organized as {dT1, dT2,..., dTN}. The elements in 260 one vector are singletons distinct with each other in terms of both 261 measurement point and time. Given the vector V as an example, the 262 element dT1 is distinct from the rest by measured at receiver 1 at 263 time T1. Additional to a singleton, Vector gives information over a 264 space dimension. 266 2.8. Matrix 268 Several vectors can organize form up a Matrix, which contains results 269 observed in a sampling interval at different place of a network at 270 different time. For instance, given One-way delay vectors V1={dT11, 271 dT12,..., dT1N}, V2={dT21, dT22,..., dT2N},..., Vm={dTm1, dTm2,..., 272 dTmN} for Packet P1, P2,...,Pm, we can have a One-way delay Matrix 273 {V1, V2,...,Vm}. Additional to the information given by a Vector, a 274 Matrix is more powerful to present network performance in both space 275 and time dimensions. It normally corresponds to a sample. 277 The relation among Singleton, Vector and Matrix can be shown in the 278 following Figure 1. 280 one-to-group Singleton 281 / Sample 282 Src Recv .............................. 283 .................... 1 R1dT1 R1dT2 R1dT3 R1dT4 284 `:=-.._ 285 T `._ ``-..__ 286 `. `-... 2 R2dT1 R2dT2 R2dT3 R2dT4 287 `-. 288 `-. 289 `.... N R3dT1 R3dT2 R3dT3 R3dT4 291 Vector Matrix 292 (space) (time) 294 Figure 1: Relation beween Singletons, vectors and matrix 296 3. Motivations for spatial and one-to-group metrics 298 All IPPM metrics are defined for end-to-end measurement. These 299 metrics provide very good guides for measurement in the pair 300 communications. However, further efforts should be put to define 301 metrics for multiparty measurements such as one to one trajectory 302 metrics and one to multipoint metrics. 304 3.1. spatial metrics 306 Decomposition of instantaneous end-to-end measures is needed: 308 o Decomposing the performance of interdomain path is desirable in 309 interdomain to qualify per AS contribution to the performance. So 310 it is necessary to define standard spatial metrics before going 311 further in the computation of inter domain path with QoS 312 constraint. 314 o Traffic engineering and troubleshooting applications require 315 spatial views of the one-way delay consumption, identification of 316 the location of the lost of packets and the decomposition of the 317 jitter over the path. 319 o Monitoring the QoS of a multicast tree, of MPLS point-to- 320 multipoint and inter-domain communication require spatial 321 decomposition of the one-way delay, of the packet loss and of the 322 jitter. 324 o Composition of metrics is a need to scale in the measurement 325 plane. Spatial measure give typically the individual performance 326 of an intra domain segment. It is the elementary piece of 327 information to exchange for measuring interdomain performance 328 based on composition of metrics. 330 o The PSAMP WG defines capabilities to sample packets in a way to to 331 support instantaneous measurement respecful of the IPPM framework 332 [RFC2330]. Consequently it is necessary to define a set of 333 spatial metrics for passive and active techniques. 335 3.2. One-to-group metrics 337 While the node-to-node based spatial measures can provide very useful 338 data in the view of each connection, we also need measures to present 339 the performance of a multiparty communication in the view of a group 340 with consideration that it involves a group of people rather than 341 two. As a consequence a simple one-way metric cannot describe the 342 multi-connection situation. We need some new metrics to collect 343 performance of all the connections for further statistics analysis. 344 A group of metrics are proposed in this stage named one-to-group 345 performance metrics based on the unicast metrics defined in IPPM WG. 346 One-to-group metrics are trying to composite one-way metrics from one 347 source to a group of destinations to make up new metrics. The 348 compositions are necessary for judging the network performance of 349 multiparty communications and can also be used to describe the 350 difference of the QoS served among a group of users. 352 One-to-group performance metrics are needed for several reasons: 354 o For designing and engineering multicast trees and MPLS point-to- 355 multipoint LSP; 357 o For evaluating and controlling of the quality of the multicast 358 services; 360 o For controlling the performance of the inter domain multicast 361 services; 363 o For presenting and evaluating the relative QoS requirements for 364 the multiparty communications. 366 To understand the connection situation between one source and any one 367 receiver in the multiparty communication group, we need the 368 collection of instantaneous end-to-end measures. It will give us 369 very detailed insight into each branch of the multicast tree in terms 370 of end-to-end absolute QoS. It can provide clear and helpful 371 information for engineers to identify the connection with problems in 372 a complex multiparty routing tree. 374 The one-to-group metrics described in this memo introduce one-to-many 375 concerns to the IPPM working group to measure the performance of a 376 group of users who receiving data from the same source. The concept 377 extends the "path" in the one-way measurement to "path tree" to cover 378 both one-to-one and one-to-many communications. Nevertheless, 379 applied to one-to-one communications they provide exactly the same 380 results as the corresponding one-to-one metrics. 382 3.3. Discussion on Group-to-one and Group-to-group metrics 384 We note that points of interest can also be selected to define 385 measurements on Group-to-one and Group-to-group topologies. These 386 topologies are currently beyond the scope of this memo, because they 387 would involve multiple packets launched from different sources. 388 However, we can give some clues here on these two cases. 390 The measurements for group-to-one topology can be easily derived from 391 the one-to-group measurement. The measurement point is the reference 392 point that is acting as a receiver while all of clients/receivers 393 defined for one-to-group measurement act as sources in this case. 395 For the group-to-group connection topology, we can hardly define the 396 reference point and, therefore, have difficulty to define the 397 measurement points. However, we can always avoid this confusion by 398 treating the connections as one-to-group or group-to-one in our 399 measurements without consideration on how the real communication will 400 be carried out. For example, if one group of hosts < ha, hb, hc, 401 ..., hn > are acting as sources to send data to another group of 402 hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n 403 one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, 404 Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, 405 ..., Hm >. 407 4. Spatial metrics definitions 409 Spatial decomposition metrics are based on standard end-to-end 410 metrics. 412 The definition of a spatial metric is coupled with the corresponding 413 end-to-end metric. The methodology is based on the measure of the 414 same test packet and parameters of the corresponding end-to-end 415 metric. 417 4.1. A Definition for Spatial One-way Delay Vector 419 This section is coupled with the definition of Type-P-One-way-Delay. 420 When a parameter from section 3 of [RFC2679] is first used in this 421 section, it will be tagged with a trailing asterisk. 423 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 424 statements for end-to-end one-way-delay measurements. They are 425 applicable to each point of interest Hi involved in the measure. 426 Spatial one-way-delay measurement SHOULD be respectful of them, 427 especially those related to methodology, clock, uncertainties and 428 reporting. 430 Following we adapt some of them and introduce points specific to 431 spatial measurement. 433 4.1.1. Metric Name 435 Type-P-Spatial-One-way-Delay-Vector 437 4.1.2. Metric Parameters 439 + Src*, the IP address of the sender. 441 + Dst*, the IP address of the receiver. 443 + i, An integer which ordered the hosts in the path. 445 + Hi, exchange points of the path digest. 447 + T*, a time, the sending (or initial observation) time for 448 a measured packet. 450 + dT* a delay, the one-way delay for a measured packet. 452 + dT1,..., dTn a list of delay. 454 + P*, the specification of the packet type. 456 + , a path digest. 458 4.1.3. Metric Units 460 A sequence of times. 462 4.1.4. Definition 464 Given a Type-P packet sent by the sender Src at wire-time (first bit) 465 T to the receiver Dst in the path . Given the 466 sequence of values such that dT is the 467 Type-P-One-way-Delay from Src to Dst and such that for each Hi of the 468 path, T+dTi is either a real number corresponding to the wire-time 469 the packet passes (last bit received) Hi, or undefined if the packet 470 never passes Hi. 472 Type-P-Spatial-One-way-Delay-Vector metric is defined for the path 473 as the sequence of values 474 . 476 4.1.5. Discussion 478 Following are specific issues which may occur: 480 o the delay looks to decrease: dTi > DTi+1. this seem typically du 481 to some clock synchronisation issue. this point is discussed in 482 the section 3.7.1. "Errors or uncertainties related to Clocks" of 483 of [RFC2679]; 485 o The location of the point of interest in the device influences the 486 result. If the packet is not observed on the input interface the 487 delay includes buffering time and consequently an uncertainty due 488 to the difference between 'wire time' and 'host time'; 490 4.1.6. Interference with other test packet 492 To avoid packet collision it is preferable to include a sequence 493 number in the packet. 495 4.1.7. loss threshold 497 To determine if a dTi is defined or undefined it is necessary to 498 define a period of time after which a packet is considered loss. 500 4.1.8. Methodologies 502 Section 3.6 of [RFC2679] gives methodologies for end-to-end one-way- 503 delay measurements. Most of them apply to each points interest Hi 504 and are relevant to this section. 506 Generally, for a given Type-P, in a given Hi, the methodology would 507 proceed as follows: 509 o At each Hi, prepare to capture the packet sent a time T, take a 510 timestamp Ti', determine the internal delay correction dTi', 511 extract the timestamp T from the packet, then compute the one-way- 512 delay from Src to Hi: dTi = Ti' - dTi' - T. The one-way delay is 513 undefined (infinite) if the packet is not detected after the 'loss 514 threshold' duration; 516 o Gather the set of dTi of each Hi and order them according to the 517 path to build the Type-P-Spatial-One-way-Delay-Vector metric 518 over the path . 520 It is out of the scope of this document to define how each Hi detects 521 the packet. 523 4.1.9. Reporting the metric 525 Section 3.6 of [RFC2679] indicates the items to report. 527 4.1.10. Path 529 It is clear that a end-to-end Type-P-One-way-Delay can't determine 530 the list of hosts the packet passes through. Section 3.8.4 of 531 [RFC2679] says that the path traversed by the packet SHOULD be 532 reported but is practically impossible to determine. 534 This part of the job is provide by Type-P-Spatial-One-way-Delay- 535 Vector metric because each points of interest Hi which capture the 536 packet is part of the path. 538 4.2. A Definition of a sample of One-way Delay of a sub path 540 This metric is similar to the metric Type-P-One-way-Delay-Poisson- 541 stream defined in [RFC2679] and to the metric Type-P-One-way-Delay- 542 Periodic-Stream defined in [RFC3432]. 544 Nevertheless its definition differs because it is based of the 545 division of end-to-end One-way delay using the metric Type-P-Spatial- 546 One-way-Delay-Vector defined above. 548 It aims is to define a sample of One-way-Delay between a pair of 549 hosts of a path usable by active and passive measurements. 551 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 552 statements for end-to-end one-way-delay measurements. They are 553 applicable to each point of interest Hi involved in the measure. 554 Subpath one-way-delay measurement SHOULD be respectful of them, 555 especially those related to methodology, clock, uncertainties and 556 reporting. 558 4.2.1. Metric Name 560 Type-P-subpath-One-way-Delay-Stream 562 4.2.2. Metric Parameters 564 + Src*, the IP address of the sender. 566 + Dst*, the IP address of the receiver. 568 + i, An integer which orders exchange points in the path. 570 + k, An integer which orders the packets sent. 572 + , a path digest. 574 + Ha, a host of the path digest different from Dst and Hb; 576 + Hb, a host of the path digest different from Src and Ha. 577 Hb order in the path must greater that Ha; 579 + Hi, exchange points of the path digest. 581 + dT1,..., dTn a list of delay. 583 + P*, the specification of the packet type. 585 4.2.3. Metric Units 587 A sequence of pairs . 589 T is one of time of the sequence T1...Tn; 591 dt is a delay. 593 4.2.4. Definition 595 Given 2 hosts Ha and Hb of the path , given 596 a flow of packets of Type-P sent from Src to Dst at the times T1, 597 T2... Tn. At each of these times, we obtain a Type-P-Spatial-One- 598 way-Delay-Vector . We define the 599 value of the sample Type-P-subpath-One-way-Delay-Stream as the 600 sequence made up of the couples . dTk.a is the 601 delay between Src and Ha. dTk.b is the delay between Src and Hb. 602 'dTk.b - dTk.a' is the one-way delay experienced by the packet sent 603 at the time Tk by Src when going from Ha to Hb. 605 4.2.5. Discussion 607 Following are specific issues which may occur: 609 o When a is Src is the measure of the first hop. 611 o When b is Dst is the measure of the last hop. 613 o the delay looks to decrease: dTi > DTi+1: 615 * This is typically du to clock synchronisation issue. this point 616 is discussed in the section 3.7.1. "Errors or uncertainties 617 related to Clocks" of of [RFC2679]; 619 * This may occurs too when the clock resolution of one probe is 620 bigger than the minimum delay of a path. As an example this 621 happen when measuring the delay of a path which is 500 km long 622 with one probe synchronized using NTP having a clock resolution 623 of 8ms. 625 o The location of the point of interest in the device influences the 626 result. If the packet is not observed on the input interface the 627 delay includes buffering time and consequently an uncertainty due 628 to the difference between 'wire time' and 'host time'; 630 o dTk.b may be observed and not dTk.a. 632 o Tk is unknown if the flow is made of end user packets, that is 633 pure passive measure. In this case Tk may be forced to Tk+dTk.a. 634 This motivate separate metrics names for pure passive measurement 635 or specific reporting information. 637 o Pure passive measure should consider packets of the same size and 638 of the same Type-P. 640 4.2.6. Interference with other packet 642 4.2.7. loss threshold 644 To determine if a dTi is defined or undefined it is necessary to 645 define a period of time after which a packet is considered loss. 647 4.2.8. Methodologies 649 Both active and passive method should discussed. 651 4.2.9. Reporting the metric 653 Section 3.6 of [RFC2679] indicates the items to report. 655 4.2.10. Path 657 4.3. A Definition for Spatial One-way Packet Loss Vector 659 This section is coupled with the definition of Type-P-One-way-Packet- 660 Loss. Then when a parameter from the section 2 of [RFC2680] is first 661 used in this section, it will be tagged with a trailing asterisk. 663 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 664 statements for end-to-end one-way-Packet-Loss measurements. They are 665 applicable to each point of interest Hi involved in the measure. 666 Spatial packet loss measurement SHOULD be respectful of them, 667 especially those related to methodology, clock, uncertainties and 668 reporting. 670 Following we define the spatial metric, then we adapt some of the 671 points above and introduce points specific to spatial measurement. 673 4.3.1. Metric Name 675 Type-P-Spatial-One-way-Packet-Loss-Vector 677 4.3.2. Metric Parameters 679 + Src*, the IP address of the sender. 681 + Dst*, the IP address of the receiver. 683 + i, An integer which ordered the hosts in the path. 685 + Hi, exchange points of the path digest. 687 + T*, a time, the sending (or initial observation) time for 688 a measured packet. 690 + dT1,..., dTn, dT, a list of delay. 692 + P*, the specification of the packet type. 694 + , a path digest. 696 + B1, B2, ..., Bi, ..., Bn, a list of Boolean values. 698 4.3.3. Metric Units 700 A sequence of Boolean values. 702 4.3.4. Definition 704 Given a Type-P packet sent by the sender Src at time T to the 705 receiver Dst in the path . Given the sequence of 706 times the packet passes , 709 Type-P-One-way-Packet-Lost-Vector metric is defined as the sequence 710 of values such that for each Hi of the path, a 711 value of Bi of 0 means that dTi is a finite value, and a value of 1 712 means that dTi is undefined. 714 4.3.5. Discussion 716 Following are specific issues which may occur: 718 o the result includes the sequence 1,0. This case means that the 719 packet was seen by a host but not by it successor on the path; 721 o 723 The location of the meter in the device influences the result: 725 o Even if the packet is received by a device, it may be not observed 726 by a meter located after a buffer; 728 4.3.6. Reporting 730 Section in progress. 732 4.4. A Definition for Spatial One-way Jitter Vector 734 This section uses parameters from the definition of Type-P-One-way- 735 ipdv. When a parameter from section 2 of [RFC3393] is first used in 736 this section, it will be tagged with a trailing asterisk. 738 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 739 statements for end-to-end one-way-ipdv measurements. They are 740 applicable to each point of interest Hi involved in the measure. 741 Spatial one-way-ipdv measurement SHOULD be respectful of them, 742 especially those related to methodology, clock, uncertainties and 743 reporting. 745 Following we adapt some of them and introduce points specific to 746 spatial measurement. 748 4.4.1. Metric Name 750 Type-P-Spatial-One-way-Jitter-Vector 752 4.4.2. Metric Parameters 754 + Src*, the IP address of the sender. 756 + Dst*, the IP address of the receiver. 758 + i, An integer which ordered the hosts in the path. 760 + Hi, exchange points of the path digest. 762 + T1*, the time the first packet was sent. 764 + T2*, the time the second packet was sent. 766 + P, the specification of the packet type. 768 + P1, the first packet sent at time T1. 770 + P2, the second packet sent at time T2. 772 + , a path digest. 774 + , 775 the Type-P-Spatial-One-way-Delay-Vector for packet sent at 776 time T1; 778 + , 779 the Type-P-Spatial-One-way-Delay-Vector for packet sent at 780 time T2; 782 + L*, a packet length in bits. The packets of a Type P 783 packet stream from which the 784 Type-P-Spatial-One-way-Delay-Vector metric is taken MUST 785 all be of the same length. 787 4.4.3. Metric Units 789 A sequence of times. 791 4.4.4. Definition 793 Given the Type-P packet having the size L and sent by the sender Src 794 at wire-time (first bit) T1 to the receiver Dst in the path . 797 Given the Type-P packet having the size L and sent by the sender Src 798 at wire-time (first bit) T2 to the receiver Dst in the same path. 800 Given the Type-P-Spatial-One-way-Delay-Vector of the packet P1. 803 Given the Type-P-Spatial-One-way-Delay-Vector of the packet P2. 806 Type-P-Spatial-One-way-Jitter-Vector metric is defined as the 807 sequence of values Such that for each Hi of the path , 809 dT2.i-dT1.i is either a real number if the packets P1 and P2 passes 810 Hi at wire-time (last bit) dT1.i, respectively dT2.i, or undefined if 811 at least one of them never passes Hi. T2-T1 is the inter-packet 812 emission interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv at 813 T1,T2*. 815 4.4.5. Sections in progress 817 See sections 3.5 to 3.7 of [RFC3393]. 819 4.5. Pure Passive Metrics 821 Spatial metrics may be measured without injecting test traffic. 823 4.5.1. Discussion on Passive measurement 825 One might says that most of the operational issues occur in the last 826 mile and that consequently such measure are less useful than active 827 measurement. Nevertheless they are usable for network TE and 828 interdomain QoS monitoring, and composition of metric. 830 Such a technique have some limitations that are discussed below. 832 4.5.1.1. Passive One way delay 834 As the packet is not a test packet, it does not include the time it 835 was sent. 837 Consequently a point of interest Hi ignores the time the packet was 838 send. So It is not possible to measure the delay between Src and Hi 839 in the same manner it is not possible to measure the delay betwwen Hi 840 and Dst. 842 4.5.1.2. Passive Packet loss 844 The packet is not a test packet, so it does not include a sequence 845 number. 847 Packet lost measurement doe not require time synchronization and 848 require only one point of observation. Nevertheless it requires the 849 point of interest Hi to be expecting the packet. Practically Hi may 850 not detect a lost of packet that occurs between Src and Hi. 852 A point of interest Hi ignores the time the packet is send because 853 the packet does not carry the time it was injected in the network. 854 So a probe Hi can not compute dTi. 856 An alternative to these issues consist in considering sample spatial 857 One-way delay that T is the time when H1 (the first passive probe of 858 the path) observed the packet. 860 4.5.2. Reporting and composition 862 To avoid misunderstanding and to address specific reporting 863 constraint a proposal consists in defining distinct metrics for pure 864 passive measurement based on the definition above. 866 It is crucial to know the methodologies used because of the 867 difference of method of detection (expecting Seq++); because of the 868 difference of source of time (H1 vs Src) and because of the 869 difference of behaviour of the source (Poisson/unknown). 871 4.5.3. naming and registry 873 Having distinct metrics identifiers for spatial metrics and passive 874 spatial metrics in the [RFC4148] will avoid interoperability issues 875 especially during composition of metrics. 877 4.5.4. Passive One way delay metrics 879 4.5.5. Passive One way PacketLoss metrics 881 4.5.6. Passive One way jitter metrics 882 4.6. Discussion on spatial statistics 884 Do we define min, max, avg of spatial metrics ? 886 having the maximum loss metric value could be interesting. Say, 887 the segment between router A and B always contributes loss metric 888 value of "1" means it could be the potential problem segment. 890 Uploading dTi of each Hi consume a lot of bandwidth. Computing 891 statistics (min, max and avg) of dTi locally in each Hi reduce the 892 bandwidth consumption. 894 5. One-to-group metrics definitions 896 5.1. A Definition for one-to-group One-way Delay 898 5.1.1. Metric Name 900 Type-P-one-to-group-One-way-Delay-Vector 902 5.1.2. Metric Parameters 904 o Src, the IP address of a host acting as the source. 906 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 907 receivers. 909 o T, a time. 911 o dT1,...,dTn a list of time. 913 o P, the specification of the packet type. 915 o Gr, the multicast group address (optional). The parameter Gr is 916 the multicast group address if the measured packets are 917 transmitted by multicast. This parameter is to identify the 918 measured traffic from other unicast and multicast traffic. It is 919 set to be optional in the metric to avoid losing any generality, 920 i.e. to make the metric also applicable to unicast measurement 921 where there is only one receivers. 923 5.1.3. Metric Units 925 The value of a Type-P-one-to-group-One-way-Delay-Vector is a set of 926 singletons metrics Type-P-One-way-Delay [RFC2679]. 928 5.1.4. Definition 930 Given a Type P packet sent by the source Src at Time T, given the N 931 hosts { Recv1,...,RecvN } which receive the packet at the time { 932 T+dT1,...,T+dTn }, a Type-P-one-to-group-One-way-Delay-Vector is 933 defined as the set of the Type-P-One-way-Delay singleton between Src 934 and each receiver with value of { dT1, dT2,...,dTn }. 936 5.2. A Definition for one-to-group One-way Packet Loss 938 5.2.1. Metric Name 940 Type-P-one-to-group-One-way-Packet-Loss-Vector 942 5.2.2. Metric Parameters 944 o Src, the IP address of a host acting as the source. 946 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 947 receivers. 949 o T, a time. 951 o T1,...,Tn a list of time. 953 o P, the specification of the packet type. 955 o Gr, the multicast group address (optional). 957 5.2.3. Metric Units 959 The value of a Type-P-one-to-group-One-way-Packet-Loss-Vector is a 960 set of singletons metrics Type-P-One-way-Packet-Loss [RFC2680]. 962 5.2.4. Definition 964 Given a Type P packet sent by the source Src at T and the N hosts, 965 Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a 966 Type-P-one-to-group-One-way-Packet-Loss-Vector is defined as a set of 967 the Type-P-One-way-Packet-Loss singleton between Src and each of the 968 receivers {,,..., }. 970 5.3. A Definition for one-to-group One-way Jitter 972 5.3.1. Metric Name 974 Type-P-one-to-group-One-way-Jitter-Vector 976 5.3.2. Metric Parameters 978 + Src, the IP address of a host acting as the source. 980 + Recv1,..., RecvN, the IP addresses of the N hosts acting as 981 receivers. 983 + T1, a time. 985 + T2, a time. 987 + ddT1,...,ddTn, a list of time. 989 + P, the specification of the packet type. 991 + F, a selection function defining unambiguously the two 992 packets from the stream selected for the metric. 994 + Gr, the multicast group address (optional) 996 5.3.3. Metric Units 998 The value of a Type-P-one-to-group-One-way-Jitter-Vector is a set of 999 singletons metrics Type-P-One-way-ipdv [RFC3393]. 1001 5.3.4. Definition 1003 Given a Type P packet stream, Type-P-one-to-group-One-way-Jitter- 1004 Vector is defined for two packets from the source Src to the N hosts 1005 {Recv1,...,RecvN },which are selected by the selection function F, as 1006 the difference between the value of the Type-P-one-to-group-One-way- 1007 Delay-Vector from Src to { Recv1,..., RecvN } at time T1 and the 1008 value of the Type-P-one-to-group- One-way-Delay-Vector from Src to { 1009 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Src sent 1010 the first bit of the first packet, and T2 is the wire-time at which 1011 Src sent the first bit of the second packet. This metric is derived 1012 from the Type-P-one-to- group-One-way-Delay-Vector metric. 1014 Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one- to- 1015 group-One-way-Jitter-Vector from Src to { Recv1,...,RecvN } at T1, T2 1016 is {ddT1,...,ddTn} means that Src sent two packets, the first at 1017 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 1018 and the packets were received by { Recv1,...,RecvN } at wire-time 1019 {dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time 1020 {dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that 1021 {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 1023 6. One-to-Group Sample Statistics 1025 The defined one-to-group metrics above can all be directly achieved 1026 from the relevant unicast one-way metrics. They managed to collect 1027 all unicast measurement results of one-way metrics together in one 1028 profile and sort them by receivers and packets in a multicast group. 1029 They can provide sufficient information regarding the network 1030 performance in terms of each receiver and guide engineers to identify 1031 potential problem happened on each branch of a multicast routing 1032 tree. However, these metrics can not be directly used to 1033 conveniently present the performance in terms of a group and neither 1034 to identify the relative performance situation. 1036 From the performance point of view, the multiparty communication 1037 services not only require the absolute performance support but also 1038 the relative performance. The relative performance means the 1039 difference between absolute performance of all users. Directly using 1040 the one-way metrics cannot present the relative performance 1041 situation. However, if we use the variations of all users one-way 1042 parameters, we can have new metrics to measure the difference of the 1043 absolute performance and hence provide the threshold value of 1044 relative performance that a multiparty service might demand. A very 1045 good example of the high relative performance requirement is the 1046 online gaming. A very light difference in delay might result in 1047 failure in the game. We have to use multicast specific statistic 1048 metrics to define exactly how small the relative delay the online 1049 gaming requires. There are many other services, e.g. online biding, 1050 online stock market, etc., that require multicast metrics in order to 1051 evaluate the network against their requirements. Therefore, we can 1052 see the importance of new, multicast specific, statistic metrics to 1053 feed this need. 1055 We might also use some one-to-group statistic conceptions to present 1056 and report the group performance and relative performance to save the 1057 report transmission bandwidth. Statistics have been defined for One- 1058 way metrics in corresponding FRCs. They provide the foundation of 1059 definition for performance statistics. For instance, there are 1060 definitions for minimum and maximum One-way delay in [RFC2679]. 1061 However, there is a dramatic difference between the statistics for 1062 one-to-one communications and for one-to-many communications. The 1063 former one only has statistics over the time dimension while the 1064 later one can have statistics over both time and space dimensions. 1065 This space dimension is introduced by the Matrix concept as 1066 illustrated in Figure 7. For a Matrix M each row is a set of One-way 1067 singletons spreading over the time dimension and each column is 1068 another set of One-way singletons spreading over the space dimension. 1070 Receivers 1071 Space 1072 ^ 1073 1 | / R1dT1 R1dT2 R1dT3 ... R3dTk \ 1074 | | | 1075 2 | | R2dT1 R2dT2 R2dT3 ... R3dTk | 1076 | | | 1077 3 | | R3dT1 R3dT2 R3dT3 ... R3dTk | 1078 . | | | 1079 . | | | 1080 . | | | 1081 n | \ RndT1 RndT2 RndT3 ... RndTk / 1082 +--------------------------------------------> time 1083 T0 1085 Figure 7: Matrix M (n*m) 1087 In Matrix M, each element is a One-way delay singleton. Each column 1088 is a delay vector contains the One-way delays of the same packet 1089 observed at M points of interest. It implies the geographical factor 1090 of the performance within a group. Each row is a set of One-way 1091 delays observed during a sampling interval at one of the points of 1092 interest. It presents the delay performance at a receiver over the 1093 time dimension. 1095 Therefore, one can either calculate statistics by rows over the space 1096 dimension or by columns over the time dimension. It's up to the 1097 operators or service provides which dimension they are interested in. 1098 For example, a TV broadcast service provider might want to know the 1099 statistical performance of each user in a long term run to make sure 1100 their services are acceptable and stable. While for an online gaming 1101 service provider, he might be more interested to know if all users 1102 are served fairly by calculating the statistics over the space 1103 dimension. This memo does not intend to recommend which of the 1104 statistics are better than the other. 1106 To save the report transmission bandwidth, each point of interest can 1107 send statistics in a pre-defined time interval to the reference point 1108 rather than sending every One-way singleton it observed. As long as 1109 an appropriate time interval is decided, appropriate statistics can 1110 represent the performance in a certain accurate scale. How to decide 1111 the time interval and how to bootstrap all points of interest and the 1112 reference point depend on applications. For instance, applications 1113 with lower transmission rate can have the time interval longer and 1114 ones with higher transmission rate can have the time interval 1115 shorter. However, this is out of the scope of this memo. 1117 Moreover, after knowing the statistics over the time dimension, one 1118 might want to know how this statistics distributed over the space 1119 dimension. For instance, a TV broadcast service provider had the 1120 performance Matrix M and calculated the One-way delay mean over the 1121 time dimension to obtain a delay Vector as {V1,V2,..., VN}. He then 1122 calculated the mean of all the elements in the Vector to see what 1123 level of delay he has served to all N users. This new delay mean 1124 gives information on how good the service has been delivered to a 1125 group of users during a sampling interval in terms of delay. It 1126 needs twice calculation to have this statistic over both time and 1127 space dimensions. We name this kind of statistics 2-level statistics 1128 to distinct with those 1-level statistics calculated over either 1129 space or time dimension. It can be easily prove that no matter over 1130 which dimension a 2-level statistic is calculated first, the results 1131 are the same. I.e. one can calculate the 2-level delay mean using 1132 the Matrix M by having the 1-level delay mean over the time dimension 1133 first and then calculate the mean of the obtained vector to find out 1134 the 2-level delay mean. Or, he can do the 1-level statistic 1135 calculation over the space dimension first and then have the 2-level 1136 delay mean. Both two results will be exactly the same. Therefore, 1137 when define a 2-level statistic, there is no need to specify in which 1138 procedure the calculation should follow. 1140 Comment: The above statement depends on whether the order of 1141 operations has any affect on the outcome. 1143 Many statistics can be defined for the proposed one-to-group metrics 1144 over either the space dimension or the time dimension or both. This 1145 memo treats the case where a stream of packets from the Source 1146 results in a sample at each of the Receivers in the Group, and these 1147 samples are each summarized with the usual statistics employed in 1148 one-to-one communication. New statistic definitions are presented, 1149 which summarize the one-to-one statistics over all the Receivers in 1150 the Group. 1152 6.1. Discussion on the Impact of packet loss on statistics 1154 The packet loss does have effects on one-way metrics and their 1155 statistics. For example, the lost packet can result an infinite one- 1156 way delay. It is easy to handle the problem by simply ignoring the 1157 infinite value in the metrics and in the calculation of the 1158 corresponding statistics. However, the packet loss has so strong 1159 impact on the statistics calculation for the one-to-group metrics 1160 that it can not be solved by the same method used for one-way 1161 metrics. This is due to the complex of building a Matrix, which is 1162 needed for calculation of the statistics proposed in this memo. 1164 The situation is that measurement results obtained by different end 1165 users might have different packet loss pattern. For example, for 1166 User1, packet A was observed lost. And for User2, packet A was 1167 successfully received but packet B was lost. If the method to 1168 overcome the packet loss for one-way metrics is applied, the two 1169 singleton sets reported by User1 and User2 will be different in terms 1170 of the transmitted packets. Moreover, if User1 and User2 have 1171 different number of lost packets, the size of the results will be 1172 different. Therefore, for the centralized calculation, the reference 1173 point will not be able to use these two results to build up the group 1174 Matrix and can not calculate the statistics. In an extreme 1175 situation, no single packet arrives all users in the measurement and 1176 the Matrix will be empty. One of the possible solutions is to 1177 replace the infinite/undefined delay value by the average of the two 1178 adjacent values. For example, if the result reported by user1 is { 1179 R1dT1 R1dT2 R1dT3 ... R1dTK-1 UNDEF R1dTK+1... R1DM } where "UNDEF" 1180 is an undefined value, the reference point can replace it by R1dTK = 1181 {(R1dTK-1)+( R1dTK+1)}/2. Therefore, this result can be used to 1182 build up the group Matrix with an estimated value R1dTK. There are 1183 other possible solutions such as using the overall mean of the whole 1184 result to replace the infinite/undefined value, and so on. It is out 1185 of the scope of this memo. 1187 For the distributed calculation, the reported statistics might have 1188 different "weight" to present the group performance, which is 1189 especially true for delay and jitter relevant metrics. For example, 1190 User1 calculates the Type-P-Finite-One-way-Delay-Mean R1DM as shown 1191 in Figure. 8 without any packet loss and User2 calculates the R2DM 1192 with N-2 packet loss. The R1DM and R2DM should not be treated with 1193 equal weight because R2DM was calculated only based on 2 delay values 1194 in the whole sample interval. One possible solution is to use a 1195 weight factor to mark every statistic value sent by users and use 1196 this factor for further statistic calculation. 1198 6.2. General Metric Parameters 1200 o Src, the IP address of a host 1202 o G, the Group IP address 1204 o N, the number of Receivers (Recv1, Recv2, ... RecvN) 1206 o T, a time (start of test interval) 1208 o Tf, a time (end of test interval) 1210 o K, the number of packets sent from the source during the test 1211 interval 1213 o J[n], the number of packets received at a particular Receiver, n, 1214 where 1<=n<=N 1216 o lambda, a rate in reciprocal seconds (for Poisson Streams) 1218 o incT, the nominal duration of inter-packet interval, first bit to 1219 first bit (for Periodic Streams) 1221 o T0, a time that MUST be selected at random from the interval [T, 1222 T+I] to start generating packets and taking measurements (for 1223 Periodic Streams) 1225 o TstampSrc, the wire time of the packet as measured at MP(Src) (the 1226 Source Measurement Point) 1228 o TstampRecv, the wire time of the packet as measured at MP(Recv), 1229 assigned to packets that arrive within a "reasonable" time 1231 o Tmax, a maximum waiting time for packets at the destination, set 1232 sufficiently long to disambiguate packets with long delays from 1233 packets that are discarded (lost), thus the distribution of delay 1234 is not truncated 1236 o dT, shorthand notation for a one-way delay singleton value 1238 o L, shorthand notation for a one-way loss singleton value, either 1239 zero or one, where L=1 indicates loss and L=0 indicates arrival at 1240 the destination within TstampSrc + Tmax, may be indexed over n 1241 Receivers 1243 o DV, shorthand notation for a one-way delay variation singleton 1244 value 1246 6.3. One-to-Group one-way Delay Statistics 1248 This section defines the overall one-way delay statistics for an 1249 entire Group or receivers. For example, we can define the group mean 1250 delay, as illustrated below. This is a metric designed to summarize 1251 the entire Matrix. 1253 Recv /----------- Sample -------------\ Stats Group Stat 1255 1 R1dT1 R1dT2 R1dT3 ... R1dTk R1DM \ 1256 | 1257 2 R2dT1 R2dT2 R2dT3 ... R2dTk R2DM | 1258 | 1259 3 R3dT1 R3dT2 R3dT3 ... R3dTk R2DM > GMD 1260 . | 1261 . | 1262 . | 1263 n RndT1 RndT2 RndT3 ... RndTk RnDM / 1265 Figure 8: One-to-GroupGroup Mean Delay 1267 where: 1269 R1dT1 is the Type-P-Finite-One-way-Delay singleton evaluated at 1270 Receiver 1 for packet 1. 1272 R1DM is the Type-P-Finite-One-way-Delay-Mean evaluated at Receiver 1 1273 for the sample of packets (1,...K). 1275 GMD is the mean of the sample means over all Receivers (1, ...N). 1277 6.3.1. Definition and Metric Units 1279 Using the parameters above, we obtain the value of Type-P-One-way- 1280 Delay singleton for all packets sent during the test interval at each 1281 Receiver (Destination), as per [RFC2679]. For each packet that 1282 arrives within Tmax of its sending time, TstampSrc, the one-way delay 1283 singleton (dT) will be a finite value in units of seconds. 1284 Otherwise, the value of the singleton is Undefined. 1286 For each packet [i] that has a finite One-way Delay at Receiver n (in 1287 other words, excluding packets which have undefined one-way delay): 1289 Type-P-Finite-One-way-Delay-Receiver-n-[i] = 1291 = TstampRecv[i] - TstampSrc[i] 1293 The units of Finite one-way delay are seconds, with sufficient 1294 resolution to convey 3 significant digits. 1296 6.3.2. Sample Mean Statistic 1298 This section defines the Sample Mean at each of N Receivers. 1300 Type-P-Finite-One-way-Delay-Mean-Receiver-n = RnDM = 1301 J[n] 1302 --- 1303 1 \ 1304 --- * > Type-P-Finite-One-way-Delay-Receiver-n-[i] 1305 J[n] / 1306 --- 1307 i = 1 1309 Figure 9: Type-P-Finite-One-way-Delay-Mean-Receiver-n 1311 where all packets i= 1 through J[n] have finite singleton delays. 1313 6.3.3. One-to-Group Mean Delay Statistic 1315 This section defines the Mean One-way Delay calculated over the 1316 entire Group (or Matrix). 1318 Type-P-One-to-Group-Mean-Delay = GMD = 1319 N 1320 --- 1321 1 \ 1322 - * > RnDM 1323 N / 1324 --- 1325 n = 1 1327 Figure 10: Type-P-One-to-Group-Mean-Delay 1329 Note that the Group Mean Delay can also be calculated by summing the 1330 Finite one-way Delay singletons in the Matrix, and dividing by the 1331 number of Finite One-way Delay singletons. 1333 6.3.4. One-to-Group Range of Mean Delays 1335 This section defines a metric for the range of mean delays over all N 1336 receivers in the Group, (R1DM, R2DM,...RnDM). 1338 Type-P-One-to-Group-Range-Mean-Delay = GRMD = max(RnDM) - min(RnDM) 1340 6.3.5. One-to-Group Maximum of Mean Delays 1342 This section defines a metrics for the maximum of mean delays over 1343 all N receivers in the Group, (R1DM, R2DM,...RnDM). 1345 Type-P-One-to-Group-Max-Mean-Delay = GMMD = max(RnDM) 1347 6.4. One-to-Group one-way Loss Statistics 1349 This section defines the overall 1-way loss statistics for an entire 1350 Group. For example, we can define the group loss ratio, as 1351 illustrated below. This is a metric designed to summarize the entire 1352 Matrix. 1354 Recv /----------- Sample ----------\ Stats Group Stat 1356 1 R1L1 R1L2 R1L3 ... R1Lk R1LR \ 1357 | 1358 2 R2L1 R2L2 R2L3 ... R2Lk R2LR | 1359 | 1360 3 R3L1 R3L2 R3L3 ... R3Lk R3LR > GLR 1361 . | 1362 . | 1363 . | 1364 n RnL1 RnL2 RnL3 ... RnLk RnLR / 1366 Figure 11: One-to-Group Loss Ratio 1368 where: 1370 R1L1 is the Type-P-One-way-Loss singleton (L) evaluated at Receiver 1 1371 for packet 1. 1373 R1LR is the Type-P-One-way-Loss-Ratio evaluated at Receiver 1 for the 1374 sample of packets (1,...K). 1376 GLR is the loss ratio over all Receivers (1, ..., N). 1378 6.4.1. One-to-Group Loss Ratio 1380 The overall Group loss ratio id defined as 1382 Type-P-One-to-Group-Loss-Ratio = 1383 K,N 1384 --- 1385 1 \ 1386 = --- * > L(k,n) 1387 K*N / 1388 --- 1389 k,n = 1 1391 Figure 12 1393 ALL Loss ratios are expressed in units of packets lost to total 1394 packets sent. 1396 6.4.2. One-to-Group Loss Ratio Range 1398 Given a Matrix of loss singletons as illustrated above, determine the 1399 Type-P-One-way-Packet-Loss-Average for the sample at each receiver, 1400 according to the definitions and method of [RFC2680]. The Type-P- 1401 One-way-Packet-Loss-Average, RnLR for receiver n, and the Type-P-One- 1402 way-Loss-Ratio illustrated above are equivalent metrics. In terms of 1403 the parameters used here, these metrics definitions can be expressed 1404 as 1406 Type-P-One-way-Loss-Ratio-Receiver-n = RnLR = 1407 K 1408 --- 1409 1 \ 1410 - * > RnLk 1411 K / 1412 --- 1413 k = 1 1415 Figure 13: Type-P-One-way-Loss-Ratio-Receiver-n 1417 The One-to-Group Loss Ratio Range is defined as 1419 Type-P-One-to-Group-Loss-Ratio-Range = max(RnLR) - min(RnLR) 1421 It is most effective to indicate the range by giving both the max and 1422 minimum loss ratios for the Group, rather than only reporting the 1423 difference between them. 1425 6.4.3. Comparative Loss Ratio 1427 Usually, the number of packets sent is used in the denominator of 1428 packet loss ratio metrics. For the comparative metrics defined here, 1429 the denominator is the maximum number of packets received at any 1430 receiver for the sample and test interval of interest. 1432 The Comparative Loss Ratio is defined as 1434 Type-P-Comp-Loss-Ratio-Receiver-n = RnCLR = 1435 K 1436 --- 1437 \ 1438 > Ln(k) 1439 / 1440 --- 1441 k=1 1442 = ----------------------------- 1443 / K \ 1444 | --- | 1445 | \ | 1446 K - Min | > Ln(k) | 1447 | / | 1448 | --- | 1449 \ k=1 / N 1451 Figure 14: Type-P-Comp-Loss-Ratio-Receiver-n 1453 6.5. One-to-Group one-way Delay Variation Statistics 1455 There is are two delay variation (DV) statistics to summarize the 1456 performance over the Group: the maximum DV over all receivers and the 1457 range of DV over all receivers. 1459 The detailed definitions are T0 BE PROVIDED. 1461 7. Measurement Methods: Scaleability and Reporting 1463 Virtually all the guidance on measurement processes supplied by the 1464 earlier IPPM RFCs (such as [RFC2679] and [RFC2680]) for one-to-one 1465 scenarios is applicable here in the spatial and multiparty 1466 measurement scenario. The main difference is that the spatial and 1467 multiparty configurations require multiple measurement points where a 1468 stream of singletons will be collected. The amount of information 1469 requiring storage grows with both the number of metrics and the 1470 number of measurement points, so the scale of the measurement 1471 architecture multiplies the number of singleton results that must be 1472 collected and processed. 1474 It is possible that the architecture for results collection involves 1475 a single aggregation point with connectivity to all the measurement 1476 points. In this case, the number of measurement points determines 1477 both storage capacity and packet transfer capacity of the host acting 1478 as the aggregation point. However, both the storage and transfer 1479 capacity can be reduced if the measurement points are capable of 1480 computing the summary statistics that describe each measurement 1481 interval. This is consistent with many operational monitoring 1482 architectures today, where even the individual singletons may not be 1483 stored at each measurement point. 1485 In recognition of the likely need to minimize form of the results for 1486 storage and communication, the Group metrics above have been 1487 constructed to allow some computations on a per-Receiver basis. This 1488 means that each Receiver's statistics would normally have an equal 1489 weight with all other Receivers in the Group (regardless of the 1490 number of packets received). 1492 7.1. Computation methods 1494 The scalability issue can be raised when there are thousands of 1495 points of interest in a group who are trying to send back the 1496 measurement results to the reference point for further processing and 1497 analysis. The points of interest can send either the whole measured 1498 sample or only the calculated statistics. The former one is a 1499 centralized statistic calculation method and the latter one is a 1500 distributed statistic calculation method. The sample should include 1501 all metrics parameters, the values and the corresponding sequence 1502 numbers. The transmission of the whole sample can cost much more 1503 bandwidth than the transmission of the statistics that should include 1504 all statistic parameters specified by policies and the additional 1505 information about the whole sample, such as the size of the sample, 1506 the group address, the address of the point of interest, the ID of 1507 the sample session, and so on. Apparently, the centralized 1508 calculation method can require much more bandwidth than the 1509 distributed calculation method when the sample size is big. This is 1510 especially true when the measurement has huge number of the points of 1511 interest. It can lead to a scalability issue at the reference point 1512 by over load the network resources. The distributed calculation 1513 method can save much more bandwidth and release the pressure of the 1514 scalability issue at the reference point side. However, it can 1515 result in the lack of information because not all measured singletons 1516 are obtained for building up the group matrix. The performance over 1517 time can be hidden from the analysis. For example, the loss pattern 1518 can be missed by simply accepting the loss ratio as well as the delay 1519 pattern. This tradeoff between the bandwidth consuming and the 1520 information acquiring has to be taken into account when design the 1521 measurement campaign to optimize the measurement results delivery. 1522 The possible solution could be to transit the statistic parameters to 1523 the reference point first to obtain the general information of the 1524 group performance. If the detail results are required, the reference 1525 point should send the requests to the points of interest, which could 1526 be particular ones or the whole group. This procedure can happen in 1527 the off peak time and can be well scheduled to avoid delivery of too 1528 many points of interest at the same time. Compression techniques can 1529 also be used to minimize the bandwidth required by the transmission. 1530 This could be a measurement protocol to report the measurement 1531 results. It is out of the scope of this memo. 1533 7.2. Measurement 1535 To prevent any biais in the result, the configuration of a one-to- 1536 many measure must take in consideration that implicitly more packets 1537 will to be routed than send and selects a test packets rate that will 1538 not impact the network performance. 1540 7.3. effect of Time and Space Aggregation Order on Group Stats 1542 This section presents the impact of the aggregation order on the 1543 scalability of the reporting and of the the computation. It makes 1544 the hypothesis that receivers are managed remotly and not co-located. 1546 2 methods are available to compute group statistics: 1548 Figure 8and (Figure 11) illustrate the method method choosen: the 1549 one-to-one statistic is computed per interval of time before the 1550 computation of the mean over the group of receivers [method1]; 1552 Figure 15 presents the second one, metric is computed over space 1553 and then over time [method2]. 1555 They differ only by the order of the time and of the space 1556 aggregation. View as a matrix this order is neutral as it does not 1557 impact the result, but the impact on a measurement deployement is 1558 critical. 1560 Recv 1562 1 R1S1 R1S1 R1S1 ... R1Sk \ 1563 | 1564 2 R2S1 R2S2 R2S3 ... R2Sk | 1565 | 1566 3 R3S1 R3S2 R3S3 ... R3Sk > sample over space 1567 . | 1568 . | 1569 . | 1570 n RnS1 RnS2 RnS3 ... RnSk / 1572 S1M S2M S3M ... SnM Stats over space 1574 \------------- ------------/ 1575 \/ 1576 Group Stat over space and time 1578 Figure 15: Impact of space aggregation on Group Stat 1580 In both cases the volume of data to report is proportional to the 1581 number of probes. But there is a major difference between these 2 1582 methods: 1584 method2: In space and time aggregation mode the volume of data to 1585 collect is proportionnal to the number of test packets received; 1586 Each received packet RiSi triggers out a block of data that must 1587 be reported to a common place for computing the stat over space; 1589 method1: In time and space aggregation mode the volume of data to 1590 collect is proportionnal to the period of aggregation, so it does 1591 not depend on the number of packet received; 1593 Method 2 property has severe drawbacks in terms of security and 1594 dimensionning: 1596 The increasing of the rate of the test packets may result in a 1597 sort of DoS toward the computation points; 1599 The dimensioning of a measurement system is quite impossible to 1600 validate. 1602 The time agregation interval provides the reporting side with a 1603 control of various collecting aspects such as bandwidth and 1604 computation and storage capacities. So this draft defines metrics 1605 based on method 1. 1607 Note: In some specific cases one may need sample of singletons over 1608 space. To adress this need it is suggested firstly to limit the 1609 number of test and the number of test packets per seconds. Then 1610 reducing the size of the sample over time to one packet give sample 1611 of singleton over space.. 1613 7.4. effect of Time and Space Aggregation Order on Spatial Stats 1615 TBD 1617 8. Open issues 1619 9. Security Considerations 1621 Active measurement: (TODO: security considerations of owd pl, jitter 1622 rfcs applies (editor notes: add references). 1624 9.1. passive measurement 1626 The generation of packets which match systematically the hash 1627 function may lead to a DoS attack toward the collector. 1629 The generation of packets with spoofing addresses may corrupt the 1630 results without any possibility to detect the spoofing. 1632 9.2. one-to-group metric 1634 The configuration of a measure must take in consideration that 1635 implicitly more packets will to be routed than send and selects a 1636 test packets rate accordingly. 1638 Collecting statistics from a huge number of probes may overload any 1639 combination of the network the measurement controller is attach to, 1640 measurement controller network interfaces and measurement controller 1641 computation capacities. 1643 one-to-group metrics: 1645 10. Acknowledgments 1647 Lei would like to acknowledge Zhili Sun from CCSR, University of 1648 Surrey, for his instruction and helpful comments on this work. 1650 11. IANA Considerations 1652 Metrics defined in this memo Metrics defined in this memo are 1653 designed to be registered in the IANA IPPM METRICS REGISTRY as 1654 described in initial version of the registry [RFC4148] : 1656 IANA is asked to register the following metrics in the IANA-IPPM- 1657 METRICS-REGISTRY-MIB : 1659 Spatial-One-way-Delay-Vector OBJECT-IDENTITY 1661 STATUS current 1663 DESCRIPTION 1665 "Type-P-Spatial-One-way-Delay-Vector" 1667 REFERENCE 1669 "Reference "RFCyyyy, section 4.1." 1671 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1672 note 1674 := { ianaIppmMetrics nn } -- IANA assigns nn 1676 subpath-One-way-Delay-Stream OBJECT-IDENTITY 1678 STATUS current 1680 DESCRIPTION 1682 "Type-P-subpath-One-way-Delay-Stream" 1684 REFERENCE 1686 "Reference "RFCyyyy, section 4.2." 1688 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1689 note 1691 := { ianaIppmMetrics nn } -- IANA assigns nn 1693 Spatial-One-way-Packet-Loss-Vector OBJECT-IDENTITY 1694 STATUS current 1696 DESCRIPTION 1698 "Type-P-Spatial-One-way-Packet-Loss-Vector" 1700 REFERENCE 1702 "Reference "RFCyyyy, section 4.3." 1704 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1705 note 1707 := { ianaIppmMetrics nn } -- IANA assigns nn 1709 Spatial-One-way-Jitter-Vector OBJECT-IDENTITY 1711 STATUS current 1713 DESCRIPTION 1715 "Type-P-Spatial-One-way-Jitter-Vector" 1717 REFERENCE 1719 "Reference "RFCyyyy, section 4.4." 1721 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1722 note 1724 := { ianaIppmMetrics nn } -- IANA assigns nn 1726 one-to-group-One-way-Delay-Vector OBJECT-IDENTITY 1728 STATUS current 1730 DESCRIPTION 1732 "Type-P-one-to-group-One-way-Delay-Vector" 1734 REFERENCE 1736 "Reference "RFCyyyy, section 5.1." 1738 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1739 note 1741 := { ianaIppmMetrics nn } -- IANA assigns nn 1743 one-to-group-One-way-Packet-Loss-Vector OBJECT-IDENTITY 1745 STATUS current 1747 DESCRIPTION 1749 "Type-P-one-to-group-One-way-Packet-Loss-Vector" 1751 REFERENCE 1753 "Reference "RFCyyyy, section 5.2." 1755 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1756 note 1758 := { ianaIppmMetrics nn } -- IANA assigns nn 1760 one-to-group-One-way-Jitter-Vector OBJECT-IDENTITY 1762 STATUS current 1764 DESCRIPTION 1766 "Type-P-one-to-group-One-way-Jitter-Vector" 1768 REFERENCE 1770 "Reference "RFCyyyy, section 5.3." 1772 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1773 note 1775 := { ianaIppmMetrics nn } -- IANA assigns nn 1777 One-to-Group-Mean-Delay OBJECT-IDENTITY 1779 STATUS current 1781 DESCRIPTION 1783 "Type-P-One-to-Group-Mean-Delay" 1785 REFERENCE 1787 "Reference "RFCyyyy, section 6.3.3." 1789 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1790 note 1792 := { ianaIppmMetrics nn } -- IANA assigns nn 1794 One-to-Group-Range-Mean-Delay OBJECT-IDENTITY 1796 STATUS current 1798 DESCRIPTION 1800 "Type-P-One-to-Group-Range-Mean-Delay" 1802 REFERENCE 1804 "Reference "RFCyyyy, section 6.3.4." 1806 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1807 note 1809 := { ianaIppmMetrics nn } -- IANA assigns nn 1811 One-to-Group-Max-Mean-Delay OBJECT-IDENTITY 1813 STATUS current 1815 DESCRIPTION 1817 "Type-P-One-to-Group-Max-Mean-Delay" 1819 REFERENCE 1821 "Reference "RFCyyyy, section 6.3.5." 1823 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1824 note 1826 := { ianaIppmMetrics nn } -- IANA assigns nn 1828 One-to-Group-Loss-Ratio OBJECT-IDENTITY 1830 STATUS current 1832 DESCRIPTION 1834 "Type-P-One-to-Group-Loss-Ratio" 1836 REFERENCE 1838 "Reference "RFCyyyy, section 6.4.1." 1839 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1840 note 1842 := { ianaIppmMetrics nn } -- IANA assigns nn 1844 -- 1846 One-to-Group-Loss-Ratio-Range OBJECT-IDENTITY 1848 STATUS current 1850 DESCRIPTION 1852 "Type-P-One-to-Group-Loss-Ratio-Range" 1854 REFERENCE 1856 "Reference "RFCyyyy, section 6.4.2." 1858 -- RFC Ed.: replace yyyy with actual RFC number & remove this 1859 note 1861 := { ianaIppmMetrics nn } -- IANA assigns nn 1863 -- 1865 12. References 1867 12.1. Normative References 1869 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1870 "Framework for IP Performance Metrics", RFC 2330, 1871 May 1998. 1873 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1874 Delay Metric for IPPM", RFC 2679, September 1999. 1876 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1877 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1879 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1880 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1881 November 2002. 1883 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1884 Registry", BCP 108, RFC 4148, August 2005. 1886 12.2. Informative References 1888 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 1889 Connectivity", RFC 2678, September 1999. 1891 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1892 Delay Metric for IPPM", RFC 2681, September 1999. 1894 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 1895 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 1896 July 2001. 1898 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 1899 Metrics", RFC 3357, August 2002. 1901 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1902 performance measurement with periodic streams", RFC 3432, 1903 November 2002. 1905 [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active 1906 Measurement Protocol (OWAMP) Requirements", RFC 3763, 1907 April 2004. 1909 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 1910 Zekauskas, "A One-way Active Measurement Protocol 1911 (OWAMP)", RFC 4656, September 2006. 1913 [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, 1914 S., and J. Perser, "Packet Reordering Metrics", RFC 4737, 1915 November 2006. 1917 Authors' Addresses 1919 Stephan Emile 1920 France Telecom Division R&D 1921 2 avenue Pierre Marzin 1922 Lannion, F-22307 1924 Fax: +33 2 96 05 18 52 1925 Email: emile.stephan@orange-ftgroup.com 1926 Lei Liang 1927 CCSR, University of Surrey 1928 Guildford 1929 Surrey, GU2 7XH 1931 Fax: +44 1483 683641 1932 Email: L.Liang@surrey.ac.uk 1934 Al Morton 1935 200 Laurel Ave. South 1936 Middletown, NJ 07748 1937 USA 1939 Phone: +1 732 420 1571 1940 Email: acmorton@att.com 1942 Full Copyright Statement 1944 Copyright (C) The IETF Trust (2007). 1946 This document is subject to the rights, licenses and restrictions 1947 contained in BCP 78, and except as set forth therein, the authors 1948 retain all their rights. 1950 This document and the information contained herein are provided on an 1951 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1952 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1953 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1954 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1955 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1956 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1958 Intellectual Property 1960 The IETF takes no position regarding the validity or scope of any 1961 Intellectual Property Rights or other rights that might be claimed to 1962 pertain to the implementation or use of the technology described in 1963 this document or the extent to which any license under such rights 1964 might or might not be available; nor does it represent that it has 1965 made any independent effort to identify any such rights. Information 1966 on the procedures with respect to rights in RFC documents can be 1967 found in BCP 78 and BCP 79. 1969 Copies of IPR disclosures made to the IETF Secretariat and any 1970 assurances of licenses to be made available, or the result of an 1971 attempt made to obtain a general license or permission for the use of 1972 such proprietary rights by implementers or users of this 1973 specification can be obtained from the IETF on-line IPR repository at 1974 http://www.ietf.org/ipr. 1976 The IETF invites any interested party to bring to its attention any 1977 copyrights, patents or patent applications, or other proprietary 1978 rights that may cover technology that may be required to implement 1979 this standard. Please address the information to the IETF at 1980 ietf-ipr@ietf.org. 1982 Acknowledgment 1984 Funding for the RFC Editor function is provided by the IETF 1985 Administrative Support Activity (IASA).