idnits 2.17.1 draft-ietf-ippm-multimetrics-01.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 on line 1274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1251. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1264. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 374: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 480: '... [RFC2679] says that the path traversed by the packet SHOULD be...' RFC 2119 keyword, line 503: '...elay measurement SHOULD be respectful ...' RFC 2119 keyword, line 611: '...loss measurement SHOULD be respectful ...' RFC 2119 keyword, line 685: '...ipdv measurement SHOULD be respectful ...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 25, 2006) is 6516 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2330 ** 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) == Outdated reference: A later version (-02) exists of draft-boschi-ipfix-reducing-redundancy-01 == Outdated reference: A later version (-16) exists of draft-ietf-ippm-spatial-composition-00 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 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 Expires: December 27, 2006 L. Liang 5 University of Surrey 6 A. Morton 7 AT&T Labs 8 June 25, 2006 10 IP Performance Metrics (IPPM) for spatial and multicast 11 draft-ietf-ippm-multimetrics-01 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 December 27, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1. Multiparty metric . . . . . . . . . . . . . . . . . . . . 5 56 2.2. Spatial metric . . . . . . . . . . . . . . . . . . . . . . 5 57 2.3. Spatial metric points of interest . . . . . . . . . . . . 5 58 2.4. One-to-group metric . . . . . . . . . . . . . . . . . . . 5 59 2.5. One-to-group metric points of interest . . . . . . . . . . 5 60 2.6. Reference point . . . . . . . . . . . . . . . . . . . . . 5 61 2.7. Group of singletons . . . . . . . . . . . . . . . . . . . 6 62 3. Motivations for spatial and one-to-group metrics . . . . . . . 6 63 3.1. spatial metrics . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. One-to-group metrics . . . . . . . . . . . . . . . . . . . 7 65 3.3. Discussion on Group-to-one and Group-to-group metrics . . 8 66 4. Spatial metrics definitions . . . . . . . . . . . . . . . . . 8 67 4.1. A Definition for Spatial One-way Delay Stream . . . . . . 8 68 4.2. A Definition of a sample of One-way Delay of a sub path . 11 69 4.3. A Definition for Spatial One-way Packet Loss Stream . . . 13 70 4.4. A Definition for Spatial One-way Jitter Stream . . . . . . 15 71 4.5. Pure Passive Metrics . . . . . . . . . . . . . . . . . . . 17 72 4.6. Discussion on spatial statistics . . . . . . . . . . . . . 19 73 5. One-to-group metrics definitions . . . . . . . . . . . . . . . 19 74 5.1. A Definition for one-to-group One-way Delay Stream . . . . 19 75 5.2. A Definition for one-to-group One-way Packet Loss 76 Stream . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 5.3. A Definition for one-to-group One-way Jitter Stream . . . 21 78 5.4. Discussion on one-to-group statistics . . . . . . . . . . 22 79 6. Extension from one-to-one to one-to-many measurement . . . . . 24 80 7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 25 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 83 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 26 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 26 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 88 Intellectual Property and Copyright Statements . . . . . . . . . . 29 90 1. Introduction 92 The metrics specified in this memo are built on notions introduced 93 and discussed in the IPPM Framework document, RFC 2330 [RFC2330]. 94 The reader should be familiar with these documents. 96 This memo makes use of definitions of end-to-end One-way Delay 97 Metrics defined in the RFC 2679 [RFC2679] to define metrics for 98 decomposition of end-to-end one-way delays measurements. 100 This memo makes use of definitions of end-to-end One-way Packet loss 101 Metrics defined in the RFC 2680 [RFC2680] to define metrics for 102 decomposition of end-to-end one-way packet loss measurements. 104 The IPPM WG defined a framework for metric definitions and end-to-end 105 measurements: 107 o A general framework for defining performance metrics, described in 108 the Framework for IP Performance Metrics, RFC 2330 [RFC2330]; 110 o A One-way Active Measurement Protocol Requirements, RFC 3763 111 [RFC3763]; 113 o A One-way Active Measurement Protocol (OWAMP) [work in progress]; 115 o An IP Performance Metrics Registry , RFC 4148 [RFC4148]; 117 It specified a set of end-to-end metrics, which conform to this 118 framework: 120 o The IPPM Metrics for Measuring Connectivity, RFC 2678 [RFC2678]; 122 o The One-way Delay Metric for IPPM, RFC 2679 [RFC2679]; 124 o The One-way Packet Loss Metric for IPPM, RFC 2680 [RFC2680]; 126 o The Round-trip Delay Metric for IPPM, RFC 2681 [RFC2681]; 128 o A Framework for Defining Empirical Bulk Transfer Capacity Metrics 129 RFC 3148 [RFC3148]; 131 o One-way Loss Pattern Sample Metrics, RFC 3357 [RFC3357]; 133 o IP Packet Delay Variation Metric for IPPM, RFC 3393 [RFC3393]; 135 o Network performance measurement for periodic streams, RFC 3432 136 [RFC3432]; 138 o Packet Reordering Metric for IPPM [Work in progress]; 140 Based on these works, this memo defines 2 kinds of multi party 141 metrics. 143 Firstly it defines spatial metrics: 145 o A 'sample', called Type-P-Spatial-One-way-Delay-Stream, will be 146 introduced to decompose an end-to-end Type-P-One-way-Delay in a 147 spatial sequence of one-way delays. 149 o A 'sample', called Type-P-Spatial-One-way-Packet-Loss-Stream, will 150 be introduced to decompose an end-to-end Type-P-One-way-Packet- 151 Loss in a spatial sequence of packet loss. 153 o Using the Type-P-Spatial-One-way-Delay-Stream metric, a 'sample', 154 called Type-P-Spatial-One-way-Jitter-Stream, will be introduced to 155 decompose an end-to-end Type-P-One-way-ipdv in a spatial sequence 156 of jitter. 158 o Using the Type-P-Spatial-One-way-Delay-Stream metric, a 'sample', 159 called Type-P-subpath-One-way-Delay-Stream, will be introduced to 160 define the one-way-delay between any host of the path. 162 o Using Type-P-subpath-x-Stream, a 'sample' Type-P-Passive-x-Stream 163 will be introduced to define the Passive metrics. These metrics 164 are designed for pure passive measurement methodology as 165 introduced by PSAMP WG. 167 Then it defines one-to-group metrics. 169 o Using one test packet sent from one sender to a group of 170 receivers, a 'sample', called Type-P-one-to-group-One-way-Delay- 171 Stream, will be introduced to define the list of Type-P-one-way- 172 delay between this sender and the group of receivers. 174 o Using one test packet sent from one sender to a group of 175 receivers, a 'sample', called Type-P-one-to-group-One-way-Packet- 176 Loss-Stream, will be introduced to define the list of Type-P-One- 177 way-Packet-Loss between this sender and the group of receivers 179 o Using one test packet sent from one sender to a group of 180 receivers, a 'sample', called Type-P-one-to-group-One-way-Jitter- 181 Stream, will be introduced to define the list of Type-P-One-way- 182 ipdv between this sender and the group of receivers 184 o Then a discussion section presents the set of statistics that may 185 be computed on the top of these metrics to present the QoS in a 186 view of a group of users as well as the requirements of relative 187 QoS on multiparty communications. 189 2. Terminology 191 2.1. Multiparty metric 193 A metric is said to be multiparty if the definition involved more 194 than two sources or destinations in the measurements. All multiparty 195 metrics define a set of hosts called "points of interest", where one 196 host is the source and other hosts are the measurement collection 197 points. For example, if the set of points of interest is < ha, hb, 198 hc, ..., hn >, where ha is the source and < hb, hc, ..., hn > are the 199 destinations, then measurements may be conducted between < ha, hb>, < 200 ha, hc>, ..., . 202 2.2. Spatial metric 204 A metric is said to be spatial if one of the hosts involved is 205 neither the source nor the destination of the metered packet. 207 2.3. Spatial metric points of interest 209 Points of interest of a spatial metric are the routers or sibling in 210 the path between source and destination (in addition to the source 211 and the destination themself). 213 2.4. One-to-group metric 215 A metric is said to be one-to-group if the measured packet is sent by 216 one source and (potentially) received by several destinations. Thus, 217 the topology of the communication group can be viewed as a centre- 218 distributed or server-client topology with the source as the centre/ 219 server in the topology. 221 2.5. One-to-group metric points of interest 223 Points of interest of One-to-group metrics are the set of host 224 destinations receiving packets from the source (in addition to the 225 source itself). 227 2.6. Reference point 229 The centre/server in the one-to-group measurement that is controlled 230 by network operators can be a very good reference point where 231 measurement data can be collected for further processing although the 232 actual measurements have to be carried out at all points of interest. 234 I.e., the measurement points will be all clients/receivers while the 235 reference point acts as source for the one-to-group metric. Thus, we 236 can define the reference point as the host while the statistic 237 calculation will be carried out. 239 2.7. Group of singletons 241 A group of singletons is the set of results of the observation of the 242 behaviour of the same packet at different places of a network. 244 3. Motivations for spatial and one-to-group metrics 246 All IPPM metrics are defined for end-to-end measurement. These 247 metrics provide very good guides for measurement in the pair 248 communications. However, further efforts should be put to define 249 metrics for multiparty measurements such as one to one trajectory 250 metrics and one to multipoint metrics. 252 3.1. spatial metrics 254 Decomposition of instantaneous end-to-end measures is needed: 256 o The PCE WG is extending existing protocols to permit remote path 257 computation and path computation quality, including inter domain. 258 One may say that in intra domain the decomposing the performance 259 of a path is not whished. However such decomposition is desirable 260 in interdomain to qualify each AS computation with the initial 261 request. So it is necessary to define standard spatial metrics 262 before going further in the computation of inter domain path with 263 QoS constraint. 265 o Traffic engineering and troubleshooting applications require 266 spatial views of the one-way delay consumption, identification of 267 the location of the lost of packets and the decomposition of the 268 jitter over the path. 270 o Monitoring the QoS of a multicast tree, of MPLS point-to- 271 multipoint and inter-domain communication require spatial 272 decomposition of the one-way delay, of the packet loss and of the 273 jitter. 275 o Composition of metrics is a need to scale in the measurement 276 plane. The definition of composition metrics is a work in 277 progress [I-D.ietf-ippm-spatial-composition]; . Spatial measure 278 give typically the individual performance of an intra domain 279 segment. It is the elementary piece of information to exchange 280 for measuring interdomain performance based on composition of 281 metrics. 283 o The PSAMP WG defines capabilities to sample packets in a way to to 284 support measurement. [I-D.boschi-ipfix-reducing-redundancy]; 285 defines a method to collect packets information to measure the 286 instantaneous spatial performance without injecting test traffic. 287 Consequently it is urgent to define a set of common spatial 288 metrics for passive and active techniques which respect the IPPM 289 framework [RFC2330]. This need is emphases by the fact that end- 290 to-end spatial measurement involves the 2 techniques; 292 3.2. One-to-group metrics 294 While the node-to-node based spatial measures can provide very useful 295 data in the view of each connection, we also need measures to present 296 the performance of a multiparty communication in the view of a group 297 with consideration that it involves a group of people rather than 298 two. As a consequence a simple one-way metric cannot describe the 299 multi-connection situation. We need some new metrics to collect 300 performance of all the connections for further statistics analysis. 301 A group of metrics are proposed in this stage named one-to-group 302 performance metrics based on the unicast metrics defined in IPPM WG. 303 One-to-group metrics are trying to composite one-way metrics from one 304 source to a group of destinations to make up new metrics. The 305 compositions are necessary for judging the network performance of 306 multiparty communications and can also be used to describe the 307 difference of the QoS served among a group of users. 309 One-to-group performance metrics are needed for several reasons: 311 o For designing and engineering multicast trees and MPLS point-to- 312 multipoint LSP; 314 o For evaluating and controlling of the quality of the multicast 315 services; 317 o For controlling the performance of the inter domain multicast 318 services; 320 o For presenting and evaluating the relative QoS requirements for 321 the multiparty communications. 323 To understand the connection situation between one source and any one 324 receiver in the multiparty communication group, we need the 325 collection of instantaneous end-to-end measures. It will give us 326 very detailed insight into each branch of the multicast tree in terms 327 of end-to-end absolute QoS. It can provide clear and helpful 328 information for engineers to identify the connection with problems in 329 a complex multiparty routing tree. 331 3.3. Discussion on Group-to-one and Group-to-group metrics 333 We note that points of interest can also be selected to define 334 measurements on Group-to-one and Group-to-group topologies. These 335 topologies are currently beyond the scope of this memo, because they 336 would involve multiple packets launched from different sources. 337 However, we can give some clues here on these two cases. 339 The measurements for group-to-one topology can be easily derived from 340 the one-to-group measurement. The measurement point is the reference 341 point that is acting as a receiver while all of clients/receivers 342 defined for one-to-group measurement act as sources in this case. 344 For the group-to-group connection topology, we can hardly define the 345 reference point and, therefore, have difficulty to define the 346 measurement points. However, we can always avoid this confusion by 347 treating the connections as one-to-group or group-to-one in our 348 measurements without consideration on how the real communication will 349 be carried out. For example, if one group of hosts < ha, hb, hc, 350 ..., hn > are acting as sources to send data to another group of 351 hosts < Ha, Hb, Hc, ..., Hm >, we can always decompose them into n 352 one-to-group communications as < ha, Ha, Hb, Hc, ..., Hm >, < hb, Ha, 353 Hb, Hc, ..., Hm >, , ..., < hn, Ha, Hb, Hc, 354 ..., Hm >. 356 4. Spatial metrics definitions 358 Spatial decomposition metrics are based on standard end-to-end 359 metrics. 361 The definition of a spatial metric is coupled with the corresponding 362 end-to-end metric. The methodoly is based on the measure of the same 363 test packet and parameters of the corresponding end-to-end metric. 365 4.1. A Definition for Spatial One-way Delay Stream 367 This section is coupled with the definition of Type-P-One-way-Delay. 368 When a parameter from section 3 of [RFC2679] is first used in this 369 section, it will be tagged with a trailing asterisk. 371 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 372 statements for end-to-end one-way-delay measurements. They are 373 applicable to each point of interest Hi involved in the measure. 374 Spatial one-way-delay measurement SHOULD be respectful of them, 375 especially those related to methodology, clock, uncertainties and 376 reporting. 378 Following we adapt some of them and introduce points specific to 379 spatial measurement. 381 4.1.1. Metric Name 383 Type-P-Spatial-One-way-Delay-Stream 385 4.1.2. Metric Parameters 387 + Src*, the IP address of the sender. 389 + Dst*, the IP address of the receiver. 391 + i, An integer which ordered the hosts in the path. 393 + Hi, exchange points of the path digest. 395 + T*, a time, the sending (or initial observation) time for 396 a measured packet. 398 + dT* a delay, the one-way delay for a measured packet. 400 + dT1,..., dTn a list of delay. 402 + P*, the specification of the packet type. 404 + , a path digest. 406 4.1.3. Metric Units 408 A sequence of times. 410 4.1.4. Definition 412 Given a Type-P packet sent by the sender Src at wire-time (first bit) 413 T to the receiver Dst in the path . Given the 414 sequence of values such that dT is the 415 Type-P-One-way-Delay from Src to Dst and such that for each Hi of the 416 path, T+dTi is either a real number corresponding to the wire-time 417 the packet passes (last bit received) Hi, or undefined if the packet 418 never passes Hi. 420 Type-P-Spatial-One-way-Delay-Stream metric is defined for the path 421 as the sequence of values 422 . 424 4.1.5. Discussion 426 Following are specific issues which may occur: 428 o the delay looks to decrease: dTi > DTi+1. this seem typically du 429 to some clock synchronisation issue. this point is discussed in 430 the section 3.7.1. "Errors or uncertainties related to Clocks" of 431 of [RFC2679]; 433 o The location of the point of interest in the device influences the 434 result (see [I-D.quittek-ipfix-middlebox]). If the packet is not 435 observed on the input interface the delay includes buffering time 436 and consequently an uncertainty due to the difference between 437 'wire time' and 'host time'; 439 4.1.6. Interference with other test packet 441 To avoid packet collision it is preferable to include a sequence 442 number in the packet. 444 4.1.7. loss threshold 446 To determine if a dTi is defined or undefined it is necessary to 447 define a period of time after which a packet is considered loss. 449 4.1.8. Methodologies 451 Section 3.6 of [RFC2679] gives methodologies for end-to-end one-way- 452 delay measurements. Most of them apply to each points interest Hi 453 and are relevant to this section. 455 Generally, for a given Type-P, in a given Hi, the methodology would 456 proceed as follows: 458 o At each Hi, prepare to capture the packet sent a time T, take a 459 timestamp Ti', determine the internal delay correction dTi', 460 extract the timestamp T from the packet, then compute the one-way- 461 delay from Src to Hi: dTi = Ti' - dTi' - T. The one-way delay is 462 undefined (infinite) if the packet is not detected after the 'loss 463 threshold' duration; 465 o Gather the set of dTi of each Hi and order them according to the 466 path to build the Type-P-Spatial-One-way-Delay-Stream metric 467 over the path . 469 It is out of the scope of this document to define how each Hi detects 470 the packet. 472 4.1.9. Reporting the metric 474 Section 3.6 of [RFC2679] indicates the items to report. 476 4.1.10. Path 478 It is clear that a end-to-end Type-P-One-way-Delay can't determine 479 the list of hosts the packet passes throught. Section 3.8.4 of 480 [RFC2679] says that the path traversed by the packet SHOULD be 481 reported but is practically impossible to determine. 483 This part of the job is provide by Type-P-Spatial-One-way-Delay- 484 Stream metric because each points of interest Hi which capture the 485 packet is part of the path. 487 4.2. A Definition of a sample of One-way Delay of a sub path 489 This metric is similar to the metric Type-P-One-way-Delay-Poisson- 490 stream defined in [RFC2679] and to the metric Type-P-One-way-Delay- 491 Periodic-Stream defined in [RFC3432]. 493 Nevertheless its definition differs because it is based of the 494 decomposition of end-to-end One-way delay using the metric Type-P- 495 Spatial-One-way-Delay-Stream defined above. 497 It aims is to define a sample of One-way-Delay between a pair of 498 hosts of a path usable by active and passive measurements. 500 Sections 3.5 to 3.8 of [RFC2679] give requirements and applicability 501 statements for end-to-end one-way-delay measurements. They are 502 applicable to each point of interest Hi involved in the measure. 503 Subpath one-way-delay measurement SHOULD be respectful of them, 504 especially those related to methodology, clock, uncertainties and 505 reporting. 507 4.2.1. Metric Name 509 Type-P-subpath-One-way-Delay-Stream 511 4.2.2. Metric Parameters 513 + Src*, the IP address of the sender. 515 + Dst*, the IP address of the receiver. 517 + i, An integer which orders exchange points in the path. 519 + k, An integer which orders the packets sent. 521 + , a path digest. 523 + Ha, a host of the path digest different from Dst and Hb; 525 + Hb, a host of the path digest different from Src and Ha. 526 Hb order in the path must greater that Ha; 528 + Hi, exchange points of the path digest. 530 + dT1,..., dTn a list of delay. 532 + P*, the specification of the packet type. 534 4.2.3. Metric Units 536 A sequence of pairs . 538 T is one of time of the sequence T1...Tn; 540 dT is a delay. 542 4.2.4. Definition 544 Given 2 hosts Ha and Hb of the path , given 545 a flow of packets of Type-P sent from Src to Dst at the times T1, 546 T2... Tn. At each of these times, we obtain a Type-P-Spatial-One- 547 way-Delay-Stream . We define the 548 value of the sample Type-P-subpath-One-way-Delay-Stream as the 549 sequence made up of the couples . dTk.a is the 550 delay between Src and Ha. dTk.b is the delay between Src and Hb. 551 'dTk.b - dTk.a' is the one-way delay experienced by the packet sent 552 at the time Tk by Src when going from Ha to Hb. 554 4.2.5. Discussion 556 Following are specific issues which may occur: 558 o The definition permits the measure of when a is 559 Src. 561 o The definition permits the measure of when b is 562 Dst. 564 o the delay looks to decrease: dTi > DTi+1. this seem typically du 565 to some clock synchronisation issue. this point is discussed in 566 the section 3.7.1. "Errors or uncertainties related to Clocks" of 567 of [RFC2679];. 569 o The location of the point of interest in the device influences the 570 result (see [I-D.quittek-ipfix-middlebox]). If the packet is not 571 observed on the input interface the delay includes buffering time 572 and consequently an uncertainty due to the difference between 573 'wire time' and 'host time'; 575 o dTk.b may be observed and not dTk.a. 577 o Tk is unknown if the flow is made of end user packets, that is 578 pure passive measure. In this case Tk may be forced to Tk+dTk.a. 579 This motivate separate metrics names for pure passive measurement 580 or specific reporting information. 582 o Pure passive measure should consider packets of the same size and 583 of the same Type-P. 585 4.2.6. Interference with other packet 587 4.2.7. loss threshold 589 To determine if a dTi is defined or undefined it is necessary to 590 define a period of time after which a packet is considered loss. 592 4.2.8. Methodologies 594 Both active and passive method should discussed. 596 4.2.9. Reporting the metric 598 Section 3.6 of [RFC2679] indicates the items to report. 600 4.2.10. Path 602 4.3. A Definition for Spatial One-way Packet Loss Stream 604 This section is coupled with the definition of Type-P-One-way-Packet- 605 Loss. Then when a parameter from the section 2 of [RFC2680] is first 606 used in this section, it will be tagged with a trailing asterisk. 608 Sections 2.5 to 2.8 of [RFC2680] give requirements and applicability 609 statements for end-to-end one-way-Packet-Loss measurements. They are 610 applicable to each point of interest Hi involved in the measure. 611 Spatial packet loss measurement SHOULD be respectful of them, 612 especially those related to methodology, clock, uncertainities and 613 reporting. 615 Following we define the spatial metric, then we adapt some of the 616 points above and introduce points specific to spatial measurement. 618 4.3.1. Metric Name 620 Type-P-Spatial-One-way-Packet-Loss-Stream 622 4.3.2. Metric Parameters 624 + Src*, the IP address of the sender. 626 + Dst*, the IP address of the receiver. 628 + i, An integer which ordered the hosts in the path. 630 + Hi, exchange points of the path digest. 632 + T*, a time, the sending (or initial observation) time for 633 a measured packet. 635 + dT1,..., dTn, dT, a list of delay. 637 + P*, the specification of the packet type. 639 + , a path digest. 641 + B1, B2, ..., Bi, ..., Bn, a list of boolean values. 643 4.3.3. Metric Units 645 A sequence of boolean values. 647 4.3.4. Definition 649 Given a Type-P packet sent by the sender Src at time T to the 650 receiver Dst in the path . Given the sequence of 651 times the packet passes , 653 Type-P-One-way-Packet-Lost-Stream metric is defined as the sequence 654 of values such that for each Hi of the path, a 655 value of Bi of 0 means that dTi is a finite value, and a value of 1 656 means that dTi is undefined. 658 4.3.5. Discussion 660 Following are specific issues wich may occur: 662 o the result includes the sequence 1,0. This case means that the 663 packet was seen by a host but not by it successor on the path; 665 o 667 The location of the meter in the device influences the result: 669 o Even if the packet is received by a device, it may be not observed 670 by a meter located after a buffer; 672 4.3.6. Reporting 674 Section in progress. 676 4.4. A Definition for Spatial One-way Jitter Stream 678 This section uses parameters from the definition of Type-P-One-way- 679 ipdv. When a parameter from section 2 of [RFC3393] is first used in 680 this section, it will be tagged with a trailing asterisk. 682 Sections 3.5 to 3.7 of [RFC3393] give requirements and applicability 683 statements for end-to-end one-way-ipdv measurements. They are 684 applicable to each point of interest Hi involved in the measure. 685 Spatial one-way-ipdv measurement SHOULD be respectful of them, 686 especially those related to methodology, clock, uncertainities and 687 reporting. 689 Following we adapt some of them and introduce points specific to 690 spatial measurement. 692 4.4.1. Metric Name 694 Type-P-Spatial-One-way-Jitter-Stream 696 4.4.2. Metric Parameters 698 + Src*, the IP address of the sender. 700 + Dst*, the IP address of the receiver. 702 + i, An integer which ordered the hosts in the path. 704 + Hi, exchange points of the path digest. 706 + T1*, the time the first packet was sent. 708 + T2*, the time the second packet was sent. 710 + P, the specification of the packet type. 712 + P1, the first packet sent at time T1. 714 + P2, the second packet sent at time T2. 716 + , a path digest. 718 + , 719 the Type-P-Spatial-One-way-Delay-Stream for packet sent at 720 time T1; 722 + , 723 the Type-P-Spatial-One-way-Delay-Stream for packet sent at 724 time T2; 726 + L*, a packet length in bits. The packets of a Type P 727 packet stream from which the 728 Type-P-Spatial-One-way-Delay-Stream metric is taken MUST 729 all be of the same length. 731 4.4.3. Metric Units 733 A sequence of times. 735 4.4.4. Definition 737 Given the Type-P packet having the size L and sent by the sender Src 738 at wire-time (first bit) T1 to the receiver Dst in the path . 741 Given the Type-P packet having the size L and sent by the sender Src 742 at wire-time (first bit) T2 to the receiver Dst in the same path. 744 Given the Type-P-Spatial-One-way-Delay-Stream of the packet P1. 747 Given the Type-P-Spatial-One-way-Delay-Stream of the packet P2. 750 Type-P-Spatial-One-way-Jitter-Stream metric is defined as the 751 sequence of values Such that for each Hi of the path , 753 dT2.i-dT1.i is either a real number if the packets P1 and P2 passes 754 Hi at wire-time (last bit) dT1.i, respectively dT2.i, or undefined if 755 at least one of them never passes Hi. T2-T1 is the inter-packet 756 emission interval and dT2-dT1 is ddT* the Type-P-One-way-ipdv at 757 T1,T2*. 759 4.4.5. Sections in progress 761 See sections 3.5 to 3.7 of [RFC3393]. 763 4.5. Pure Passive Metrics 765 Spatial metrics may be measured without injecting test traffic as 766 described in [I-D.boschi-ipfix-reducing-redundancy] . 768 4.5.1. Discussion on Passive measurement 770 One might says that most of the operational issues occur in the last 771 mile and that consequently such measure are less useful than active 772 measuremeent. Nevertheless they are usable for network TE and 773 interdomain QoS monitoring, and composition of metric. 775 Such a technique have some limitations that are discussed below. 777 4.5.1.1. Passive One way delay 779 As the packet is not a test packet, it does not include the time it 780 was sent. 782 Consequently a point of interest Hi ignores the time the packet was 783 send. So It is not possible to measure the delay between Src and Hi 784 in the same manner it is not possible to measure the delay betwwen Hi 785 and Dst. 787 4.5.1.2. Passive Packet loss 789 The packet is not a test packet, so it does not include a sequence 790 number. 792 Packet lost measurement doe not require time synchronization and 793 require only one point of observation. Nevertheless it requires the 794 point of interest Hi to be expecting the packet. Practically Hi may 795 not detect a lost of packet that occurs between Src and Hi. 797 A point of interest Hi ignores the time the packet is send because 798 the packet does not carry the time it was injected in the network. 799 So a probe Hi can not compute dTi. 801 An alternative to these issues consist in considering sample spatial 802 One-way delay that T is the time when H1 (the first passive probe of 803 the path) observed the packet. 805 4.5.2. Reporting and composition 807 To avoid misunderstanding and to address specific reporting 808 constraint a proposal consists in defining distinct metrics for pure 809 passive measurement based on the definition above. 811 It is crucial to know the methodologie used because of the difference 812 of method of detection (expecting Seq++); because of the difference 813 of source of time (H1 vs Src) and because of the difference of 814 behavior of the source (Poisson/unknown). 816 4.5.3. naming and registry 818 Having distinct metrics identifiers for spatial metrics and passive 819 spatial metrics in the [RFC4148] will avoid interoperabily issues 820 especially during composition of metrics. 822 They may be named 824 o Type-P-Passive-One-way-delay-Stream 826 o Type-P-Passive-One-way-Packet-Loss-Stream 828 o Type-P-Passive-One-way-jitter-Stream 830 In the same way sample should be registred too. they may be named 832 o Type-P-Passive-One-way-delay-Sample 834 o Type-P-Passive-One-way-Packet-Loss-Sample 836 o Type-P-Passive-One-way-jitter-Sample 838 4.5.4. Passive One way delay metrics 840 4.5.5. Passive One way PacketLoss metrics 842 4.5.6. Passive One way jitter metrics 844 4.6. Discussion on spatial statistics 846 Do we define min, max, avg of spatial metrics ? 848 having the maximum loss metric value could be interesting. Say, 849 the segment between router A and B always contributes loss metric 850 value of "1" means it could be the potential problem segment. 852 Uploading dTi of each Hi consume a lot of bandwidth. Computing 853 statistics (min, max and avg) of dTi locally in each Hi reduce the 854 bandwidth consumption. 856 5. One-to-group metrics definitions 858 5.1. A Definition for one-to-group One-way Delay Stream 860 5.1.1. Metric Name 862 Type-P-one-to-group-One-way-Delay-Stream 864 5.1.2. Metric Parameters 866 o Src, the IP address of a host acting as the source. 868 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 869 receivers. 871 o T, a time. 873 o dT1,...,dTn a list of time. 875 o P, the specification of the packet type. 877 o Gr, the multicast group address (optional). The parameter Gr is 878 the multicast group address if the measured packets are 879 transmitted by multicast. This parameter is to identify the 880 measured traffic from other unicast and multicast traffic. It is 881 set to be optional in the metric to avoid losing any generality, 882 i.e. to make the metric also applicable to unicast measurement 883 where there is only one receivers. 885 5.1.3. Metric Units 887 The value of a Type-P-one-to-group-One-way-Delay-Stream is a set of 888 singletons metrics Type-P-One-way-Delay [RFC2679]. 890 5.1.4. Definition 892 Given a Type P packet sent by the source Src at Time T, given the N 893 hosts { Recv1,...,RecvN } which receive the packet at the time { 894 T+dT1,...,T+dTn }, a Type-P-one-to-group-One-way-Delay-Stream is 895 defined as the set of the Type-P-One-way-Delay singleton between Src 896 and each receiver with value of { dT1, dT2,...,dTn }. 898 5.2. A Definition for one-to-group One-way Packet Loss Stream 900 5.2.1. Metric Name 902 Type-P-one-to-group-One-way-Packet-Loss-Stream 904 5.2.2. Metric Parameters 906 o Src, the IP address of a host acting as the source. 908 o Recv1,..., RecvN, the IP addresses of the N hosts acting as 909 receivers. 911 o T, a time. 913 o T1,...,Tn a list of time. 915 o P, the specification of the packet type. 917 o Gr, the multicast group address (optional). 919 5.2.3. Metric Units 921 The value of a Type-P-one-to-group-One-way-Packet-Loss-Stream is a 922 set of singletons metrics Type-P-One-way-Packet-Loss [RFC2680]. 924 5.2.4. Definition 926 Given a Type P packet sent by the source Src at T and the N hosts, 927 Recv1,...,RecvN, which should receive the packet at T1,...,Tn, a 928 Type-P-one-to-group-One-way-Packet-Loss-Stream is defined as a set of 929 the Type-P-One-way-Packet-Loss singleton between Src and each of the 930 receivers {,,..., }. 932 5.3. A Definition for one-to-group One-way Jitter Stream 934 5.3.1. Metric Name 936 Type-P-one-to-group-One-way-Jitter-Stream 938 5.3.2. Metric Parameters 940 + Src, the IP address of a host acting as the source. 942 + Recv1,..., RecvN, the IP addresses of the N hosts acting as 943 receivers. 945 + T1, a time. 947 + T2, a time. 949 + ddT1,...,ddTn, a list of time. 951 + P, the specification of the packet type. 953 + F, a selection function defining unambiguously the two 954 packets from the stream selected for the metric. 956 + Gr, the multicast group address (optional) 958 5.3.3. Metric Units 960 The value of a Type-P-one-to-group-One-way-Jitter-Stream is a set of 961 singletons metrics Type-P-One-way-ipdv [RFC3393]. 963 5.3.4. Definition 965 Given a Type P packet stream, Type-P-one-to-group-One-way- Jitter- 966 Stream is defined for two packets from the source Src to the N hosts 967 {Recv1,...,RecvN },which are selected by the selection function F, as 968 the difference between the value of the Type-P-one-to-group-One-way- 969 Delay-Stream from Src to { Recv1,..., RecvN } at time T1 and the 970 value of the Type-P-one-to-group- One-way-Delay-Stream from Src to { 971 Recv1,...,RecvN } at time T2. T1 is the wire-time at which Scr sent 972 the first bit of the first packet, and T2 is the wire-time at which 973 Src sent the first bit of the second packet. This metric is derived 974 from the Type-P-one-to- group-One-way-Delay-Stream metric. 976 Therefore, for a set of real number {ddT1,...,ddTn},Type-P-one- to- 977 group-One-way-Jitter-Stream from Src to { Recv1,...,RecvN } at T1, T2 978 is {ddT1,...,ddTn} means that Src sent two packets, the first at 979 wire-time T1 (first bit), and the second at wire-time T2 (first bit) 980 and the packets were received by { Recv1,...,RecvN } at wire-time 981 {dT1+T1,...,dTn+T1}(last bit of the first packet), and at wire-time 982 {dT'1+T2,...,dT'n+T2} (last bit of the second packet), and that 983 {dT'1-dT1,...,dT'n-dTn} ={ddT1,...,ddTn}. 985 5.4. Discussion on one-to-group statistics 987 The defined one-to-group metrics above can all be directly achieved 988 from the relevant unicast one-way metrics. They managed to collect 989 all unicast measurement results of one-way metrics together in one 990 profile and sort them by receivers and packets in a multicast group. 991 They can provide sufficient information regarding the network 992 performance in terms of each receiver and guide engineers to identify 993 potential problem happened on each branch of a multicast routing 994 tree. However, these metrics can not be directly used to 995 conveniently present the performance in terms of a group and neither 996 to identify the relative QoS situation. 998 One may say that no matter how many people join the communication, 999 the connections can still be treated as a set of one-to-one 1000 connection. However, we might not describe a multiparty 1001 communication by a set of one-way measurement metrics because of the 1002 difficulty for understanding and the lack of convenience. For 1003 instance, an engineer might not describe the connections of a 1004 multiparty online conference in terms of one-to-group one-way delay 1005 for user A and B, B and C, and C and A because people might be 1006 confused. If there are more users in the same communication, the 1007 description might be very long. And he might use the one-way metrics 1008 with worst and the best value to give users an idea of the QoS range 1009 of the service they are providing. But it is not clear enough and 1010 might not be accurate in a large multiparty communication scenario. 1012 From the QoS point of view, the multiparty communication services not 1013 only require the absolute QoS support but also the relative QoS. The 1014 relative QoS means the difference between absolute QoS of all users. 1015 Directly using the one-way metrics cannot present the relative QoS 1016 situation. However, if we use the variations of all users one-way 1017 parameters, we can have new metrics to measure the difference of the 1018 absolute QoS and hence provide the threshold value of relative QoS 1019 that a multiparty service might demand. A very good example of the 1020 high relative QoS requirement is the online gaming. A very light 1021 worse delay will result in failure in the game. We have to use the 1022 new statistic metrics to define exactly how small the relative delay 1023 the online gaming requires. There are many other services, e.g. 1024 online biding, online stock market, etc., need a rule to judge the 1025 relative QoS requirement. Therefore, we can see the importance of 1026 new statistic metrics to feed this need. 1028 We might use some one-to-group statistic conceptions to present the 1029 group performance and relative QoS. In this stage, we define one-to- 1030 group mean stream and one-to-group variation stream. These 1031 statistics are offered mostly to be illustrative of what could be 1032 done. 1034 One-to-group mean streams are trying to measure the overall QoS for a 1035 multicast group associated to one source. It is a reflection of the 1036 absolute QoS of a multiparty communication service when we treat all 1037 receivers as one customer. It can also present the trend of the 1038 absolute QoS of all receivers, i.e., it shows that most of the 1039 receivers in the multiparty communication service trend to receive an 1040 absolute QoS close to the mean. 1042 One-to-group variation streams are trying to measure how the QoS 1043 varies among all of the users in a multicast group associated to one 1044 source. The word "variation" in this memo is the population standard 1045 deviation. It reflects the relative QoS situation in a multiparty 1046 communication service, i.e., the level of the difference between the 1047 absolute QoS of each receivers. 1049 Using the one-to-group mean and one-to-group variation concepts, we 1050 can have a much clear understand on the QoS of a multiparty 1051 communication service in terms of its trend and range. There can be 1052 mean and variation stream definitions for each of the three one-to- 1053 group metrics defined above. We only present the definition of Type- 1054 P-one-to-group-One-way- Delay-Mean-Stream and Type-P-one-to-group- 1055 One-way-Delay-Variation-Stream as examples in this memo. 1057 5.4.1. Type-P-one-to-group-One-way-Delay-Mean-Stream 1059 Given a Type-P-one-to-group-One-way-Delay-Stream, the mean stream of 1060 all { dT1, dT2,...,dTn } for the packet from Src at time T to { 1061 Recv1,...,RecvN }. 1063 For example, suppose we take a sample and the results are: 1065 Delay_Stream = < 1066 {T1,...,Tn} 1067 {T'1,...,T'n} 1068 {T''1,...T''n} 1069 > 1071 Then the mean stream would be: 1073 Delay_Mean_Stream = < 1074 DM1 1075 DM2 1076 DM3 1077 > 1078 = < 1079 sum{T1,...,Tn}/n 1080 sum{T'1,...,T'n}/n 1081 sum{T''1,...T''n}/n 1082 > 1084 5.4.2. Type-P-one-to-group-One-way-Delay-Variation-Stream 1086 Given a Type-P-one-to-group-One-way-Delay-Stream, the variation 1087 stream of all { dT1, dT2,...,dTn } for the packet from Src at time T 1088 to { Recv1,...,RecvN }. 1090 We still take the above Delay_Stream as a sample and the variation 1091 stream would be: 1093 Delay_Variation_Stream = < 1094 DV1 1095 DV2 1096 DV3 1097 > 1098 =< 1099 (SUM{(T1-DM1)^2,...,(Tn-DM1)^2)}/n)^(1/2) 1100 (SUM{(T'1-DM2)^2,...,(T'n-DM2)^2)}/n)^(1/2) 1101 (SUM{(T''1-DM3)^2,...,(T''n-DM3)^2)}/n)^(1/2) 1102 > 1104 6. Extension from one-to-one to one-to-many measurement 1106 The above one-to-group metrics were defined to compose measurement 1107 results of a group of users who receive the same data from one 1108 source. Moreover, this is one of efforts to introducing the one-to- 1109 many concern to the IPPM working group with respect to the fact that 1110 all existing documents in the group are unicast oriented, which talk 1111 about only one-to-one single "path" in measurements. This concept 1112 can be extended from the "path" to "path tree" to cover both one-to- 1113 one and one-to-many communications. Actually, the one-to-one 1114 communications can be viewed as a special case of one-to-many from 1115 the routing point of view. The one-to-many communications build up a 1116 routing tree in the networks and one-to-one can be viewed as a 1117 special simplified tree without branches but only the "trunk". 1119 Therefore, the one-to-group metrics described in this memo can even 1120 be viewed as general metrics to measure the delay, jitter and packet 1121 loss in IP networks. When it applies to one-to-one communications, 1122 the metrics will have N receivers while N equal to 1. And the 1123 statistic metrics for one-to-one communications are exactly the one- 1124 to-group metrics themselves when calculated using the methods given. 1126 7. Open issues 1128 8. Security Considerations 1130 Active measumrement: see security section in owd pl, jitter rfcs 1131 (editor notes: add references). 1133 passive measurement: The rate of packet sampling is controled by hash 1134 funcion. The analysis of such a function to generate packets that 1135 match the hash funcion may lead to a DoS attack toward the collector. 1136 The generation of packets with spoofing adresses may corrupt the 1137 results without any possibility to detect the spoofing. 1139 TODO: one-to-group metrics defined here are not intrusive: they rely 1140 on measures of owd... nevertheless they require collection of 1141 singletons which may overload the network the measurement controller 1142 is attach to. 1144 The one-to-group metrics are derived from one-way metrics and 1145 therefore, they have very close relationship. 1147 9. Acknowledgments 1149 Lei would like to acknowledge Zhili Sun from CCSR, University of 1150 Surrey, for his instruction and helpful comments on this work. 1152 10. IANA Considerations 1153 Metrics defined in this memo will be registered in the IANA IPPM 1154 METRICS REGISTRY as described in initial version of the registry 1155 [RFC4148]. 1157 11. References 1159 11.1. Normative References 1161 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 1162 "Framework for IP Performance Metrics", RFC 2330, 1163 May 1998. 1165 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1166 Delay Metric for IPPM", RFC 2679, September 1999. 1168 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1169 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1171 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation 1172 Metric for IP Performance Metrics (IPPM)", RFC 3393, 1173 November 2002. 1175 [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics 1176 Registry", BCP 108, RFC 4148, August 2005. 1178 11.2. Informative References 1180 [I-D.boschi-ipfix-reducing-redundancy] 1181 Boschi, E. and L. Mark, "Reducing redundancy in IPFIX and 1182 PSAMP reports", draft-boschi-ipfix-reducing-redundancy-01 1183 (work in progress), March 2006. 1185 [I-D.ietf-ippm-spatial-composition] 1186 Morton, A. and E. Stephan, "Spatial Composition of 1187 Metrics", draft-ietf-ippm-spatial-composition-00 (work in 1188 progress), February 2006. 1190 [I-D.quittek-ipfix-middlebox] 1191 Quittek, J., "Guidelines for IPFIX Implementations on 1192 Middleboxes", draft-quittek-ipfix-middlebox-00 (work in 1193 progress), February 2004. 1195 [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring 1196 Connectivity", RFC 2678, September 1999. 1198 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip 1199 Delay Metric for IPPM", RFC 2681, September 1999. 1201 [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining 1202 Empirical Bulk Transfer Capacity Metrics", RFC 3148, 1203 July 2001. 1205 [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample 1206 Metrics", RFC 3357, August 2002. 1208 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network 1209 performance measurement with periodic streams", RFC 3432, 1210 November 2002. 1212 [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active 1213 Measurement Protocol (OWAMP) Requirements", RFC 3763, 1214 April 2004. 1216 Authors' Addresses 1218 Stephan Emile 1219 France Telecom Division R&D 1220 2 avenue Pierre Marzin 1221 Lannion, F-22307 1223 Fax: +33 2 96 05 18 52 1224 Email: emile.stephan@francetelecom.com 1226 Lei Liang 1227 CCSR, University of Surrey 1228 Guildford 1229 Surrey, GU2 7XH 1231 Fax: +44 1483 683641 1232 Email: L.Liang@surrey.ac.uk 1234 Al Morton 1235 200 Laurel Ave. South 1236 Middletown, NJ 07748 1237 USA 1239 Phone: +1 732 420 1571 1240 Email: acmorton@att.com 1242 Intellectual Property Statement 1244 The IETF takes no position regarding the validity or scope of any 1245 Intellectual Property Rights or other rights that might be claimed to 1246 pertain to the implementation or use of the technology described in 1247 this document or the extent to which any license under such rights 1248 might or might not be available; nor does it represent that it has 1249 made any independent effort to identify any such rights. Information 1250 on the procedures with respect to rights in RFC documents can be 1251 found in BCP 78 and BCP 79. 1253 Copies of IPR disclosures made to the IETF Secretariat and any 1254 assurances of licenses to be made available, or the result of an 1255 attempt made to obtain a general license or permission for the use of 1256 such proprietary rights by implementers or users of this 1257 specification can be obtained from the IETF on-line IPR repository at 1258 http://www.ietf.org/ipr. 1260 The IETF invites any interested party to bring to its attention any 1261 copyrights, patents or patent applications, or other proprietary 1262 rights that may cover technology that may be required to implement 1263 this standard. Please address the information to the IETF at 1264 ietf-ipr@ietf.org. 1266 Disclaimer of Validity 1268 This document and the information contained herein are provided on an 1269 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1270 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1271 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1272 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1273 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1274 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1276 Copyright Statement 1278 Copyright (C) The Internet Society (2006). This document is subject 1279 to the rights, licenses and restrictions contained in BCP 78, and 1280 except as set forth therein, the authors retain all their rights. 1282 Acknowledgment 1284 Funding for the RFC Editor function is currently provided by the 1285 Internet Society.