idnits 2.17.1 draft-ionta-spatial-metrics-multiparty-services-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 832 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC6390], [RFC5835], [RFC5644]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- The document date (December 5, 2012) is 4157 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) ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Ionta 2 Internet-Draft Telecom Italia Labs 3 Intended status: Standard Track December 5, 2012 4 Expires: June 4, 2013 6 Spatial Aggregation Metrics for Multipary Services 7 draft-ionta-spatial-metrics-multiparty-services-01 9 Abstract 11 One of the best chances for a Service Provider to face the complex 12 growth of IP Services, and their challenging requirements/SLAs along 13 the Core network, is to enrich the current Performance metrics - mainly 14 derived from a Network-oriented point of view, and therefore a general 15 perspective, not focused on specific services - with some more 16 Performance factors, so to include a Service-oriented point of view, 17 more centred on the particular kind of service, with its own 18 characteristics in terms of protocol, application, manageability, 19 and so on. 20 To achieve the above goal, and starting from the one-to-group 21 performance metrics outlined in RFC 5644 [RFC5644], an effort to a 22 deeper analysis and definition of spatial aggregation metrics (as a 23 part of the framework for metric composition defined in RFC 5835 24 [RFC5835])is proposed in this memo, where the main focus is on 25 multiparty communications (e.g. video providers, online biding, 26 online stock market, etc.). 27 This memo lends itself to passive measurement as well as active 28 measurement. 29 Finally this memo is tuned to RFC 6390 [RFC6390] in terms of scopes, 30 framework concepts, and need to widen the current performance metrics 31 depending on the application, service etc. 33 Status of this memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 7, 2012. 48 Copyright Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 63 1. Introduction and Scope ..........................................2 64 2. Terminology .....................................................3 65 3. Brief metric description.........................................6 66 4. One-to-Group Link Metrics definition ............................7 67 5. One-to-Group Link and Path Statistics ...........................8 68 6. One-to-Group Overall Packet Loss Statistics ....................11 69 7. Extended applications...........................................12 70 8. Security Considerations ........................................12 71 9. References .....................................................13 72 10. Acknowledgments................................................13 74 1. Introduction and Scope 76 Current Performance Metrics, especially those applied to the core 77 network, derive from a general perspective approach, only based on a 78 Network-oriented point of view, therefore unconnected to the kind of 79 service offered on the network. 80 But, due to the growing need to face the complexity of the new IP 81 Services, and their challenging SLAs, this approach has become 82 inadequate, especially while trying to detect the impact of a 83 performance measurement on a particular service. For instance, if a 84 network or a link has a 10-4 average PLR, does this impact on the kind 85 of service required to be monitored? And to what degree? 87 Moreover, this general perspective approach is unsuited to perceive 88 further various factors to be taken into account, such as: 90 - the specificity of the service, with its own protocol, application 91 (i.e. coding), and management (i.e. QOS, fragmentation management) 92 characteristics. 94 - the kind of network topology over which the particular service is 95 implemented (i.e. redundancy, tunneling, etc.). 97 A trivial but clarifying example of this occurs when the same PLR is 98 detected over two different links: one of the link coming out from the 99 root (source) of a multicast tree, and the other link ending with a 100 leaf (receiver). 102 The impact on the service, of course, is dramatically different if the 103 two cases are considered separately, since the first kind of link 104 conveys the whole set of flows originating from the source, while the 105 second one conveys just a subset of the whole set of flows. 107 As a consequence of the above consideration, a Service-oriented point of 108 View - more centred on the particular kind of service, and its own 109 specific characteristics - must be taken into account while defining 110 Performance metrics. 111 In particular two needs raise: 113 - an effort to a deeper analysis and definition of spatial aggregation 114 metrics (as a part of the framework for metric composition defined in 115 RFC 5835 [RFC5835]), thus assigning a sort of weight, specific, and 116 different for each link, to the PLR measured over it, in order to take 117 into account the impact of the PLR on the service. 119 - starting from the metrics outlined in the RFC 5644 [RFC5644] for 120 multiparty services, define performance metrics aggregation, so to 121 enrich the current Performance Metrics, mainly derived from a 122 Network-oriented point of view. 124 The main focus of this memo is to address these two needs for 125 multiparty communications (e.g. TV broadcast providers, video 126 providers, online biding, online stock market, etc.) in order to 127 better evaluate the network against the service requirements. 129 This memo lends itself to passive measurement as well as active 130 measurement (with dedicated test traffic). In reality, if the 131 service provider is in control of the Source traffic on the tree, 132 and knows and/or can arrange the traffic headers to be suitable for 133 measurement, then it blurs the lines quite a bit between passive and 134 active. The Source's inter-packet sending time distribution comes into 135 focus as the main difference - it will not be Poisson and may not be 136 Periodic. This is a key area to address further. 138 Finally this memo is tuned to RFC 6390 [RFC6390] in terms of scopes, 139 framework concepts, and need to widen the current performance metrics 140 depending on the application, service etc. 142 1.1. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 2. Terminology 150 2.1 Naming of the metrics 152 The names of the metrics, including capitalized letters, are as close as 153 possible of the names of the one-way end-to-end or one-to-group metrics 154 they are derived from. 156 2.2 Terms defined elsewhere 158 composed metric: section 4 of RFC 5835 159 composition function: section 4 of RFC 5835 160 higher-order composition: section 5 of RFC 5835 161 host: section 5 of RFC 2330 162 link: path: section 5 of RFC 2330 163 one-to-group metric: section 2 of RFC 5644 164 path: section 5 of RFC 2330 165 router: section 5 of RFC 2330 166 routers digest: section 2 of RFC 5644 167 sample: section 11 of RFC 2330 168 singleton: section 11 of RFC 2330 169 spatial aggregation: section 5 of RFC 5835 170 spatial composition: section 5 of RFC 5835 171 spatial metric: section 2 of RFC 5644 172 subpath: section 5 of RFC 2330 173 temporal aggregation: section 5 of RFC 5835 174 Type-P: see RFC 2330 175 Type-P-One-way-Packet-Loss-Average: see RFC 2680, and RFC 5644 177 2.3 One-to-Group metrics defined elsewhere 179 Type-P-One-to-group-Packet-Loss-Vector: section 7, and 8 of RFC 5644 180 Type-P-One-to-group-Receiver-n-Loss-Ratio: section 7, and 8 of RFC 5644 181 Type-P-One-to-group-Loss-Ratio: section 7, and 8 of RFC 5644 183 2.4 Points of Interest 185 The points of interest correspond to the hosts (according to the RFC 186 2330 definition, "hosts" include routing nodes), - i.e. measurement 187 collection points - which are a sub-set of the set of hosts involved in 188 the delivery of the packets (in addition to the source itself). 189 In RFC 5644 two possible scenarios concerning the points of interest 190 (the spatial one, and one-to-group) have been considered. 191 For the purpose of this memo a sort of mixed scenario, among the ones 192 shown above, is taken into account. In fact the whole set of the hosts 193 composing a multicast tree, including destinations, are points of 194 interest. An example of a very simple multicast tree, and its related 195 points of interest is depicted in Fig. 1. 197 Dst 198 /----(*)1 199 (*)----(*)2 200 / \____(*)3 201 / 202 / /--(*)4 203 Src --- (*)-- (*)--(*)5 204 \ 205 ... ...--(*)x 206 \ 207 (*)----(*)X-1 208 \____(*)X 210 Note : (*) represent the nodes that are points of interest 212 Figure 1: Points of Interest for a multicast tree 214 2.5 Multicast tree equivalent splitting 216 A generic single-source multicast tree, like the very simple one 217 depicted in Fig.2, is composed by J links, and X receivers. 219 Link 1 Link 2 Link 3 220 +--------+ +--------+ +--------+ +--------+ 221 | H1 <>--------<> H2 <>---------<> H3 <>--------<> H4 | 222 +--------+ +---<>---+ +--------+ +--------+ 223 | 224 | 225 | Link 4 +--------+ 226 +-----------------------------------<> H5 | 227 +--------+ 228 <> Interface 229 ---- Link 231 Figure 2: Example of a whole (or part of) multicast tree 233 To accomplish the task of this memo, an equivalent representation of the 234 generic single-source multicast tree is proposed, which is obtained by 235 splitting it in X different Multicast Equivalent Paths (called ME-Paths, 236 from now on), each of them corresponding to one of the X different paths 237 - as better explained below - starting from the source, and ending up 238 into one of the X receivers. 240 The generic ME-Path x is composed by the sequence of hosts, and 241 corresponding links between the source, and the receiver x. 243 As a result, the ME-Paths are different from each other because even if 244 they can partially overlap, they never do it completely. This happens 245 because each ME-Path is different from all the other ones regarding at 246 least one link, the one ending on the receiver, belonging just to one 247 ME-Path. 248 To clarify this concept, just apply the splitting method to the very 249 simple tree in Fig. 2. 251 It has only two leaves (receivers), therefore, only two different 252 ME-Paths can be derived, as shown below (Fig. 3). 254 Link 1 Link 2 Link 3 255 +--------+ +--------+ +--------+ +--------+ 256 | H1 <>--------<> H2 <>---------<> H3 <>--------<> H4 | 257 +--------+ +---<>---+ +--------+ +--------+ 259 Link 1 Link 4 260 +------+ +-------+ +-------+ 261 ME-PATH 2 | H1 <>-------<> H2 <>-------------------------<> H5 | 262 +------+ +-------+ +-------+ 264 <> Interface 265 ---- Link 267 Figure 3: single-source multicast tree equivalent splitting. 269 The ME-Path definition shown above allows possible partial overlappings 270 among some ME-Paths (e.g. ME-Path 1, and ME-Path 2 in Fig. 3). This is 271 a specific choice, as detailed hereafter in section 5.3.1. 273 The numbering of the links composing the multiparty tree is free, 274 provided that: 276 - the link numbering is unique (that is not repeated) with respect to 277 the multicast tree. 279 - even if belonging to many ME-Paths, the same link between the same 280 two hosts keeps the same name (e.g. Link 1 in both ME-Path 1, and 281 ME-Path 2 in Fig. 3) 283 2.6 Vector 285 In accordance with the definition of RFC 5644 stated in section 2, a 286 vector is a set of singletons (single atomic results) comprised of 287 observations corresponding to a packet sent from one point to another. 288 In this memo the packet is sent from one side to the other one of each 289 of the J links composing the multicast tree. For instance, if the 290 one-way loss singletons observed over J links are LL1,LL2,...,LLJ 291 (where LL stands for Link Loss) then a generic one- way loss vector V 292 with J elements can be organized as {LL1, LL2,..., LLJ}. The 293 complete vector gives information over the dimension of space, a set of 294 J links in this memo. 295 Different vectors for common measurement points of interest are 296 distinguished by the packet sending time. 298 2.7 Matrix 300 As stated in RFC 5644, several vectors form a matrix, which contains 301 results observed over a sampling interval (from T0 to TK) at different 302 places in a network at different times. 303 For instance, a one-way loss Matrix {V1,V2,...,Vk,...,VK} is formed by 304 the one-way loss vectors V1={LL11,LL21,...,LLj1, ...,LLJ1}, 305 V2={LL12,LL22,...,LLj2, ...,LLJ2},..., Vk={LL1k,LL2k,...,LLjk, 306 ...,LLJk},...,VK={LL1K,LL2K,...,LLjK, ...,LLJK} for a sample of packets 307 P1, P2,...,Pk,...PK. 308 The matrix organizes the vectors information to present network 309 performance in both space and time. 310 Each row is a set of oneway singletons spreading over the time 311 dimension, and each column is another set of One-way singletons 312 spreading over the space dimension. 313 A one-dimensional matrix (row) corresponds to a sample in simple 314 point-to-point (a link in this memo) measurement. 315 The relationship among sample, vector, and matrix is illustrated in 316 Figure 4. 318 Space 319 ^ 320 Link | /----------- Samples ------------------\ 321 | 322 1 | LL11 LL12 LL13 ... LL1k ... LL1K 323 | 324 2 | LL21 LL22 LL23 ... LL2k ... LL2K 325 | 326 3 | LL31 LL32 LL33 ... LL3k ... LL3K 327 . | . . . ... . . 328 . | . . . ... . . 329 j | LLj1 LLj2 LLj3 ... LLjk ... LLjK 330 . | . . . ... . . 331 . | . . . ... . . 332 J | LLJ1 LLJ2 LLJ3 ... LLJk ... LLJK 333 | 334 +-----+-----+-----+---...-----+----...---+----> time 335 T0 T1 T2 T3 Tk TK 336 ^ ^ 337 | | 338 Vector V2 Vector Vk 340 Figure 4: Relationship among Samples,Vectors, and Matrix. 342 3. Brief metric description 344 The metrics, and KPI defined in this memo are based on the source-to- 345 destination or end-to-end or one-to-group metrics defined by IETF in 346 [RFC2679], [RFC2680], [RFC3393], [RFC3432], and [RFC5644]. 347 The [RFC2330], and [RFC5644] framework of parameters, unit of 348 measurement, and measurement methodologies are also adopted. 350 In RFC5644 two different approaches have been considered: the spatial 351 metric approach - intended to measure the performance of each segment 352 along a path - and the multiparty one, aimed at measuring the 353 end-to-end performance between one sorce and a group of receivers. 354 To achieve the goals of this memo - enriching the current one-to-group 355 Performance metrics, and statistics also with a Service-oriented point 356 of view 357 - a mixed approach is taken into account in this memo, and a new set of 358 multiparty metrics is stated. 360 This memo defines two new metrics: 362 - Type-P-One-to-Group-Link-Packet-Loss-Vector which collects the set of 363 Type-P-One-way-Packet-Loss singletons between one side and the other 364 one of each of the links composing a multicast tree; 366 - Type-P-One-to-Group-Link-Packet-Loss-Matrix which organizes the 367 above vectors information to present network performance in both space 368 and time. 370 Based on the above mentioned new metrics, new link, and path statistics 371 are defined: 373 - Type-P-One-to-Group-Link-j-Loss-Ratio captures the overall 374 packet loss ratio for link j; 376 - Type-P-One-to-Group-Link-Loss-Ratio-Vector which collects the set of 377 Type-P-One-to-Group-Link-j-Loss-Ratios of each of the links composing 378 a multicast tree; 380 - Type-P-One-to-Group-Link-j-Weighted-Loss-Ratio captures the overall 381 Weighed packet loss ratio for link j; 383 - Type-P-One-to-Group-Link-Weighted-Loss-Vector which collects the set 384 of Type-P-One-to-Group-Link-j-Weighted-Loss-Ratios of each of the links 385 composing a multicast tree. Since this is a very important vector, in 386 this memo it is also referred to as the Reference Vector; 388 - Type-P-One-to-Group-MEPath-x-Loss-Vector which collects a subset of 389 Type-P-One-to-Group-Link-Weighted-Loss-Vector elements, which are 390 only those corresponding to the links belonging to the generic MEpath x. 392 Finally, based on the statistics shown above, a new overall performance 393 metrics composition/aggregation framework is defined: 395 - Type-P-One-to-Group-MEPath-x-Loss-Ratio is a user definable metric 396 composition/aggregation function applied to the set of Type-P-One-to- 397 group-Link-j-Loss-Ratios associated to the links belonging to the 398 generic ME-Path x; 400 - Type-P-One-to-Group-KPI-Loss-Ratio is a user definable metric 401 composition/aggregation function applied to all Type-P-One-to-group- 402 Path-x-Loss-Ratios of the ME-Paths composing the multiparty tree. 404 4. One-to-Group Link Metrics definition 406 This section defines vectors, and matrix for a one-to-group topology 407 using loss singleton over the J links composing the multicast tree. 409 4.1. Type-P-One-to-Group-Link-Packet-Loss-Vector 411 Each element of the vector defined in section 2 of this memo represents 412 a loss singleton over one of the J links composing the multicast tree. 413 Thus the number of elements composing the whole vector equals the number 414 of links (that is J) composing the whole multiparty tree. 415 The generic Type-P-One-to-Group-Link-Packet-Loss-Vector for a packet 416 sent at time Tk can be represented as: 418 Vk = 420 where j=1,2, ..., J , and LLj is the loss singleton over link j. 422 4.2. Type-P-One-to-Group-Link-Packet-Loss-Matrix 424 Composing the J vectors shown above, as described in section 2, a 425 Type-P-One-to-Group-Link-Packet-Loss-Matrix can be built as shown in 426 the following Fig. 5. 428 space 429 ^ 430 Link | /----------- Samples ----------\ Stats 431 | 432 1 | LL11 LL12 ... LL1k ... LL1K LL1LR 433 | 434 2 | LL21 LL22 ... LL2k ... LL2K LL2LR 435 | 436 3 | LL31 LL32 ... LL3k ... LL3K LL3LR 437 . | . . ... . . . 438 . | . . ... . . . 439 j | LLj1 LLj2 ... LLjk ... LLjK LLjLR <-- Link-j Loss Ratio 440 . | . . ... . . . 441 . | . . ... . . . 442 J | LLJ1 LLJ2 ... LLJk ... LLJK LLJLR 443 | 444 +---+-----+----...----+----...--+-->time ^ 445 T0 T1 T2 Tk TK | 446 ^ | 447 | | 448 Vector Vk Link Loss Ratio Vector 450 Figure 5: Type-P-One-to-Group-Link-Packet-Loss-Matrix J*K 452 From the considerations stated above it can be derived that the number 453 of rows composing the matrix equals the number of links (that is J) 454 composing the whole multicast tree. 456 All loss ratios are expressed in units of packets lost to total packets 457 sent. Statistics are computed on the sample of 458 Type-P-One-way-Packet-Loss[RFC2680] of the above matrix. 460 Based on the one-to-group vector metrics listed above, statistics are 461 defined below, so to capture single link performance, ME-Path 462 performance, and group performance, and the relative performance for a 463 multiparty communication. 465 5. One-to-Group Link and Path Statistics 467 Starting from the above metrics definition, this section defines link, 468 and path statistics for a one-to-group topology. 470 5.1. Type-P-One-to-Group-Link-j-Loss-Ratio 472 Given the Type-P-One-to-Group-Link-Packet-Loss-Matrix depicted in Fig. 473 5, and according to the definitions, and method of [RFC2680], a Type-P- 474 One-way-Packet-Loss-Average for the sample at each of the J links can be 475 determined, and named Type-P-One-to-group-Link-j-Loss-Ratio, also 476 called LLjLR. 477 It can be expressed as 479 K 480 ------ 481 1 \ 482 LLjLR = - * > LLjk 483 K / 484 ------ 485 k = 1 487 Figure 6: Type-P-One-to-group-Link-j-Loss-Ratio for Link j. 489 5.2. Type-P-One-to-Group-Link-Loss-Ratio-Vector 491 The Type-P-One-to-Group-Link-Loss-Vector collects all the Type-P-One- 492 to-group-Link-j-Loss-Ratios computed on the J links composing the 493 multicast tree. 494 An example of Type-P-One-to-Group-Link-Loss-Vector is depicted in Fig. 495 3. 497 5.3. Discussion about the Weighing Factor 499 The purpose of this memo is to enrich the current Performance metrics - 500 mainly derived from a Network-oriented point of view, and therefore a 501 general perspective, which is not focused on specific services - with 502 some more Performance factors, so to include a Service-oriented point 503 of view as well, more centred on: 505 - the specificity of the service or services to be monitored, with their 506 own protocols, applications (i.e. coding), and management (i.e. QOS, 507 fragmentation management) characteristics. 509 - the kind of network topology over which the service or services to be 510 monitored are implemented (i.e. redundancy, tunneling, etc.). 512 To accomplish this task a weighing factor Wj, related to the 513 corresponding Link j, is introduced. Thus each Type-P-One-to-group- 514 Link-j-Loss-Ratio is weighed through its own specific Wj. 515 Since this memo introduces a framework for performance metrics, the 516 characterization of Wj is user definable, and up to the service 517 provider, depending on many factors he has to manage. 518 Some, but not all, of the possible network, and/or service factors that 519 can be taken into account while characterizing Wj are: number of 520 multicast flows over link j, bandwith, capacity (any possible type: 521 total, available, etc.) of link j,its redundancy, traffic flowing 522 through link j, type of service to be monitored over the link, 523 location of the link with respect to the whole topology, and so on. 525 5.3.1 Discussion about the Overlapping Factor 527 While characterizing each Wj - the so called Overlapping Factor - is 528 worthy of a special remark. 529 As discussed in section 2, ME-Paths can partially overlap, thus 530 sharing one or more links (e.g. Link 1 in Fig. 2). As a result, a 531 generic Link j can belong to more than one ME-Path. A consequence of 532 this fact is that the more the ME-Paths the generic Link j belongs to, 533 the more a packet loss over that link impacts the service it conveys. 534 For instance, even if the same packet loss is detected both over a link 535 coming out from the root (source) of a multicast tree, and over a link 536 ending on a receiver, the impact on the service is dramatically 537 different in the two cases. 538 As a consequence, the Overlapping Factor MUST be taken into account 539 while characterizing each Wj. 540 Considering this, a question arises: how to expressly include it in the 541 Wj characterization, since the ME-Paths overlappings are dynamically 542 varying, following the dynamic topology changes of the multicast tree. 543 A possible way to solve this problem is to take the Overlapping Factor 544 into account just implicitly, while calculating the final 545 Type-P-One-to-Group-KPI-Loss-Ratio, as hereafter deepened. 547 5.4. Type-P-One-to-Group-Link-j-Weighted-Loss-Ratio 549 Based on the above discussion, a new entity is introduced: the Type-P- 550 One-to-group-Link-j-Weighted-Loss-Ratio (LLjWLR), defined as: 552 LLjWLR = LLjLR * Wj 554 Note that if Wj is set to 1, thus the weighing factor is not taken into 555 consideration for link j. 557 5.5. Type-P-One-to-Group-Link-Weighted-Loss-Vector 559 A new kind of loss vector is introduced, the Type-P-One-to-Group-Link- 560 Weighted-Loss-Vector (Fig. 7). 561 It collects all the Type-P-One-to-group-Link-j-Weighted-Loss-Ratios of 562 each of the links composing a multicast tree. 564 / LL1LR * W1 \ / LL1WLR \ 565 | LL2LR * W2 | | LL2WLR | 566 | LL3LR * W3 | | LL3WLR | 567 | LL4LR * W4 | ---> | LL4WLR | 568 | . | | . | 569 | . | | . | 570 | LLjLR * Wj | | LLjWLR | 571 | . | | . | 572 | . | | . | 573 \ LLJLR * WJ / \ LLJWLR / 575 Fig. 7. Type-P-One-to-Group-Link-Weighted-Loss-Vector 577 Type-P-One-to-Group-Link-Weighted-Loss-Vector is hereafter considered 578 the Reference Vector for the definition of the next statistics, and KPI 579 definitions. 581 5.6. Type-P-One-to-Group-MEPath-x-Loss-Vector 583 This section defines the overall one-way loss statistics for an ME-Path 584 (as defined above). 585 Starting from the Reference vector (the above Type-P-One-to-Group- 586 Link-Weighted-Loss-Vector), and given the X possible ME-Paths 587 generated after the multicast tree splitting described in section 2, X 588 different Type-P-One-to-Group-MEPath-x-Loss-Vectors are created, each 589 of them composed by a subset of the whole set of the Reference Vector 590 elements (LLjWLR), in other words, only by those elements LLjWLR 591 associated to the links composing ME-Path x. 592 A clarifying example can be given applying the concepts shown above to 593 ME-Path 1, and 2 in Fig. 3. 594 For ME-Path 1: 595 /LL1WLR \ 596 Type-P-One-to-Group-MEPath-1-Loss-Vector = | LL2WLR | 597 \LL3WLR / 599 while for ME-Path 2: 600 /LL1WLR \ 601 Type-P-One-to-Group-MEPath-2-Loss-Vector = \LL4WLR / 603 The number of elements composing the generic Type-P-One-to-Group- 604 MEPath-x-Loss-Vector equals the number of links composing the ME- 605 Path x it derives from. 606 Note that since all ME-Paths are different from each other - at least 607 for one link - as a result of this, all 608 Type-P-One-to-Group-MEPath-x-Loss-Vectors are different from each other 609 as well. 611 6. One-to-Group Overall Packet Loss Statistics 613 Starting from the link, and path statistics definition stated above, 614 this section defines the overall statistics for a one-to-group topology. 616 6.1. Type-P-One-to-Group-MEPath-x-Loss-Ratio 618 The current network oriented point of view states that the 619 calculation of the Packet Loss Ratio over a path is based on the 620 Packet Loss Ratio detected over each of the links belonging to the path, 621 applying the usual spatial composition formula: 623 Path Packet Loss Ratio = 1 - [(1-L1LR) * (1-L2LR) * ... *(1-LnLR)] 625 where LnLR represents the Packet Loss Ratio detected over the generic 626 link n belonging to the path. 628 However, due to the growing interest in enriching the current 629 performance metrics with a service oriented point of view as well, the 630 purpose of this memo is to propose a new framework for performance 631 metric composition/aggregation. 632 Thus a new definition of an equivalent PLR over a generic ME-Path x is 633 given: 635 Type-P-One-to-Group-Path-x-Loss-Ratio= Fa (Type-P-One-to-Group- 636 MEPath-x-Loss-Vector) 638 where Fa is a user definable metric composition/aggregation function 639 applied to the set of Type-P-One-to-group-Link-j-Loss-Ratios associated 640 to the links belonging to the generic ME-Path x. 642 A very common example of Fa is the usual spatial composition formula 643 mentioned above. 645 6.2 Type-P-One-to-Group-KPI-Loss-Ratio 647 This section defines the overall one-way network-service KPI (Key 648 Performance Indicator) for a multicast tree loss statistics. 650 Type-P-One-to-Group-KPI-Loss-Ratio = Fb (Type-P-One-to-Group-Path- 651 1-Loss-Ratio, Type-P-One-to-Group-Path-2-Loss-Ratio, ..., Type-P-One- 652 to-Group-Path-X-Loss-Ratio) 654 where Fb is a user definable metric composition/aggregation function 655 applied to all Type-P-One-to-group-Path-x-Loss-Ratios of the ME-Paths 656 composing the multiparty tree. 658 Each service provider defines his own Fb, based on the topology of his 659 network, on the way the monitored service is implemented, on the 660 specific SLAs associated with the monitored service, and so on. 661 A very common example of Fb is the average function among all the 662 Type-P-One-to-group-Path-x-Loss-Ratios. Other possibilities are the 663 maximum value, the minimum value, the range, and so on. 664 Please point out that the Overlapping Factor described in section 665 5.3.1 is here taken into account, even if implicitly. In fact all the 666 paths are now considered, regardless of the presence of overlapping 667 links in the paths. 669 7. Extended applications 671 7.1. Extended applications to multi-source one-to-group topology 673 All the above discussion is applicable both to a single-source 674 one-to-group topology, and to a multi-source one-to-group topology. 675 In fact, given one single group flowing from several sources - thus 676 different from several groups flowing from several sources, that is a 677 group-to group topology - each host chooses just one, and only one 678 source at a time from which the flow is accepted, thus leading 679 us back to the single-source one-to-group situation already dealt with 680 in this memo. 682 7.2. Extended applications to One-way Delay and Delay Variation 684 The framework proposed in this memo is wide enough to be applicable not 685 only to the Packet Loss analysis, but also to the One-way Delay, and 686 Delay Variation ones. 687 This goal is achievable by adequately defining Fa, Fb, and Wj. 688 Anyway, this is out of the scope of this memo, and it will be deepened 689 in another memo. 691 8. Security Considerations 693 Spatial, and one-to-group metrics are defined on the top of end-to-end 694 metrics. Security considerations discussed in the one-way delay 695 metrics definitions of [RFC2679], in packet loss metrics definitions 696 of [RFC2680], and in IPDV metrics definitions of [RFC3393], and 697 [RFC3432] apply to metrics defined in this memo. 698 Someone may spoof the identity of a point of interest identity, and 699 intentionally send corrupt results in order to remotely orient the 700 traffic engineering decisions. 701 A point of interest could intentionally corrupt its results in order 702 to remotely orient the traffic engineering decisions. 704 8.1. One-to-Group Metrics 706 Reporting of measurement results from a huge number of probes may 707 overload reference point resources (network, network interfaces, 708 computation capacities, etc.). 709 The configuration of a measurement must take into consideration that 710 implicitly more packets will be routed than sent and select a test 711 packet rate accordingly. Collecting statistics from a huge number of 712 probes may overload any combination of the network to which the 713 measurement controller is attached, measurement controller network 714 interfaces, and measurement controller computation capacities. 715 One-to-group metric measurements should consider using source 716 authentication protocols, standardized in the MSEC group, to avoid 717 fraud packet in the sampling interval. The test packet rate could be 718 negotiated before any measurement session to avoid denial-of-service 719 attacks. 720 A point of interest could intentionally degrade its results in order 721 to remotely increase the quality of the network on the branches of 722 the multicast tree to which it is connected. 724 9. References 726 9.1. Normative References 728 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate 729 Requirement Levels, BCP 14, RFC 2119, March 1997. 731 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, A One-way 732 Delay Metric for IPPM, RFC 2679, September 1999. 734 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, A One-way 735 Packet Loss Metric for IPPM, RFC 2680, September 1999. 737 [RFC3393] Demichelis, C., and P. Chimento, IP Packet Delay Variation 738 Metric for IP Performance Metrics (IPPM), RFC 3393, 739 November 2002. 741 [RFC5644] Stephan, E., Liang L., Morton A., IP Performance Metrics 742 (IPPM): Spatial and Multicast, RFC5644, October 2009. 744 [RFC6390] Clark, A., Guidelines for Considering New Performance Metric 745 Development, BCP170, RFC6390, October 2011. 747 9.2. Informative References 749 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 750 Framework for IP Performance Metrics, RFC 2330, 751 May 1998. 753 [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, Network 754 performance measurement with periodic streams, RFC 3432, 755 November 2002. 757 [RFC5835] Morton, A., Van den Berghe, S., Framework for metric 758 composition, RFC5835, April 2010. 760 10. Acknowledgments 762 A special thank to Daniela, Irene and Elisa for their creative support. 763 The author would like to thank his workmates A. Barbetti, A. Cappadona 764 and S. Mariani for their helpful support while designing the main ideas 765 behind this memo. 766 I also acknowledge the precious comments and suggestions from Al Morton. 768 Author Address 770 Tiziano Ionta (editor) 771 Telecom Italia Labs 772 Via Valcannuta 250 773 00167 Rome 774 Italy 776 Phone: +39 06 3688 5600 777 Email: tiziano.ionta@telecomitalia.it