idnits 2.17.1 draft-ietf-ippm-framework-compagg-00.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 506. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 483. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 490. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 496. ** 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 : ---------------------------------------------------------------------------- No issues found here. 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 (February 24, 2006) is 6629 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) == Missing Reference: 'RFC2330' is mentioned on line 267, but not defined == Unused Reference: 'I-D.ietf-ippm-multimetrics' is defined on line 442, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ippm-multimetrics-00 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton, Ed. 3 Internet-Draft AT&T Labs 4 Expires: August 28, 2006 S. Van den Berghe, Ed. 5 Ghent University - IBBT 6 February 24, 2006 8 Framework for Metric Composition 9 draft-ietf-ippm-framework-compagg-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 28, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This memo describes a framework for composing and aggregating metrics 43 (both in time and in space) defined by RFC 2330 and developed by the 44 IPPM working group. The framework describes the generic composition 45 and aggregation mechanisms. It provides a basis for additional 46 documents that implement this framework for detailed, and practically 47 useful, compositions and aggregations of metrics. 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Description of Metric Types . . . . . . . . . . . . . . . . . 4 61 3.1. Time Aggregation Description . . . . . . . . . . . . . . . 4 62 3.2. Spatial Aggregation Description . . . . . . . . . . . . . 5 63 3.3. Spatial Composition Description . . . . . . . . . . . . . 5 64 3.4. Help Metrics . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.5. Higher Order Composition . . . . . . . . . . . . . . . . . 6 66 4. Requirements for Composed Metrics . . . . . . . . . . . . . . 6 67 5. Guidelines for Defining Composed Metrics . . . . . . . . . . . 7 68 5.1. Ground Truth: Comparison with other IPPM Metrics . . . . . 7 69 5.2. Deviation from the Ground Truth . . . . . . . . . . . . . 9 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 77 Intellectual Property and Copyright Statements . . . . . . . . . . 13 79 1. Introduction 81 The IPPM framework RFC 2330 [RFC2330] describes two forms of metric 82 composition, spatial and temporal. Also, the text suggests that the 83 concepts of the analytical framework (or A-frame) would help to 84 develop useful relationships to derive the composed metrics from real 85 metrics. The effectiveness of composed metrics is dependent on their 86 usefulness in analysis and applicability to practical measurement 87 circumstances. 89 This memo expands on the notion of composition, and provides a 90 detailed framework for several classes of metrics that were mentioned 91 in the original IPPM framework. The classes include temporal 92 aggregation, spatial aggregation, and spatial composition. 94 1.1. Motivation 96 The deployment of a measurement infrastructure and the collection of 97 elementary measurements are not enough to understand and keep under 98 control the network's behaviour. Network measurements need in 99 general to be post-processed to be useful for the several tasks of 100 network engineering and management. The first step of this post 101 processing is often a process of "composition" of single measurements 102 or measurement sets into other ones. The reasons for doing so are 103 briefly introduced here. 105 A first reason, mainly applicable to network engineering, is 106 scaleability. Due to the number of network elements in large 107 networks, it is impossible to perform measurements from each element 108 to all others. It is necessary to select a set of links of special 109 interest and to perform the measurements there. Examples for this 110 are active measurements of one-way delay, jitter, and loss. 112 Another reason may be data reduction (opposite need with respect to 113 the previous one, where more data is generated). This is of interest 114 for network planners and managers. Let us assume that there is 115 network domain in which delay measurements are performed among a 116 subset of its elements. A network manager might ask whether there is 117 a problem with the network delay in general. Therefore, it would be 118 desirable to obtain a single value giving an indication of the 119 general network delay. This value has to be calculated from the 120 elementary delay measurements, but it not obvious how: for example, 121 it does not seem to be reasonable to average all delay measurements, 122 as some links (e.g. having a higher bandwidth or more important 123 customers) might be considered more important than others. 125 Moreover, metric manipulation (or "composition") can be helpful to 126 provide, from raw measurement data, some tangible, well-understood 127 and agreed upon information about the services guarantees provided by 128 a network. Such information can be used in the SLA/SLS contracts 129 among a Provider and its Customers Finally, another important reason 130 for composing measurements is to perform trend analysis. For doing 131 so, a single value for an hour, a day or, a month is computed from 132 the basic measurements which are scheduled e.g. every five minutes. 133 In doing so, trends can be more easily witnessed, like an increasing 134 usage of a backbone link which might require the installation of 135 alternative links or the rerouting of some network flows. 137 2. Purpose and Scope 139 The purpose of this memo is provide a common framework for the 140 various classes of metrics based on composition of primary metrics. 141 The scope is limited to the definitions of metrics that are composed 142 from primary metrics using a deterministic relationship. Key 143 information about each metric, such as its assumptions under which 144 the relationship holds, and possible sources of error/circumstances 145 where the composition may fail, are included. 147 This memo will retain the terminology of the IPPM Framework as much 148 as possible, but will extend the terminology when necessary. 150 3. Description of Metric Types 152 This section defines the various classes of Composition. There are 153 two classes more accurately referred to as aggregation over time and 154 space, and the third is simply composition in space. 156 3.1. Time Aggregation Description 158 Firstly, aggregation in time is defined as the composition of metrics 159 with the same type and scope obtained in different time instants or 160 time windows. For example, starting from a time series of One-Way 161 Delay measurements on a certain network path obtained in 5-minute 162 periods and averaging groups of 12 consecutive values, a time series 163 measurement with a coarser resolution. The main reason for doing 164 time aggregation is to reduce the amount of data that has to be 165 stored, and make the visualization/spotting of regular cycles and/or 166 growing or decreasing trends easier. Another useful application is 167 to detect anomalies or abnormal changes in the network 168 characteristics. 170 Note that in RFC 2330, the term temporal composition is introduced, 171 but with a different meaning than the one given here to aggregation 172 in time. The temporal composition considered there refers to 173 methodologies to predict future metrics on the basis of past 174 observations, exploiting the time correlation that certain metrics 175 can exhibit. We do not consider this type of composition here. 177 3.2. Spatial Aggregation Description 179 Aggregation in space is defined as the composition of metrics of the 180 same type but with different scope. This composition may involve 181 weighing the contributions of the several input metrics. For 182 example, if we want to compose together the average OWD of the 183 several Origin- Destination pairs of a network domain (thus where the 184 inputs are already "statistics" metrics) it makes sense to weight 185 each metric according to the traffic carried on the relative OD pair: 186 OWD_sum=f1*OWD_1+f2*OWD_2+...+fn*OWD_n where fi=load_OD_i/total_load. 187 Another example of metric that could be "aggregated in space", is the 188 maximum edge-to-edge delay across a single domain. Assume that a 189 Service Provider wants to advertise the maximum delay that transit 190 traffic will experience while passing through his/her domain. As 191 there are multiple edge-to-edge paths across a domain, shown with 192 different coloured arrows in the following figure, the Service 193 Provider has to either advertise a list of delays each of them 194 corresponding to a specific edge-to-edge path, or advertise a maximum 195 value. The latter approach is more scalable and simplifies the 196 advertisement of measurement information via interdomain protocols, 197 such as BGP. Similar operations can be provided to other metrics, 198 e.g. "maximum edge-to-edge packet loss", etc. We suggest that space 199 aggregation is generally useful to obtain a summary view of the 200 behaviour of large network portions, or in general of coarser 201 aggregates. The metric collection time instant, i.e. the metric 202 collection time window of measured metrics is not considered in space 203 aggregation. We assume that either it is consistent for all the 204 composed metrics, e.g. compose a set of average delays all referred 205 to the same time window, or the time window of each composed metric 206 does not affect aggregated metric. 208 3.3. Spatial Composition Description 210 The concatenation in space is defined as the composition of metrics 211 of same type and different (physical and non-overlapping) spatial 212 scope, so that the resulting metric is representative of what the 213 metric would be if directly obtained with a direct measurement over 214 the sequence of the several spatial scopes. An example is the sum of 215 OWDs of different edge-to- edge domain's delays, where the 216 intermediate edge points are close to each other or happen to be the 217 same. In this way, we can for example estimate OWD_AC starting from 218 the knowledge of OWD_AB and OWD_BC. 220 Different from aggregation in space, all path's portions contribute 221 equally to the composed metric, independent of the traffic load 222 present. 224 3.4. Help Metrics 226 Finally, note that in practice there is often the need of extracting 227 a new metric making some computation over one or more metrics with 228 the same spatial and time scope. For example, the composed metric 229 rtt_sample_variance may be composed from two different metrics: the 230 help metric rtt_square_sum and the statistical metric rtt_sum. This 231 operation is however more a simple calculation and not an aggregation 232 or a concatenation, and we'll not investigate it further in this 233 document. 235 3.5. Higher Order Composition 237 Composed metrics might themselves be subject to further concatenation 238 or aggregation. An example would be a maximal domain obtained 239 through the spatial composition of end-to-end delays, that are 240 themselves obtained through spatial composition. All requirements 241 for first order composition metrics apply to higher order 242 composition. 244 4. Requirements for Composed Metrics 246 The definitions for all composed metrics MUST include sections to 247 treat the following topics. 249 The description of each metric will clearly state: 251 1. the definition (and statistic, where appropriate); 253 2. the composition or aggregation relationship; 255 3. the specific conjecture on which the relationship is based; 257 4. a justification of practical utility or usefulness for analysis 258 using the A-frame concepts; 260 5. one or more examples of how the conjecture could be incorrect and 261 lead to inaccuracy; 263 6. the information to be reported. 265 Each metric will require a relationship to determine the aggregated 266 or composed metric. The relationships may involve conjecture, and 267 [RFC2330] lists four points that the metric definitions should 268 include: 270 o the specific conjecture applied to the metric, 272 o a justification of the practical utility of the composition, in 273 terms of making accurate measurements of the metric on the path, 275 o a justification of the usefulness of the aggregation or 276 composition in terms of making analysis of the path using A-frame 277 concepts more effective, and 279 o an analysis of how the conjecture could be incorrect. 281 For each metric, the applicable circumstances are defined, in terms 282 of whether the composition or aggregation: 284 o Requires homogeneity of measurement methodologies, or can allow a 285 degree of flexibility (e.g., active or passive methods produce the 286 "same" metric). Also, the applicable sending streams will be 287 specified, such as Poisson, Periodic, or both. 289 o Needs information or access that will only be available within an 290 operator's domain, or is applicable to Inter-domain composition. 292 o Requires precisely synchronized measurement time intervals in all 293 component metrics, or loosely synchronized, or no timing 294 requirements. 296 o Requires assumption of component metric independence w.r.t. the 297 metric being defined/composed, or other assumptions. 299 o Has known sources of inaccuracy/error, and identifies the sources. 301 5. Guidelines for Defining Composed Metrics 303 5.1. Ground Truth: Comparison with other IPPM Metrics 305 Figure 1 illustrates the process to derive a metric using spatial 306 composition, and compares the composed metric to other IPPM metrics. 308 Metrics describe the performance of sub-paths between 309 the Source and Destination of interest during time interval . 310 These metrics are the inputs for a Composition Relationship that 311 produces a Composed Metric. 313 Sub-Path Metrics 314 ++ M1 ++ ++ M2 ++ ++ M3 ++ 315 Src ||.......|| ||.......|| ||.......|| Dst 316 ++ `. ++ ++ | ++ ++ .' ++ 317 `. | .-' 318 `-. | .' 319 `._..|.._.' 320 ,-' `-. 321 ,' `. 322 | Composition | 323 \ Relationship ' 324 `._ _,' 325 `--.....--' 326 | 327 ++ | ++ 328 Src ||...............................|| Dst 329 ++ Composed Metric ++ 331 ++ Complete Path Metric ++ 332 Src ||...............................|| Dst 333 ++ ++ 334 Spatial Metric 335 ++ S1 ++ S2 ++ S3 ++ 336 Src ||........||.........||..........|| Dst 337 ++ ++ ++ ++ 338 Figure 1 Comparison with other IPPM metrics 340 The Composed Metric is an estimate of an actual metric collected over 341 the complete Source to Destination path. We say that the Complete 342 Path Metric represents the "Ground Truth" for the Composed Metric. 343 In other words, Composed Metrics seek to minimize error w.r.t. the 344 Complete Path Metric. 346 Further, we observe that a Spatial Metric I-D.ietf-ippm-multimetrics 347 [I-D.ietf-ippm-multimetrics]collected for packets traveling over the 348 same set of sub-paths provide a basis for the Ground Truth of the 349 individual Sub-Path metrics. We note that mathematical operations 350 may be necessary to isolate the performance of each sub-path. 352 Next, we consider multiparty metrics as defined in [I-D.ietf-ippm- 353 multimetrics], and their spatial composition. Measurements to each 354 of the Receivers produce an element of the one-to-group metric. 355 These elements can be composed from sub-path metrics and the composed 356 metrics can be combined to create a composed one-to-group metric. 357 Figure 2 illustrates this process. 359 Sub-Path Metrics 360 ++ M1 ++ ++ M2 ++ ++ M3 ++ 361 Src ||.......|| ||.......|| ||.......||Rcvr1 362 ++ ++ ++`. ++ ++ ++ 363 `-. 364 M4`.++ ++ M5 ++ 365 || ||.......||Rcvr2 366 ++ ++`. ++ 367 `-. 368 M6`.++ 369 ||Rcvr3 370 ++ 372 One-to-Group Metric 373 ++ ++ ++ ++ 374 Src ||........||.........||..........||Rcvr1 375 ++ ++. ++ ++ 376 `-. 377 `-. ++ ++ 378 `-||..........||Rcvr2 379 ++. ++ 380 `-. 381 `-. ++ 382 `-.||Rcvr3 383 ++ 384 Figure 2 Composition of One-to-Group Metrics 386 Here, Sub-path Metrics M1, M2, and M3 are combined using a 387 relationship to compose the metric applicable to the Src-Rcvr1 path. 388 Similarly, M1, M4, and M5 are used to compose the Src-Rcvr2 metric 389 and M1, M4, and M6 compose the Src-Rcvr3 metric. 391 The Composed One-to-Group Metric would list the Src-Rcvr metrics for 392 each Receiver in the Group: 394 (Composed-Rcvr1, Composed-Rcvr2, Composed-Rcvr3) 396 The "Ground Truth" for this composed metric is of course an actual 397 One-to-Group metric, where a single source packet has been measured 398 after traversing the Complete Paths to the various receivers. 400 5.2. Deviation from the Ground Truth 402 A metric composition can deviate from the ground truth for several 403 reasons. Two main aspects are: 405 o The propagation of the inaccuracies of the underlying measurements 406 when composing the metric. As part of the composition function, 407 errors of measurements might propagate. Where possible, this 408 analysis should be made and included with the description of each 409 metric. 411 o A difference in scope. When concatenating hop-by-hop active 412 measurement results to obtain the end-to-end metric, the actual 413 measured path will not be identical to the end-to-end path. It is 414 in general difficult to quantify this deviation, but a metric 415 definition might identify guidelines for keeping the deviation as 416 small as possible. 418 The description of the metric composition MUST include an section 419 identifying the deviation from the ground truth. 421 6. IANA Considerations 423 This document makes no request of IANA. 425 Note to RFC Editor: this section may be removed on publication as an 426 RFC. 428 7. Security Considerations 430 8. Acknowledgements 432 The authors would like to thank Maurizio Molina, Andy Van Maele, 433 Andreas Haneman, Igor Velimirovic, Andreas Solberg, Athanassios 434 Liakopulos, David Schitz, Nicolas Simar and the Geant2 Project. We 435 also acknowledge comments and suggestions from Emile Stephan and Lei 436 Liang. 438 9. References 440 9.1. Normative References 442 [I-D.ietf-ippm-multimetrics] 443 Stephan, E., "IP Performance Metrics (IPPM) for spatial 444 and multicast", draft-ietf-ippm-multimetrics-00 (work in 445 progress), January 2006. 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, March 1997. 450 9.2. Informative References 451 Authors' Addresses 453 Al Morton (editor) 454 AT&T Labs 455 200 Laurel Avenue South 456 Middletown,, NJ 07748 457 USA 459 Phone: +1 732 420 1571 460 Fax: +1 732 368 1192 461 Email: acmorton@att.com 462 URI: http://home.comcast.net/~acmacm/ 464 Steven Van den Berghe (editor) 465 Ghent University - IBBT 466 G. Crommenlaan 8 bus 201 467 Gent 9050 468 Belgium 470 Phone: +32 9 331 49 73 471 Email: steven.vandenberghe@intec.ugent.be 472 URI: http://www.ibcn.intec.ugent.be 474 Intellectual Property Statement 476 The IETF takes no position regarding the validity or scope of any 477 Intellectual Property Rights or other rights that might be claimed to 478 pertain to the implementation or use of the technology described in 479 this document or the extent to which any license under such rights 480 might or might not be available; nor does it represent that it has 481 made any independent effort to identify any such rights. Information 482 on the procedures with respect to rights in RFC documents can be 483 found in BCP 78 and BCP 79. 485 Copies of IPR disclosures made to the IETF Secretariat and any 486 assurances of licenses to be made available, or the result of an 487 attempt made to obtain a general license or permission for the use of 488 such proprietary rights by implementers or users of this 489 specification can be obtained from the IETF on-line IPR repository at 490 http://www.ietf.org/ipr. 492 The IETF invites any interested party to bring to its attention any 493 copyrights, patents or patent applications, or other proprietary 494 rights that may cover technology that may be required to implement 495 this standard. Please address the information to the IETF at 496 ietf-ipr@ietf.org. 498 Disclaimer of Validity 500 This document and the information contained herein are provided on an 501 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 502 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 503 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 504 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 505 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 506 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 508 Copyright Statement 510 Copyright (C) The Internet Society (2006). This document is subject 511 to the rights, licenses and restrictions contained in BCP 78, and 512 except as set forth therein, the authors retain all their rights. 514 Acknowledgment 516 Funding for the RFC Editor function is currently provided by the 517 Internet Society.